SSH key sprawl exposes machine identity control gaps in modern infra

At a glance

What this is: This is an analysis of unmanaged SSH keys as a machine identity problem, showing how static credentials create hidden access paths across modern infrastructure.

Why it matters: It matters because identity teams cannot govern what they cannot inventory, and static machine access undermines NHI, PAM, and broader IAM controls at the point where attackers look for lateral movement.

👉 Read SSH Communications Security's analysis of SSH key sprawl and machine identity risk

Context

SSH keys are machine credentials that allow systems, tools, and administrators to authenticate without human interaction. In modern environments they often become the most persistent form of non-human identity, especially when they are copied into scripts, endpoints, images, and admin workflows without a clear owner or expiry.

That is why SSH key management is not a narrow infrastructure issue. It sits directly inside NHI governance, where visibility, lifecycle control, and privilege scope determine whether access remains bounded or becomes a lateral movement path that outlives the original use case.

Key questions

Q: How should security teams govern SSH keys in cloud-first environments?

A: Treat SSH keys as governed machine identities, not convenience artifacts. Build an inventory that ties each key to an owner, workload, purpose, and expiry state, then remove keys that cannot be attributed. Governance fails when keys live outside lifecycle control, because revocation, review, and accountability all depend on that context.

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: What do teams get wrong about SSH key rotation?

A: Teams often rotate keys without first understanding where the keys are used. That creates outages or blind spots because revocation happens before dependencies are mapped. Rotation only works when each credential has clear ownership, known consumers, and a tested replacement path across all automation and admin workflows.

Q: Who is accountable when an unmanaged SSH key causes an incident?

A: Accountability should sit with the team that owns machine identity governance, not only the system administrator who created the key. If a credential is unmanaged, the incident exposes a lifecycle failure in inventory, review, and revocation controls. In regulated environments, that also becomes an audit and evidence problem.

Technical breakdown

Why SSH keys become unmanaged non-human identities

SSH keys were designed as an admin convenience, but in cloud-first operations they behave like durable machine identities. They rarely expire, are easy to duplicate, and often sit outside central IAM records because they are embedded in automation, developer systems, and infrastructure tooling. That makes them difficult to classify, track, and revoke consistently. The technical problem is not SSH itself. It is the absence of an authoritative inventory that ties each key to a system, purpose, owner, and expiry state. Once that context is missing, the credential becomes a standing access object rather than a governed identity.

Practical implication: build a complete inventory of SSH keys and bind each one to a known owner, workload, and lifecycle state.

How static SSH credentials enable lateral movement

Static SSH keys are attractive to attackers because one stolen key can unlock multiple systems if the same credential is reused or broadly trusted. The compromise path is usually simple: extract the key from an endpoint, repo, or automation host, then use it to authenticate laterally without triggering the friction that human controls like MFA would create. PAM can be bypassed when the credential is already trusted at the target, and long-lived keys expand the time window for abuse. The architectural issue is that the access grant is separated from the actual workload need, so privilege persists long after the original task is complete.

Practical implication: replace long-lived SSH keys with short-lived certificates and reduce credential reuse across hosts and environments.

Why zero trust for machine access depends on time-bound credentials

Zero trust for machine access is not just about verifying the network path. It requires credentials that carry scope, duration, and context at the moment of use. SSH certificates can support this better than static keys because they can encode expiry and constrain where the credential is valid. That shifts control from a vault of reusable secrets to a policy model that issues access only for the approved task. In practice, the real control boundary is the credential lifetime. If access can be copied, cached, or reused indefinitely, the environment still relies on implicit trust even when the architecture claims otherwise.

Practical implication: align SSH access policy with zero standing privilege by issuing access only for defined systems, tasks, and time windows.

Threat narrative

Attacker objective: The attacker aims to turn one unmanaged machine credential into broad, low-noise access across infrastructure.

1. Entry occurs when attackers locate SSH keys or tokens on developer and admin endpoints, repositories, or automation systems.
2. Escalation follows when the stolen credential is reused across trusted systems, letting the attacker move laterally without MFA friction or clear ownership boundaries.
3. Impact lands as undetected infrastructure access, operational disruption, or financial loss when the attacker reaches critical systems before the credential is discovered and revoked.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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 machine identity governance failure, not a tooling inconvenience. When keys outnumber tracked accounts and live outside IAM records, the organisation has lost the ability to explain who or what can reach critical infrastructure. That is a governance failure because access exists without lifecycle ownership, not just a hygiene problem. Practitioners should treat SSH keys as governed identities, not leftover admin artifacts.

