TL;DR: Bastion hosts concentrate authentication, session handling, and lateral movement into one always-on server that attackers expect to exist, according to Twingate, and even managed variants can expose backend systems when the bastion is compromised. Zero trust breaks that assumption by removing the jump box from the access path entirely.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Bastion hosts concentrate SSH trust and reachability into one server, making compromise of the jump layer a high-blast-radius event.
Why it matters: Practitioners responsible for SSH and privileged remote access need to treat bastions as a governance problem, because one shared access layer can collapse identity, session, and network controls at once.
Context
A bastion host is a privileged intermediary that sits between administrators and the systems they manage, so its failure mode is different from an ordinary server outage. When the same box carries authentication, session brokering, and network reachability, it becomes both a control point and a concentration point for risk.
That design made sense in older perimeter-based environments, but it weakens under zero trust because the access decision is no longer tied to a single internal jump point. SSH governance works better when the target host is not exposed on the internet and access is bound to identity and session policy instead of a shared network foothold.
Key questions
Q: How do bastion hosts increase SSH blast radius?
A: A bastion host increases SSH blast radius by concentrating privileged entry on one hardened jump server, so compromise of that host can expose many downstream systems and credentials. If it also handles authentication, session brokering, or key forwarding, the attacker can reuse one foothold to pivot across multiple SSH targets and recorded sessions.
Q: Why does SSH key sprawl make offboarding risky?
A: SSH key sprawl makes offboarding risky because the same public keys often appear across many servers and the corresponding private keys may still belong to former staff or contractors. Unless you track and remove those keys from authorized_keys files, replace shared credentials, and rotate any related accounts, access can survive the leaver process.
Q: What is the difference between a bastion host and zero trust access?
A: A bastion host is a controlled jump point for SSH access, while zero trust access makes a per-session decision based on identity, device, policy and context. A bastion often grants network reach after entry, but zero trust access evaluates each session and usually narrows standing exposure with stronger policy enforcement and shorter-lived credentials.
Q: What signs suggest a bastion host has become a security liability?
A: A bastion host becomes a security liability when it runs stale software, accumulates broad administrative trust, logs too much sensitive session data, or is shared for many purposes without strong segregation. Signs include delayed patching, unused accounts, weak key management, and uncontrolled network paths from the jump box to many internal systems.
Technical breakdown
Why bastion hosts become attack magnets
A bastion host is a deliberately exposed administrative relay, which means it inherits the trust of everything behind it. Attackers do not need a novel technique to value it: if they obtain a shell on the bastion, they can often observe active sessions, capture credentials, or reuse trusted network position to reach backend hosts. The architectural issue is not only exposure, but concentration. The bastion turns many separate systems into one reachable choke point, so patch lag, misconfiguration, or credential reuse all compound into the same failure domain.
Practical implication: Treat the bastion itself as a high-value security boundary, not just another server, and reduce the amount of backend trust it can inherit.
How SSH key distribution weakens offboarding
Many bastion designs rely on SSH keys spread across authorized_keys files or managed through configuration tooling. That model ties access to a secret artifact rather than to a live identity decision, so revocation becomes a search problem across hosts, teams, and automation layers. The practical weakness is lifecycle drift: people leave, roles change, but keys can remain valid long after the business relationship ends. In that sense, the bastion often behaves like a credential warehouse rather than a governed access broker. See the Joiner-Mover-Leaver (JML) Guide.
Practical implication: Replace ad hoc key sprawl with identity-bound access that can be revoked centrally when a user or contractor leaves.
Why zero trust removes the need for a jump box
Zero trust shifts the control point from network presence to per-session authorization. Instead of placing users on a trusted internal network and then letting them traverse to anything reachable, the model verifies identity, device posture, and policy at the moment of access. For SSH, that means the target host should not need an internet-facing management port or a publicly reachable intermediary. The session is brokered at the edge, but the trust decision belongs to identity controls, not to the existence of a shared jump server. See the Secure Remote Access Beyond VPN Guide.
Practical implication: Design remote administration so access is brokered per session rather than concentrated in a public jump host.
Threat narrative
Attacker objective: The attacker wants to turn one compromised administrative relay into broad access across the backend environment.
- Initial access begins with an exposed bastion management surface, typically SSH or HTTPS on a public address.
- Credential access follows when stored keys, cached sessions, or agent-forwarded credentials are present on the bastion.
- Lateral movement becomes straightforward because the bastion is trusted to reach backend hosts by design.
- Impact occurs when the attacker uses that position to reach databases, virtual machines, or administrative panels at scale.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bastion hosts create a trust concentration problem, not just an exposure problem. The issue is that one server now carries identity checks, session handling, and backend reachability at the same time. That concentration means a single compromise can invalidate several control layers at once, so the real failure mode is architectural overloading of one privileged intermediary.
Offboarding breaks down when SSH access is still anchored to distributed keys. A bastion that depends on authorized_keys files or copied secrets makes revocation operationally fragile. Access removal becomes an inventory exercise across hosts instead of a single governance action, which leaves former access paths alive longer than teams expect.
Zero trust weakens the assumption that administrators need a shared internal jump point. The access decision should move to the session edge, where identity, device, and policy can be evaluated together. When the network is still treated as the trust boundary, the bastion stays in place as a legacy proxy for trust that no longer matches the operating model.
Identity-bound SSH changes the blast radius of a compromise. A model that authenticates the person and the session, rather than the key and the host, narrows the value of any single access component. That matters because the most dangerous server is not the one with the most traffic, but the one that can silently inherit trust for everything else.
What this signals
Identity-based administrative access is replacing the old jump-box model. Bastions solved a perimeter-era problem, but they now force teams to trust one always-on server with too much reach. The next governance step is to make session policy, not host location, the control point for SSH and other privileged access.
Blast-radius control is the real metric for privileged remote access. The question is not whether a jump server is hardened enough, but how much backend trust it inherits if it fails. That framing shifts architecture reviews from server hygiene to privilege containment and access-path design.
For practitioners
- Audit bastion blast radius Map every backend system, database, and control plane the bastion can reach, then classify which of those paths exist only because the jump host is trusted.
- Remove key-based offboarding debt Inventory every place SSH keys are accepted today, then make revocation a central identity action rather than a file-by-file cleanup task.
- Eliminate public management exposure Move administrative access to an architecture where targets do not need public SSH ports or a publicly reachable jump server.
- Separate session trust from network trust Require session-level authorization for administrative access so identity, device posture, and policy are checked before the connection is proxied.
Key takeaways
- Bastion hosts concentrate authentication, session handling, and backend reachability into one privileged control point.
- When that control point is compromised, the resulting blast radius can extend to every system it was allowed to reach.
- Identity-bound session brokering reduces the need for shared jump infrastructure and makes offboarding materially cleaner.
Related NHI Mgmt Group resources: IAM and IGA Basics · Joiner-Mover-Leaver (JML) Guide · Secure Remote Access Beyond VPN Guide · Coupang Signing Key Breach
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The bastion concentrates too much reach in one privileged administrative path. |
| NHI-01 — Improper Offboarding | Key-based bastion access often survives offboarding because revocation is dispersed across hosts. | |
| Recommendation — Reduce overprivileged administrative pathways by removing shared jump access and scoping access per session. Centralise offboarding so access removal revokes all SSH entry paths at once. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH key sprawl is an authenticator lifecycle problem, not just a hosting issue. |
| Recommendation — Apply authenticator lifecycle controls to SSH keys and retire stale credentials promptly. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | A compromised bastion is valuable because it can expose credentials and enable pivoting. |
| Recommendation — Hunt for credential access and lateral movement paths that begin with privileged relay compromise. | ||
| NIST Zero Trust (SP 800-207) | section 3.1 — Zero Trust principles | The article argues that administrative access should not rely on a trusted internal jump box. |
| Recommendation — Design privileged access so each session is authorised independently of network location. | ||
Key terms
- Bastion Host: A bastion host is an intermediary system used to reach protected internal resources. It centralises entry but also concentrates trust and availability risk, which means the design only works well when logging, offboarding, and recovery are tightly controlled.
- SSH key sprawl: SSH key sprawl is the uncontrolled growth of key pairs across servers, users, and teams, usually without a reliable owner or expiry process. In practice, it creates hidden access paths that are difficult to audit, rotate, or revoke, which turns routine administration into an unmanaged security exposure.
- Lateral Movement: A post-compromise technique where an attacker uses a compromised NHI to move through a network, accessing additional systems and escalating impact without triggering detection.
- Zero Trust Architecture (ZTA): Zero Trust Architecture is a security model that assumes no user, device, workload, or network path should be trusted by default. It continuously verifies identity, context, and policy before allowing access, using least privilege, strong authentication, and segmentation to reduce blast radius and limit lateral movement.
Deepen your knowledge
NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org