SSH key sprawl exposes the limits of manual PKI governance

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Keyfactor's blog post: SSH key sprawl and unmanaged keys undermine PKI governance, visibility, and revocation discipline.

Why it matters: It matters because IAM, PAM, and NHI teams need controls that govern keys as dynamic access assets, not as files that can be inventoried once and forgotten.

Context

SSH key sprawl is the uncontrolled growth of cryptographic keys across cloud platforms, DevOps pipelines, and machine-to-machine environments. Once keys become hard to inventory, they stop behaving like manageable assets and start behaving like hidden access paths.

The governance gap is not only volume. Manual provisioning, fragmented trust models, orphaned keys, and short-lived certificates create a control environment where owners, expiry, and revocation are no longer reliably tied to real usage. For IAM and NHI programmes, that is a lifecycle problem as much as a visibility problem.

The article’s starting position is typical for modern infrastructure: scale outpaces manual control, and the problem is already embedded in normal operating patterns rather than exceptional misuse.

Key questions

Q: What breaks when SSH keys are managed manually across many systems?

A: Manual management breaks inventory accuracy, ownership clarity, and timely revocation. Keys get copied, forgotten, and left behind on servers that no one actively reviews. The result is access sprawl, especially in environments with contractors, automation, or many ephemeral servers. Visibility and central control are the first things that fail.

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: How should security teams govern SSH keys in cloud and server environments?

A: Treat SSH keys as governed non-human identities. Assign an owner, define an expiry or rotation interval, track where the key is trusted, and revoke it when the access relationship ends. The key control is lifecycle discipline, because an unused but valid key is still an active credential. Central visibility matters as much as the algorithm choice.

Q: What is the difference between SSH keys and SSH certificates for governance?

A: SSH keys are reusable credentials that can persist indefinitely unless administrators remove them, while SSH certificates are time-bounded identities signed by a central authority. For governance, certificates make ownership, expiry, and auditability easier to control. That usually makes them a better fit for privileged access and automated workflows.

Technical breakdown

Why SSH key sprawl breaks inventory-based governance

SSH keys are asymmetric credentials used for authentication and access control, but in practice they are often created outside central governance and left in place for long periods. That creates a state where the organisation cannot reliably answer who owns a key, where it is used, or whether it still should exist. The technical issue is not merely count, but decentralised issuance combined with weak lifecycle tracking. Once keys spread across infrastructure, containers, IoT devices, and endpoints, traditional inventory methods become incomplete by design.

Practical implication: move SSH keys into governed discovery and ownership workflows rather than relying on periodic manual audits.

How fragmented trust models expand the cryptographic attack surface

Fragmented trust happens when multiple root CAs, orphaned certificates, and inconsistent SSH trust patterns coexist without a single policy model. In that state, revocation and expiration lose their value because different parts of the environment may validate trust differently or not at all. Manual tools tend to expose only a slice of the estate, which leaves hidden privilege paths intact. The broader issue is that cryptographic trust becomes non-uniform across platforms, making governance decisions local instead of enterprise-wide.

Practical implication: unify trust policy and certificate lifecycle controls across SSH and PKI estates before remediation efforts become partial and inconsistent.

Why automation is the control plane for SSH lifecycle governance

Automation changes SSH key governance from reactive cleanup to continuous lifecycle management. Instead of depending on teams to notice stale credentials, it can monitor, renew, revoke, and report across environments at machine speed. That matters because manual rotation and revocation are too slow and error-prone when keys are widespread and long-lived. Automation also makes reporting and alerts more reliable, which is essential when compliance, auditability, and operational stability all depend on the same underlying credential state.

Practical implication: treat lifecycle automation as the operating model for SSH governance, not as a convenience feature layered on top.

Threat narrative

Attacker objective: The attacker aims to exploit unmanaged SSH trust to gain persistent, privileged access that outlives normal ownership and review cycles.

1. Entry occurs through a legitimate SSH key that was created without central visibility and later forgotten in the environment. The key remains valid after the original owner no longer needs it.
2. Escalation comes from the key’s standing access, which can grant privileged reach into servers, cloud workloads, or pipeline systems without additional human interaction.
3. Impact is persistent access, trust fragmentation, and exposure to outages or compliance failure when expired or orphaned keys are still accepted by parts of the estate.

