SSH bastions in 2026: a threat model

The SSH bastion has been the default privileged-access design for more than a decade, for good reason. It is cheap, well understood, and it reduces the reachable surface of production from 'everything on port 22' to 'one host on port 22.' That is a real reduction. It is not, however, the end of the analysis.

This post threat-models the bastion pattern as it is typically deployed in 2026 — not the idealized textbook version — and catalogs where the model leaks. The goal is not to argue that bastions are indefensible. It is to be specific about what assumptions a bastion relies on, so you can decide which of those still hold in your environment.

What the bastion is designed to protect against

Classic bastion threat model: an external attacker who can reach the internet but has no credentials. The bastion is a single hardened entry point. The attacker cannot reach production directly, so they must first compromise the bastion. If the bastion is patched, MFA-gated, and monitored, this is expensive.

Against exactly that threat actor, a well-run bastion still works. The trouble is that the threat landscape has moved. Most real incidents in the last few years involve an attacker who already has credentials — through phishing, a compromised endpoint, a leaked key, or a third-party support channel. Against a credentialed attacker, the bastion's value is much narrower than the design originally assumed.

Assumption: the bastion sees every path

The bastion is a useful choke point only if it is actually the only path. In practice, most estates have several parallel paths that accumulated over years: a VPN for contractors, a Kubernetes jump pod for the platform team, a vendor support tunnel that opens on request, a break-glass account on a handful of hosts. Each of them is a rational decision in isolation and a liability in aggregate.

A useful exercise: list every inbound path to production that a human operator has used in the last 90 days. If the bastion is not the only one on the list — and in most estates it is not — the bastion's threat model is not your organization's threat model.

Assumption: the credential is the identity

Classic bastions gate access by SSH key. A key is convenient, but it is not an identity. Keys get shared, cached on laptops, backed up into developer dotfile repos, and — with surprising regularity — committed to public code hosts. A compromised key looks identical to a legitimate key at the bastion. The bastion has no way to distinguish a contractor's laptop from the laptop of the attacker who phished them.

The mitigations everyone knows — short-lived certificates, hardware-backed keys, an SSH CA — help, but they only help to the extent they are actually enforced. In environments with a mix of human operators, long-running scripts, and third-party support sessions, the weakest credential defines the model.

Assumption: the session is unobservable by the bastion

The bastion typically sees the connection attempt and then forwards bytes. It has no view of what the operator is doing once the session is brokered. If the session is recorded at all, it is recorded by a sidecar or a screen-scraper running on the target, not by the bastion. That arrangement has two consequences.

• Evidence is distributed across every target, with the usual retention, tampering, and consistency problems.
• A compromise of a single target also compromises that target's evidence — the attacker lands on the host with the recorder and has the same privileges as the recorder.

Assumption: the bastion authorizes, not just authenticates

The bastion authenticates the operator and then, in most deployments, forwards the connection. Fine-grained authorization — which commands, which hosts, at which times — is typically delegated to sudoers, to ACLs on the target, or to nothing at all. That delegation is invisible from the bastion. Two operators with the same SSH key can have very different effective authority, and the bastion cannot tell you which.

Where this leaves the pattern

None of these failures are new, and none of them mean the bastion is useless. They do mean that a bastion is a necessary-but-not-sufficient answer. The control you actually want is a policy-enforcing, identity-authenticating, session-observing intermediary — what the industry has started calling a privileged access gateway, and what Wardengate is built to be.

In practical terms, the three-sentence version of the upgrade path looks like this. Keep the choke-point property of the bastion; replace the 'one hardened host' with 'a policy-evaluating broker that terminates the protocol.' Replace 'key-equals-identity' with 'identity from the IdP, credential injected by the broker.' Replace 'session is unobservable' with 'session is recorded at the broker, where the operator cannot reach the recorder.'

One closing note on operational realism

A common objection is that any of the above adds friction. It does — but less than teams expect, and dramatically less than the friction of an actual breach review. A security engineer at a Fortune 500 financial services firm described the switch this way during a roundtable last fall: 'We stopped having the argument about who can reach what. The policy answers it, and the policy is in git.' That is the operational win the threat model is pointing at. The failure modes above are not abstract; they cost time every week. A gateway removes the argument.