A common mistake is assuming that integrating identity with server login automatically solves SSH key governance. In practice, the hard part is still lifecycle control: provisioning, rotation, revocation, and enforcing access boundaries across cloud and on-prem systems. Teams also underestimate how quickly unmanaged keys become a privileged access liability.
SSH access is often treated as an identity problem when it is really a lifecycle problem
Identity platforms can centralise login, but SSH governance still fails if keys, certificates, and fallback access paths are not owned and reviewed as assets in their own right. The practical issue is not just “who can log in”, it is how access is created, how long it lives, what it can reach, and how quickly it is removed when the underlying need changes.
That is why the strongest controls are still lifecycle controls: discovery, provisioning, rotation, expiry, revocation, and ownership. A login flow can look well integrated while stale keys, shared keys, and unmanaged authorized_keys files continue to provide durable access to servers that identity teams no longer see.
For SSH specifically, the control boundary must span both cloud and on-prem systems. A platform that governs interactive sign-in but does not cover bastions, local user keys, automation accounts, or certificate issuance only shifts the problem into places where review is weaker and exceptions accumulate.
What teams misjudge about SSH boundaries and privileged access
Teams often assume SSH access can be made safe by authenticating through the identity layer and then leaving the server-side trust model mostly intact. In practice, SSH is a privileged access channel, so the real question is whether access is bounded, attributable, and short lived enough to prevent privilege creep.
The common failure mode is reuse. When the same key is copied across systems, environments, or administrators, one compromise turns into broad reach, and revocation becomes slow because no one is sure which hosts still trust the key. If a key persists beyond the job, contractor, or automation it was meant for, the platform has not solved governance, it has only hidden it.
Another recurring mistake is treating server login as the end state rather than one step in a wider access model. SSH certificates, bastions, and just in time elevation can all help, but they only improve security when they are paired with clear ownership and an enforced expiry model. The control objective is to reduce standing access, not to preserve it in a more modern wrapper.
Why unmanaged keys become a liability at scale
Unmanaged keys become risky because SSH access tends to spread faster than teams can inventory it. Once developers, operators, scripts, and vendors each maintain their own path, the estate develops hidden trust edges that are difficult to monitor and even harder to remove during offboarding or incident response.
That risk grows with scale. A single orphaned key on one host is a maintenance issue; dozens of orphaned keys across fleets become an access-control failure that can survive role changes, cloud migrations, and infrastructure refreshes. Identity platforms do not automatically remove those trust relationships unless the server estate is continuously reconciled against the source of truth.
For a deeper treatment of governance, review SSH Key and SSH Certificate Management Guide, which covers key sprawl, authorized_keys risk, bastions, and rotation. The broader access lifecycle patterns in IAM and IGA Basics are also useful when SSH access has to be governed across humans and machines.
Risk and Threat Considerations
SSH access becomes dangerous when a trusted key or certificate outlives the person, process, or system that was supposed to use it. The main exposure is not the initial login itself, but the durable and often invisible privilege that remains after ownership has drifted or revocation has not been enforced.
Failure mechanism: Stale or duplicated keys, weak offboarding, and incomplete server reconciliation let an attacker or former user keep working access after the original approval has expired.
Impact: The result can be persistent privileged access, lateral movement across systems, and a much larger blast radius during compromise because the trust path is already established.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys and certificates are authenticators that require lifecycle control. |
| AC-6 — Least Privilege | SSH access should be bounded to only the systems and actions needed. | |
| IA-9 — Service Identification and Authentication | SSH automation and machine access often use non-human authenticators. | |
| Recommendation — Enforce rotation, revocation, and expiration for SSH authenticators. Restrict SSH access to the minimum privileges required. Authenticate SSH automation and service access with managed, scoped credentials. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | SSH access governance depends on defining and enforcing access rules. |
| A.8.5 — Secure authentication | SSH keys, certificates, and login paths require secure authentication controls. | |
| A.8.2 — Privileged access rights | SSH commonly provides privileged server access that must be controlled. | |
| Recommendation — Define and enforce SSH access rules through the access control policy. Use secure authentication mechanisms and protect SSH authenticator material. Review and limit privileged SSH access rights on an ongoing basis. | ||
| CIS Controls v8 | CIS-5 — Account Management | SSH keys and login paths must be provisioned and removed with account changes. |
| CIS-6 — Access Control Management | SSH access boundaries and revocation are core access-control concerns. | |
| Recommendation — Track SSH-related accounts and remove access promptly when no longer needed. Centralise SSH access approvals and enforce timely revocation. | ||
Practitioner Guidance
What to prioritise: Treat SSH access as an inventory and lifecycle problem before you treat it as a login problem. If you cannot answer where keys live, who owns them, and when they expire, you do not yet have control.
What to verify: Check that revocation actually propagates to servers, bastions, automation, and break-glass paths. Identity integration is not sufficient unless the server-side trust material is removed or time bound.
Common mistake: Teams often measure whether authentication works and stop there. The better measure is whether access disappears on schedule and whether orphaned trust paths are discoverable before they become incident paths.
Practitioner takeaway: The security win comes from shortening trust duration and shrinking the places where SSH access can persist, not from simply routing server login through a platform.
Related resources from NHI Mgmt Group
- What do teams get wrong about managing open access in complex file and collaboration platforms?
- What do teams get wrong about managed deployment platforms and identity governance?
- What do teams get wrong about managing access with configuration as code?
- What do security teams get wrong about centralised identity platforms?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
