TL;DR: A bastion host is a single, privileged, always-on server that every attacker in your threat model already knows to look for. Twingate Privileged Access for SSH removes it from the architecture entirely.

Every infrastructure team has one. The jump box. The SSH gateway. The Azure Bastion or the AWS Session Manager fronted by a hardened EC2 instance.

Whatever you call it, it's the server you SSH into first so you can SSH into everything else. And in November 2025, Microsoft disclosed CVE-2025-49752, a critical authentication vulnerability in Azure Bastion that scored a 10.0 on CVSS and let unauthenticated attackers escalate privileges against every VM the bastion could reach.

That's the risk model in one CVE. You built a fortress at the front door and put every crown jewel behind it.

The bastion host contradiction

The bastion host predates zero trust by about two decades. The original idea, from Marcus Ranum's 1990s firewall work, was reasonable given the constraints of the time: harden one machine to the extreme, expose only that machine to the untrusted network, and force all administrative access through it. Fewer attack surfaces, easier to monitor, easier to patch.

That logic held when "the network" meant a data center with a well-defined perimeter and a handful of admins. It falls apart the moment you have:

• Engineers hitting production from home networks and coffee shops

• Workloads spread across multiple clouds and regions

• SSH, RDP, kubectl, and database sessions all needing the same trust decision

• Auditors asking who accessed what, when, and why

The bastion becomes a chokepoint for everything, which means every one of those problems is now the bastion's problem. And architecturally, the bastion is doing something zero trust explicitly warns against: sitting on the network as a privileged, always-on, always-reachable server that trusts anything on the other side of it.

What actually goes wrong with bastions

I've been in enough post-incident reviews to know the theory doesn't match the practice. Here's what real bastion problems look like.

They rot. The bastion is critical infrastructure that nobody wants to touch. Patching means downtime, downtime means someone can't ship, so patches get deferred. Fleet-wide the average bastion is running an OS a year or two older than the workloads behind it.

They're a lateral movement dream. Once an attacker has a shell on the bastion, they don't need to exploit anything else. They just wait for the next admin to SSH through and steal the session, credentials, or agent-forwarded keys. This is exactly the pattern the MITRE ATT&CK framework catalogs under Lateral Movement (TA0008), and the bastion is the ideal foothold.

Their access controls are fictional. Most bastions authenticate with SSH keys distributed via config management. The bastion doesn't know who you are. It knows a key was presented. Off-boarding a contractor means chasing down every authorized_keys file on every host and hoping you got them all before their laptop hits eBay.

HA is expensive and rarely tested. Real production bastions need multiple instances, a load balancer, session affinity, and a runbook for what happens when the primary dies mid-session. Most teams have half of that.

They're the loudest signal in your logs. Every SSH connection, every failed auth attempt, every port scan on the internet hits your bastion first. Which means your SOC is drowning in bastion noise while real signal gets buried.

The Azure Bastion CVE is a good illustration. According to Microsoft's advisory, the vulnerability allowed improper authentication handling that could let an attacker intercept and replay tokens to gain access to backend VMs. The mitigation was a patch pushed by Microsoft, but the architectural fact remains: a single service, sitting between users and every VM in the tenant, is exactly the kind of high-value target that will keep getting attacked. CVE-2025-49752 will not be the last one.

The bastion's role in the attack chain

Here's a rough map of how a bastion typically shows up in a real breach, using the standard tactic categories from ATT&CK:

None of this is exotic. This is what a bastion does for legitimate users, which is why it's such a productive target when it gets compromised.

What replaces a bastion in a zero trust model

Zero trust doesn't harden the front door. It removes the door and stops treating "inside the network" as a meaningful trust boundary. For SSH specifically, that means three things need to be true:

1. No public IP, no exposed SSH port. The target host should not be reachable from the internet at all. Not on port 22. Not on port 2222. Not through a bastion with a public IP.

2. Every session is authenticated to a person, not a key. Off-boarding should be one action in your identity provider, not a scavenger hunt through authorized_keys files.

