What breaks when privileged users can place SSH keys directly on target systems outside PAM controls?

Why This Breaks Privileged Access Controls

Letting privileged users place ssh key directly on target systems creates an access path that PAM no longer mediates. That means the system can authenticate the key even when the approved session, checkout, or ticket has ended. The result is standing access that survives outside central policy, which undermines session recording, approval enforcement, and revocation. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts, a reminder that unmanaged identity paths are often discovered only after misuse.

This is not just a procedural exception. It changes the trust model from controlled, time-bound access to local persistence on the asset itself. The same weakness shows up in broader identity failures covered by the Ultimate Guide to NHIs — Key Challenges and Risks and in the access-control expectations described by OWASP Non-Human Identity Top 10. In practice, many security teams discover the problem only after a key has already been copied, reused, or left behind on a server that PAM can no longer govern.

How the Failure Manifests in Operations

When SSH key placement is allowed outside PAM, three controls begin to fail at once: authorization, auditability, and revocation. The user may still be “approved” at the ticket level, but the system now has a durable credential that can be reused without another PAM-mediated checkout. If the key is added to

authorized_keys

• Session path visibility is lost because PAM no longer sits in the middle of the connection.
• Revocation becomes manual if the key is copied to multiple hosts or embedded in automation.
• Audit logs show file changes, but not always the intent, approval context, or full session trail.
• Blast radius increases if the same key is reused across systems or shared by operators.

Best practice is evolving toward centralised key issuance, short-lived credentials, and controls that prevent direct edits to trust files on target systems. NIST control families such as NIST SP 800-53 Rev 5 Security and Privacy Controls support least privilege, account management, and audit logging, but they still need local enforcement to stop operators from bypassing PAM in the first place. The operational fix is to treat SSH key installation as a governed change, not as a convenience action by any privileged user. These controls tend to break down in legacy Unix estates where admins retain direct shell access and configuration management cannot reliably prevent local key injection.

Where the Real-World Edge Cases Appear

Tighter key governance often increases operational friction, requiring organisations to balance emergency access speed against the risk of hidden persistence. That tradeoff is most visible in break-glass scenarios, clustered systems, and automation pipelines where teams want rapid recovery but also need revocation certainty. There is no universal standard for this yet, but current guidance suggests that emergency access should still be time-bound, logged, and centrally revocable.

Edge cases usually involve service accounts, deployment tooling, or local admin exceptions that bypass the normal PAM workflow. If SSH keys are needed for automation, they should be issued per system or per job, rotated frequently, and removed by policy at the end of the task. Where local access cannot be eliminated, organisations should at least detect unauthorised edits to SSH trust files and compare them against approved access records. For further practitioner guidance, NHI Mgmt Group’s Ultimate Guide to NHIs — Standards explains why visibility and lifecycle controls must extend beyond the vault. In environments with unmanaged root access or manually administered legacy appliances, PAM can be present and still effectively blind.

Related resources from NHI Mgmt Group

• What breaks when organisations do not have PAM in place for privileged accounts and servers?
• What breaks when end users still see database credentials or SSH keys?
• What breaks when SSH keys are managed manually across many systems?
• What breaks when SSH keys are used as standing privileged access in trading environments?