SSH key sprawl exposes the limits of manual PKI governance

At a glance

What this is: This is an analysis of SSH key sprawl and the key finding is that manual key management no longer scales across modern infrastructure.

Why it matters: It matters because unmanaged SSH keys sit inside the same identity and privilege governance problem set as NHI, workload identity, and PAM, where invisibility becomes exposure.

👉 Read Keyfactor's analysis of SSH key sprawl and PKI governance

Context

SSH key sprawl is the uncontrolled growth of cryptographic keys across cloud platforms, DevOps pipelines, infrastructure, and machine-to-machine access paths. In practice, the issue is not only volume but governance failure, because organisations lose sight of which keys are active, who owns them, and when they should expire.

For IAM, PAM, and NHI programmes, this is a lifecycle problem as much as a cryptographic one. Once SSH keys become orphaned or unmanaged, they create persistent access that bypasses normal identity review, revocation, and audit expectations, which is why manual administration breaks down in environments built on speed and scale.

Key questions

Q: How should security teams manage SSH key sprawl across cloud and DevOps environments?

A: Start with central discovery, then assign ownership, define expiry rules, and automate rotation and revocation. The goal is to move SSH keys out of ad hoc administration and into lifecycle governance, so access can be reviewed, removed, and audited consistently across infrastructure, pipelines, and endpoints.

Q: Why do unmanaged SSH keys create persistent access risk?

A: Because keys can survive long after the people, services, or projects that created them have changed. If no one tracks ownership and expiry, a key can continue to grant privileged access even when it should have been removed, which turns a forgotten credential into standing access.

Q: What do teams get wrong about automating SSH key management?

A: They often automate the mechanics without fixing the governance model. Automation helps with rotation, expiry, and reporting, but it does not replace ownership, policy boundaries, or approval logic. If those controls are missing, automation can make sprawl faster to manage, not smaller.

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.

Technical breakdown

How SSH key sprawl breaks visibility and ownership

SSH keys become a governance problem when they proliferate faster than the organisation can inventory them. Unlike interactive human identities, keys are often created by automation, copied into pipelines, embedded in systems, or left behind after project changes. That creates orphaned access and fragmented trust, where no single team can confidently answer which keys are in use, which are expired, and which principals still depend on them. In PKI-heavy environments, the same problem extends to certificates when renewal is fragmented across teams and tools.

Practical implication: centralise discovery and ownership mapping before attempting rotation or cleanup.

Why manual rotation and revocation fail at scale

Manual key management depends on humans noticing risk, opening tickets, and completing revocation on time, which is too slow for modern infrastructure. In DevOps and cloud environments, keys and certificates may be short-lived, environment-specific, and tied to ephemeral workloads, so the window between issuance and expiry is operationally narrow. When revocation is manual, the organisation typically reacts after exposure has already widened. Automation changes the control model by making rotation, expiry enforcement, and removal part of the normal lifecycle rather than an exception-handling process.

Practical implication: automate rotation and revocation as lifecycle controls, not as ad hoc remediation tasks.

How fragmented trust undermines cryptographic governance

Key sprawl is not just a storage problem. It also creates multiple trust roots, inconsistent SSH validation patterns, and uneven policy enforcement across environments. When different teams use different certificate authorities, different approval paths, or separate visibility tools, cryptographic governance becomes fragmented and hard to audit. That weakens assurance because the organisation cannot easily prove which credentials are authorised, which policies apply, or whether access paths are still legitimate. In regulated environments, that fragmentation becomes a reporting and control issue, not merely a technical nuisance.

Practical implication: unify trust policy, reporting, and audit trails across certificates, SSH keys, and workload access paths.

Threat narrative

Attacker objective: The attacker aims to preserve or exploit privileged access through credentials the organisation can no longer reliably see or govern.

1. Entry occurs when unmanaged SSH keys or certificates remain present across cloud, DevOps, or endpoint environments after normal administrative change.
2. Escalation follows when orphaned keys continue to grant persistent privileged access because no lifecycle control removed them on time.
3. Impact appears when fragmented trust and invisible credentials enable unauthorised access, failed audits, or operational disruption from expired or mismanaged certificates.

Breaches seen in the wild

