Topic starter
06/11/2026 6:56 pm
TL;DR: SSH keys create a durable access problem because they often outlive the people and services that received them, according to Twingate's analysis of server access. For practitioners, the real issue is not key strength but whether offboarding and inventory controls can actually remove standing server access.
Editorial analysis by NHI Mgmt Group, based on content published by Twingate: “Stop Relying on Static SSH Keys”.
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.
Key questions
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: SSH keys behave like standing privileged credentials when they are copied broadly and never revoked, which turns a convenience mechanism into a governance liability.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:56 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: SSH key sprawl turns access governance into a liability