TL;DR: SSH keys remain a persistent access risk because they do not expire, rotate, or reliably disappear on offboarding, and Twingate says many organisations cannot inventory them accurately. Static credentials that servers trust without session-time identity checks keep turning governance gaps into invisible lateral access.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: SSH keys create standing server access that organisations struggle to inventory, revoke, and govern across their lifecycle.
Why it matters: IAM, PAM, and NHI teams need to treat SSH keys as governed credentials rather than convenience artefacts, because offboarding and audit controls fail when keys persist outside the IdP.
By the numbers:
- CrowdStrike's 2025 Global Threat Report found that 79% of attacks in 2024 were malware-free.
- Studies from Ponemon and Venafi have found that 60–90% of enterprises do not have a complete inventory of their SSH keys.
- Large organisations average more than 7,000 orphaned SSH keys with root or privileged access.
- An SSH key is used to authenticate to more than 10 servers on average.
Context
SSH keys are long-lived credentials that servers trust directly, which makes them hard to revoke cleanly when people move roles or leave. Once copied into authorized_keys, a backup, a CI runner, or a shared bastion, the key often escapes the lifecycle controls that govern human accounts and becomes a standing access path.
The governance gap is not simply that keys exist. The problem is that many organisations cannot tie each key to a named owner, a current purpose, and a revocation point, so offboarding becomes partial, delayed, or incomplete. SSH key management is the right lens because this is a lifecycle control failure, not just an authentication preference.
Key questions
Q: How should security teams inventory SSH keys across large environments before they can control risk?
A: Security teams should start by building a complete inventory of every SSH key pair, where it is used, and who owns it. They should map trust relationships, compare keys against policy, and flag orphaned or unapproved keys for immediate review. Without inventory, organisations cannot see hidden access paths, assess exposure, or remove backdoors that attackers may exploit.
Q: Why does SSH key sprawl make offboarding risky?
A: SSH key sprawl makes offboarding risky because the same public keys often appear across many servers and the corresponding private keys may still belong to former staff or contractors. Unless you track and remove those keys from authorized_keys files, replace shared credentials, and rotate any related accounts, access can survive the leaver process.
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.
Q: How do session brokers change privileged SSH access?
A: Session brokers replace direct SSH login with a mediated connection that authenticates the requester, checks entitlement, and then issues or proxies access to the target system. In privileged access, they reduce standing access by brokering short-lived sessions, recording activity, and, where used, verifying the user against the IdP before allowing the connection.
Technical breakdown
Why authorized_keys becomes a hidden trust registry
OpenSSH trusts any key listed in authorized_keys as a valid authenticator for that account. That design is simple and efficient, but it also means each copied public key becomes a durable authorisation entry unless someone removes it. In practice, keys accumulate on production hosts, bastions, backup images, and automation systems without a single inventory source of truth. The result is a distributed trust registry that outlives the people and services it was meant to represent. See the SSH Key and SSH Certificate Management Guide.
Practical implication: Treat authorized_keys as governed access inventory, not a convenience file, and reconcile it against ownership and offboarding records.
Why SSH keys break offboarding and role change workflows
SSH keys do not naturally follow joiner-mover-leaver processes because they are not centrally issued by the IdP and do not expire when an account is disabled. A user can leave, yet their public key can remain active on dozens of servers if no one knows where it was copied. Role changes create the same problem in slower motion: access that used to be legitimate remains valid long after it should have been narrowed or removed. That makes SSH access drift invisible to normal identity governance.
Practical implication: Tie server access to the same lifecycle events that disable human accounts so stale SSH access cannot survive a personnel change.
Why session brokering changes the trust model
Session brokering removes the server-side need to trust a stored key material artefact. Instead of checking a static credential on the target system, the broker validates the user against the IdP at session time and then proxies the connection. This shifts enforcement from distributed per-host credentials to a central identity decision, which is easier to log, revoke, and audit. It also separates human access from service and workload access, which matters because automation should not inherit the same model as an interactive operator.
Practical implication: Move interactive SSH to session-time authorization so the server no longer depends on persistent key material.
Threat narrative
Attacker objective: The attacker wants durable, trusted access to internal servers and the ability to move laterally without triggering malware-based detections.
- Entry comes from a stolen, leaked, or forgotten SSH key that still authenticates successfully to production systems. The attacker does not need malware or a zero-day because the server accepts the credential as legitimate.
- Escalation happens when that key has privileged access or reaches multiple hosts, letting the attacker move from one system to another with the same trusted identity. The article's cited breach patterns show how a single key can open a wide lateral path.
- Impact is prolonged undetected access, because successful logins look normal in the audit trail and the original owner often has no idea the key is still active. That creates months of exposure before anyone finds and removes the key.
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.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
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 keys create a standing-access model that identity teams can no longer govern reliably. The problem is not key strength but persistence: once a key is copied, it becomes a durable trust object that sits outside normal offboarding and recertification workflows. That makes SSH access a lifecycle issue first and an authentication issue second. Practitioners should treat every server-side key as a governed entitlement, not a one-time setup artefact.
Authorised key sprawl is a visibility failure, not just an inventory gap. Many teams know keys exist, but they do not know where each key is installed, who owns it, or whether it still corresponds to a current job role or workload. unused GitHub deploy keys and SSH keys is relevant because dormant keys are where governance decay becomes attacker opportunity. The practical conclusion is that access review has to start with discoverability, or it is not really a review at all.
Session brokering is valuable because it collapses the server's trust in static credential material. When the server no longer relies on a stored private key or long-lived public key entry, revocation becomes a central identity action instead of a manual hunt across hosts. That changes the operating model for human SSH access and draws a cleaner line between interactive users and workload identities. Practitioners should stop evaluating SSH only as a transport and start governing it as a privileged access channel.
SSH certificate authorities reduce some risk, but they do not remove the underlying credential model. Short-lived certificates improve expiry and revocation, yet they still require certificate issuance, CA custody, and policy maintenance. The article's deeper point is that many organisations are carrying operational debt in the form of managed static trust. The stronger control objective is to eliminate default dependence on persistent key material where interactive identity is already available.
What this signals
SSH access should be governed like any other privileged entitlement, not treated as a one-off configuration choice. When a credential survives role change, offboarding, and image reuse, it becomes part of the identity plane rather than the host plane. That means IAM, PAM, and NHI teams need one lifecycle view for human access and the machine-style artefacts that keep that access alive.
Key sprawl is the operational symptom of a deeper trust problem. If a server still depends on a copied key file to decide who may enter, then revocation depends on someone remembering every copy location. The programme implication is straightforward: central identity decisions scale better than distributed trust artefacts, especially where auditability matters.
Orphaned SSH keys are a form of identity debt. Each forgotten key extends the period in which an access path exists without an accountable owner, and that gap widens when keys are reused across many servers. Security teams should expect pressure to replace static key dependencies with session-based controls wherever interactive access still matters.
For practitioners
- Map every SSH key to an owner and purpose Build a current inventory that links each key to a person, service, or workload, then remove any key that cannot be justified by an active business use.
- Remove SSH access from leaver workflows Add server access to the same offboarding path that disables accounts so public keys do not survive HR termination or role changes.
- Reduce root access carried by keys Eliminate direct root logins where possible and scope remaining administrative access to the smallest set of hosts and commands needed.
- Broker interactive SSH through identity Use session-time authorization against the IdP so users authenticate centrally and the server no longer depends on distributed static key material.
- Separate automation keys from human access Use distinct controls for CI, scripts, and service accounts so machine access does not inherit the same model as interactive SSH users.
Key takeaways
- SSH keys behave like standing privileged credentials when they are copied broadly and never revoked, which turns a convenience mechanism into a governance liability.
- The article cites evidence that many enterprises cannot fully inventory SSH keys, and that orphaned keys can remain active across large server estates.
- Replacing static keys with session-brokered access changes revocation from a host-by-host cleanup task into a central identity event.
Related NHI Mgmt Group resources: SSH Key and SSH Certificate Management Guide · How to find unused GitHub deploy keys and SSH keys · Compute Engine Security Guide · Unix and Linux Privileged Access Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Leaver workflows fail when SSH keys remain valid after account deprovisioning. |
| NHI-05 — Overprivileged NHI | The article describes keys granting root or broad server access far beyond necessity. | |
| NHI-07 — Long-Lived Secrets | Persistent SSH keys remain valid until manually removed, which creates the central risk here. | |
| Recommendation — Remove SSH access during offboarding so public keys cannot survive the identity they were issued to. Reduce SSH key scope to the minimum set of hosts and commands required for the use case. Replace long-lived SSH secrets with short-lived, centrally governed access tokens or sessions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys are authenticators whose issuance, rotation, and revocation need lifecycle control. |
| Recommendation — Apply authenticator lifecycle controls so SSH credentials are revoked as soon as they are no longer needed. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Persistent SSH access is an entitlement problem, not just a host configuration issue. |
| Recommendation — Review and revoke SSH entitlements as part of access governance rather than treating them as static configuration. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle governance is required when human access persists through unmanaged SSH keys. |
| Recommendation — Tie SSH access removal to account lifecycle events and eliminate orphaned server credentials. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen SSH keys enable trusted login followed by lateral movement across hosts. |
| Recommendation — Hunt for stolen SSH credentials and monitor for lateral movement from hosts that share key-based access. | ||
Key terms
- SSH Key: A cryptographic key pair used to authenticate to servers and services via the Secure Shell (SSH) protocol. SSH keys associated with service accounts and automated pipelines are a common NHI attack vector and frequently found orphaned or unrotated.
- 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.
- Authorized_keys: The authorized_keys file is the server-side list of public keys allowed to authenticate to a user account. It is a governance boundary as much as a technical file, because stale entries extend access and undermine offboarding, rotation, and least privilege.
- Session Brokering: Session brokering is the pattern of placing a control layer between the external user and the target system. The broker authenticates the user, retrieves credentials from a secure store, injects them into the session, and records activity, which reduces direct secret exposure and improves accountability.
Deepen your knowledge
NHI governance, identity lifecycle management, and workload identity security 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.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org