Key takeaways

• Most zero trust remote access implementations enforce policy only at the network layer, granting or denying connections but stopping verification once a session begins.
• The real attack surface for remote work isn't the network connection; it's the browser session where users interact with sensitive data, SaaS apps, and internal tools after access is approved.
• Frameworks like NIST SP 800-207 call for continuous verification, yet conventional ZTNA architectures lack visibility into what happens inside application sessions.
• Extending zero trust controls into the browser closes the enforcement gap network-only approaches leave open, enabling policy at the actual point of data interaction.

Zero trust remote access was supposed to replace implicit trust, not relocate it

Your security team made the right call adopting ZTNA. The logic was sound: eliminate the broad network access VPNs granted, replace it with per-application access decisions based on identity, device posture, and context. Move from "trust the network" to "trust nothing."

The concept traces back to 2009, when Forrester introduced the zero trust model to eliminate implicit trust from network architectures. Over the following decade, zero trust network access emerged as the practical framework: verify who's connecting, check their device, and grant access only to specific applications. No more broad network tunnels. No more lateral movement by default.

The industry responded. A 2024 Gartner survey found 63% of organizations worldwide have implemented a zero trust strategy. Adoption is mainstream. The question isn't whether enterprises believe in zero trust; it's whether their implementations actually deliver it.

Here's where the gap lives. Most ZTNA deployments enforce zero trust at a single moment: the access decision. Approve or deny the connection. After the session begins, the architecture reverts to implicit trust. The user can copy sensitive data to a personal app, download files to an unmanaged device, screenshot confidential records, or paste credentials into a phishing page. The network-layer controls that verified their identity five seconds ago can't see any of it.

This isn't a failure of intent. ZTNA was designed to solve the VPN problem, and it did. But the access decision was the part of zero trust network-layer tools could enforce. Everything happening inside the session sits beyond their reach. The trust didn't disappear. It moved.

What ZTNA controls and what it can't see

Your ZTNA deployment handles the access layer well. Give credit where it's earned. The capabilities it delivers at the network layer are genuinely valuable:

• Identity verification: SSO, MFA, and device certificates confirm the user is who they claim to be
• Device posture checks: OS version, endpoint agent status, and disk encryption validate the device meets policy
• Per-application access: Users connect to specific apps, not the entire network
• Microsegmentation: Application connections are isolated, limiting lateral movement

These controls address a real problem. They replaced VPNs' all-or-nothing access model with something far more precise. But they operate at the connection layer, and the connection layer has a hard boundary. Once the user is inside the application, ZTNA's job is done. Everything after that point falls outside its field of view.

What ZTNA can't see or enforce once the session is active:

• Data interactions inside the session: copy/paste to personal apps, downloads to unmanaged devices, uploads to unauthorized destinations
• User behavior within SaaS applications after login: what they access, what they export, how they handle sensitive records
• Screenshots or screen-sharing of confidential data
• Browser extension activity, including data exfiltration and credential harvesting
• Contractor and third-party activity on unmanaged devices where endpoint agents don't exist

NIST SP 800-207 calls for policy enforcement "as close to the resource as possible." The network layer is structurally far from where data interaction happens. CISA's Zero Trust Maturity Model emphasizes continuous diagnostics and monitoring across the full session lifecycle. Both frameworks describe a standard most ZTNA deployments don't meet, because the architecture wasn't designed to reach that far.

Why the browser session is the actual enforcement gap

Your security visibility ends where your users' actual work begins. That's the paradox most zero trust architectures haven't resolved.

The majority of enterprise work now happens inside the browser. SaaS applications, internal web tools, cloud management consoles, email, collaboration platforms. For remote and hybrid workers, the browser isn't one of many tools; it's the workspace itself. Every document opened, every record viewed, every file shared passes through a browser tab.

Traditional endpoint agents can see process-level activity on the device, but they lack context about what's happening inside that browser tab. Which application is open? What data is the user viewing? Did they just copy a customer record? Network-layer controls see traffic metadata (source, destination, volume) but not application-level behavior. Neither layer can answer the question zero trust demands: what is this user doing with this data right now?

This gap is especially sharp for contractors, BYOD users, and third-party vendors. These users access sensitive applications from devices your organization doesn't manage. Endpoint agents can't be installed. VDI can be deployed, but it's expensive, slow, and creates its own friction. The browser session on an unmanaged device is effectively a black box to most security architectures.

The result is a structural mismatch. Zero trust remote access verifies everything about the connection, then goes silent during the session where data actually moves. The browser session is the last mile of zero trust. It's where access becomes action. And most architectures leave it unmonitored.

Three capabilities that extend zero trust past the network layer

