TL;DR: SSH key environments often grow into hundreds or thousands of unmanaged credentials, with unused keys, weak rotation discipline, and offboarding gaps creating persistent access risk according to StrongDM. The practical lesson is that SSH key governance is a lifecycle problem, not just a key-management problem.
At a glance
What this is: StrongDM argues that SSH key management breaks down when organisations treat keys as static artefacts instead of governed identities with inventory, rotation and offboarding controls.
Why it matters: IAM, PAM and NHI teams need to treat SSH keys as lifecycle-managed credentials because unmanaged keys create durable server access that survives role changes and weakens auditability.
Context
SSH key management is the discipline of creating, assigning, rotating and deleting public-private key pairs used to authenticate to servers, databases and other remote systems. The operational problem is not the cryptography itself but the governance around issuance, reuse and removal.
When key inventories are incomplete, organisations lose track of which keys still matter, which users or machines they belong to, and which ones should already have been removed. That creates lingering access paths that behave like standing privilege, especially in DevOps and infrastructure environments where keys are often reused across hosts.
StrongDM's article frames SSH key management as a lifecycle issue because the practical failure mode is not one bad key but many unmanaged keys spread across people, machines and procedures. That is a familiar NHI governance pattern, even when the immediate subject is server access.
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 public keys create security risk in large environments?
A: Long-lived SSH public keys create risk because they are hard to track, easy to copy between devices, and often remain on hosts after people change roles or leave. That produces unclear access boundaries, lingering permissions, and a larger blast radius if a key is stolen. Without centralized control, administrators also struggle to answer who should have access to what.
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: Should organisations keep managing SSH keys directly or move to mediated access?
A: If teams spend more time distributing, revoking and auditing keys than using them for real operational access, mediated access usually wins. The decision is less about convenience than about whether the programme can reliably enforce lifecycle controls at scale. Direct key management works only when ownership, rotation and offboarding are tightly disciplined.
Technical breakdown
Why SSH key sprawl becomes a governance problem
SSH keys are often created without a clear expiry model, then distributed across servers, laptops and automation workflows. As environments scale, administrators lose reliable visibility into where keys live, who owns them and whether they still support an active business purpose. That turns a technical authentication method into an inventory and accountability problem. A key can remain valid long after the user or workload that received it has moved on, which means the control boundary is defined more by memory than by policy. Practical implication: treat key inventory as a governed asset register, not an optional spreadsheet.
Practical implication: inventory every SSH key as an identity object with owner, purpose, host scope and removal criteria.
How rotation gaps create persistent access
SSH keys have no inherent expiration unless an organisation imposes one through process or certificate design. In practice, rotation often fails because admins must update both the key holder and every server that trusts the old key, and any missed update can break access. That operational friction explains why old keys linger and why some environments end up with large pools of unused keys that still authenticate successfully. For certificate-based SSH, expiry helps, but only if reissuance is actually managed on schedule. Practical implication: shorten the trust window by pairing rotation policy with enforced expiry and verification of server-side removal.
Practical implication: enforce key expiry and verify that old keys are removed from every authorised host, not just regenerated centrally.
Why offboarding is the hardest SSH control to get right
SSH access often survives user movement, contractor churn and workload relocation because the private key or authorised key entry was never revoked everywhere it existed. The result is a durable access path that may continue to work after the original purpose has ended. That is especially risky when teams use shared accounts or embed keys in programs and client machines. The article also ties this to auditability: without logs showing who added or removed a key and when, no one can prove the offboarding happened correctly. Practical implication: make revocation the default response to role change, machine replacement or end of need.
Practical implication: build revocation into offboarding workflows so access is removed as part of the move, termination or system replacement process.
Threat narrative
Attacker objective: Maintain durable SSH access to servers and automation targets through stale, shared or unrevoked keys.
- Entry occurs when SSH public keys are spread across servers and client systems without a reliable inventory or expiry boundary, allowing old credentials to remain valid.
- Credential access is sustained when unused or shared keys continue to authenticate because rotation and revocation are incomplete.
- Impact follows when former users, moved programs or shared accounts retain server access long after the original need has ended, creating persistent administrative exposure.
Breaches seen in the wild
- EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SSH key governance fails when access is treated as a technical setup task instead of a lifecycle discipline. The article shows that inventory gaps, missed rotation and weak deprovisioning are the real sources of risk. That is not a cryptography problem. It is an identity governance problem in which the control only works when ownership, purpose and revocation are tracked as part of the credential's full life cycle.
Unaccounted SSH keys create identity blast radius. Once a key is copied across servers, laptops or automated jobs, the number of places that must be updated or revoked multiplies quickly. That is why unmanaged SSH environments drift into hidden standing access even when teams believe they are handling access manually. The implication is that server access should be governed as a federated trust graph, not as isolated key pairs.
Auditability is not an optional add-on in SSH programs. The article correctly ties missing logs to missing accountability, because a team cannot govern what it cannot reconstruct. In practice, audit evidence is what distinguishes a policy from an aspiration. Practitioners should treat key issuance, use and deletion as evidence-bearing events that must be traceable end to end.
Shared SSH accounts are a lifecycle shortcut that breaks identity ownership. When multiple administrators use the same key, the organisation loses the ability to link access to a person, a machine or a business justification. That makes revocation incomplete by design and complicates compliance reviews. The durable lesson is that identity ownership must stay one-to-one wherever SSH access is still used.
Centralised access layers are changing the question, not just the tooling. The article's control-plane example points to a broader market shift away from per-host key management toward governed session mediation. That direction validates the idea that SSH access should be issued, observed and revoked through identity policy, not scattered across endpoints. For practitioners, the architectural question is how much host-level key trust the programme still needs to carry.
What this signals
Identity blast radius is the hidden SSH problem: once a key is copied to multiple hosts or embedded in automation, the number of places that must be corrected multiplies and revocation becomes a reconstruction exercise. That makes host-level key management increasingly fragile as environments scale.
Teams should expect governance pressure to move from key generation toward key issuance, revocation and evidence. In practice, the programme question is no longer whether SSH keys work, but whether the organisation can prove that every key still in circulation is still justified.
For practitioners
- Inventory every SSH key and owner Build a complete register of public keys, private-key holders, service accounts and automated jobs that can still authenticate to production systems. Include host scope, purpose, last-use date and revocation owner so gaps become visible before they become access debt.
- Enforce key rotation with host-side removal checks Set a rotation interval and require verification that old public keys were deleted from every authorised server, not just regenerated at the source. Track failures where distribution to all hosts is incomplete because that is where stale access often survives.
- Tie offboarding to immediate SSH revocation Remove SSH access when a user changes role, a contractor ends, or a workload is moved to a different machine. Treat revocation as part of the offboarding record, not a separate manual clean-up task that can be forgotten.
- Eliminate shared SSH accounts where ownership is unclear Replace shared admin accounts with individually attributable access so every SSH action can be tied back to a person or workload. Shared keys erase accountability and make it impossible to know which access should be removed first.
- Use certificates or mediated access for short-lived trust Where possible, move away from long-lived SSH keys and toward certificate-backed or centrally mediated access that expires by design. This reduces the number of endpoints that must be updated during onboarding, offboarding and host replacement.
Key takeaways
- SSH key risk is driven less by cryptography than by incomplete ownership, rotation and revocation controls.
- Large key estates create persistent access because unused and shared keys often survive role changes and machine moves.
- The practical fix is lifecycle governance: inventory, rotate, revoke and audit keys with the same discipline used for other privileged access.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article's core failure mode is leaving SSH access behind after users or machines move on. |
| NHI-07 — Long-Lived Secrets | Unrotated SSH keys remain valid far longer than the access need they were created for. | |
| Recommendation — Apply NHI-01 to revoke SSH access as part of every offboarding and machine replacement workflow. Use NHI-07 to shorten SSH trust windows with enforced rotation and expiry. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly maps to the lifecycle handling of SSH authenticators and their rotation. |
| Recommendation — Enforce IA-5 to manage SSH key issuance, rotation and revocation as a controlled authenticator lifecycle. | ||
| CIS Controls v8 | CIS-5 — Account Management | SSH key sprawl is an account and access governance problem across servers and automation. |
| Recommendation — Apply CIS-5 to inventory SSH-enabled accounts and remove access that no longer has a business owner. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | SSH keys are entitlements that need governed assignment and removal across systems. |
| Recommendation — Use PR.AA-05 to align SSH key grants and removals with defined authorisation rules. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stale SSH keys are a common enabler of credential reuse and movement across servers. |
| Recommendation — Map stale SSH keys to TA0006 and TA0008 to prioritise hunts for reused server access. | ||
Key terms
- SSH Key Inventory: An SSH key inventory is a complete record of keys that exist, where they are used, and who or what owns them. It gives security teams the baseline needed to find orphaned, shared, or stale keys. Without that inventory, access reviews and rotation efforts are usually incomplete and unreliable.
- SSH Key Rotation: SSH key rotation is the regular replacement of key pairs so old credentials stop providing access. It reduces exposure from stolen, forgotten, or widely distributed keys, especially in environments where private keys live on servers and automation hosts for long periods.
- Offboarding Revocation Window: The time between a user or workflow no longer needing access and that access being fully removed across relevant systems. Longer windows increase the chance that obsolete credentials, sessions, or delegated rights can be reused during or after departure.
- Shared SSH Account: An SSH access pattern where multiple administrators or processes use the same account or key pair. This weakens attribution and makes revocation unreliable because the organisation can no longer tell which individual or workload still needs the access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle 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.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org