Should organisations replace bastion hosts with a broader access control plane?

Why This Matters for Security Teams

Bastion hosts solve a narrow problem: controlled entry to servers. They do not, by themselves, govern how access is issued, evidenced, or revoked across APIs, cloud control planes, service accounts, and agentic workloads. That matters because modern estates are built around secrets and machine identities, not just SSH paths. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is exactly the kind of sprawl a broader access control plane is meant to address.

The real question is whether security can enforce policy consistently across all resources or only at the bastion boundary. A broader control plane can hide underlying credentials, broker just-in-time access, and maintain session evidence across different targets. That aligns with the direction of the OWASP Non-Human Identity Top 10, which treats unmanaged machine access as a systemic issue rather than a server-only problem. In practice, many security teams discover the gap only after a service account or API key has already been reused outside the bastion path.

How It Works in Practice

A broader access control plane acts as the decision layer above individual systems. Instead of granting a user or workload a standing secret for each resource, the plane evaluates request context at runtime, issues short-lived access, and records what was allowed. For server access, that may still include a bastion-like workflow. For everything else, it can front APIs, databases, cloud consoles, and even agent tooling.

Typical operating patterns include:

• Authenticating the requester as a workload or operator, then mapping that identity to policy.
• Issuing JIT credentials or temporary tokens only for the task duration.
• Hiding long-lived secrets from the client and rotating or revoking them centrally.
• Capturing session metadata and access evidence for audit and incident response.

This is where Zero Trust thinking becomes practical. NIST’s Zero Trust Architecture emphasizes continuous verification, while NHIMG’s Key Challenges and Risks discussion highlights why static secrets and broad privileges remain common failure points. For organisations handling cardholder data, the access plane also needs to preserve evidence and least-privilege discipline in ways that support PCI DSS v4.0 expectations.

Current guidance suggests the control plane should be the policy source of truth, while bastions become one implementation option among several, not the only choke point. These controls tend to break down in legacy environments where applications require embedded credentials, direct database clients, or unmanaged third-party integrations because the plane cannot mediate every path.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance stronger governance against deployment complexity and change management. That tradeoff is most visible when teams want to replace a mature bastion with a broader plane before they have workload identity, asset inventory, and credential lifecycle discipline in place.

There is no universal standard for this yet, but best practice is evolving toward layered control. Some organisations keep bastions for high-risk administrative SSH access and use a broader plane for APIs, service accounts, and cloud operations. Others move entirely to a control plane once they can issue identity-bound, short-lived access at scale. The right answer depends on whether the organisation can enforce policy without creating exceptions that nobody can later audit.

This is especially important for autonomous systems. When agents chain tools, assume standing access is unsafe. A broader plane is useful only if it can evaluate intent, issue ephemeral access, and revoke it automatically after task completion. NHIMG’s 52 NHI Breaches Analysis is a reminder that failures usually show up as credential misuse and privilege spread, not as a clean bastion bypass. The model breaks down when an environment cannot express all access paths as policy-controlled sessions.

Related resources from NHI Mgmt Group

• Should organisations centralise all server, database, and Kubernetes access in one control plane?
• Should organisations replace VPNs with an identity-aware proxy for all access?
• What do IAM and security teams get wrong about GenAI access control?
• What should organisations do when agent access keeps expanding during pilots?