• CI/CD pipeline exploitation case study — full server takeover via exposed .git directory and mismanaged CI/CD pipeline secrets.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 sprawl is a lifecycle failure before it is a tooling failure. The article is right to emphasise automation, but the deeper issue is that unmanaged keys outgrow the governance model that was supposed to control them. Once SSH keys are scattered across cloud, DevOps, and machine access paths, ownership, expiry, and revocation stop being reliable identity functions. The implication is that key management must be treated as a lifecycle discipline, not a periodic admin task.

Fragmented trust is the named failure mode here. Multiple root CAs, orphaned certificates, and inconsistent SSH validation create a cryptographic estate that no longer behaves like one control plane. That is exactly where auditability breaks, because policy, evidence, and enforcement no longer line up. Practitioners should read this as a governance warning: if trust is distributed without a single operating model, assurance fragments with it.

Untracked SSH keys create standing privilege that behaves like unmanaged NHI access. Even when the credentials are not human, the governance problem is the same: access persists after the business need has changed. That persistence turns access review into a retrospective exercise rather than a control. The implication is that identity and privilege programmes need one lifecycle model for humans, service accounts, and key-based machine access.

PKI automation only works when it is tied to ownership and policy, not just velocity. Automated discovery and rotation reduce operational drag, but they do not by themselves prove legitimacy or business need. Without explicit ownership boundaries and expiry enforcement, automation can speed up sprawl rather than reduce it. Practitioners should treat automation as a control enabler, not a substitute for governance design.

NHI governance and SSH governance are converging control problems. The same patterns that create NHI exposure, invisible credentials, overlong access, and weak audit trails also show up in SSH key estates. That convergence matters because teams still organise tooling by asset type instead of by access lifecycle. The practical conclusion is to align PKI, IAM, PAM, and NHI oversight around one entitlement and revocation model.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• NHI Lifecycle Management Guide helps teams map ownership, expiry, and offboarding back to a single credential lifecycle.

What this signals

SSH key sprawl is a warning that identity programmes are still organised around administration patterns rather than credential lifecycles. The next control maturity step is not another scanner, but a governance model that can link discovery, ownership, expiry, and audit evidence across PKI, PAM, and machine access paths. Teams that already struggle with secrets sprawl should expect the same failure mode to surface in SSH estates unless they consolidate control points.

A useful way to frame this problem is as cryptographic trust fragmentation: the estate remains technically functional while the governance model quietly breaks apart. That is why practitioners should expect more attention on unified reporting, certificate lifecycle enforcement, and policy-backed revocation. For a baseline on where these issues sit in the broader control stack, the NIST Cybersecurity Framework 2.0 remains a useful alignment point.

For practitioners

• Centralise SSH key discovery across all environments Build a live inventory that spans cloud, DevOps pipelines, infrastructure hosts, containers, and user endpoints so you can identify active, orphaned, and expired keys from one control point.
• Convert manual revocation into lifecycle automation Automate key rotation, expiry enforcement, and revocation so removal happens as part of normal lifecycle management rather than through tickets after exposure has widened.
• Define ownership for every cryptographic identity Require a named business or platform owner for each SSH key, certificate, and trust root so no credential can remain active without an accountable party.
• Unify reporting across PKI and SSH trust paths Use one audit trail for certificate lifecycles, SSH key usage, and policy exceptions so compliance teams can prove where access exists and why it remains authorised.

Key takeaways

• SSH key sprawl turns machine access into an identity governance problem when keys outlive their owners and their intended use.
• The scale of the issue is operational and audit-related as much as technical, because fragmented trust destroys visibility, ownership, and revocation discipline.
• Teams that want control need central discovery, named ownership, and automated lifecycle enforcement rather than manual key administration.

Key terms

• SSH Key Sprawl: The uncontrolled growth of SSH keys across environments, teams, and workflows. It becomes a governance problem when keys are created faster than they can be inventoried, owned, rotated, and revoked, leaving hidden privileged access behind after systems, projects, or people change.
• Fragmented Trust: A state where cryptographic trust is spread across multiple authorities, tools, or validation rules without a single operating model. In practice, it makes it difficult to prove which credentials are valid, which policies apply, and whether audit evidence matches real access paths.
• Certificate Lifecycle Automation: The use of policy-driven automation to issue, renew, rotate, and revoke certificates and related credentials. It reduces manual error and latency, but it only improves governance when it is tied to ownership, expiry rules, and an auditable control model.

Deepen your knowledge

NHI governance, machine identity security, and secrets 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 lifecycle governance in your organisation, it is worth exploring.

This post draws on content published by Keyfactor: Solving the Problem of SSH Key Sprawl. Read the original.