If your enforcement gap lives in the browser session, the enforcement point has to move there, too. Closing this gap requires capabilities operating where data interaction actually happens, not just where connections are made.

Last-mile policy enforcement

Zero trust security requires controls at the point of data interaction, not just data access. That means governing copy/paste behavior based on context: a user can paste into a work application but not into a personal email tab. Download and upload policies can reflect the sensitivity of the data, the user's role, and the device's posture. Screenshot prevention, watermarking, and print controls apply at the moment someone interacts with sensitive content. These aren't blanket restrictions. They're contextual policies shaped by identity, role, device state, and application sensitivity.

Session-level continuous verification

NIST SP 800-207 calls for continuous verification, but network-layer ZTNA can only verify at the connection point. Browser-level telemetry changes this equation. Real-time monitoring of user actions within applications creates the session-level audit trail zero trust architectures need. Anomaly detection based on behavioral context (not just traffic patterns) identifies risks the network layer can't see. This is the continuous verification the frameworks describe, applied where the work actually takes place.

Coverage for unmanaged devices and third parties

Contractors, third-party vendors, and BYOD users represent the hardest zero trust remote access use case. Endpoint agents can't be installed on devices you don't own. VDI provisioning is slow and expensive. Island's Enterprise Browser solves this by making the browser itself the managed endpoint. No agents, no VDI, no device dependency. One organization reduced contractor onboarding from 45 days to 45 minutes by replacing VDI provisioning with browser-based access controls. The browser becomes the trust boundary, regardless of the device underneath it.

How to evaluate whether your zero trust strategy covers the last mile

Most organizations aren't starting from scratch. You've invested in ZTNA, and that investment delivers real value at the access layer. The question is whether it covers the full attack surface.

Five questions to pressure-test your current zero trust architecture:

1. Can you enforce data-handling policies (copy, paste, download, screenshot) inside application sessions, or do your controls stop at the connection?
2. Do you have visibility into what users do after the access decision, or only whether they connected?
3. Can contractors and BYOD users access applications without VDI or endpoint agents while maintaining policy enforcement?
4. Does your zero trust architecture distinguish between "accessing the app" and "interacting with sensitive data inside the app"?
5. Can you generate a session-level audit trail showing user actions within applications, not just connection logs?

If the answer to most of these is "no," the gap isn't in your strategy. It's in the enforcement layer. Most organizations are at stage one of CISA's Zero Trust Maturity Model: network-layer access controls are in place, but session-layer enforcement hasn't been addressed. This isn't a failure; it's a maturity progression. The tooling to enforce zero trust inside the session simply didn't exist when most organizations built their ZTNA deployments.

Recognizing the gap is the first step. The second is evaluating whether your current architecture can close it, or whether a new enforcement point is needed at the session layer.

Zero trust remote access must follow the user, not just the packet

Your zero trust remote access strategy likely started as a network-layer initiative. Verify the user. Check the device. Grant per-application access. That model replaced VPNs, eliminated broad network trust, and gave security teams a meaningful upgrade. It was the right architecture for its moment.

But remote work moved the workspace into the browser. The "trust nothing, verify everything" principle has to extend to the session itself: verifying not just who connects, but what they do after connecting. ZTNA solved the VPN problem it was designed for. The threat model has evolved past what network-layer controls alone can address, and enforcement has to evolve with it.

Organizations building or maturing their zero trust architectures should evaluate whether enforcement reaches the point of data interaction. The enterprises closing this gap are the ones whose secure remote access adapts to how people actually work: in browsers, in SaaS applications, from any device. Twenty percent of the Global 1000 trust Island to deliver that level of enforcement.

The access decision was the first chapter of zero trust. The session is the next one.

See how zero trust extends to the browser

If your zero trust strategy stops at the network layer, there's a gap between access and action. See how Island closes it — schedule a demo.

FAQs

What is zero trust remote access?

Zero trust remote access is a security model requiring continuous identity and context verification before and during application access, eliminating the implicit trust VPNs granted to anyone on the network.

How is ZTNA different from a VPN?

ZTNA grants per-application access based on identity and device posture, while VPNs grant broad network-level access once a user authenticates. ZTNA reduces the attack surface by hiding applications from unauthorized users entirely.

What are the limitations of network-layer ZTNA?

Network-layer ZTNA verifies identity and grants application access but can't enforce policies inside the session. It has no visibility into data interactions like copying, downloading, or screenshotting within the browser.

Why does zero trust need to extend to the browser?

The browser is where remote workers interact with sensitive data, SaaS applications, and internal tools. Enforcing policy at the browser level closes the gap between granting access and governing what happens during the session.