The choice should be driven by device trust, user role, and application type. Browser-based access suits unmanaged or personal devices because it avoids endpoint clients and limits exposure to only the published applications. VPN is better for managed devices and trusted employees who need native apps, certificate-based authentication, and full traffic protection across corporate and internet traffic.
How to choose the right remote access pattern
Start with the access problem, not the technology label. Browser-based access is strongest when you want to publish a limited set of applications to less trusted endpoints, while VPN is stronger when the user needs broader network reach, native client support, or long-lived access to internal services. The real decision is how much of the corporate environment the remote session should be able to reach.
Device trust is the first filter. If the endpoint is unmanaged, shared, or personally owned, browser-based access usually reduces exposure because the application is mediated and the user does not need a broad network tunnel. If the device is managed and meets security baseline requirements, VPN can be reasonable because the organisation can enforce stronger endpoint controls and tie access to the corporate device posture.
User role also matters. Contractors, partners, and occasional users usually need a narrower access model than employees with operational responsibilities. A published-app model often fits occasional or task-specific access better, while VPN fits users who need internal tooling, file shares, administrative workflows, or application stacks that were not designed for per-app publishing. The question is not which model is more modern; it is which one matches the actual work pattern.
Where browser access is the safer default
Browser-based access is a good fit when the goal is to minimise blast radius and avoid placing a full network edge on the endpoint. It is especially useful for business applications that already work cleanly in a browser, for third-party access, and for temporary access where you want to reduce the chance that a stolen session or compromised endpoint turns into broad internal reach.
It also changes the trust boundary in a useful way. Instead of extending the corporate network to the user device, you expose only the application the user is meant to see. That makes browser access a better match for zero trust design principles, and it aligns with guidance that emphasises verify-first access and least privilege for remote sessions. NIST’s Zero Trust Architecture guidance is a useful reference point here, and Remote Access Identity Guide covers the same practical trade-offs for VPN replacement, device posture, and MFA at the entry point.
Browser-based access can also simplify offboarding and reduce dependency on endpoint software. When you do not need a VPN client, you eliminate one more component that can be misconfigured, forgotten, or left installed after a role change. That is particularly valuable for outsourced users and short-term staff, where access should be tightly scoped and easy to revoke.
When VPN still makes more sense
VPN remains the better choice when the user genuinely needs full network access, not just application access. That includes native desktop applications, legacy systems, private subnets, and workflows that depend on internal name resolution, file systems, or protocols that do not work cleanly through a browser proxy. If the business process depends on broad internal connectivity, forcing it into a browser-only model can create brittle workarounds and shadow access paths.
VPN also makes sense when the organisation can manage the endpoint well enough to treat it as trusted. On managed devices, VPN can work with certificate-based authentication, stronger endpoint posture checks, and full traffic protection across both corporate and internet-bound traffic. The trade-off is that the tunnel expands the blast radius, so the security value depends on how tightly the organisation controls the device and the identity behind it.
That is why VPN deserves extra scrutiny in environments where credentials are the main control. The weakest remote access failures are usually not caused by the tunnel itself, but by weak authentication, dormant accounts, reused credentials, or lack of MFA. SonicWall VPN Mass Breach via Stolen Credentials shows how quickly remote access becomes a compromise path when credential hygiene is poor, and Change Healthcare breach 2024 is a reminder that a single remote login without MFA can have disproportionate consequences.
Risk and Threat Considerations
Remote access choices change the attack surface, not just the user experience. Browser-based access limits reach, but it still depends on strong session protection and clean application boundaries. VPN expands the reachable environment, so a compromised credential, stolen token, or unmanaged account can become a path to multiple internal systems rather than one published application.
Failure mechanism: Attackers typically abuse the weakest entry condition, such as reused credentials, missing MFA, dormant remote accounts, or over-broad network reach, and then pivot from the remote access path into internal services that were assumed to be protected by the tunnel.
Impact: The consequence can range from a single application compromise to broad lateral movement, data exposure, or ransomware spread, especially when remote access is treated as a convenience layer instead of a high-value control boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-05 — Least Privilege | Remote access choice should minimise exposed resources and trust per user and device. |
| Recommendation — Prefer application-scoped access and limit each remote session to the minimum required resources. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Remote access decisions hinge on how strongly employee users are authenticated. |
| IA-9 — Service Identification and Authentication | Remote access environments often include non-human clients, gateways, and backend services. | |
| Recommendation — Require strong authentication for managed-user remote access before granting tunnel-based connectivity. Authenticate remote access components and service connections separately from human users. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The question is fundamentally about controlling who can reach what over remote access. |
| Recommendation — Restrict remote users to approved applications, systems, and network paths. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | Remote access security depends on strong authentication at the access boundary. |
| Recommendation — Use strong authentication for all remote access entry points and privileged connections. | ||
Practitioner Guidance
What to verify: Before choosing VPN, confirm that the device is managed, the user truly needs network-level access, and the authentication method is strong enough for a broad trust boundary. Before choosing browser-based access, verify that the target application can function safely without broad internal connectivity and that session controls are robust.
Decision rule: If the user is on an unmanaged device or only needs a small number of applications, prefer browser-based access. If the user needs native applications, internal subnets, or full traffic handling and the endpoint is controlled, VPN can be justified, but only with strong identity and device assurance.
Common mistake: Treating VPN as the default because it is familiar. That usually creates more access than the job requires, which increases blast radius and makes account hygiene, revocation, and monitoring more important than teams often plan for.
Practitioner takeaway: The right answer is not browser versus VPN in the abstract, it is the smallest access path that still supports the work, with the tunnel reserved for cases where managed-device trust and full network reach are genuinely required.
Related resources from NHI Mgmt Group
- How do organisations decide between passwords and certificate-based authentication for remote access?
- How do organisations decide when browser-based access is appropriate?
- How should organisations reduce the risk of VPN-based compromise when remote access still depends on usernames and passwords?
- How should organisations secure remote access to high-performance workloads in Azure without relying on broad VPN access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
