A senior engineer told me that bastion hosts have been insecure and outdated for the past decade. With zero-trust designs becoming more common, is the traditional bastion or jump host actually falling out of favor, and what is the modern approach to granting secure, monitored access to isolated systems?
For example, imagine a production database that accepts normal application traffic through a load balancer and allows operating-system access from only one approved host: a hardened bastion. That bastion is reachable only through a VPN, restricted to approved developer devices, and protected with break-glass credentials.
Would it be better to remove the bastion and install a zero-trust access agent on both the database host and developer laptops, allowing developers to connect directly? Or are bastion hosts still a sound design when they are properly secured?
4 Answers
Bastion hosts are not inherently insecure or obsolete. Their security depends on how they are exposed, patched, authenticated, monitored, and maintained. A private, hardened jump host behind a VPN or identity-aware access layer can still be a perfectly reasonable design, especially for on-premises, multi-cloud, or air-gapped environments.
The weakness in many older bastion designs was treating the host as the whole security solution: long-lived user SSH keys, shared accounts, broad network access, and little control over when access was granted. Modern designs replace those pieces with SSO, MFA, short-lived credentials, just-in-time permissions, strong device checks, session recording, and detailed auditing.
For your example, I would not choose between a traditional bastion and unrestricted direct database access as if those were the only options. Keep the database on private networks, restrict its security-group rules, and use an access layer that integrates with your identity provider. That could be a short-lived bastion, a managed session service, a zero-trust network connector, or a PAM platform.
Use a bastion when it provides useful centralization, compatibility, or separation from user workstations. Replace it when it is merely an unmanaged SSH server with permanent keys and broad access. The threat model, operational recovery requirements, and platform constraints should drive the decision.
The newer pattern is generally identity-based and just-in-time access, not necessarily direct access from every developer laptop. A user requests access to a specific system for a limited period, the request is approved or policy-checked, and the connection is allowed only while the user, device, and session meet the required conditions. Short-lived SSH certificates, mTLS, SSO, MFA, device posture checks, and session recording are common parts of this model.
You can implement that through a bastion, a zero-trust gateway, a VPN, or a cloud session service. The product or hostname is less important than the properties of the access path.
Direct access from a developer laptop is not automatically more secure. If that laptop is compromised and has standing production permissions, the attacker may get a much broader foothold. Temporary, narrowly scoped permissions and strong endpoint controls matter either way.
In a cloud environment, a provider-native session service can often replace the traditional SSH jump host. For example, a service such as AWS Systems Manager Session Manager can use IAM, MFA, temporary credentials, private control-plane connectivity, and centralized logging without giving the target machine a public IP or opening inbound SSH. Comparable products exist in other cloud platforms and from vendors such as Teleport or identity-aware access providers.
That is usually preferable when you only need administrative shell access, but it is not magic. The agent, permissions, logging, recovery path, and break-glass procedure all need to be tested. You should also avoid designing a system where the only recovery method depends on an agent that might fail to start.
For database administration, you may still need a network path rather than an operating-system shell. A private VPN, identity-aware proxy, or privileged access management system can provide that access without exposing the database publicly.
A bastion can also be private and fully audited; public exposure is not a requirement. The important question is whether it reduces and controls the attack surface rather than simply adding another server to maintain.