SSH key management is now a lifecycle governance problem

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: SSH key management has become a lifecycle governance problem because manual key handling creates sprawl, weak revocation, and lingering privileged access.

Why it matters: It matters because SSH keys often underpin administrator and automation access, so IAM and PAM teams need lifecycle controls that match the way machine identities persist and accumulate risk.

Context

SSH keys are a machine identity control for remote administration, file transfer, and automated workflows. They can be safer than passwords, but they do not expire by default, and that creates a governance gap when organisations treat them as static credentials rather than managed identities.

The article argues that this gap shows up in decentralised storage, limited visibility, and manual rotation or revocation. For IAM, PAM, and NHI programmes, the question is not whether SSH works, but whether key issuance, usage, and retirement are governed as a lifecycle.

In practice, the starting point is typical: many enterprises still depend on manual discovery and ad hoc revocation. That is now an unsustainable baseline in cloud-heavy environments with privileged automation.

Key questions

Q: What breaks when SSH keys are not governed as a lifecycle asset?

A: Access persists after users move roles, contractors leave or workloads are redeployed, because the same keys continue to authenticate long after the original business need has ended. The result is hidden standing access that is hard to inventory, revoke or audit. Governance fails when ownership and removal are not built into the credential's full life cycle.

Q: Why do long-lived SSH keys increase access risk even when the algorithm is strong?

A: Because cryptographic strength does not remove trust debt. A strong key that is copied widely, never rotated, or left in authorised_keys after its owner changes role still provides persistent access. The risk comes from unmanaged entitlement, not from the math used to generate the key.

Q: How do organisations know if SSH key governance is actually working?

A: They should be able to show a complete inventory, a clear owner for each credential, enforced expiry dates, and a reliable audit trail for rotation and revocation. If any of those are missing, the programme is controlling fragments of the problem rather than the full credential lifecycle.

Q: What is the difference between SSH keys and SSH certificates for server access?

A: SSH keys are static credentials that must be distributed and manually removed on each server, while SSH certificates are issued by a trusted certificate authority for a defined user, host, and time period. Certificates improve scalability and revocation because access policy is centralised, but they require upfront CA setup and client authorization controls.

Technical breakdown

Why SSH keys create lifecycle debt

SSH keys do not expire on their own, and that is the central technical weakness. Unlike certificates, a private key can remain valid indefinitely unless an administrator discovers it, rotates it, or removes every authorised copy. Because keys are stored locally and often reused across systems, one undetected key can preserve access long after the original trust decision has changed. That turns what looks like an authentication mechanism into a persistence layer for machine identity. In NHI terms, the risk is not the cryptography itself but the absence of lifecycle state around the credential.

Practical implication: Treat every SSH key as a governed identity object with issuance, expiry, and revocation states.

How decentralised storage expands privileged access risk

SSH private keys are usually copied to endpoints, automation hosts, and admin workstations, which makes the control plane fragmented. When keys are distributed this way, visibility drops and privileged access becomes hard to inventory. That is why stale keys and orphaned identities persist, especially where root or administrator access is involved. If a key is copied beyond its intended use case, the organisation loses the ability to distinguish legitimate administration from hidden reuse. The technical problem is not just theft, but uncontrolled replication of an identity credential across environments.

Practical implication: Inventory where privileged SSH keys exist before you can govern where they are allowed to operate.

Why SSH certificates change the trust model

SSH certificates move trust from isolated key pairs to a certificate authority that signs identities with metadata and expiry. That adds lifecycle structure, so access is no longer simply a matter of whether a public key remains in an authorised_keys file. Certificates support shorter validity windows, stronger auditability, and clearer policy enforcement for automation and admin access. The main architectural shift is that trust becomes centrally issued and time-bound instead of locally accumulated. For identity teams, this is a change in governance model, not just a different credential format.

Practical implication: Use SSH certificates where you need time-bounded trust and central policy enforcement for machine access.

Threat narrative

Attacker objective: The attacker aims to turn forgotten SSH trust into durable administrative access that survives normal review cycles.

