How should teams migrate away from long-lived SSH keys to short-lived certificate-based access at scale?

Why Migrating SSH Access Matters for Security Teams

Long-lived SSH keys create the same problem across hundreds or thousands of systems: durable trust that is hard to see, hard to revoke, and easy to copy. Moving to certificate-based access reduces standing access and lets teams expire trust automatically instead of chasing stale keys after staff changes, contractor exits, or host rebuilds. It also makes access reviews more realistic because the authority to connect is issued centrally rather than hidden in unmanaged key files. The challenge is not just security hygiene. At scale, key sprawl becomes an operational drag, and manual cleanup quickly falls behind the pace of infrastructure change. NHI Management Group’s research shows only 38% of organisations have automated certificate lifecycle management in place, which explains why expiry-driven outages remain common.

That gap matters because SSH access often sits outside normal identity workflows, yet it still reaches production systems. Guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group’s Ultimate Guide to NHIs both point to the same issue: static credentials expand blast radius faster than teams can govern them. In practice, many security teams discover SSH sprawl only after an offboarding miss, a lost laptop, or a key-based lateral movement path has already been used.

How Certificate-Based SSH Access Works in Practice

The migration usually starts by putting a certificate authority between users and hosts. Instead of distributing a private key that works for months or years, the user or automation job authenticates to a trusted issuer, receives a short-lived SSH certificate, and presents that certificate to the target host. The host trusts the CA public key, validates the certificate, and checks the embedded identity, principals, and expiry time. That changes the control point from file distribution to runtime issuance.

Teams usually get the best results when they treat SSH certificates as part of a broader identity pipeline:

• Use a central issuer for human users and separate issuers for automation where needed.
• Keep certificate lifetimes short enough that revocation becomes less important than expiry.
• Bind certificates to named principals, not broad wildcard access.
• Log issuance, use, and expiry events so access can be reviewed by team, host group, and purpose.
• Prefer ephemeral credentials over long-lived shared keys for build systems and operational jobs.

This approach aligns with the NIST SP 800-53 Rev 5 Security and Privacy Controls emphasis on access enforcement and with NHIMG’s static vs dynamic secrets guidance, which highlights why short-lived trust is materially safer than reusable credentials. For scaling, the real work is operational: integrate issuance into SSO or workload identity, automate certificate renewal, and make host-side trust in the CA consistent across every environment. These controls tend to break down when legacy hosts cannot validate certificates consistently because teams then fall back to parallel static-key paths.

Common Migration Pitfalls and Where the Model Breaks Down

Tighter SSH control often increases operational overhead at first, requiring organisations to balance stronger access governance against host diversity and legacy tooling. The most common mistake is to replace one static model with another: a long-lived CA signing key, a manual approval queue, or certificates that last too long to matter. Current guidance suggests that short TTLs work best when issuance is automated and host trust is pre-provisioned; there is no universal standard for certificate lifetime yet, so teams should choose expiry based on their change rate and response capacity.

Edge cases usually appear in mixed estates. Older appliances may not support certificate validation, some break-glass workflows need temporary exceptions, and administrative SSH for incident response may require separate policy from routine access. Those exceptions should be explicit, time-bound, and audited, not informal workarounds. The risk is especially high when certificate issuance is tied to shared accounts or when one CA serves too many unrelated environments, because compromise of the issuer becomes a central failure point. NHI Management Group’s Why NHI Security Matters Now and Key Challenges and Risks research both reflect the same operational truth: visibility improves only when issuance, expiry, and revocation are built into the control plane rather than layered on as afterthoughts.

Related resources from NHI Mgmt Group

• Why do long-lived SSH keys and password logins increase access risk on Ubuntu servers?
• How should security teams replace static SSH keys with short-lived access controls?
• Why do long-lived API keys create more risk than scoped OAuth 2.0 client credentials for machine-to-machine access?
• How should security teams phase out password-based SSH access in Linux environments?