3. Access is proxied at the session layer, with per-session policy. Not "you're on the VPN so you can reach 10.0.0.0/8." More like "this specific identity, on this specific device, is authorized for SSH to this specific host, for this session, and every command is logged."

The mesh VPN category (WireGuard-based overlays) gets you closer to #1 by hiding hosts behind an overlay network, but it still puts the user on a network where they can enumerate other hosts. That's a smaller bastion, not the absence of one.

Traditional VPNs get you none of the three. Cloud proxy providers get you #1 and part of #2, but usually stop at HTTPS and require a separate SSH story.

How Twingate's approach removes the bastion

Twingate is a ZTNA product with a specific architecture that maps cleanly onto the three requirements above. The relevant components:

• Client on the user's device intercepts DNS for authorized resources only. No overlay network, no CGNAT range exposed to the user, no ability to scan.

• Connector runs behind the customer's firewall, all outbound-only. It has no listening ports and no public IP. It authenticates to the Controller with certificate-pinned TLS.

• Controller delegates authentication to your existing IdP. Twingate never sees credentials.

• Privileged Access for SSH adds a Layer 7 gateway that terminates the SSH session at the Connector, applies per-session identity policy, and records the session.

For an SSH connection specifically, the flow looks like this:

1. User runs ssh prod-db-01.internal on their laptop.

2. The Twingate Client sees the DNS match and requests authorization from the Controller.

3. The Controller checks the user's IdP session, device posture, and access policy. If everything checks out, it issues a signed authorization.

4. The Client opens a TLS tunnel to the Connector, either directly via QUIC/P2P or through a Relay if NAT traversal fails. Relays do not decrypt traffic.

5. The Connector verifies the authorization independently against its own copy of the ACL, then proxies the SSH session to prod-db-01.internal.

6. Every command in the session is logged with a real human identity attached.

There is no bastion in that flow. There is no exposed SSH port on prod-db-01. There is no jump box to patch, no HA pair to babysit, and no authorized_keys file to audit. Off-boarding a user removes them from the IdP group; the next connection attempt fails at step 3.

The tradeoff worth calling out honestly: you're now depending on the Connector and the Controller instead of a bastion. The Connector is a lighter piece of software than a full OS-hardened jump host, and you deploy multiple per Remote Network for redundancy. The Controller is Twingate's problem to keep up. Whether that tradeoff is acceptable depends on your compliance posture — but for most teams, "outbound-only proxy running as a container" is a smaller failure domain than "publicly reachable Linux VM with SSH open."

What this looks like in practice

The migration from a bastion to identity-based SSH access isn't a rip-and-replace weekend. It usually looks more like:

• Stand up a Connector in the same VPC as your bastion. Route a small set of low-risk hosts through it first.

• Onboard a pilot group of engineers. Their SSH commands don't change, ssh hostname still works, because the Client intercepts the DNS query transparently.

• Move higher-privilege access (production database hosts, Kubernetes control planes) once policy is dialed in and logging is confirmed.

• Decommission the bastion by removing the public IP first, then the instance itself. Keep it in a shutdown state for a few weeks in case you need to reverse course.

Engineers rarely miss the bastion. The command they type is the same. What changes is what happens behind the scenes: an IdP check instead of an SSH key match, a session-level policy decision instead of a network-level one, and a log entry with a real name on it instead of "root@bastion."

The uncomfortable question

If you've been running a bastion for years without incident, it's tempting to conclude the model is fine. It might be. But the question worth asking is what your incident response looks like the day the bastion does get popped, because CVE-2025-49752 is a reminder that even the managed, patched, cloud-provider-operated versions have this fate available to them.

A bastion breach is a bad day. Every session that touched it in the compromise window is suspect. Every credential cached on it is burned. Every backend host it could reach needs to be assumed potentially compromised. That's a lot of blast radius for a piece of infrastructure whose entire purpose was to reduce blast radius.

Zero trust doesn't harden the bastion. It asks why the bastion exists at all.

Closing

For more on how Twingate handles SSH, session recording, and identity-based access policies, see the Identity Firewall for SSH documentation.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.