Notifications
Clear all
Topic starter
25/06/2026 12:47 am
TL;DR: SSH keys remain widely used for automation and remote access, but unmanaged, static keys can bypass PAM, create hidden trust chains, and leave organisations unable to track who can reach critical systems, according to SSH Communications Security. The governance problem is not key usage itself, but persistent, unscoped access that survives outside normal review and lifecycle controls.
NHIMG editorial — based on content published by SSH Communications Security
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
SSH Communications Security's full webinar covers the operational detail this post intentionally leaves for the source:
- Live demonstration of the key management workflow for discovering unmanaged SSH keys across servers and automation paths
- Detailed examples of how certificate-based access redirects existing SSH clients without requiring code changes
- Operational discussion of policy enforcement, remediation sequencing, and lifecycle controls for long-lived keys
- The vendor's own product demonstration showing how the discovery and migration process is implemented in practice
👉 Read SSH Communications Security’s webinar on unmanaged SSH keys and keyless access →
SSH keys and standing access gaps: what IAM teams are missing?
Explore further
25/06/2026 9:47 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: SSH keys expose standing access gaps in enterprise remote operations
