SSH key management still breaks down without lifecycle governance

At a glance

What this is: This is a StrongDM analysis of SSH key management showing that sprawl, manual rotation, weak offboarding, and poor auditability make keys hard to govern at scale.

Why it matters: It matters because the same lifecycle failures that leave SSH keys exposed also show up across service accounts, secrets, and other non-human identities, making governance consistency the real control problem.

By the numbers:

• In a study by Dimensional Research, 40% of organizations said they don't rotate keys at all or only do so occasionally.
• Research shows that in some large organizations up to 90% of authorized keys are no longer used, and 10% of those grant privileged access.

👉 Read StrongDM's guide to SSH key management best practices

Context

SSH key management is the lifecycle discipline for creating, assigning, rotating, revoking, and auditing keys that grant access to servers and databases. The primary problem in this article is not cryptography, but control drift: keys accumulate, outlive their need, and keep working long after the business reason for access has changed. That is the same governance pattern IAM teams see across other non-human identities when inventory, ownership, and revocation are weak.

For practitioners, the important lesson is that SSH keys behave like durable credentials unless the programme makes them ephemeral by design. The article’s core argument is that manual administration does not scale cleanly, especially when keys are shared, copied to multiple hosts, or left behind during offboarding. That makes SSH keys a useful lens for broader NHI lifecycle governance, not just a legacy access method.

Key questions

Q: What breaks when SSH keys are not rotated or revoked properly?

A: When SSH keys are not rotated or revoked properly, access can survive long after the original user, machine, or business need has changed. That creates standing privilege, weakens accountability, and makes it difficult to prove who still has access to what. The result is hidden exposure rather than controlled access.

Q: Why do SSH keys create governance problems in large environments?

A: SSH keys create governance problems in large environments because they scale as durable credentials, not as managed relationships. Once keys are copied across hosts, shared across accounts, or left behind during offboarding, teams lose the ability to reason confidently about ownership, necessity, and revocation timing.

Q: How do security teams know if SSH key management is actually working?

A: SSH key management is working when every key is inventoried, attributable, rotated on a defined schedule, and removed promptly when access ends. If teams cannot produce a current list of keys and explain why each one still exists, the programme is not under control.

Q: What should organizations do when SSH access is needed for contractors or remote teams?

A: Organizations should put contractor and remote access behind centrally mediated controls with clear expiry and revocation rules. The goal is to avoid leaving durable keys on servers or laptops, because those keys often outlive the assignment and remain usable after the work is done.

Technical breakdown

SSH key authentication and trust chains

SSH authentication uses asymmetric key pairs, where a public key is placed on the target system and the private key remains with the user or machine. The server challenges the client, and only the holder of the private key can complete the exchange. Certificates add a trusted issuer and expiry date, which improves lifecycle control, but the basic trust model still depends on knowing which keys exist, where they live, and who owns them. When that inventory is incomplete, the security model degrades from controlled trust to inherited trust.

Practical implication: maintain a complete key inventory and map each key to an owner, a system, and a valid business purpose.

Why SSH key sprawl creates governance debt

Key sprawl happens when keys are created faster than they are reviewed, rotated, or removed. Because SSH keys often have no inherent expiry, they tend to accumulate across servers, laptops, and service workflows. The article highlights a familiar failure mode: unused keys remain authorized, shared accounts blur accountability, and administrators lose visibility into which keys still matter. In governance terms, sprawl is not just volume. It is untracked access persistence that expands the attack surface and makes certification exercises unreliable.

Practical implication: treat stale SSH keys as governance debt and remove them through recurring inventory reconciliation, not ad hoc cleanup.

Control plane mediation and temporary access

A centralized control plane changes the access model by placing authentication, authorization, and session routing in one place rather than distributing keys directly to every server. The article describes temporary credentials, delegated identity providers, and session logging as the mechanisms that reduce direct key exposure. This does not eliminate SSH, but it reduces the number of places where durable secrets must exist. Operationally, the value is not just convenience. It is the ability to revoke access centrally without hunting for private keys on endpoints or individual hosts.

Practical implication: route privileged SSH access through a mediated control layer so revocation and logging happen centrally.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH key management is really a lifecycle governance problem, not a cryptography problem. The article shows that the hard part is not generating keys, but knowing when they are still valid, who owns them, and when they should be removed. That is the same structural failure seen in broader NHI programmes when credentials outlive the business need that created them. Practitioners should treat keys as governed identities with a full lifecycle, not as static configuration artifacts.

