The Bastion Host Was a Good Idea in 2010

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

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, the 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 and 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.

If that scene made you wince, you’ve met the bastion host at the exact moment it stops being an asset and starts being a liability. Here’s the thing though: 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, lock it down hard, and force every connection to hop through it. One box to patch. One box to monitor. 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 was the humane alternative to that double-hop misery. 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.

Flexera 2026 State of the Cloud Report

Three cracks show up once the environment outgrows the model. First, 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. Second, it gives you a hop, not an identity. Everyone routes through the same host, often the same shared account, so your audit trail says traffic passed through here, not who did what once they were inside. Third, 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.

And the perimeter-shaped box is exactly what attackers have learned to love. In the 2025 Verizon DBIR, exploitation of edge and VPN-style devices, the internet-facing gear that exists to be reachable, jumped roughly eightfold year over year, and only about half of those flaws were patched, with a median fix time of 32 days. The thing you put at the edge to protect everything else becomes the thing worth attacking.

Attacks exploiting edge and VPN devices rose roughly 8x year over year. Only ~54% were patched, with a median remediation time of 32 days.

Verizon 2025 Data Breach Investigations Report

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 was never going to age well, and the DBIR keeps making that case for us: stolen credentials were the initial access vector in 22% of breaches, and 88% of basic web application attacks involved stolen credentials. Getting secrets into a managed vault is a real improvement.

Stolen credentials were the top initial access vector in 22% of breaches; 88% of basic web application attacks involved stolen credentials.

Verizon 2025 Data Breach Investigations Report

But now look at what it actually takes to make that vault useful inside your Linux access flow. The key is in Secrets Manager, 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 Secrets Manager, 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 IAM policy drifts, when the rotation schedule changes, when the agent needs patching, that’s your team.

This is the quiet punchline of build vs. buy. 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. StrongDM integrates directly with AWS Secrets Manager, so the credential keeps living exactly where you already decided it should live. Nothing gets migrated. Your secret store stays your secret store, with its rotation, its policies, and its audit log intact. If your other teams standardized on Azure Key Vault, GCP Secret Manager, or HashiCorp Vault, the same pattern holds.

What changes is the last mile. When an engineer connects to a resource, StrongDM pulls the credential from your vault just in time and injects it directly into the session at connection time. The engineer never sees the key. It never lands on their laptop. There’s no fetch script to babysit, no rotation cron to maintain, no agent on the target waiting to be patched. The credential goes from your vault into the session and nowhere else, scoped to that resource, for that session.

And because access now runs through an identity-aware path instead of a shared hop, you also close the audit gap the bastion left open. Every session is tied to a real person, authenticated through your identity provider, and recorded end to end. And because the path is also protocol-aware, we 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. 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 a time and place in the early cloud days, it solved it 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. Keep AWS Secrets Manager exactly where it is. 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.

Want to see what that actually looks like? The short demo below walks a live connection from request to recorded session, credential pulled from Secrets Manager, never exposed, fully audited.

Want to read more? See how StrongDM’s Just-in-Time access supports Zero Trust in AWS: StrongDM’s Just-in-Time Access Is Key for Zero Trust Security in AWS.

Sources

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