Key Takeaways

• Secure remote access was engineered as a network problem (VPN, then ZTNA, then SASE), but enterprise work now happens in the browser, beyond where those network-layer controls can see.
• Because the browser is now where remote work actually happens, the browser, not the VPN, is the natural control point for secure remote access.
• The attack surface has followed the old control point rather than the work: remote-access appliances keep getting targeted precisely because access is still enforced at the perimeter instead of in the session.
• Delivering access through the browser, with identity, device posture, and data controls at the last mile, closes the gap that VPN-less network tunnels still leave open.

Your VPN was built for a network your work already left

Every morning, remote employees and contractors sign in and wait for a tunnel to connect them to the corporate network, and then the applications they actually need answer from someone else's cloud. That small detour is the tell.

Remote work isn't the exception anymore. Five in 10 full-time US employees hold remote-capable jobs, and among those workers 52% are hybrid and another 26% are fully remote, according to Gallup. The office is one place work happens, not the place.

The VPN solved the access problem of its era. When applications lived in the data center and people needed to reach the network, a tunnel back to headquarters was exactly the right design, and it did that job well for two decades.

Work has since moved. Most applications now live in SaaS and the cloud, so the VPN backhauls a user to a network that no longer holds the work they came to do. The tunnel terminates at the perimeter; the work happens further out, inside a browser tab the tunnel never sees.

There's a trust question, too. Once a user authenticates, a VPN often opens a path to a whole network segment rather than the one application they need, which is more standing access than most remote sessions call for. A single set of stolen credentials then reaches far more than the app the attacker was after.

And the appliance itself has become a target. In 2024, CISA ordered federal agencies to disconnect Ivanti VPN appliances after more than 2200 devices were compromised, and in 2026 it gave agencies three days to patch an actively exploited Check Point VPN zero-day tied to a ransomware campaign. Verizon's 2025 Data Breach Investigations Report found vulnerability exploitation up 34% year over year, singling out perimeter devices and VPNs.

None of this makes the VPN a mistake. It means the VPN is pointed at a network that no longer holds the work, and every layer added on top of it inherits the same blind spot.

VPN, ZTNA, and SASE keep answering a question the network can't

Most teams didn't stand still. They moved from VPN to ZTNA, which replaced the broad tunnel with per-application access and continuous verification. That was a real improvement: a remote user reaches the one app they're entitled to, and nothing else, with their identity checked along the way.

SASE went further, converging networking and security into a single cloud-delivered service. The market has largely settled the debate about whether the two belong together. Forrester's 2025 evaluation of the category noted the standalone security service edge (SSE) market has "largely disappeared," with networking teams now running ZTNA as a natural transition from the VPN.

So the network answer kept getting better with each generation. What none of these approaches were built to do is see inside the session itself. They enforce at the network and transport layers, granting or denying a connection, and when they were designed that was the whole job, because the risk lived on the wire, not in the tab. Asking them to read intent inside a SaaS session is asking them for something they were never meant to provide.

This is also why "VPN-less" can be misleading. Dropping the tunnel is a real gain for both user experience and attack surface, but it moves the connection, not the control point. Access still terminates upstream of the browser, so the same in-session actions stay invisible. Losing the tunnel and moving the controls to where work happens are two different projects, and only the second one closes the gap.

The modern environment surfaced a new question. A copy from a SaaS record into a personal document, a download to an unmanaged laptop, a screenshot of a customer list: these happen inside the browser, after the connection is granted, where a network-layer control has no visibility. The connection can be perfect and the data can still walk out.

Which points to where the missing control belongs. Not deeper in the network, but at the last mile, in the browser where the work actually lands.

The access layer moved to the browser, so the controls should, too

Picture the moment a remote user starts working. They don't connect to your network; they open a tab. The application is a URL, the session is a browser session, and every control you care about (who they are, what device they're on, what they can do with the data) has to apply right there or not at all.

The analysts see the same thing. Gartner describes the browser as the primary access method for most modern corporate applications and an endpoint-agnostic enterprise security control point. Gartner also projects that by 2028, 25% of organizations will deploy at least one secure enterprise browser technology, up from under 10% today. The shift is early, but it's real, and it follows the work.

If the browser is where access happens, the question becomes where the security actually lives. There are three broad architectures:

1. An enterprise browser with security built into the browser itself, so identity, device posture, and data controls apply at the point of work.
2. An extension that adds a security layer to a consumer browser, extending governance to the browsers people already use.
3. A network or proxy approach that sits outside the browser and inspects the connection, but can't interpret what happens inside the session.

The first two put controls where work happens; the third watches from the wire. The distinction that matters isn't extension versus browser, since both belong in a real deployment. It's whether the control point sits inside the session or upstream of it.

