Should organisations treat SSH access as part of PAM and access review programmes?

Why This Matters for Security Teams

SSH is often treated as an admin convenience, but in production environments it is privileged access and should be governed that way. If SSH keys, jump-host access, or automation accounts sit outside PAM and periodic access review, they become durable non-human identities with weak visibility and weak offboarding. That is the same pattern seen across broader NHI risk: NHI Mgmt Group notes that Ultimate Guide to NHIs reports only 5.7% of organisations have full visibility into their service accounts, which is why SSH often becomes an unmanaged privileged channel rather than a controlled access path.

The security issue is not the protocol itself. It is the combination of long-lived keys, shared accounts, embedded credentials, and review processes that only focus on human users. Once SSH is excluded, teams lose the ability to answer basic governance questions: who can reach production, which keys are still valid, and whether access matches current job function or task need. The OWASP Non-Human Identity Top 10 treats secret handling and lifecycle failures as core identity risks, not secondary hygiene issues. In practice, many security teams encounter SSH misuse only after an incident review exposes a forgotten key that retained production access for months.

How It Works in Practice

The right control model is to classify SSH as privileged machine access and fold it into the same governance stream used for PAM, secrets management, and access recertification. That means tracking SSH keys and certificates as identities, not just as technical artifacts. Where possible, teams should prefer short-lived SSH certificates or brokered sessions over static keys, because short TTLs reduce the window for abuse and make revocation meaningful.

A practical programme usually combines three layers. First, centralise issuance and storage so SSH access is discoverable. Second, enforce approval and step-up controls for production targets. Third, review entitlements on a schedule that includes both interactive admin access and machine-originated access paths. The NHI Lifecycle Management Guide is useful here because SSH access should have the same lifecycle events as any other non-human identity: create, approve, rotate, monitor, and revoke.

• Inventory all SSH keys, certificates, and break-glass accounts tied to production systems.
• Separate interactive admin SSH from application or automation SSH, then review both.
• Use PAM session brokering, command recording, or just-in-time elevation where the environment supports it.
• Rotate or expire credentials automatically instead of relying on manual cleanup.
• Reconcile access reviews against actual system reach, not just directory memberships.

For policy design, the OWASP Non-Human Identity Top 10 aligns with treating SSH secrets and credentials as governed NHI assets. These controls tend to break down when teams rely on shared root keys across fleets because attribution, revocation, and review become operationally ambiguous.

Common Variations and Edge Cases

Tighter SSH governance often increases operational overhead, requiring organisations to balance faster incident response against stronger access control. That tradeoff becomes visible in legacy estates, ephemeral cloud workloads, and automated deployment pipelines where SSH is still embedded in tooling. Current guidance suggests SSH used by humans and SSH used by machines should not be reviewed the same way, even if both reach the same server, because the risk signals differ.

Edge cases matter. Break-glass SSH accounts may be exempt from daily approvals, but they still need explicit ownership, logging, and post-use review. Shared vendor access is another common exception, yet it should still pass through PAM or a controlled gateway rather than being granted a standing key on target hosts. If certificates are used, they should be short-lived and tied to workload or operator identity, not issued as reusable long-term access tokens. The 52 NHI Breaches Analysis is a useful reminder that mature attackers routinely exploit identity sprawl, not just misconfigured firewalls. Organisations should also remember the broader exposure profile: NHI Mgmt Group reports in the Ultimate Guide to NHIs that 97% of NHIs carry excessive privileges, which makes standing SSH access especially hard to justify. The model breaks down most sharply in environments where root-level SSH is still used for normal operations because review evidence does not reflect actual privilege depth.

Related resources from NHI Mgmt Group

• What should organisations do after a user access review finds exceptions?
• Why do certificate-based authentication programmes still need access review and offboarding?
• When should organisations treat an NHI as a high-priority risk?
• When should organizations review access controls?