1. Entry begins when an old or duplicated SSH key remains authorised on a system after it should have been removed.
2. Escalation occurs when that key still carries privileged access, allowing the attacker to act as a trusted administrator or automation identity.
3. Impact follows when the attacker uses the lingering trust to create new access paths, move through managed systems, or maintain persistence through unmanaged keys.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH key management is now a lifecycle governance problem, not a point control problem. The article is right to frame SSH keys as digital identities rather than disposable credentials. Once a key can persist without expiry, revocation discipline becomes the security boundary, and that is an IAM and PAM issue as much as a crypto issue. The practitioner conclusion is simple: governance has to follow the identity, not the file.

Stale SSH keys create identity blast radius. A forgotten key is not merely unused access, because it can remain valid on privileged systems, automation hosts, and remote administration paths. That means the blast radius is defined by where the key was ever trusted, not where it is currently remembered. Teams need to think in terms of exposure duration and reuse potential, not only technical strength.

SSH certificate adoption changes the operating model for machine access. Certificate-based SSH shifts trust from scattered local artefacts to centrally issued, time-bound identities with better auditability. That aligns better with OWASP-NHI and NIST-CSF expectations around least privilege, visibility, and lifecycle control for machine identities. The practical implication is that organisations should treat certificate automation as a governance upgrade, not just an authentication refresh.

Manual discovery is the control failure behind most SSH governance gaps. The article makes clear that teams lose track of where keys live, who copied them, and whether they still map to an approved trust decision. That is a structural offboarding and recertification problem for NHI credentials. The practitioner conclusion is to stop assuming authorised_keys files reflect current reality.

Privileged SSH access should be governed like standing admin privilege. Root login, local key sprawl, and ad hoc monitoring turn SSH into a hidden PAM pathway. The article’s strongest implication is that machine access governance must be reviewed with the same seriousness as human elevated access. Teams that ignore that equivalence will continue to inherit unmanaged privilege through SSH.

What this signals

Identity blast radius is the right lens for SSH governance. A key that was once valid for admin work can remain trusted across systems long after the original approval context has disappeared. That means governance needs to focus on where a credential can still be used, not only where it was first issued.

Central trust does more than simplify administration. Moving from scattered SSH keys to centrally issued SSH certificates changes the control boundary from local files to policy-backed identity issuance. That is the point at which lifecycle governance becomes operationally enforceable rather than purely procedural.

For practitioners

• Establish a complete SSH identity inventory Map every authorised key, certificate, and admin host that can accept SSH authentication, then reconcile it against approved owners and systems. Include automation accounts and backup jobs, not just interactive admin use.
• Move privileged access to SSH certificates Replace long-lived keys for sensitive administration paths with certificates that carry explicit expiry and centrally issued trust decisions. Use the certificate authority as the policy boundary for who can connect and for how long.
• Disable direct root SSH access Require sudo or equivalent elevation workflows for administrative tasks so that SSH authentication does not directly equate to root access. This narrows the blast radius of any key that is copied or misused.
• Automate key revocation and orphan cleanup Build recurring checks for stale, inactive, duplicated, and unowned SSH identities, then remove any key that no longer maps to an active trust decision. Manual cleanup is too slow for cloud-scale estates.
• Log and review SSH usage as an identity signal Capture who used which key or certificate, from where, and at what time, then alert on unusual source addresses, off-hours logins, or identities that appear outside their normal pattern.

Key takeaways

• SSH keys become a governance problem when they outlive the trust decision that created them.
• The article’s risk story is driven by sprawl, hidden privileged access, and revocation that depends on manual discovery.
• Certificate-based SSH and automated identity tracking are the controls that change the lifecycle model, not just the credential format.

Key terms

• SSH key lifecycle: The full governance path for an SSH key from creation to revocation. It includes ownership, deployment, rotation, backup handling, and removal from every host that trusts it. In practice, lifecycle control is what makes SSH credentials auditable rather than merely functional.
• SSH Certificate: An SSH certificate is a signed credential that lets a server trust an identity without relying on a static key alone. In NHI terms, it is a short-lived machine credential whose security depends on issuance policy, principal validation, and where the trust anchor is accepted.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.