This is the shift Island has spent years building toward: an enterprise environment where security is built in, not bolted on. The Island Enterprise Browser and the Island Extension put access and control at the last mile, so identity, device posture, and data governance live in the browser session itself rather than in a tunnel routed somewhere else.

What secure remote access looks like in the browser

Now imagine onboarding a new hire or a contractor without shipping a laptop or standing up a tunnel for them. They open the browser, authenticate, and reach exactly the applications they're cleared for. Nothing is provisioned to a device you may never see, which is what changes when access and control live at the last mile.

A few capabilities become straightforward once the browser is the control point:

• Conditional access evaluated at the moment of access, based on identity, device posture, network, location, and application.
• Zero trust access to private applications without a VPN, delivered through Island Private Access.
• Last-mile data controls inside the session, governing copy and paste, downloads, screenshots, and printing, with DLP applied at the point of interaction.
• Direct paths for most traffic, not a backhaul to a distant proxy, so access stays fast: the idea behind Island Network Services.

Put together, these turn remote access from a plumbing problem into a policy one. The same session that grants the connection also governs what happens next, so a download that shouldn't leave a regulated app simply can't, regardless of the device on the other end.

The effect shows up most clearly with the people who are hardest to equip. When access is delivered through the browser, a contractor installs a browser on any device, authenticates, and gets to work in minutes, with no hardware to ship, no imaging, and no VPN client to stand up. The contractor logs in and works, because the controls were already there.

Contractors and unmanaged devices are where network-centric access breaks

A contractor needs two internal applications for a six-week engagement, on a laptop your team doesn't own and can't reimage. This is the case that quietly breaks network-centric access, and almost every organization runs into some version of it.

The 2025 Verizon report captured the stakes: third-party involvement in confirmed breaches doubled to 30%. Yet the tools on hand force an uncomfortable trade. Ship a managed device with a VPN client and lose days to hardware and imaging, or grant broad network access to a device no one controls. Neither is a good answer; they're just the answers most teams have.

Move the controls to the browser session and the trade mostly dissolves. The unmanaged laptop reaches precisely the applications it should, data controls travel with the session, and nothing sensitive persists locally after the user signs out. The device stays untrusted, and the work still gets done safely.

Offboarding gets simpler for the same reason. When the engagement ends, access ends with the session, so there's no lingering VPN account or standing credential to hunt down and revoke weeks later. For third-party access, where the relationship is temporary by design, that clean expiry is often the difference between a closed engagement and an open door.

Here's the part the feature matrices miss. The real proving ground for any remote-access model isn't the headquarters employee on a corporate machine; it's the contractor no one wants to buy a laptop for. If a model only works when IT owns the endpoint, it hasn't solved remote access. It's relocated it.

How to evaluate a secure remote access approach in 2026

By the time you're comparing options, you've probably read a stack of feature matrices that all start to look alike. The questions that actually separate these approaches rarely show up in the columns.

Four are worth asking directly:

• Where does the control point sit: inside the session where work happens, or upstream of it on the network?
• Can it govern in-session actions like data movement and downloads, or does it only grant and deny the connection?
• Does it cover unmanaged and third-party devices without an agent to install or hardware to ship?
• What's the real deployment and adoption friction, since access controls people route around protect nothing?

That last one is the one to press on. Ask for deployment-friction and adoption data, not another feature list, because the best remote-access architecture on paper fails the moment the workforce works around it. And the workforce works around friction constantly, whether that means a personal device, a copied password, or a forwarded file. It's also worth asking what the approach can show you afterward: whether every in-session action is visible and auditable, or whether the record stops at the connection log.

The stakes for that bypass are already measurable. IBM's 2024 Cost of a Data Breach report put stolen or compromised credentials as the top initial attack vector at 16%, with the global average breach reaching $4.88 million. The 2025 Verizon report attributed another 22% of breaches to credential abuse. A remote-access model people quietly bypass widens the exact gap you were trying to close.

Your remote access problem already moved to the browser

If you're rethinking where secure remote access should live, we're happy to walk through what we've built. Request a demo.

FAQs

What is secure remote access?

Secure remote access is controlled, authenticated, and continuously verified access to corporate applications and data for people working off the network. Modern approaches move enforcement from the network tunnel to the browser session where work actually happens.

Is ZTNA the same as secure remote access?

No. ZTNA is one network-layer way to deliver it, granting per-application access instead of broad VPN access, but it still can't govern what a user does inside the browser session once connected.

Can you have secure remote access without a VPN?

Yes. Browser-delivered zero trust access reaches private applications without a tunnel, and unlike VPN-less network tools, it also enforces data controls inside the session itself.

How do you secure remote access for contractors and unmanaged devices?

Put the controls on the browser session rather than the device, so a contractor on an unmanaged laptop reaches only the approved applications with data controls intact and nothing left behind locally.