How VPN, bastion, and identity-aware access differ
There is no need to standardise administrative access on one method. Web admin consoles and cloud consoles suit identity-aware access, which permits users per resource. Where server SSH and RDP sessions need control and a record of the work performed, a bastion is the better fit. Where several legacy protocols, thick clients, UDP, and network diagnostic tools are required, a scope-limited VPN remains a realistic choice.
In real operations the three are usually combined rather than reduced to one. Identity-aware access verifies the user and a bastion then carries the SSH session, or a VPN admits the user to the management network and an approved bastion carries them to the target server. Another pattern uses identity-aware access day to day and keeps a separate VPN or bastion path as break-glass for when that system or the IdP fails. So the question is not whether VPNs are old and zero trust is new. It is who reaches exactly which resource, from which device, over which protocol, what evidence remains along the way, and how you recover when the access system breaks.
NIST's zero trust architecture likewise does not trust a user merely for being inside the network. The principle is to verify user and device, grant access per resource and session, and decide dynamically on identity, device state, and environment. At the same time NIST explains that perimeter-based access and zero trust coexist for a considerable period.[1] This article covers only the paths by which a person reaches an administrative screen, cloud control plane, database tool, or SSH and RDP management plane. What WAF, gateway, JWT, and mTLS do for API requests, the exposure paths that bypass straight to the origin, and TLS certificate issuance, renewal, and revocation are each separate problems.
A VPN creates a path that reaches the network. Taking IPsec VPN as the reference, its core function is protecting communication at the IP network layer. Which subnets, IPs, and ports the user can reach after connecting is decided by routing, firewall, ACL, and network segmentation policy. A VPN does not have to open the whole corporate network. You can split routes and ACLs per user group, permit only the management subnet, and combine device certificates, MFA, and device posture. The problem is when none of that is done. Reading a successful VPN connection as trust in everything internal gives one compromised account or device broad network reachability. The VPN gateway is itself an asset to protect. NSA and CISA note that a VPN server is an entry point into the protected network and therefore a target, and recommend strong authentication, prompt patching, and disabling unnecessary features.
A bastion gathers management protocols into a controlled waypoint. Administrators do not connect to the target server by SSH or RDP directly; they cross the bastion first. The target can sit in a private network with no public IP or externally exposed port, and the bastion can be restricted to the permitted targets and protocols. Microsoft's current bastion architecture uses the same structure: the bastion relays RDP and SSH connections to private-IP VMs inside the virtual network, and target VMs need no public IP. That a bastion exists and that sessions are audited remain different facts, though. A plain Linux jump host records the SSH connection time and not the commands. Session recording may be offered only in certain tiers or connection methods. Azure Bastion's screen recording is a separate feature, and AWS Session Manager states that for SSH and port forwarding the inner session data is re-encrypted, so command logging is not provided. Where session recording, credential brokering, ephemeral permissions, and approval workflow are all needed, privileged access management belongs in the review alongside a plain bastion.
Identity-aware access judges the user and context in front of the resource. Rather than admitting the user to the internal network and letting them move, a proxy or broker in front of the application, resource, or port checks identity and policy and opens only the path to that resource. With Google IAP, for example, a central authorization layer sits in front of an HTTPS application and grants access per user or group. Combined with context-aware policy, conditions such as IP, device attributes, patch state, time, and URL path can be used. TCP management services including SSH and RDP can also be relayed through an HTTPS tunnel depending on the implementation. But the name identity-aware does not make every implementation equal. HTTP and HTTPS are comparatively natural, while SSH, RDP, and other TCP support varies by product and deployment. UDP, broadcast, older thick clients, and tools requiring network discovery are hard to support or need a separate VPN. Identity-aware access does not replace the target's final authorization either. Even when the broker decides "this user may connect to this server's SSH port", whether they may hold root inside the server or alter a particular database schema is decided again by the target OS, application, and database.[2]
- VPN
- A VPN creates a protected communication path between a remote device and the organisation's network, and how far a user can reach after connecting is decided by routing, firewall, ACL, and segmentation.
- Bastion
- A bastion is a controlled waypoint an administrator must cross instead of connecting directly to a target server, restricted to the permitted targets and protocols.
- Identity-aware access
- Identity-aware access places a proxy or broker in front of the resource that checks identity and policy and opens only the path to that resource, instead of first admitting the user to the internal network.
Five questions that come before product comparison
First, who is accessing? Separate internal administrators, developers, outsourced maintenance vendors, vendor support, and automation systems.
Second, from which device? Decide whether only company-managed devices are permitted, or whether personal and vendor devices are allowed.
Third, which protocols are needed? Confirm whether HTTPS alone suffices, or whether SSH, RDP, database clients, file transfer, UDP, and legacy tools are also required.
Fourth, exactly how far do they need to reach? Distinguish one admin screen, one specific server, the whole management subnet, or the networks of several sites.
Fifth, what evidence and recovery path are needed? Decide whether connection times suffice, whether the allow policy and device state have to be recorded, whether actual commands and screens have to be captured, and who gets in how during an IdP outage.
Without writing those five down, even the newest product tends to carry over the same broad permissions and the same unclear procedures.
Inspect and protect requests before they reach the service — Review request and blocking records, tune protection rules and manage certificates and access controls.
Comparing identity, reachability, and protocol
The grades below are not grades any standard or vendor officially assigns. They are an editorial synthesis, against this article's decision questions, of NIST zero trust principles and VPN guidance,[1] the access control model for cloud-native environments,[2] Microsoft's bastion architecture, and Google's identity-aware access documentation. Actual capability varies by product and configuration.
Axis | VPN | Bastion | Identity-aware access |
|---|---|---|---|
| User identity | Integrates with IdP, MFA, and client certificates, but authentication usually admits you to the tunnel and each target's permission is separate | The bastion login identity and the target OS or database account are separate. With PAM, temporary permissions and credential brokering become possible | User, group, role, and resource sit at the centre of policy. Granting and revoking per resource is relatively natural |
| Device identity / posture | Client certificate, MDM, and EDR or posture checks can integrate, but this depends heavily on product and configuration | A plain jump host cannot verify the state of the user's endpoint. A separate check is needed in front of the bastion | Device ownership, encryption, patch state, and location fit naturally into policy. Per-implementation support still has to be confirmed |
| Network reachability | Reaches as much of the network as the permitted routes and ACLs allow. Weak segmentation widens the range | The user reaches the bastion, and only the bastion connects to permitted targets | Opens a path to a specific application, resource, or port rather than a general network |
| Protocol support | Most flexible for IP-based protocols and legacy tools. Suits environments needing UDP or thick clients | Best suited to SSH and RDP. Databases, file transfer, and custom ports vary by product and proxy method | HTTPS is most natural. SSH, RDP, and some TCP are possible, but UDP, broadcast, and legacy compatibility are limited |
| Least privilege | Routes, subnets, ports, and user groups have to be divided finely. A VPN does not create least privilege on its own | The targets, ports, and accounts the bastion may reach have to be restricted. A bastion that reaches the whole management network leaves a gap | Suits per-resource, per-user, and per-session policy. Permissions inside the target still need separate restriction |
| Credential exposure | A VPN protects the transport path and does not remove target passwords or SSH keys | Credentials can be concentrated on the bastion, or exposure reduced through ephemeral keys and brokering. Designs differ widely | Federation and short-lived tokens reduce static secrets. Legacy targets still demand their own passwords or keys |
| Third-party access | Without separating profiles, management subnets, access hours, and routes, external vendors get broad access | Suits limited SSH and RDP maintenance on specific servers. Session recording combines easily | Good for opening a specific application or resource to an external identity. Federation and protocol support are prerequisites |
Comparing audit, availability, and recovery
Deciding on identity and protocol alone produces a design where the entire management plane locks at the moment of an outage. Audit coverage, availability dependencies, operational complexity, emergency access, break-glass, and revocation belong in the same table.
Axis | VPN | Bastion | Identity-aware access |
|---|---|---|---|
| Session audit | Who connected to the tunnel and when is recorded, but what they did on the target needs separate logs | Target and time are easy to see centrally. Command and screen recording require separate proxy, PAM, or product features | Good at leaving a decision log of who was allowed or denied to which resource. It does not capture the actual commands or in-application behaviour |
| Availability | The VPN gateway, IdP, DNS, and routing become operational dependencies. HA and a patch strategy are required | The bastion instance or managed service, routes, and target accounts all have to be available. A single jump host is a point of failure | The IdP, policy engine, and proxy or connector become the access control plane. Replication and a separate emergency path are needed |
| Operational complexity | Client distribution, routes, split tunnel, firewall, gateway patching, and capacity | Host hardening, patching, scaling, target allowlists, accounts, and session storage. A managed bastion reduces some of this | IdP, resource inventory, policy, connectors, device management, and log integration together. Initial policy design is heavy |
| Emergency access | An independent VPN gateway and management network can serve as a recovery path. It has to be separate from everyday permissions | A limited emergency bastion can serve as a recovery waypoint. It is pointless if it shares a failure domain with the primary | Strong for everyday access but unable to route around an outage of the same IdP or policy engine. An independent emergency identity and route are required |
| Break-glass | Configure separate accounts, authentication, routes, approvals, and alerts in advance. Avoid a fail-open that opens the whole network automatically | Configure an emergency bastion and target accounts in advance and rotate credentials after use | An emergency identity or backup IdP that is not tied to the same federation and conditional policy |
| Revocation | Beyond ending VPN sessions and revoking accounts and certificates, existing sessions and credentials on the target have to be reclaimed | Ending the bastion session, revoking bastion permissions, and removing target accounts, keys, and persistent sessions | Central policy and tokens can be revoked quickly, but cached sessions and permissions inside the target need separate termination |
Which to reach for first, by situation
Where web admin screens dominate, start from identity-aware access. Internal back offices, Grafana, CI/CD admin screens, and database web consoles — resources reached over HTTPS — suit it well. Resources divide per user and group, and context conditions such as a company-managed device or a time window attach easily. Where an external development or maintenance vendor needs exactly one application, a per-resource policy explains and revokes the access scope more easily than a VPN that joins the whole management network. But turning on an access proxy does not automatically remove the existing direct paths. Google IAP states that enabling IAP on an administrative resource does not by itself block direct requests. Whether any hostname, IP, or port remains that bypasses the access broker has to be verified separately.
Where SSH and RDP to private servers dominate, look at a bastion. If you do not want SSH or RDP open on production servers and need central control of who reached which server, a bastion is the natural fit. Where evidence of the actual work is also required, confirm six things separately: whether it is only connection history, whether shell commands are recorded, whether the RDP screen is recorded, whether both native and browser clients are recorded, whether file transfer and port forwarding are audited, and whether records are retained in a separate immutable store. Do not stop at the feature name "session recording supported" — check whether the protocol and client path in use falls inside the actual recording scope.
Where several legacy protocols and thick tools are needed, keeping the VPN is acceptable. If management work needs several TCP and UDP ports, vendor thick clients, network discovery, and device management protocols as well as SSH and RDP, a VPN is simpler. What matters then is not turning the VPN into an entry ticket to the whole corporate network. Apply a separate management network, per-user routes, target allowlists, MFA, device authentication, and access-hour limits. Authentication and authorization at the target still run again after the VPN connection. Keeping a VPN is not abandoning zero trust. As long as network position grants no automatic trust and permissions are reduced per user, device, and resource and continuously revocable, zero trust principles apply to the existing path.[1]
How the three combine
Identity-aware access with a bastion is the most common combination. Identity-aware access verifies the administrator's user identity, MFA, and device posture and leaves a resource policy and access decision log. A bastion or PAM then relays SSH and RDP, controls target accounts and credentials, records the session, and connects to the managed server. The identity-aware layer decides who may use the bastion; the bastion controls which server they reach, with which account, and what they did in the session.
VPN with a bastion is used where legacy tools require a VPN but direct access to the whole management network is not wanted. The administrator's device enters through a restricted VPN where only the bastion address is reachable, and the bastion or PAM carries them to approved targets. If VPN users can connect to the target server directly, the reason for the bastion weakens. Routes and firewall policy have to force the bastion hop.
Identity-aware access with a restricted VPN is another combination. Administrative web applications move to identity-aware access while only some legacy network tools stay on a separate VPN. It is a realistic transition for organisations that cannot migrate every protocol at once. NIST also explains that a large organisation rarely moves to zero trust in one technology swap, and that old and new methods coexist per workflow.[3]
Identity-aware access with an independent emergency path is the fourth. Per-resource identity-aware access carries everyday work while a separate emergency identity and a restricted VPN or bastion stand by for an IdP or policy system outage. But if the two paths only look separate and actually depend on the same IdP, DNS, MFA service, and network connector, that is not an independent recovery path. Draw the failure dependencies component by component.
Separate connection logs, decision logs, and session recordings
Auditing administrative access is not a question of whether logs exist but of which questions they answer. Identity-aware access is strong at explaining an access decision but does not automatically record shell commands. A bastion concentrates the connection path, yet a plain jump host holds no command record. A VPN records tunnel connections without knowing behaviour inside the target application.
Google IAP's audit log provides the user, source IP, requested resource, and allow decision. Azure Bastion shows the currently connected user, target VM, source IP, and connection time and duration, with screen recording as a separate feature. Whether that information alone reconstructs every final change has to be judged alongside the target's OS, application, and database audit.
Evidence level | Question it answers | Representative evidence |
|---|---|---|
| Connection log | Who connected from where, when, to which gateway or target | VPN login, bastion connection, source IP, target, session duration |
| Access decision log | Which identity, device state, group, or policy caused the allow or deny | Policy version, device posture, access level, authorization result |
| Session / action audit | Which commands, screens, and configuration changes actually followed the connection | Shell command, RDP recording, application audit, database query audit |
Operations connected from observation to improvement — Respond using service indicators and alerts, then connect change records and incident reviews to improvements.
Manage the access system itself as a production dependency
Adopting zero trust or identity-aware access makes the security control plane a new operational dependency. NIST notes that if the policy engine, policy administrator, or policy enforcement point stops, resource access itself is blocked and the organisation's operations are affected. This is not unique to zero trust; legacy remote-access VPNs carry a similar outage risk.[1] So the access architecture needs a failure policy alongside the normal flow.
Automatic fail-open looks convenient for administrative access, but it turns a policy system outage into full exposure of the management plane. In high-risk environments it is better to build a limited break-glass path than to widen the everyday path automatically.
Failed component | Default policy | Exception to design in advance |
|---|---|---|
| IdP / federation | Administrative access fails closed as a rule | An emergency identity or backup IdP that does not depend on the same federation |
| Policy engine / access broker | Stop access to high-risk resources | A separate emergency gateway or bastion with a restricted target role |
| Device posture service | Do not silently ignore the condition | Permit limited time and resources from an approved secure workstation |
| Session recording | Halt high-risk changes or require separate approval | A limited emergency session with an independent log and a manual incident record |
| Central log sink | Local buffer or restricted mode | Independent storage, manual evidence, and later reconciliation |
| Primary bastion | No direct public exposure of targets | An emergency bastion in a different failure domain, or a cloud console recovery path |
Break-glass is designed and audited in advance
Break-glass is not a backdoor that quietly bypasses normal control. It is an emergency operating procedure, designed and audited in advance, that lets a limited group perform necessary recovery when the normal access system has failed. The official guidance of Microsoft, Google Cloud, and AWS commonly emphasises redundancy of the emergency identity, dependencies different from the everyday identity chain, strong authentication, alerting on every use, periodic testing, and credential reclamation after use.
On trigger conditions and accountability, check five things. Are the outage and security incident conditions for using break-glass documented? Are the owner who approves activation and a backup approver named? Does the approval procedure work at night and on holidays? Is convenience use without a related incident or change ticket prevented? Do destructive actions require two-person approval or dual control where possible?
On emergency identity and credentials, check six. Are there two or more emergency identities or credential sets so that no single account or hardware key becomes a point of failure? Is at least one emergency identity not blocked by an outage of the everyday federation, SSO, or conditional access? Does it use phishing-resistant MFA or a hardware credential of a different kind from the everyday admin account? Are the credential and the recovery device stored in different secure locations? Is the account safe from automatic dormancy deletion, expiry, and HR movement processing? Is the emergency identity kept out of everyday work and automation?
On reachability and permissions, check six. Is the emergency access path configured before the incident? Is only the management plane and the targets needed for recovery reachable, rather than the whole network? Are the permitted roles and command scope defined in advance? Where possible, is a maximum duration set on permissions and sessions? Are admin ports or screens kept off the public internet rather than permanently exposed for break-glass? Are cloud access and on-premises access free of a single shared failure dependency?
On audit and detection, check five. Does every successful and failed login of the emergency identity raise an immediate alert? Are the user, time, source, target, trigger reason, and approver recorded? Are shell commands, screens, and configuration changes recorded separately where possible? Does evidence also land in a log store separate from the primary access system? Is there a manual incident log template for when the recording system is down?
On testing and return to normal, check six. Are real logins and limited administrative tasks tested at a cadence matching the risk? Do the tests include IdP failure, MFA failure, DNS failure, and primary bastion failure? Can the operator use the recovery path from the documentation alone? Are all sessions, tokens, certificates, and keys terminated or reclaimed after use? Are long-lived credentials rotated immediately if used? Are the commands and changes reviewed and the return to the normal path confirmed? Are the runbook and permission scope revised after real use or an exercise?
Five designs that commonly fail
First, treating a VPN connection as administrative permission. A VPN provides network reachability. It does not mean a user inside the VPN should reach every admin screen and server. User identity, target authorization, and network segmentation are still needed behind the VPN.
Second, adding a bastion while leaving a bypass. If administrators use the bastion but the target's SSH and RDP ports are also directly reachable on another route, audit and control become optional. Architecture and network policy have to force the bastion hop.
Third, mistaking bastion connection records for evidence of work. That user A connected to server B for thirty minutes is a different fact from which command changed which setting. Session recording and target audit have to be designed separately.
Fourth, turning on identity-aware access without checking direct paths. Even with the access proxy working, a remaining hostname, direct IP, internal route, or management port can skip the proxy's authentication and policy. The concrete exposure paths and how to close them belong to origin security.
Fifth, believing that disabling the IdP account ends all access. Already-issued tokens, VPN tunnels, bastion sessions, target OS sessions, SSH keys, and local accounts may remain. Revocation finishes only once identity, access path, target credentials, and active sessions have all been checked.
Write the decision down as sentences
Once a method is chosen, operating sentences are more useful than product names. Production admin screens are reached only from company-managed devices through identity-aware access. Users and groups are granted per resource, and every allow and deny decision is written to the central log. SSH to production servers is permitted only through the bastion with ephemeral accounts. Target servers are not directly reachable from an administrator's device, and connection history and shell audit are retained separately. Legacy network tools are used only on the separate management VPN. VPN users can reach only the bastion and approved device addresses, not the general business network. On an IdP or access broker outage, a pre-registered emergency identity and a separate bastion are used. Every use is declared an incident, and session termination, credential rotation, and post-review follow the recovery. If those sentences cannot be written, a product has been chosen but the access architecture has not.
A VPN is strong at connecting many protocols and network tools. A bastion is strong at gathering management sessions such as SSH and RDP into a controlled waypoint. Identity-aware access is strong at centralising per-user, per-device, and per-resource policy and the allow decision. None of them is complete on its own. A VPN does not replace target permissions or work auditing. A bastion does not automatically resolve user device state or application authorization. Identity-aware access does not support every legacy protocol, and it still needs target-internal permissions and an independent recovery path of its own.
The right order for deciding administrative access is protocol, resource scope, user identity, device trust, credential, audit, availability, break-glass. Answering the questions in that order, rather than asking which is more modern, produces a management plane that opens minimally in normal times and actually recovers during an outage.
