SSH keys expose standing access gaps in enterprise remote operations

At a glance

What this is: This is SSH Communications Security’s analysis of how unmanaged SSH keys create invisible, persistent access paths that traditional PAM controls often miss.

Why it matters: It matters because SSH key sprawl affects NHI governance, privileged access control, and lifecycle management across infrastructure, operations, and hybrid identity programmes.

👉 Read SSH Communications Security’s webinar on unmanaged SSH keys and keyless access

Context

SSH key sprawl is a non-human identity problem: every unmanaged key is a credential that can outlive the person, system, or process that created it. In hybrid environments, those keys often sit outside the normal access review cycle, which means standing access can persist long after ownership has become unclear.

Traditional PAM assumes privileged access is mediated, visible, and centrally enforced. SSH keys break that assumption when teams can place their own keys on servers, bypass control paths, and create trust chains that are difficult to discover or revoke without dedicated inventory and policy enforcement.

Key questions

Q: What breaks when SSH keys are not centrally managed?

A: Unmanaged SSH keys create persistent access paths that are difficult to inventory, audit, and revoke. They can bypass PAM, survive role changes, and continue authenticating long after ownership is unclear. The result is standing privilege that expands the blast radius of any stolen or shared key, especially in hybrid environments with many servers and automation jobs.

Q: Why do SSH keys complicate privileged access governance?

A: SSH keys complicate governance because they can be installed directly on hosts and reused across systems without repeated approval. That makes entitlement review, session mediation, and revocation harder than with brokered access. If teams cannot see where keys are accepted, they cannot reliably prove who has privileged access or when it should be removed.

Q: How can security teams reduce the risk of shared SSH keys?

A: They should eliminate shared private keys wherever possible, map each key to a named owner, and move high-risk access to short-lived certificates. Shared keys are dangerous because no one can prove who is using them at a given moment, and the same credential may grant access to multiple critical systems at once.

Q: When should organisations replace SSH keys with certificates?

A: They should replace SSH keys with certificates when access needs to be time-bound, revocable, and tied to a clear lifecycle. If a key can persist across teams, systems, or months of change, the organisation has already outgrown static key management. Certificates are the better fit when operational continuity must coexist with tighter control.

Technical breakdown

Why SSH keys become invisible standing privilege

SSH keys function as durable credentials that authenticate a user or workload without repeated interactive approval. In practice, the problem is not the protocol itself but the way keys accumulate across servers, scripts, administrators, and automation jobs. Once a private key is copied, it can authenticate indefinitely unless the key is found and removed everywhere it is trusted. That makes the key an instance of standing privilege, not just an access token. Fingerprinting, inventory, and ownership mapping are the only way to know which keys are active and where they work.

Practical implication: build a complete key inventory before trying to enforce policy or rotation.

How SSH keys bypass PAM controls in practice

PAM tools are designed to govern high-risk human or service access through mediated sessions, approvals, and logging. SSH keys often sit outside that path because they can be installed directly on hosts, embedded in automation, or shared between operators. Once a key is accepted by the target system, PAM may never see the session. That creates an access layer the control stack does not govern, especially when users can alter key restrictions or create local trust relationships without detection. The result is privilege that exists, but is not administered through the privileged access programme.

Practical implication: treat host-level SSH key acceptance as a control boundary that PAM alone does not close.

Why certificates change the trust model for remote access

Certificate-based SSH access replaces durable secrets with centrally issued, time-limited credentials. The key distinction is lifecycle: a certificate expires after a short window, so leaked credentials have limited utility and no long-term reuse value. This aligns remote access with zero trust principles by tying each session to a specific role, time bound, and issuing authority. It also reduces the operational risk of broad key reuse because identity is verified at issuance rather than preserved through copyable private material. The model is stronger when discovery, policy, and revocation are connected end to end.

Practical implication: use certificate issuance to shrink the blast radius of remote access without rewriting applications.

Threat narrative

Attacker objective: The attacker’s objective is durable privileged access across critical infrastructure with minimal visibility and no need for repeated authentication.

