At small scale, SSH keys can work. As the number of users and hosts grows, key distribution, rotation, and removal become harder to manage consistently. That creates access sprawl and operational friction, especially when keys must exist on both the bastion and destination systems. The article argues that SSH certificates avoid much of this manual overhead.
Why SSH keys stop scaling cleanly in a bastion-based access model
ssh key are convenient when a small group of users reaches a small set of systems. In a bastion environment, though, every additional user, host, environment, or exception multiplies the number of keys that must be issued, copied, tracked, and removed. The result is not just more administration, but a weaker access model with more stale trust to clean up.
The core problem is that SSH keys are long-lived credentials tied to file placement and manual trust management. Once a key exists on a bastion and on a destination host, the organisation has created two operational control points that both must remain correct. That makes it easy for access to linger after role changes, offboarding, or incident response, especially when teams manage keys differently across environments.
This is where the article’s emphasis on SSH certificates matters: certificates change the model from repeated key distribution to time-bound, centrally issued trust. For teams that need a broader identity and secrets view of why long-lived credentials become hard to govern, NHIMG’s Ultimate Guide to NHIs is a useful reference point, especially on rotation, offboarding, and credential lifecycle control. Related breach patterns show the same failure mode when exposed keys or tokens persist longer than intended, as seen in ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation.
At scale, the real operational breakage is inconsistency. Keys that are supposed to be unique often get shared, copied into too many places, or left active after a user no longer needs them. Bastions can reduce network exposure, but they do not automatically solve entitlement sprawl if the authentication material itself remains static and manually maintained.
What access sprawl looks like once the bastion becomes the control plane
When teams rely on SSH keys across a growing bastion estate, the bastion often becomes the place where access is easiest to grant and hardest to revoke. That creates a hidden control plane problem: operators may still think they are managing a small number of named users, while in practice they are maintaining many host-by-host trust edges.
Three failure patterns tend to emerge. First, provisioning becomes inconsistent, because new access is added faster than it is documented. Second, revocation lags, because removing a user requires finding every copy of every key and every authorised destination. Third, exception handling becomes permanent, because temporary access paths are rarely revisited once business pressure passes. The longer this continues, the more the bastion ceases to be a security boundary and becomes a distribution layer for standing access.
That operational drift is exactly why certificate-based approaches are attractive. Time-limited credentials reduce the blast radius of missed cleanup and make access easier to expire by design rather than by memory. In practice, the difference is between continuously proving that a key is still allowed and simply assuming no one forgot to remove it.
Practitioners should also recognise that SSH key sprawl behaves like other credential sprawl problems, it weakens visibility before it creates a headline incident. If you cannot answer which key is valid for which operator, host pair, and time window, you do not have controlled access, you have accumulated trust. For readers who want a broader governance lens on rotation, lifecycle, and visibility, the Ultimate Guide to NHIs is the strongest internal starting point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | SSH keys are long-lived credentials that need rotation, storage and removal control. |
| NHI-02 — Identity Lifecycle and Offboarding | Bastion key sprawl creates stale access when users and hosts change over time. | |
| NHI-03 — Least Privilege and Access Scope | Growing bastion estates often expand key reach beyond the access actually needed. | |
| Recommendation — Move SSH access to time-bound credentials and enforce rotation plus revocation workflows. Define owner-based offboarding and expiry for every SSH key pair and host exception. Restrict each SSH credential to the smallest host set and command scope possible. | ||
| CIS Controls v8 | 6.3 — Access Granting and Revocation | The question centers on how access becomes hard to revoke as environments grow. |
| 6.4 — Least Privilege Access Principles | Key sprawl broadens who can reach what through the bastion path. | |
| Recommendation — Automate SSH access revocation and verify removal from every bastion and target host. Apply least privilege to bastion access and reduce shared or reusable SSH trust. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity Management, Authentication and Access Control | SSH keys are an access control mechanism whose lifecycle must be governed. |
| Recommendation — Manage SSH credentials through controlled issuance, review and revocation processes. | ||
Practitioner Guidance
What to prioritise: Treat key lifecycle management as the primary control problem, not just SSH authentication. If keys are still being copied manually between bastions and destinations, the first gap to close is revocation speed and ownership, because that is where stale access accumulates fastest.
What to verify: Confirm that every active SSH key has a clear owner, a bounded use case, and a removal path that actually works across bastion and target systems. If offboarding or emergency revocation depends on people remembering where keys were installed, the control is not reliable enough for scale.
Common mistake: Using the bastion as proof that access is centralised. A central jump host can still hide a distributed, long-lived credential problem if the organisation has not moved to short-lived, auditable trust.
Practitioner takeaway: The scaling failure is not SSH itself, it is static trust with manual cleanup. Once the bastion becomes the place where access is copied rather than issued and expired, operational friction turns into persistent access risk.
