Key takeaways
- Enterprise browsers work where work happens in a browser — but BYOD, contractors, AI desktop clients, and Electron-based apps have moved a growing share of the work outside that scope.
- The standard fallback — a browser extension for unmanaged devices — doesn’t close the gap, because it remains scoped to a browser the user can disable, bypass, or simply not open.
- Securing the session itself, rather than the application that opened it, brings BYOD, contractor, and AI desktop work into the same control surface without device management.
Enterprise browsers are effective within their intended scope. The problem is that the scope is shrinking relative to where modern work actually happens.
The category was designed for a workforce that no longer exists in most enterprises: one device per employee, all corporate-issued, all running the mandated browser. That assumption held for a while. It doesn’t anymore. The enterprise browser is a device-bound control, and modern work is no longer device-bound. The gap between those two facts is what this piece is about.
The managed-fleet assumption
An enterprise browser works by installing on the endpoint, having the user log in, and routing their session traffic through the browser the company controls. For that to deliver coverage, three things have to be true: the endpoint is one you manage, the user actually opens the browser you mandated, and the work happens inside that browser.
Three years ago, each of those was a reasonable assumption in most enterprises. Today, each one is shakier than the last. The coverage gap is what opens up between the assumption and the reality.
Where the coverage actually breaks
Browser-bound controls work where work happens in a browser. An increasing share of work doesn’t. The perimeter has been widening from four directions at once.
First, the workforce moved off managed devices. BYOD adoption has become mainstream. Global Relay’s 2024 industry research found that 67% of firms use BYOD policies as part of their communications compliance strategy. Even where formal policies prohibit BYOD, Ivanti found that 78% of employees still use personal devices for work. Contractors, third parties, and external consultants compound the problem — you cannot mandate a browser install on machines you don’t own, and most enterprises don’t try. A global payments company with roughly 24,000 employees deployed Island and saw adoption stall at around 20% — about 4,000 seats — because the rollout was a behavior-change project across populations the company didn’t fully control. The vendor answer here is usually “we have an extension for unmanaged devices,” which is its own problem; the next section handles it.
Then, work moved outside browser tabs. This is the part most enterprise browser content still hasn’t caught up to. AI desktop clients are not browsers. Claude Desktop, ChatGPT Desktop, Cursor, and Microsoft Copilot embedded at the OS level are full applications making direct HTTPS calls to external models, and browser-bound controls cannot observe or govern those interactions. An engineer pastes proprietary code into Cursor—an application now used across more than half of the Fortune 500—and no enterprise browser sees it. A salesperson drafts customer-facing language in Claude Desktop, which Anthropic publishes enterprise deployment guidance for through Intune, SCCM, and Windows Group Policy. A finance analyst summarizes a deal memo in ChatGPT Desktop. None of that traverses a browser tab. The implicit assumption in most enterprise browser positioning — that AI equals a browser session — no longer holds. The build moment, the point at which an employee turns a prompt into output that becomes part of the business, has moved off-browser for a meaningful and growing share of AI work.
Then, the applications themselves started making direct HTTPS calls. The growing class of Electron-based desktop applications — Slack, VS Code, Notion, Discord, and the desktop AI clients themselves — route data through HTTPS without ever rendering inside a browser tab. Microsoft’s WebView2 runtime hosts a similar class of experiences inside Office and other Microsoft-stack applications. The session traffic is there; browser-bound controls cannot reach it. Palo Alto Networks has publicly acknowledged this gap with Prisma Browser Beyond, which extends browser-style visibility and control to thick desktop applications that traditionally sat outside that layer of enforcement. CrowdStrike has made a similar move with Falcon Data Protection expanding to local applications. When two of the largest vendors in the space publicly extend their architecture beyond the browser, the gap is no longer a Red Access argument. It’s a category admission.
Finally, users began bypassing the mandated browser altogether. Deployment friction teaches users to route around the control. They open Chrome instead of the corporate browser when the mandated one slows them down. They use personal accounts. They install browser extension “AI wrappers” — in one Red Access deployment, after a company blocked the DeepSeek domain, around 70% of the fleet was found to be using a browser extension that routed data to those same servers anyway. The control only works if the user stays inside it.
Why “extend to BYOD with an extension” doesn’t close the gap
The standard vendor response to the BYOD and contractor problem is a browser extension that can be installed on unmanaged Chrome or Edge. It’s a real improvement on full-browser-swap, and we’d note honestly that it works for a defined set of cases. But extensions can be disabled by users, are scoped to the browser they’re installed in, and don’t reach the desktop AI clients or thick apps that account for a growing share of the work. A security architect at a major partner put it bluntly on a recent call: “I don’t even consider browser extensions as real security at this point.”
The issue is not whether you can deploy the control more easily. The issue is that the control remains attached to a browser, while an increasing share of work no longer happens inside one.
What it looks like to secure the session instead of the application
There’s a different starting point: secure the session itself, not the application that opened it. A session-layer approach observes traffic inside the HTTPS session regardless of which application generated it. Red Access lives in the session — not on the device, not bound to a particular browser. The same control surface observes the session and acts on it: two hats, one place. BYOD and contractors come into coverage without device management. AI desktop clients become visible because they’re emitting session traffic like anything else. Thick apps routing through HTTPS come into view through the same control.
None of this is free or effortless — every architecture has rollout work. But the control isn’t tied to which application the user happens to open, and the coverage doesn’t end at the edge of a browser tab.
When an enterprise browser is still the right call
Enterprise browsers fit some environments cleanly. Call centers and kiosk-style workstations where the device is shared and the browser is the workspace. Highly regulated managed fleets where every device is corporate-issued and tightly locked down. Organizations with near-total device ownership and controlled software inventory. Third-party access scenarios where the goal is specifically to confine a contractor inside an isolated browser session you fully control. M&A integration windows where you need fast lockdown on a defined population.
In those cases, the architecture matches the workforce, and the rollout friction is acceptable. For everyone else, the question worth asking isn’t whether browser-bound controls work — they do, where they apply. It’s whether your workforce still fits inside the scope where they apply.
