They still route traffic, but they do not reliably control what users do inside a trusted session. That leaves gaps around copy, paste, screenshots, uploads, and browser extensions, which are often the real path for data loss in SaaS-heavy environments.
Why VPNs and proxies miss the real control problem
VPNs and proxies are good at moving and filtering network traffic, but browser-first work is controlled at a different layer. Once a user is inside a trusted session, the highest-risk actions happen in the browser, not on the wire. That is why routing alone rarely governs SaaS use, file handling, or user-driven exfiltration in a meaningful way.
The practical distinction matters: a control that sees destinations and sessions does not automatically see intent, content handling, or local user actions. In SaaS-heavy environments, the browser becomes the execution surface, so the control plane has to address the session, the app, and the endpoint together.
That is also why a network control can appear to “work” while still leaving the organisation exposed. Traffic is still tunneled, but copy, paste, uploads, downloads, screenshots, and extension activity can all occur inside an otherwise valid session. Remote Access Identity Guide frames this as a remote-access design issue, not just a connectivity problem.
Where the control gap shows up in browser-first SaaS work
Browser-first work concentrates risk in user actions that traditional perimeter tools do not own. A VPN can tell you that a device reached a SaaS app, but it does not reliably distinguish an approved business action from a bulk export, a sensitive paste into the wrong field, or data staged into a personal browser extension.
Proxies improve visibility at the HTTP level, but they still struggle with modern web workflows that use encrypted app traffic, multiple tabs, local browser storage, and federation-based sessions. They are also weak at understanding what is happening after authentication, which is exactly where many data-loss decisions are made.
Modern remote-access guidance is increasingly shifting toward conditional access, device posture, and session-aware controls. SonicWall SSL VPN account compromises 2025 and CitrixBleed 2 2025 are reminders that access controls also have to consider session abuse and token theft, not only network reachability.
What effective governance has to control instead
To govern browser-first work well, organisations need controls that follow the session and the data, not just the route. That usually means browser DLP, SaaS access controls, device trust, step-up authentication for risky actions, and policies for extensions and unmanaged devices. In practice, the question is not whether traffic is permitted, but whether the action should be allowed at that moment and on that device.
The strongest designs also reduce reliance on static trust. If a session can reach production SaaS from any device and the browser can freely copy, paste, upload, and install extensions, then the control boundary is too wide. Zero trust patterns are relevant here because they narrow implicit trust and force policy checks closer to the action. NIST SP 800-207 Zero Trust Architecture is useful when you need to reframe access around least privilege and continuous verification.
The governance lesson is that browser-first control is an action-control problem, not a tunnel-control problem. Once teams accept that, they can choose controls that are actually capable of limiting data movement inside the session, rather than assuming the network path is enough.
Risk and Threat Considerations
Browser-first work creates a false sense of control when organisations equate network routing with data governance. The exposed area is not just the connection itself, but the approved session in which a user can still move data out through copy, paste, upload, screenshots, extensions, and synchronized browser state.
Failure mechanism: The organisation trusts the VPN or proxy to enforce access, but the user remains inside a fully functional browser session that can interact directly with SaaS applications and local browser capabilities. Attackers and careless users can exploit that gap without breaking the connection.
Impact: Sensitive data can leave through ordinary user actions while logging and routing controls still look normal, which makes detection slower and containment harder. That increases the chance of silent leakage in SaaS-heavy environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Browser-first control depends on limiting what users can do inside sessions. |
| Recommendation — Enforce least privilege on session actions and app access paths. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The issue is over-trusting a session after network entry. |
| Recommendation — Apply continuous verification and narrow trust around each browser session. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Browser-first governance needs tighter control over who can use what and how. |
| Recommendation — Restrict access paths and review high-risk browser and SaaS permissions. | ||
| OWASP API Security Top 10 | API6 — Unrestricted Access to Sensitive Business Flows | Browser-driven SaaS actions can leak data through legitimate business flows. |
| Recommendation — Protect sensitive workflows from abuse even when the session is authenticated. | ||
| NIST CSF 2.0 | PR.AA-05 — Identities and credentials are managed, verified, and enforced | Session trust and browser access depend on strong identity enforcement. |
| Recommendation — Bind browser access to verified identities and strong session controls. | ||
Practitioner Guidance
What to prioritise: Treat the browser, the device, and the SaaS session as the policy boundary. If your current stack only gates network entry, prioritise controls that can restrict risky in-session actions such as upload, paste, download, and extension use.
What to verify: Test whether your control stack can actually stop the specific data-loss paths you care about. A useful proof is whether it can block a sensitive copy-paste, prevent an unsanctioned upload, or flag an unmanaged browser extension during a real SaaS session.
What good looks like: Users can reach approved apps, but high-risk actions are constrained by policy, device trust, and session context. The organisation can show that access is not just permitted, it is bounded.
Practitioner takeaway: If the control cannot influence what happens inside the browser session, it is not governing browser-first work, it is only transporting it.
Related resources from NHI Mgmt Group
- Why do SOC and AppSec programmes fail to work well together in practice?
- Why do legacy VPNs and thinly layered browser controls increase risk in hybrid work environments?
- Why do browser-in-the-browser attacks work so well against single sign-on users?
- How should security teams govern browser-based AI agents in SaaS environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org