Should organisations replace VPNs and bastions with identity-based access controls?

Why identity-based controls are a better replacement than perimeter entry points

VPNs and bastions were designed to create a narrower path into infrastructure, but they still tend to act as coarse access brokers. Identity-based access controls shift the decision point from network location to verified identity, policy, and session context. That matters when the real problem is not reachability, but who can do what, from where, and under which conditions.

That difference changes how organisations govern privileged access. Instead of granting broad network presence and assuming the bastion or VPN will contain the blast radius, identity-based models can enforce per-user, per-device, per-session, and sometimes per-action decisions. Remote Access Identity Guide is useful here because it frames VPN replacement as a broader remote-access governance decision, not just a connectivity swap.

It also aligns better with modern infrastructure patterns. Infrastructure access is increasingly distributed across cloud consoles, admin APIs, remote shells, and third-party support paths, so a single network choke point often misses the actual trust decision. Zero Trust Identity Guide helps explain why identity-centric policy and continuous verification fit this shift better than a static entry layer.

What organisations still need to solve after removing VPN and bastion dependency

Replacing VPNs and bastions does not remove the need for strong authentication, device trust, session control, or entitlement governance. If those controls are weak, the new access layer simply inherits the same weakness with a different front door. The practical improvement comes from combining identity proof, least privilege, and session-level enforcement.

That is why access governance remains central even when network access is no longer the main control. Organisations still need to know which identities exist, what they are entitled to, and whether those entitlements are still justified. IAM and IGA Basics is a strong companion for the governance side of this decision because it covers authentication versus authorization, access reviews, and entitlement management across people and machines.

For infrastructure administration specifically, identity-based access works best when it is paired with just-in-time privilege, short session windows, and auditability. That avoids turning “no VPN” into “always-on admin access.” Privileged Access Management Guide supports the operational side of this shift by focusing on vaulting, just-in-time access, zero standing privilege, and session recording.

When replacement improves security, and when it only changes the shape of the problem

Identity-based controls are most valuable when the organisation needs granular access decisions, stronger accountability, and reduced lateral movement. They are especially effective where bastions have become shared jump hosts, where VPNs expose large internal network ranges, or where remote access has accumulated exceptions over time. In those cases, the old model tends to preserve broad trust even when the business only needs narrow administrative action.

The same logic applies to modern attack paths. Valid credentials, credential replay, and overprivileged access can defeat perimeter-style controls quickly once an attacker is inside. Identity-centric access does not eliminate compromise, but it can reduce how far a stolen session or reused secret can travel. Identity Threat Detection and Response (ITDR) Guide is relevant because it ties access design to the attack techniques and detections that matter after initial compromise.

For infrastructure teams, the real question is not whether VPNs and bastions are obsolete, but whether they are still the best control for the use case. If the access pattern is high-trust, persistent, and poorly attributed, identity-based access is usually the better governance model. If the environment still relies on broad administrative movement without strong policy enforcement, the replacement will be cosmetic rather than protective.

Practitioner Guidance

What to prioritise: Treat this as an access-governance redesign, not a tooling migration. The first decision is which infrastructure actions truly require human interactive access, and which can be shifted to policy-controlled, time-bound, and fully logged access paths.

What to verify: Before retiring VPN or bastion dependency, verify that the replacement can enforce strong authentication, conditional access, per-session approval or scoping, and complete audit trails for every privileged path. If the replacement cannot explain who accessed what and why, it is not an equivalent control.

Common mistake: Replacing a perimeter mechanism with another broad gateway and calling it identity-based. If users still receive wide internal reach once admitted, the organisation has changed the entry mechanism but not the trust model.

Practitioner takeaway: The strongest replacements are narrow, attributable, and reversible, they reduce standing reach rather than just hiding it behind a different login screen.

Related resources from NHI Mgmt Group

• Should organisations replace VPNs with an identity-aware proxy for all access?
• How should security teams replace VPN access with identity-based controls?
• When should organisations replace shared infrastructure access with role-based session controls?
• Who is accountable when privileged access spans VPNs, bastions, and identity-based tooling?