Perspective
The Browser Is the New Endpoint
Key Finding
Securing browsers is a more honest framing than securing endpoints in 2026. The hardware ships with the user; the browser carries the policy.
The endpoint as a control surface made sense when enterprise work ran inside corporate applications on corporate-managed devices. That estate still exists, but it is no longer where most enterprise work happens. Most work happens in a browser, against SaaS, on devices the organisation does not always own or manage. The endpoint agents shipped to enforce policy on those devices do not see the SaaS traffic, do not understand the application context, and increasingly cannot install on the device at all.
The architectural argument for the enterprise browser as a control surface is not that it replaces every existing control. It is that it sits at the layer where the work actually runs, with native context (the application, the user, the data, the session) that no network-layer or endpoint-layer control can recover by inspection.
The risk to manage is that the browser does not become a parallel identity plane. The IdP is the source of authority; the browser is a downstream policy-enforcement point that consumes identity assurance, applies last-mile controls, and exports session telemetry to the SOC. The architecture decision is where the boundary sits between the IdP's authority and the browser's enforcement — and what happens when one of them is unavailable.
We design and operate enterprise-browser deployments through our Enterprise Browser practice with Island as the lead platform.
Need help with your identity architecture?
Every incident on this page was preventable with the right architecture. Let's talk about yours.
Book a Conversation