If teams spend more time distributing, revoking and auditing keys than using them for real operational access, mediated access usually wins. The decision is less about convenience than about whether the programme can reliably enforce lifecycle controls at scale. Direct key management works only when ownership, rotation and offboarding are tightly disciplined.
When does direct SSH key management stop scaling?
Direct SSH key management starts to fail when the operational burden is no longer justifiable by the level of control it gives you. If teams must manually distribute, inventory, rotate and revoke keys across many hosts and users, the process becomes fragile, slow and easy to drift. That is the point where mediated access, which centralises policy and session control, usually becomes the safer operating model.
In practice, the question is not whether keys can be managed at all, but whether the organisation can keep ownership, expiry and offboarding accurate under change. Direct key handling can still work in small, stable environments with disciplined administration, but it gets weaker as the number of systems, teams and exceptions grows.
For a more detailed treatment of SSH key sprawl, bastions and certificate-based patterns, see SSH Key and SSH Certificate Management Guide.
Why mediated access changes the security model
Mediated access changes the control point from the key itself to the access path. That means users can authenticate through a central policy layer, gain time-bound access, and have activity logged in one place rather than relying on every host to trust a long-lived public key. This is especially valuable where the real risk is not login failure, but stale access that survives role changes or account offboarding.
It also reduces the number of places where a key can be copied, reused or forgotten. The trade-off is that mediated access introduces its own dependency on the access platform, bastion, broker or gateway being available and correctly configured. The control is stronger when it narrows standing access and improves observability, not merely when it adds another hop.
Current practice increasingly favours mediated models such as SSH certificates, just-in-time elevation and jump-host enforcement when organisations need consistent lifecycle control across many admins, contractors or ephemeral environments. For teams evaluating that shift, the core question is whether they want to govern individual secrets or govern the access decision itself.
When the access path is centralised, PAM Buyer’s Guide is a useful comparison point for vault-centred and JIT-centred patterns.
What should drive the decision in real operations?
The best decision rule is simple: if the environment requires frequent changes to who should have access, direct key management tends to accumulate risk; if access is rare, static and tightly owned, direct management can remain acceptable. The closer your operations get to shared admin access, contractor use, production break-glass and rapid onboarding or offboarding, the more mediated access pays off.
Another practical test is whether you can prove revocation quickly. If a departed engineer, outsourced operator or compromised endpoint could retain access because keys are scattered across hosts, the architecture is already too loose. If you can remove or expire access centrally and verify the change from logs or broker records, the organisation has a stronger control story.
Where teams are already struggling with lifecycle discipline, a mediated model is often less about modernisation and more about restoring control boundaries. That is why key management guidance and certificate-based access patterns are usually paired with stronger offboarding, rotation and audit expectations.
For a cloud-oriented analogue of the same lifecycle problem, Cloud Workload Identity Guide shows how organisations replace static secrets with temporary, centrally governed access.
Risk and Threat Considerations
Direct SSH keys create exposure when they outlive the people, systems or purposes that justified them. The main risk is not just compromise, but persistence: a copied private key or orphaned authorized_keys entry can preserve access long after the original owner has moved on. Mediation reduces that blast radius by concentrating policy and session control, but only if the broker itself is protected and lifecycle events are actually enforced.
Failure mechanism: Keys drift into servers, laptops and automation scripts, then survive role changes, endpoint loss or incomplete deprovisioning, leaving unauthorised access paths in place.
Impact: Attackers or former users can continue accessing systems, and defenders may lack a reliable central record to confirm which keys still work.
For an operational example of how exposed access material can lead to real misuse, CI/CD pipeline exploitation case study illustrates how SSH key placement can become an attack path when credentials are reachable in the wrong place.
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 are authenticators whose lifecycle must be controlled. |
| IA-9 — Service Identification and Authentication | SSH key use for servers, automation and non-human access aligns to service authentication. | |
| AC-6 — Least Privilege | Mediated access is chosen to reduce standing access and limit privilege. | |
| Recommendation — Enforce rotation, revocation and inventory for SSH keys as authenticators. Use service authentication controls when SSH keys protect machine-to-machine access. Apply least-privilege access paths and remove unnecessary direct SSH reach. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The decision is about governing who can access systems and how that access is mediated. |
| Recommendation — Define and enforce access control rules for SSH and mediated sessions. | ||
| CIS Controls v8 | CIS-5 — Account Management | SSH key ownership, revocation and offboarding are account-management problems. |
| Recommendation — Keep accounts and their SSH access rights inventoried, current and removed on exit. | ||
Practitioner Guidance
What to prioritise: Start with the environments where key ownership is weakest and the consequences of stale access are highest, typically production administration, contractors and automation. Those are the places where mediated access usually delivers the clearest reduction in standing privilege and audit gaps.
What to verify: Before staying with direct key management, verify that you can answer three questions quickly: who owns each key, where it is authorised, and how fast it is revoked after offboarding. If any of those answers depends on manual detective work, the model is already under strain.
Practitioner takeaway: Direct SSH key management is only defensible when lifecycle discipline is consistently provable; once that proof becomes hard to sustain, mediated access is usually the more secure operating choice.
Related resources from NHI Mgmt Group
- What breaks when organisations keep managing EC2 access with manual SSH keys and bastion hosts?
- What breaks when organisations keep adding SSH keys and security layers without fixing the underlying access model?
- How should security teams govern API keys used for generative AI access?
- What breaks when organisations keep using shared API keys for machine-to-machine access?