Static SSH keys are a quiet compliance disaster. They live on laptops, get committed to git, get shared via Slack, and never rotate. Innovexus brokers ephemeral credentials per session through a per-tenant pod — engineers never hold the keys, the keys expire when the session ends, and there is nothing to "rotate" because nothing persists.
Every team starts with a few `~/.ssh/id_rsa` files. By the time the team is 20 engineers and 200 hosts, the keys have multiplied, ownership is unclear, and rotation is a multi-quarter project that nobody owns. The honest version of why this happens.
Engineers copy private keys to laptops, dev VMs, build servers, and the occasional Lambda. There is no inventory because nobody can scan every machine in the fleet. The first time you try, you find keys you did not know existed — including some that auditors will find first.
When an engineer leaves, removing their key from every host's `~/.ssh/authorized_keys` is a manual sweep. Most teams skip it because there is no clean tooling. Departed engineers retain access for months — sometimes years.
Rotating a single shared key across the fleet means generating a new key, distributing it, swapping authorized_keys everywhere, verifying nothing broke, then revoking the old. Most teams do this once when something forces them to, then never again.
SOC 2 CC6.1, ISO 27001 A.9.4.3, PCI DSS 8.3.10, and NIST SP 800-63B all expect privileged credentials to be rotated on a defined schedule. "We don't rotate SSH keys" is increasingly a finding rather than an accepted practice.
Innovexus eliminates the rotation problem by removing persistent credentials from the engineer side entirely. The vault holds the device's actual credentials. The pod brokers each session by generating short-lived authentication material. When the session ends, the auth material is invalid. There is no key on a laptop, no `authorized_keys` for an individual engineer, and no "rotation" because nothing persists.
Engineers authenticate to Innovexus with a FIDO2 hardware key (YubiKey or equivalent). They never see, copy, or possess an SSH private key for the target devices. Lost laptop = no compromise; the laptop never had keys to lose.
When an authorised engineer opens a session to a target device, the per-tenant pod generates short-lived authentication material (ephemeral SSH cert or short-TTL key, depending on target type), injects it into the session, and discards it on session close. Each session is its own credential.
The actual device-side credentials (the local admin password, the SSH key on `authorized_keys`, the TACACS+ shared key) live in the AES-256 vault. Rotation runs automatically on a schedule — every 24 hours by default — and happens during the credential broker exchange, invisible to engineers.
On Linux hosts, the pod's SSH certificate authority signs short-lived certs that the host accepts via `TrustedUserCAKeys`. There is one trust anchor — the pod's CA — instead of N keys per N engineers. Removing an engineer means revoking their hardware key in the IdP, not editing `authorized_keys` everywhere.
Every credential vault access, every ephemeral cert issuance, and every session start/end is in the signed audit log. Auditors get one log to search, not three (vault, IdP, host syslog) plus a manual correlation.
Most teams have ephemeral SSH access running across their fleet within 1–2 days. Here's the actual sequence.
Sign up, dedicated per-tenant pod provisions in your chosen region, outbound IP allowlisted on your target SSH hosts. The pod is the only authorised source for SSH connections going forward.
For Linux hosts: add the pod's public CA as `TrustedUserCAKeys` in `sshd_config`. For network devices: vault the local admin credential or the existing SSH key. For bastion hosts: configure the bastion to allowlist only the pod's IP.
SAML/OIDC integration with your IdP (Okta, Azure AD, JumpCloud). FIDO2 hardware keys enrolled at the platform login. Roles map to which devices an engineer can reach — the pod enforces this before issuing the ephemeral cert.
Engineers log into Innovexus with their hardware key, see only the hosts their role permits, click into a session. The pod generates an ephemeral cert (typically 5–15 minute TTL), authenticates to the host, and streams the session.
For network devices and any non-cert-based hosts, the vault rotates the device-side credential on schedule (default 24 hours). Engineers don't see the rotation; their next session uses the new credential automatically.
There are several established ways to manage SSH key lifecycle. Each has tradeoffs. Honest read on where Innovexus fits.
OpenSSH has supported certificate-based authentication since 5.4. Building your own CA, integrating with your IdP, and operating short-lived certs is achievable and many teams do it. Trade-off: you own the operational burden — CA key custody, signing service availability, audit, monitoring. Innovexus uses this same OpenSSH CA mechanism but operates the CA for you and adds NOC/SOC tooling alongside.
Vault's SSH secrets engine is feature-complete for ephemeral SSH cert issuance. Trade-off: Vault itself is a substantial operational commitment — HA setup, unsealing, audit storage, version upgrades. Vault is the right tool when you need a general-purpose secret manager for many use cases beyond SSH; Innovexus is purpose-built for the privileged-access subset.
Teleport (Gravitational) and HashiCorp Boundary both address ephemeral access for engineers. Both are strong, both have per-user pricing models that scale with team size. Innovexus is closer in pricing structure (flat tier) and adds the NOC and SOC workspaces alongside. If your team is access-only and per-user pricing fits, Teleport is a credible alternative.
Cron jobs that scrape `authorized_keys` and replace keys quarterly are a real pattern at small companies. They work until something breaks during rotation, the script's run history is unclear, or the auditor asks for a date-specific evidence bundle. Manual rotation is the worst possible state at any scale beyond ~10 hosts.
Direct answers — written so each passage stands alone for AI-engine citation.
No, but the value comes from doing so. During trial you can use Innovexus alongside existing key-based access. The full benefit shows up when you stop using static keys and rely entirely on ephemeral certs brokered through the pod. Migration is incremental: enable cert-based auth on a subset of hosts, validate engineers can reach them, expand. Most teams complete the migration over 2–4 weeks for a 100–500 host fleet.
You don't. Two break-glass mechanisms: (1) Each host retains a vaulted local credential that can be retrieved through the Innovexus emergency-access workflow even if SSH is degraded. (2) You can keep one or two static "emergency" SSH keys held in offline storage for genuine disaster recovery — many teams do. The point of Innovexus is to eliminate the day-to-day reliance on static keys, not to remove every fallback.
Yes for network devices (IOS, NX-OS, IOS-XR, Juniper, Arista, FortiGate, Palo Alto — anything taking SSH or Telnet); the vault holds the device-side credential and rotates it on schedule. Windows targets (RDP) work via the same broker model. Mainframe access via TN3270 or SSH-wrapped sessions is supported on the Enterprise tier. The ephemeral cert path is Linux-specific because it depends on OpenSSH `TrustedUserCAKeys`; everything else uses the rotating vaulted credential model.
Default TTL is 15 minutes for human SSH sessions, configurable from 5 minutes to 24 hours per role. Service accounts that need longer-lived auth can be configured separately. Most teams settle on 15-minute TTL for engineer access — short enough that a leaked cert is materially limited, long enough that a single session does not hit the boundary.
Innovexus emits a single signed audit log per session: who authenticated (FIDO2 hardware key), when, which device, what cert was issued, when the session started and ended. For SOC 2 CC6.1 / CC6.6, that's the evidence the auditor wants. For PCI DSS 8.3.10 ("change passwords/passphrases at least once every 90 days") the vault-rotation schedule satisfies this for vaulted credentials; for cert-based auth the rotation isn't the right metric — TTL is, and the signed log demonstrates short-lived issuance. We provide pre-built export templates for each framework.
Vault is a general-purpose secret management platform — strong at SSH secrets, also at database creds, cloud creds, PKI, transit encryption, and many other use cases. Innovexus is purpose-built for the privileged-access workflow specifically: SSH/RDP/console sessions, network device PAM, NOC and SOC bundled. If your need is "general secret management across every secret type," Vault is the right pick. If your need is "rotate creds and broker sessions to my fleet with a usable engineer UX and audit," Innovexus is the closer fit. Many teams run both — Vault for application secrets, Innovexus for human privileged access.
Provision a pod, configure SSH CA trust on a subset of hosts, point engineers at it. Static keys can come out of the fleet in weeks instead of quarters.