Notifications
Clear all
Topic starter
25/06/2026 2:53 pm
TL;DR: SSH key sprawl creates unmanaged, privileged access paths that outpace manual inventory, rotation, and revocation across cloud, DevOps, and machine-to-machine environments, according to Keyfactor. The governance problem is not just scale but trust fragmentation, because access controls fail when keys are invisible, orphaned, or treated as static assets.
NHIMG editorial — based on content published by Keyfactor: Solving the Problem of SSH Key Sprawl
Questions worth separating out
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.
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.
Q: What do teams get wrong about automating SSH key management?
A: They often automate the mechanics without fixing the governance model.
Practitioner guidance
- 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.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance on unifying SSH key discovery with certificate inventory across infrastructure and DevOps estates
- Specific examples of automated key rotation, expiry enforcement, and revocation workflows for modern PKI programmes
- Implementation details for self-service key generation and automated provisioning in server and cloud workloads
- Reporting and alerting patterns for audit readiness, including how to expose compliance evidence to auditors
👉 Read Keyfactor's analysis of SSH key sprawl and PKI governance →
SSH key sprawl and PKI governance: what IAM teams must fix?
Explore further
25/06/2026 4:05 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SSH key sprawl exposes the limits of manual PKI governance
