TL;DR: SSH keys and automated credentials often outlive the systems and workflows they protect, creating unmanaged machine identity exposure that can bypass PAM, MFA, and audit controls, according to SSH Communications Security. Long-lived access assumptions break down in cloud-first environments, where visibility, scope, and revocation become the real control points.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on SSH Communications Security's blog post: SSH key sprawl is a machine identity governance problem, with unmanaged keys and automated credentials emerging as the main control gap.
Why it matters: It matters because identity teams must govern non-human access as a lifecycle problem, not just a vaulting problem, or they will miss lateral movement and revocation risk.
Context
SSH key sprawl is a machine identity governance problem, not just a secrets problem. In cloud-first environments, automation tools, containers, API clients, vulnerability scanners, and admins all rely on credentials that often sit outside standard IAM processes, which creates a blind spot in visibility, ownership, and revocation.
The control failure is structural: SSH keys were designed for convenience, but they now function as durable access paths across modern infrastructure. When keys are reused, copied, orphaned, or stored poorly, they become a long-lived access layer that PAM, MFA, and audit review do not fully capture.
The article also shows why operational dependence matters. A bank's 12-minute outage and $1.2M trading loss after revoking a key without full dependency visibility illustrates that machine identity control gaps can turn into business disruption, not just hygiene issues.
Key questions
Q: What breaks when SSH key ownership and governance are unclear?
A: When SSH key ownership and governance are unclear, organisations lose visibility into who can access critical systems and why. That undermines auditability, makes access review unreliable, and leaves obsolete keys active long after employees or third parties leave. In practice, the control failure is not just technical. It becomes an accountability problem that weakens compliance and increases breach exposure.
Q: Why do static SSH keys increase lateral movement risk?
A: Static keys increase lateral movement risk because one copied credential can authenticate across multiple trusted systems without the friction human controls create. If the same key is reused or broadly trusted, compromise on one endpoint can become infrastructure-wide access. The longer the credential remains valid, the larger the attacker’s window.
Q: When should teams prioritise SSH certificates over SSH keys?
A: Teams should prioritise certificates when remote access must be attributable, time-bound, and easy to revoke at scale. If the environment already struggles with key sprawl, offboarding gaps, or auditability, short-lived certificates should come before further expansion of key-based access.
Q: What should teams do when revoking a machine credential could affect production?
A: Teams should map the credential's dependencies before revocation, then stage replacement access and validate the affected workflows in advance. Revocation without dependency knowledge can create outages even when the security decision is correct. The right response is to sequence containment with service continuity, so machine identity governance does not break production while reducing exposure.
Technical breakdown
Why SSH keys become unmanaged machine identities
SSH keys often start as an administrative convenience and then become embedded in DevOps automation, service workflows, and infrastructure tooling. Because they are not always registered in CMDBs or IAM inventories, they drift outside normal governance. Many keys never expire, are copied between systems, or are reused across workloads, which makes ownership and scope difficult to prove. In practice, the identity problem is not the key format itself. It is the absence of a reliable lifecycle model for issuance, dependency mapping, rotation, and revocation.
Practical implication: Map every SSH key to a workload, owner, and purpose before trying to rotate or replace it.
How long-lived credentials bypass PAM and MFA
PAM and MFA are designed to control interactive human access and high-risk elevation, but they do not automatically neutralise standing machine credentials. If an attacker harvests an SSH key or token from an endpoint, they can authenticate as an allowed identity rather than exploit a password prompt. That makes the credential itself the attack path. Once the key is valid, the attacker can move laterally with the same trust the automation was granted, and audit tools often record the session without revealing that the credential had outlived its intended context.
Practical implication: Treat any static SSH credential as an authentication bypass candidate until it is bound to scope and duration.
Why dependency visibility matters for key revocation
Revocation is where weak machine identity governance becomes operationally visible. If a key is removed without understanding which automation, hosts, or workflows depend on it, the result can be outage rather than containment. The bank example in the article shows that access and availability are linked when machine identities are embedded in critical paths. The technical issue is not just whether a key can be deleted. It is whether the organisation has graph-level visibility into the access dependencies that key supports.
Practical implication: Build dependency mapping into machine identity governance before enforcing aggressive revocation or expiry policies.
Threat narrative
Attacker objective: The attacker wants trusted, reusable infrastructure access that avoids normal interactive controls and enables undetected movement across systems.
- Initial access begins when an attacker or malware finds SSH keys or tokens on developer or admin endpoints.
- Credential abuse follows when the stolen key authenticates as a trusted machine identity and grants access to infrastructure.
- Lateral movement occurs as the attacker reuses the credential across systems that still trust the same access pattern.
- Impact emerges when attackers bypass PAM and MFA, move undetected, and retain access long enough to disrupt operations or expose systems.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
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 sprawl is really machine identity debt: the problem is not just too many keys, but too many unowned, unscoped, and unexpired identities embedded in infrastructure. When access lives outside normal identity lifecycle governance, revocation becomes guesswork and auditability collapses. Practitioners should treat every persistent SSH credential as a lifecycle asset, not a convenience artifact.
Static SSH credentials create a privilege model that assumes stability: they presume the system, workload, and dependency graph stay constant long enough for manual control to work. That assumption fails in cloud-first and DevOps environments where automation is continuous and access paths change faster than human review cycles. The practical consequence is that least privilege cannot be enforced only at issuance time when the access path itself is dynamic.
Unmanaged machine access turns PAM into a partial control: PAM can govern elevation for human sessions, but it does not automatically see or constrain all non-human access paths. When SSH keys outlive their purpose, they become a parallel trust fabric that bypasses normal access brokerage. The governance gap is the absence of authoritative inventory and lifecycle ownership, not merely the absence of a vault.
Ephemeral credentials are a scope-control shift, not a storage choice: short-lived certificates change the control point from secret retention to issuance-time policy. That matters because audit-ready telemetry, scope metadata, and expiry are what make machine access observable and revocable at speed. Security teams should frame the transition as a move from secret custody to governed access context.
Machine identity control now sits at the centre of resilience: the bank outage example shows that overcorrection and under-visibility can both create loss. Organisations need governance that can prove where credentials are used before they tighten or replace them. The right measure of maturity is not how many keys exist, but how confidently the business can explain every remaining access path.
From our research library:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
- 1 in every 1,000 non-human identities in enterprise environments is more than 10 years old.
- Read next: Guide to NHI Rotation Challenges
What this signals
The real control problem is not SSH as a protocol, but whether organisations can prove where machine identities exist and who depends on them. When that answer is unclear, key rotation and revocation become risky operational events instead of routine governance.
Identity blast radius: unmanaged SSH keys expand the blast radius of a single compromise because one reusable credential can touch many systems. That makes inventory, dependency mapping, and expiry metadata the real control points for non-human access.
For IAM and PAM teams, the shift is from credential custody to access-context governance. Static secrets that never expire will keep defeating policies built for human sessions unless machine identity lifecycle controls are brought into the same review and audit model.
For practitioners
- Build a complete SSH key inventory Scan hybrid environments for SSH keys and automated credentials, then map each one to owner, workload, and purpose so you can see which access paths are still active.
- Classify keys by dependency and criticality Tie each credential back to the systems and automation it supports before rotating or revoking anything, because machine identities often sit in hidden operational chains.
- Replace standing SSH keys with short-lived certificates Move high-risk access to ephemeral credentials that carry scope, origin, and duration metadata so access can expire with the task rather than persist indefinitely.
- Measure unmanaged credential exposure Track the number of unmanaged keys, key rotation time, and the ratio of ephemeral to static credentials to show whether machine identity governance is improving.
Key takeaways
- SSH key sprawl creates a machine identity governance gap when credentials are unowned, untracked, and reused across critical infrastructure.
- The operational evidence is clear: unmanaged machine access can bypass PAM and MFA, and revocation without dependency visibility can trigger outages.
- Teams need inventory, dependency mapping, and short-lived credentials to shrink the trust window and make machine identity control auditable.
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 and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | SSH keys are exposed, copied, and reused outside governance, which makes leakage the primary risk pattern. |
| NHI-05 — Overprivileged NHI | Reusable SSH keys often grant more access than the workload or automation actually needs. | |
| NHI-07 — Long-Lived Secrets | The article centres on keys that never expire and remain valid beyond the intended access window. | |
| Recommendation — Scan for exposed SSH keys and revoke any credential that is found outside governed storage. Reduce SSH access scope so each machine identity only reaches the hosts and commands it needs. Replace persistent SSH secrets with short-lived credentials and enforce expiry by default. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH key lifecycle, rotation, and revocation are core authenticator management concerns. |
| Recommendation — Apply authenticator management to rotate, revoke, and retire SSH credentials on a defined schedule. | ||
Key terms
- 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.
- SSH key sprawl: SSH key sprawl is the uncontrolled growth of key pairs across servers, users, and teams, usually without a reliable owner or expiry process. In practice, it creates hidden access paths that are difficult to audit, rotate, or revoke, which turns routine administration into an unmanaged security exposure.
- Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
- Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org