Bastions still matter because zero trust does not mean no control point. A bastion service acts as a trust broker that verifies identity, context, and policy before access is allowed, while preventing lateral movement and hiding internal assets from public exposure. It remains useful wherever teams need secure, controlled entry to private infrastructure.
Why bastions still matter in zero trust access architectures
A bastion still matters because zero trust is about continuously verifying access, not removing the access path. In practice, a bastion gives teams a controlled entry point that can enforce policy, broker sessions, and reduce exposure of private systems. For private infrastructure, it remains one of the simplest ways to keep access auditable, limited, and harder to abuse.
What a bastion adds that zero trust does not eliminate
Zero trust architectures are built around explicit verification, least privilege, and reduced implicit trust. A bastion fits that model when it centralises the decision to allow access, rather than letting administrators connect directly from unmanaged endpoints into sensitive networks. It can verify who is connecting, from where, under what conditions, and to which target, before a session is established.
That matters because many environments still need a practical trust broker for SSH, remote administration, database access, or other high-value entry paths. A bastion can sit at the boundary of a private segment, hide internal hosts from direct exposure, and force all privileged access through a known control point. In other words, zero trust changes the policy model, but the bastion remains the enforcement point for the path into the environment.
Used well, a bastion also simplifies operational visibility. Instead of trying to monitor many direct admin paths, teams can concentrate logging, session capture, and approval logic in one place. That makes it easier to demonstrate who accessed what, when, and for how long, especially in environments where auditors or incident responders need a single trail of administrative activity.
Where bastions fit in modern access design
Modern zero trust designs often combine a bastion with identity-aware access checks, short-lived credentials, and segmented target networks. The bastion should not be treated as a permanent trust island. It should be tightly scoped, hardened, and narrowly permitted to reach only the systems it is meant to broker.
That design is especially useful when internal systems cannot be safely exposed through public endpoints or when direct peer-to-peer access would create too much attack surface. A bastion can act as a policy gate for staff, contractors, and emergency access, while still preserving the zero trust principle that every request must be checked at the point of use. For workload-to-workload patterns, teams often pair this model with workload identity and service-to-service controls, such as Guide to SPIFFE and SPIRE, rather than assuming the bastion alone solves east-west trust.
In mature environments, the main question is not whether the bastion exists, but whether it is integrated into the broader access architecture. A bastion that bypasses policy, uses standing credentials, or allows broad network reach becomes a weak point. A bastion that is policy-driven, time-bounded, and narrowly delegated reinforces zero trust by making each access session explicit and reviewable.
Why bastions remain relevant for private infrastructure
Bastions are still valuable wherever private resources need a secure administrative doorway and direct exposure would be unacceptable. That includes legacy systems, sensitive production tiers, segmented cloud networks, and environments that need strict control over interactive access. They are also useful when organisations need one place to apply step-up checks, temporary approval, or just-in-time access for privileged work.
Their continued relevance is also architectural. Zero trust rarely removes the need for a controlled ingress point, especially when the target systems are not meant to be generally reachable. A bastion can be the boundary device or service that enforces the access policy while the rest of the environment stays hidden behind private routing and network segmentation. For practitioners, that is often a cleaner and safer design than exposing multiple direct paths and trying to secure each one independently.
This is why bastions should be judged as part of a broader control plane, not as a relic of older perimeter thinking. If the bastion is doing access brokering, session control, and exposure reduction, it is supporting zero trust. If it is only a convenient jump host with broad standing access, it is not aligned with the architecture’s intent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Bastions enforce explicit verification and bounded access at the entry point. |
| Recommendation — Use a bastion as a policy-enforced access broker with continuous verification and least privilege. | ||
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | A bastion is a controlled remote-access path for administrative entry. |
| AU-2 — Audit Events | Bastions centralise privileged access logging and session visibility. | |
| Recommendation — Route administrative access through approved controlled remote-access mechanisms. Log bastion sessions and administrative events for review and incident response. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Bastions help constrain and mediate administrative access paths. |
| Recommendation — Restrict administrative access paths and enforce least privilege through a controlled gateway. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Bastions are an access-control mechanism for private infrastructure. |
| Recommendation — Define and enforce access control for privileged entry points. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Bastions are often used to prevent broad standing access by non-human actors. |
| NHI-07 — Long-Lived Secrets | Bastion-based access is often paired with short-lived credentials instead of persistent secrets. | |
| Recommendation — Limit non-human access paths so bastion-mediated sessions stay least privilege. Replace long-lived access secrets with short-lived, bastion-brokered credentials. | ||
Practitioner Guidance
What to verify: Confirm that the bastion is enforcing policy at connection time, not merely forwarding traffic. If it cannot prove who accessed which target under what conditions, it is functioning as a transit box rather than a trust control.
Decision rule: Keep the bastion when it reduces direct exposure, centralises auditability, or enables just-in-time administration. Remove or redesign it only when it has become a broad standing-access path that weakens segmentation or duplicates weaker controls.
What good looks like: Access is time-bound, logged, and narrowly scoped to approved targets, with no direct administrative reach from user endpoints into private systems. A strong design makes the bastion easy to explain during incident response and access review.
Practitioner takeaway: Zero trust does not eliminate choke points, it demands that choke points be explicit, policy-driven, and measurable, which is exactly why a bastion still earns its place.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
