Security teams should use certificate-based SSH access with a defined grace period so old and new credentials can coexist briefly during rotation. That approach reduces dependence on long-lived keys, limits administrative drag, and makes frequent renewal practical. The control only works well if reauthentication is automatic where possible and the rotation process is safe to run regularly.
Why certificate-based SSH needs an overlap period
SSH certificate rotation fails when teams treat replacement as a hard cutover instead of a controlled handoff. A short overlap window lets existing sessions continue, gives automation time to refresh credentials, and avoids outages caused by clients, bastions, or pipelines that have not yet picked up the new certificate.
That design is especially important when certificate issuance is automated and frequent. If old and new credentials cannot coexist briefly, operators tend to keep certificates alive too long or slow down rotation altogether, which weakens the security benefit of moving away from static SSH keys.
For teams standardising SSH certificate operations, the SSH Key and SSH Certificate Management Guide is the most direct internal reference for governing rotation, bastions, and orphaned keys. The broader lifecycle view in NHI Lifecycle Management Guide is useful when SSH is one part of a larger credential estate that must be provisioned, rotated, and retired consistently.
What makes the rotation process safe to run repeatedly?
The safe pattern is to make certificate issuance predictable, short-lived, and reversible in the operational sense. That means the new certificate should be available before the old one is withdrawn, hosts should accept both during the grace period, and the process should be routine enough that teams trust it rather than delaying it until a maintenance window.
Reauthentication matters because some SSH estates still rely on long-lived sessions, cached credentials, or manual operator steps. Where possible, the renewal flow should refresh credentials automatically so the human operator is not the control plane. The less the process depends on people remembering a timed handoff, the less likely it is to drift into stale access or emergency exceptions.
Certificate lifecycle guidance in Machine Identity, PKI and Certificate Lifecycle Guide helps explain why overlap periods work for certificate-based access in general. For SSH specifically, NHI Authentication Guide is useful because SSH certificates are one of several ways non-human access can authenticate without relying on static secrets.
How should teams structure SSH access to avoid certificate expiry surprises?
Teams should make the certificate itself carry the operational intent: clear validity periods, constrained scope, and a renewal path that is simple enough to automate. When the certificate is short-lived, expiry becomes a normal event instead of an outage trigger, but only if hosts, jump boxes, and automation are all prepared to trust the replacement before the old object disappears.
It also helps to separate access policy from individual human memory. If the SSH certificate is tied to a defined role or workload, then rotation becomes a repeatable control rather than a ticket-driven exception. That is the practical difference between a managed certificate system and a pile of manually refreshed keys.
For implementation detail, Guide to SPIFFE and SPIRE is a good pattern reference for short-lived, attested identity material, even when the deployment is not using SPIFFE directly. If your team also wants a view of the failure modes behind rotation at scale, Guide to NHI Rotation Challenges covers the operational friction that appears once rotation becomes frequent rather than occasional.
Risk and Threat Considerations
SSH rotation becomes risky when organisations confuse grace with indefinite dual validity. If overlap periods are too long, old certificates remain usable after the intended cutover, which expands the window for misuse and weakens the value of frequent renewal. If the window is too short, teams create outage pressure and may keep certificates alive longer than planned.
Failure mechanism: Delayed propagation, manual reauthentication steps, or brittle automation can leave one side of the environment trusting the old certificate while the other side has already moved on, producing either access loss or lingering unauthorized access.
Impact: The result is usually operational disruption first, then security drift, because teams under pressure tend to extend lifetimes, reuse credentials, or bypass the rotation process altogether.
The same failure pattern is visible in broader credential and certificate incidents, including the Sisense breach, where exposed access material amplified downstream risk. For certificate governance, the underlying issue is not the certificate format itself, but whether lifecycle discipline is strong enough to keep access current without creating an availability exception.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH certificate rotation depends on controlled credential lifecycle and renewal. |
| IA-9 — Service Identification and Authentication | SSH certificates authenticate systems and automated access paths, not just users. | |
| Recommendation — Set defined lifetimes and automate renewal and revocation for SSH authenticators. Use certificate-based authentication for machine and service SSH access. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | SSH certificate rotation is an identity lifecycle and ownership problem. |
| A.5.17 — Authentication information | SSH certificates and related keys are authentication material that must be protected and renewed. | |
| Recommendation — Assign clear ownership for SSH certificate issuance, renewal, and retirement. Protect SSH authentication material and rotate it on a defined schedule. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The question is about replacing long-lived SSH keys with shorter-lived certificates. |
| Recommendation — Reduce SSH exposure by enforcing short-lived credentials and frequent rotation. | ||
Practitioner Guidance
What to verify: Confirm that every SSH trust path, including bastions, automation runners, and administrative jump hosts, accepts the replacement certificate before the old one is retired. If any path still depends on a manual login step, treat that path as the likely source of rotation failure.
Decision rule: If the certificate can authenticate to production systems, keep overlap short and explicit, and design the rotation job so it can be rerun safely. If the process cannot be rerun without operator intervention, it is not ready for frequent renewal.
What good looks like: New certificates appear automatically, old ones age out predictably, and operators do not need a special change window just to keep SSH access working. The control is working when rotation is boring.
Practitioner takeaway: The goal is not merely to replace SSH keys with certificates, it is to make credential turnover operationally routine so security can shorten lifetimes without forcing teams to choose between continuity and control.
Related resources from NHI Mgmt Group
- How should NHS security teams reduce privileged access risk without disrupting clinical operations?
- How should security teams run ransomware simulations so they test real defenses without disrupting operations?
- How should security teams protect MDM systems from privileged access abuse without disrupting device management operations?
- How should security teams centralise infrastructure access controls for FedRAMP without disrupting engineering operations?