Standing key privilege is the named failure mode this article exposes. SSH keys often remain authorized indefinitely, which means access persists long after users move roles, machines are repurposed, or contractors leave. That assumption was designed for stable administrative relationships. It fails when credentials are copied, shared, or forgotten across multiple hosts. The implication is that access models built on durable keys need stronger revocation discipline than manual teams usually provide.

Auditability is the control gap that turns SSH key sprawl into accountability loss. The article makes clear that without a reliable trail of who added or deleted keys, security teams cannot prove ownership or explain why access still exists. That weakens both compliance and incident response. In practice, audit depth matters as much as inventory depth because a key you cannot attribute is a key you cannot govern.

Centralized access mediation is now the practical boundary for scalable SSH governance. Once key counts climb into the hundreds or thousands, direct server-level management becomes too brittle to sustain. The control plane pattern collapses that complexity into one authorization point, which changes how lifecycle, logging, and revocation are executed. Practitioners should re-evaluate whether server-local keys are still defensible for high-change environments.

SSH key sprawl is a preview of the same problem NHI teams face across service accounts and certificates. Durable credentials create hidden access persistence wherever ownership is weak and lifecycle actions are manual. That makes SSH a useful governance test case for broader NHI programmes. The lesson is to measure how much access still depends on people remembering to clean up after systems have already moved on.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organizations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That mismatch between confidence and practice is why the NHI Lifecycle Management Guide matters when access revocation and ownership need to be made measurable.

What this signals

Standing key privilege: SSH access that never expires behaves like any other durable NHI control failure, which is why lifecycle discipline matters more than isolated hardening steps. The more a programme relies on humans to remember cleanup, the more likely stale access becomes policy by default. The better signal is whether revocation is tied to identity change, not whether a key exists at all.

For teams already managing service accounts and certificates, SSH key governance should be treated as the same lifecycle pattern with a different transport layer. The practical question is whether access is still reconstructible after a user changes role, a server is rebuilt, or a contractor leaves. If the answer is no, the programme is depending on memory instead of control.

The most useful forward move is to align SSH governance with broader NHI lifecycle controls and the NIST Cybersecurity Framework 2.0 functions for protect, detect, and respond. Inventory, revocation, and audit logging are the minimum viable signals that tell you the access model is still under governance.

For practitioners

• Build a complete SSH key inventory Record every key, owner, host, expiry condition, and business justification so stale access can be identified before it becomes invisible.
• Enforce key rotation with offboarding checkpoints Tie key revocation to role changes, machine replacement, vendor exit, and retirement of the system that uses the key.
• Eliminate shared administrative keys Replace common system accounts with individually attributable access paths so one departing user cannot leave behind active shared credentials.
• Centralize SSH access through a mediated control layer Route privileged sessions through a control plane that logs activity, brokers authentication, and lets teams revoke access from one place.
• Reconcile audit trails against live access lists Compare logs of key creation, deletion, and usage with current server authorization lists to find credentials that should no longer exist.

Key takeaways

• SSH key sprawl becomes a governance problem when ownership, rotation, and revocation are not enforced consistently.
• Unused and unrotated keys can persist as standing privilege, which makes audit and offboarding the decisive controls.
• Centralized access mediation and complete inventorying are the practical levers that reduce SSH lifecycle risk.

Key terms

• SSH key lifecycle: The SSH key lifecycle is the set of governance steps that cover creation, assignment, rotation, review, and revocation. In practice, it determines whether a key is a controlled credential or a permanent backdoor. Strong lifecycle discipline turns SSH from a durable access grant into a managed identity event.
• Standing privilege: Standing privilege is access that remains valid without a fresh business need or explicit reauthorization. For SSH, it usually appears when keys are never revoked, shared across people, or copied across hosts. The security problem is not the key itself, but its ability to keep working after the original justification disappears.
• Access mediation: Access mediation is the practice of placing an intermediary control layer between the user and the target system. For SSH, that layer can authenticate the user, broker the session, log activity, and enforce revocation centrally. It reduces direct exposure of long-lived keys and makes lifecycle management more operationally visible.

Deepen your knowledge

SSH key lifecycle governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to control durable credentials at scale, it is a relevant next step.

This post draws on content published by StrongDM: SSH Key Management Explained: Best Practices & More. Read the original.