Breaches seen in the wild

• 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.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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 a lifecycle failure, not just an inventory problem: the real issue is that authentication material outlives the governance process meant to contain it. When keys can be created, copied, and forgotten outside central oversight, ownership and expiry cease to be reliable control points. The practitioner conclusion is that SSH governance must follow identity lifecycle logic, not file-management logic.

Fragmented cryptographic trust is the named concept here: multiple root authorities, orphaned certificates, and inconsistent SSH trust assumptions create parallel control planes. That fragmentation means revocation is not truly global, which is why manual governance appears to work until a hidden path is tested. The practitioner conclusion is that trust uniformity matters as much as credential quantity.

Manual PKI governance does not scale to machine-speed environments: DevOps pipelines and ephemeral workloads create issuance and consumption patterns that human review cannot match. The article correctly shows that automation is not an efficiency add-on but the mechanism that makes renewal, revocation, and reporting operationally feasible. The practitioner conclusion is to govern keys as dynamic infrastructure, not static artifacts.

SSH key governance sits at the intersection of NHI and PAM: a key may look like a simple access artifact, but once it grants privileged command execution it becomes an NHI with administrative blast radius. That is why access scope, ownership, and revocation need the same rigor applied to privileged human accounts. The practitioner conclusion is to align SSH controls with privileged identity governance, not general endpoint hygiene.

Compliance pressure is a symptom, not the root cause: ISO 27001 and PCI-DSS only become difficult when the underlying cryptographic estate lacks centralized control and auditability. The enduring governance gap is that manual processes cannot prove what is active, owned, or expired across distributed environments. The practitioner conclusion is to use compliance as confirmation of control maturity, not as the control itself.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Machine Identity, PKI and Certificate Lifecycle Guide

What this signals

Fragmented cryptographic trust: SSH governance fails fastest when multiple trust roots, orphaned assets, and inconsistent validation rules coexist across infrastructure. That is why teams need a single control model for discovery, issuance, renewal, and revocation rather than separate handling for each platform.

Automation is the boundary between a visible key estate and a governable one. When renewal and revocation depend on manual effort, the environment will always outrun the process, especially in cloud, DevOps, and machine-to-machine contexts.

According to the Ultimate Guide to NHIs, only 5.7% of organisations have full visibility into their service accounts, which is the same governance blind spot that SSH key sprawl exposes in adjacent machine access estates.

For practitioners

• Map SSH keys to explicit ownership Build an authoritative inventory that ties each SSH key or certificate to a named owner, environment, and expiry date so orphaned access can be identified before it becomes persistent trust.
• Automate rotation and revocation workflows Replace ad hoc key handling with policy-driven rotation, revocation, and expiry enforcement across cloud, DevOps, and server estates where manual turnaround is too slow.
• Replace unmanaged SSH keys with SSH certificates Move toward centrally issued SSH certificates so access can be validated against a lifecycle-managed authority instead of relying on static key pairs that are difficult to track.
• Unify cryptographic trust reporting Produce one audit view for SSH keys, X.509 certificates, and related cryptographic assets so compliance teams can see ownership, status, and expiration without stitching reports together manually.
• Integrate key governance into DevOps and cloud workflows Insert discovery and policy checks into pipeline and workload onboarding so new machine access is governed at issuance rather than discovered after sprawl has already spread.

Key takeaways

• SSH key sprawl turns ordinary authentication material into persistent access paths that outlive ownership and review.
• The core evidence is governance failure at scale, not a lack of cryptographic primitives or policy language.
• Central discovery, lifecycle automation, and certificate-based trust controls are the levers that change the outcome.

Key terms

• 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.
• Fragmented Cryptographic Trust: A state where different parts of an environment validate keys, certificates, or authorities differently, so trust is no longer uniform. In practice, this makes revocation, expiry, and auditability uneven, which is especially damaging in distributed machine access estates.
• Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
• SSH Certificate: An SSH certificate is a signed credential that lets a server trust an identity without relying on a static key alone. In NHI terms, it is a short-lived machine credential whose security depends on issuance policy, principal validation, and where the trust anchor is accepted.

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 building or maturing an IAM programme, it is worth exploring.