Should organisations use SSH certificates instead of long-lived keys?

Yes, when they can support the operational model. SSH certificates reduce standing access, simplify revocation, and make expiration a built-in control rather than a manual cleanup task. That gives security teams a cleaner governance model for NHI access because the credential itself carries scope and lifetime limits.

Why This Matters for Security Teams

Long-lived ssh keys create standing access, weak revocation discipline, and a persistent audit gap that becomes harder to justify as infrastructure becomes more ephemeral. SSH certificates fit better when teams need time-bound access, clearer ownership, and faster deprovisioning, which is why they align well with Zero Trust thinking and modern NHI governance. NIST’s NIST Cybersecurity Framework 2.0 places strong emphasis on identity, access control, and governance outcomes rather than static credential habits.

This matters because SSH is often used for privileged operational access, and privileged access that never expires tends to outlive the business need behind it. NHIMG research shows how quickly machine identity risk scales: in the Ultimate Guide to NHIs — What are Non-Human Identities, only 5.7% of organisations report full visibility into service accounts, and 71% of NHIs are not rotated within recommended time frames. Those conditions make certificate-based access attractive because the lifecycle is built into the credential, not left to memory or spreadsheets.

In practice, many security teams only discover the cost of long-lived keys after a dormant key is still valid during a routine audit or, worse, after an incident has already spread through admin access.

How It Works in Practice

SSH certificates replace a static public key trust model with a signed credential that carries identity, role, and expiration metadata. A user or workload presents a key pair, but the trusted authority issues a short-lived certificate that says what the holder may do and for how long. That makes revocation less about hunting down every copied key and more about limiting the certificate authority, shortening TTLs, and tightening issuance policy.

For most environments, the practical model is: authenticate the requester, issue a certificate only when the request is justified, and make the certificate expire quickly enough that reuse becomes unhelpful. That is consistent with broader NHI guidance and with the idea of dynamic secrets described in Ultimate Guide to NHIs — Static vs Dynamic Secrets. The operational value is strongest where access needs are temporary, scoped, and reviewable. It also reduces the burden of offboarding, because the credential’s usefulness ends automatically instead of relying on a cleanup task.

• Use short TTLs so the certificate expires before it becomes a standing credential.
• Bind issuance to a trusted identity source and a clear approval or policy check.
• Separate user access, service access, and break-glass access so each has different controls.
• Log issuance, use, and expiry to support incident review and compliance evidence.
• Treat the signing authority as a high-value control plane asset and protect it accordingly.

NGHIM research on the Sisense breach is a reminder that credential exposure and weak lifecycle control can turn routine access into a broad compromise. Current guidance suggests SSH certificates are most effective when paired with PAM, enforced expiry, and policy-driven issuance rather than used as a simple drop-in replacement for keys. These controls tend to break down in highly distributed environments with many unmanaged jump paths because certificate authority sprawl and inconsistent host trust make enforcement uneven.

Common Variations and Edge Cases

Tighter certificate-based access often increases operational overhead, requiring organisations to balance stronger lifecycle control against certificate infrastructure, policy maintenance, and user experience. There is no universal standard for every SSH environment yet, so the right answer depends on how centralised the access model is and how much automation the team can sustain.

One common variation is using SSH certificates only for privileged human access while leaving some service-to-service paths on managed machine identities. Another is combining certificates with JIT access workflows so the certificate is issued only after approval and then revoked by expiry rather than manual cleanup. In mature environments, this can support ZT and RBAC objectives, but RBAC alone is not enough if certificates remain valid too long or if issuance policy is too broad.

Edge cases matter. Air-gapped systems, legacy appliances, and vendor-managed hosts often cannot support the same certificate lifecycle discipline as modern Linux fleets. In those cases, current guidance suggests keeping long-lived keys only where necessary, wrapping them in stronger controls, and documenting an explicit exception with a retirement plan. For agentic or highly automated workloads, the question becomes even more sensitive because workloads can behave unpredictably and request access at runtime; that is where policy evaluation and short-lived credentials matter most. Organisations that want a broader NHI governance baseline can map this decision back to the Ultimate Guide to NHIs — What are Non-Human Identities and the NIST Cybersecurity Framework 2.0.

Related resources from NHI Mgmt Group

• Should organisations prioritize short-lived certificates before replacing VPNs and bastions?
• When should organisations use AI to help manage NHIs?
• How can organisations govern AI agents that use service accounts and tokens?
• How can organisations reduce the risk of stale API keys and machine tokens?