Static SSH keys create an identity blast radius that most PAM programmes still underestimate. One copied key can unlock multiple hosts, automation paths, and privileged workflows if the same secret is trusted broadly. That blast radius is larger than a single account compromise because the credential can be reused silently across systems. The implication is that credential scope, not just credential strength, determines real exposure.

Zero trust for machine access collapses if credentials can be reused after the approved task ends. SSH keys were designed for stable, human-paced administration, but modern workloads need time-bound access with explicit duration and context. Without that, the architecture still relies on standing trust even when the policy language says otherwise. Practitioners should recognise this as a boundary problem in machine identity design.

Ephemeral certificates are the named control pattern that closes the longest-lived SSH exposure window. The article points toward short-lived credentials because they preserve operational access while removing the permanence that attackers exploit. That matters for NHI governance because lifecycle control becomes measurable only when expiry is built into the credential itself. Teams should make credential duration a first-class governance control.

From our research:

• 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, according to the 2026 Infrastructure Identity Survey.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which shows how quickly privilege assumptions drift once identity becomes machine-driven.
• For a broader machine-identity view, see the Ultimate Guide to NHIs , Key Challenges and Risks for how unmanaged access expands across secrets, service accounts, and workload identities.

What this signals

SSH key governance is converging with broader machine identity management. Teams that still treat keys as an infrastructure edge case will keep missing the real control question, which is whether the organisation can prove ownership, duration, and revocation for every non-human credential. With 70% of organisations already granting AI systems more access than human employees, according to the 2026 Infrastructure Identity Survey, machine privilege is expanding faster than manual governance can absorb.

The operational signal to watch is credential lifespan. Once keys persist beyond the task they were created for, the access model stops behaving like zero trust and starts behaving like standing privilege with a different name.

Ephemeral credential trust debt: every day a machine secret remains reusable increases the amount of trust the organisation is carrying without active verification. That debt shows up later as audit failure, outage risk, or silent lateral movement.

For practitioners

• Map every SSH key to an owner and purpose Inventory keys across servers, developer endpoints, CI systems, and automation accounts, then record the system, business purpose, and revocation path for each one. If a key cannot be tied to a named owner and workload, treat it as an orphaned identity and remove or quarantine it.
• Replace long-lived keys with short-lived certificates Use time-bound certificates for administrative and automation access so the credential expires after the approved task. Constrain issuance to specific systems and workloads, and require re-issuance rather than reuse when the access need changes.
• Measure the gap between discovery and revocation Track how long unmanaged or unused SSH keys remain active after discovery, and use that interval as a control-quality metric. Shortening that gap reduces the window attackers can exploit copied credentials across infrastructure.
• Audit reuse across automation and admin paths Look for the same SSH credential appearing in scripts, images, jump hosts, and shared admin workflows. Reuse is a sign that the key has become infrastructure glue rather than a governed identity, which increases lateral movement risk.

Key takeaways

• Unmanaged SSH keys are a non-human identity problem because they create durable access paths with weak lifecycle control.
• The main risk is not just theft of a key, but the lateral movement it enables when that key is reused across trusted systems.
• Short-lived certificates, ownership mapping, and revocation metrics are the controls that reduce SSH identity blast radius.

Key terms

• SSH Key Sprawl: SSH key sprawl is the uncontrolled growth of reusable SSH credentials across servers, endpoints, scripts, and automation systems. It becomes a governance problem when keys cannot be tied to an owner, purpose, or expiry, leaving organisations unable to prove where machine access exists or how to revoke it safely.
• Ephemeral Credentials: Ephemeral credentials are short-lived access tokens or certificates issued for a specific task and then allowed to expire. In machine identity programmes they reduce standing privilege by limiting how long a credential can be reused, which narrows the window for theft, replay, and lateral movement.
• Identity Blast Radius: Identity blast radius is the amount of infrastructure exposure created when one credential or identity is compromised. For SSH and other non-human identities, it depends on credential reuse, scope, and trust relationships, not just the strength of the secret itself.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.

This post draws on content published by SSH Communications Security: hidden risk of unmanaged SSH keys in cloud-first environments. Read the original.