1. Entry occurs when an unmanaged SSH key is accepted on a server or copied into an automation path without central oversight.
2. Escalation follows when the same key is reused across systems or carries root-level permissions, allowing the holder to move from ordinary access to privileged execution.
3. Impact appears as lateral movement and production control loss, because a single trusted key can open multiple critical hosts and remain usable until manually discovered and revoked.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 keys are a standing-privilege problem, not a protocol problem. The protocol is stable, but the governance model around it often is not. Once keys are copied, reused, and left outside lifecycle control, they become durable access artefacts that outlast ownership and review. Practitioners should treat unmanaged SSH keys as privileged identities that need inventory, accountability, and expiry discipline.

Traditional PAM does not close the SSH trust gap by itself. PAM is effective when access is brokered through a controlled path, but SSH keys can be dropped directly onto servers and used outside that path. That means the control plane and the access plane are no longer aligned. The implication is that teams need to map where privileged access is actually being granted, not where they assume it is being mediated.

Ephemeral certificates reduce key persistence, but only after discovery exposes the hidden estate. Certificates change the lifecycle of remote access, yet they do not fix unknown ownership or unmanaged trust chains on their own. The governance question is which credentials still survive without expiration and which systems still trust them. Practitioners should treat certificate migration as a lifecycle redesign, not a cosmetic replacement.

Standing trust chains are the named failure mode this article exposes. SSH keys can connect systems in ways that are hard to audit, hard to revoke, and easy to inherit across teams. That is a lifecycle and accountability failure, not simply a secrets-management gap. The practical conclusion is that access governance must follow the credential across every host that accepts it.

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.
• That gap is why teams should also review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when they move from static SSH keys to time-bound certificates.

What this signals

SSH key governance is converging with broader machine identity management. The same operational pattern appears across service accounts, automation tokens, and infrastructure access: credentials persist longer than the business need that created them. That is why a key inventory is not a narrow SSH task, but a prerequisite for broader identity lifecycle control. Readers should expect more pressure to connect SSH governance to Top 10 NHI Issues and certificate lifecycle oversight.

A practical programme signal is that certificate-based access only improves security if the organisation can prove where the old keys lived, who owned them, and which hosts still trust them. Without that baseline, migration simply moves uncertainty from a secret file to an unmanaged certificate estate. That is why discovery must come before replacement, not after it.

For practitioners

• Inventory every SSH key and trust path Scan servers, automation jobs, and administrator workstations for accepted keys, then map each key to an owner, purpose, and target host before changing policy.
• Enforce host-level key restrictions centrally Prevent local users from adding or loosening key permissions on servers, and validate that restriction settings are enforced uniformly across production systems.
• Replace long-lived keys with short-lived certificates Issue time-bound SSH certificates through a central authority so leaked credentials expire quickly and cannot be reused indefinitely across the environment.
• Tie key revocation to lifecycle events Revoke access when roles change, systems are retired, or automation is decommissioned so the credential cannot continue to authenticate after its business purpose ends.

Key takeaways

• Unmanaged SSH keys create durable privileged access that can outlive the people and systems that created them.
• The article shows how a single trusted key can open multiple production systems and bypass PAM oversight.
• Discovery, central policy enforcement, and short-lived certificates are the controls that shrink SSH access blast radius.

Key terms

• SSH Key: An SSH key is a cryptographic credential used to authenticate remote access without a password. In enterprise environments it often becomes a durable non-human identity credential, so the governance problem is not just authentication but ownership, scope, and revocation across every host that trusts it.
• Standing Privilege: Standing privilege is access that remains active outside a specific task or approval window. For SSH, it appears when keys stay valid across systems for long periods, making privilege difficult to review and easy to reuse even after the original business need has changed.
• Certificate-Based Access: Certificate-based access uses centrally issued, time-limited credentials instead of long-lived private keys. It narrows the lifetime of a trust decision and makes remote access easier to expire, but it only works well when discovery, policy, and revocation are managed as one lifecycle.

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 operational access governance, it is worth exploring.

This post draws on content published by SSH Communications Security. Read the original.