Why do unmanaged SSH keys create persistent access risk?

Why This Matters for Security Teams

Unmanaged SSH keys are dangerous because they are not just access artifacts, they are durable access paths. A key can outlive the employee, contractor, workload, or incident that originally justified it, which means access can remain active long after it is forgotten in tickets, scripts, or home directories. That is exactly the kind of standing privilege that undermines NIST Cybersecurity Framework 2.0 principles and the control expectations described in Ultimate Guide to NHIs.

The operational risk is not limited to shell access. SSH keys often unlock jump hosts, deployment servers, storage nodes, and service accounts that inherit broader trust than the key itself suggests. When organisations fail to track ownership, purpose, and expiry, they create a hidden layer of standing access that bypasses normal joiner-mover-leaver workflows. NHIMG research shows that 71% of NHIs are not rotated within recommended time frames, which helps explain why stale access remains so common in production environments.

In practice, many security teams discover this only after a contractor has left, a server has been rebuilt, or a key has already been used in an incident, rather than through intentional access review.

How It Works in Practice

SSH keys become persistent risk when they are treated as convenience credentials instead of managed identities. A key copied into a laptop, CI runner, admin jump box, or automation script can continue authenticating until it is explicitly removed from every authorised_keys file, bastion policy, or orchestration system. If there is no ownership record, there is no reliable way to know whether the key is still needed, and if there is no expiry, there is no natural pressure to retire it.

Good practice is to treat SSH keys as lifecycle-bound NHIs. That means assigning an owner, recording the business purpose, scoping where the key can authenticate, and setting a review or rotation interval. The best implementations pair this with central inventory, automated discovery, and periodic revocation checks so stale keys do not remain invisible. NHIMG’s Top 10 NHI Issues and the Lifecycle Processes for Managing NHIs section both emphasise that visibility and offboarding are foundational, not optional.

• Inventory every SSH key and map it to an owner, system, and purpose.
• Replace indefinite keys with short-lived access where possible, or tightly controlled rotation where not.
• Remove keys from hosts, vaults, scripts, and CI/CD pipelines when the workload or person changes.
• Monitor for orphaned keys on servers and in configuration repositories.

For control design, the OWASP Non-Human Identity Top 10 is useful because it frames unmanaged credentials as an identity security issue, not just a server hygiene problem. These controls tend to break down in large fleets with ad hoc automation because keys are embedded in legacy scripts, vendor tooling, and emergency access paths that no one fully inventories.

Common Variations and Edge Cases

Tighter SSH key governance often increases operational overhead, requiring organisations to balance access speed against revocation discipline. That tradeoff is real in environments with break-glass administration, unmanaged appliances, or legacy Unix estates where modern secret brokers are not yet available. Current guidance suggests that these exceptions should be explicitly documented, time-bounded, and reviewed, rather than left as permanent carveouts.

There is also no universal standard for SSH key expiry in every environment. Some teams rely on periodic rotation, while others move to short-lived certificates or brokered access to reduce persistence altogether. The right model depends on how much automation exists, how often access is needed, and whether the environment can support central policy enforcement. The Key Challenges and Risks guidance is especially relevant where access sprawl, third-party administration, or weak offboarding processes make stale keys hard to detect.

In regulated or high-assurance environments, unmanaged SSH keys can also become audit failures because the organisation cannot demonstrate who had access, why it existed, or when it was removed. That is why NHI lifecycle governance matters: persistent credentials create persistent accountability gaps.

Related resources from NHI Mgmt Group

• When does JIT access create more risk than it reduces?
• Why do access keys create persistent identity risk in AWS environments?
• Why do manual access processes create risk in critical infrastructure environments?
• Why do emergency access exceptions create long-term governance risk?