The bastion host was a good idea in 2010

Your cloud vault already fixed the keys. Here's the part it didn't fix.

It’s 2 a.m., and production is down. The one engineer who knows how the jump box is wired, the iptables rules, the key rotation cron job and the high-availability (HA) pair that has never actually failed over is on a plane with the Wi-Fi off. Everyone else is staring at a bastion host they’ve used a thousand times yet understand almost none of. The outage isn’t the database. The outage is the single door everyone has to walk through to reach it, and nobody in the room has the key.

That is the bastion host at the exact moment it stops being an asset and starts being a liability. Here’s the thing: The bastion wasn’t a mistake. It was a genuinely good answer to a real problem. The mistake is never asking whether the answer still fits the question.

Why we built bastions in the first place

Rewind to a cloud environment you just stood up. You need a way in to do the actual platform work: maintenance, debugging, deploys. But you really don’t want every box exposed to the open internet with its own listening SSH daemon. So you do the smart thing, you stand up one hardened host on a public subnet, restrict it to a single inbound port with key-based authorization, and force every connection to hop through it. There's one box to patch, one box to monitor and one place to watch the logs.

That was a real security win. Instead of dozens of internet-facing SSH endpoints, you had one chokepoint you could reason about. For a cloud environment where services stayed mostly static, save for elastic workloads, and platform and DevOps engineers lived anywhere in the world, the bastion model was the right call.

And remember what the alternative looked like. Reaching a cloud VPC back then often meant VPN into corp net, then VPN back out to the cloud, because the expensive VPN concentrator was capital gear that lived in your data center. A DevOps engineer working from home transited the office to reach infrastructure that was, ironically, reachable from anywhere. A hardened bastion on a public subnet removed that second hop. It shrank the attack surface and gave you a single place to enforce a perimeter. Nobody should feel bad about having built one.

Then the infrastructure stopped holding still

The assumptions under the bastion quietly expired. Infrastructure is not a fixed set of servers behind one security group anymore. It’s ephemeral instances, multiple accounts, managed databases, Kubernetes clusters and more than one cloud. Today, 73% of organizations run hybrid estates, spanning public and private cloud at once, and among organizations with more than 5,000 employees that climbs to 78%. The single edge you were guarding didn’t just move. It multiplied, and half of it lives somewhere the bastion was never designed to reach.

73% of organizations now operate hybrid cloud estates, and that rises to 78% among organizations with more than 5,000 employees

 

 

 

 

Three cracks show up once the environment outgrows the model.

1. The bastion is a single point of failure: one box, one config, one person who actually understands the failover. When it’s down or misconfigured, nobody gets in and that includes the people trying to fix it.

2. It gives you a hop, not an identity. Everyone routes through the same host, often the same shared account, so your audit trail shows traffic passed through here, not who did what once inside.

3. It carries a permanent maintenance tax: patching, key rotation, session logging bolted on with script wrappers, HA that has to be tested and never is. None of that was free. It just moved onto someone’s plate and stayed there.

A perimeter-shaped box is now a preferred target. In the 2026 Verizon Data Breach Investigations Report (DBIR), edge devices and VPNs, the internet-facing gear that exists to be reachable, went from 3% to 22% of the breaches that began with vulnerability exploitation, a 7x rise in a single year. Remediation moved in the opposite direction over the same period. 

Edge devices and VPNs went from 3% to 22% of vulnerability exploitation breaches in a single year

Only 26% of CISA's known exploited vulnerabilities were fully remediated in 2025, down from 28%. The median time to patch increased from 32 to 43 days. Anything you place at the edge to protect everything else inherits that exposure window.

The half-fix: bolting a vault onto the bastion

Teams that get serious about credential hygiene do the obvious next thing, and it’s the right instinct: Get the SSH keys off the bastion box and into a real secret store. If you’re on AWS, that’s AWS Secrets Manager. Now the keys live somewhere purpose-built, with rotation, access policies and an audit log of their own.

Good move. Credentials sitting in a file on a jump host were never going to age well, and the DBIR still makes that case. Credentials are less often the way in now, and more often what the intrusion runs on once it's inside. This is exactly the gap a shared hop leaves open. Getting secrets into a managed vault is a real improvement.

According to the Verizon DBIR, credential abuse fell to 13% as a standalone initial access vector, but still appears in 39% of breaches

But now look at what it actually takes to make that vault useful inside your Linux access flow. The key is in the store, and the engineer still needs it to land in an SSH session on the target host without ever touching disk. So, you build the glue: an agent or a script that authenticates to the vault; an IAM role scoped tightly enough to fetch the right secret and nothing else; a retrieval step wired into the connection path; and something to make sure the fetched key doesn’t get cached somewhere it shouldn’t. Then you own all of it. Forever.

When the policy drifts, when the rotation schedule changes, when the agent needs patching, that’s your team.

This is where build vs. buy actually lands. You bought the vault, which was the right call, and then you paid the integration tax anyway. The vault solved where the keys live. It did nothing about how they get from there into a session safely, and that last mile is where the homegrown code piles up.

Same vault, none of the glue

Here’s the part worth sitting with: You don’t have to give up the vault to get rid of the glue. Secret Server brokers the connection itself. The credential stays vaulted, the SSH session is proxied through Secret Server and the engineer never handles the key. Rotation, access policy and the audit log stay where they already are, on the vault side, rather than in a script you maintain. 

What changes is that privileged remote access gives engineers and third parties browser-based access to Linux hosts, databases and network devices without a VPN and without a jump box to keep alive. Access is granted just-in-time rather than in advance, scoped to the resource, the window and the session, and the session is recorded end-to-end. There is no fetch script to babysit, no retention cron to maintain and no agent on the target waiting to be patched. 

The machine side of the split has its own answer. DevOps Secrets Vault serves secrets to applications, pipelines and automation over CLI and API, issues dynamic secrets that expire on their own and syncs with Secret Server so human and non-human credentials are not managed in two disconnected places. Your engineers stop writing the retrieval layer because the retrieval layer is the product.

Access now runs through an identity-aware path rather than a shared hop, so you close the audit gap left open by the bastion. Every session is tied to a real person, authenticated through your identity provider, and recorded end-to-end. The path is protocol-aware too, so you know exactly what each of those people did.

The question stops being "is the bastion up" and becomes "do we know exactly who did what, when, on which resource?" That’s not a hop through a box. That’s a record.

The bastion did its job, but the job changed

None of this is a knock on the engineers who built the jump box. It solved the problem it was designed for, and for its time and place in the early cloud days, it did so well.

But the environment moved: more clouds, more ephemeral resources, more people, more scrutiny. Somewhere along the way, the single hardened door became the single point of failure, the shared hop became the audit gap, and the vault you added to fix the keys quietly handed you a pile of integration code to maintain.

The good news is that fixing it doesn’t mean ripping out what you already got right. Keep the vault that you built. Just stop maintaining the homegrown layer sitting on top of it and let the credential go straight from the store into an identity-aware, fully recorded session. Same vault, none of the glue.

Sources

• Verizon 2026 Data Breach Investigations Report
• Flexera 2026 State of the Cloud Report