Definition
A Secure Enterprise Browser (SEB) is a dedicated browser designed so that an organisation can govern it by policy. It uses the same Chromium engine as an ordinary browser, so standard web compatibility is preserved, but a security layer inside the browser engine enforces access control, data leak prevention and audit logging as native browser behaviour.
The defining property is where it runs. An SEB executes directly on the user’s device. There is no remote rendering server, no virtual desktop and no network proxy in the path.
Why the category appeared now
Most work moved into the browser, yet organisations had essentially no controls they could apply to it.
- Groupware, mail, approvals, HR and ERP all became web applications
- SaaS adoption spread, and data began living in services outside the organisation’s boundary
- Generative AI entered day-to-day work, and nobody could see what employees were typing into a prompt
Existing security tooling cannot see this layer. EDR and DLP observe outcomes from outside the browser process, so they cannot directly govern the input behaviour inside TLS-encrypted web traffic — prompt entry, clipboard paste, DOM manipulation.
Four approaches
| Browser + extension | RBI | VDI | SEB | |
|---|---|---|---|---|
| Where it runs | Device | Remote container | Remote virtual OS | Device |
| Governs the browser itself | No | N/A | N/A | Yes |
| Local screen capture control | No | No (without an agent) | Partial | Yes |
| Additional infrastructure | None | Rendering server farm | Servers, storage, hypervisor | One policy server |
| Perceived performance | Native | Latency | High latency | Native |
| Best suited to | Minimal control | Browsing unclassified sites | Legacy client required | Web and SaaS centred work |
The structural limit of extensions
An extension only operates within the APIs the browser chooses to expose. That leaves three things it cannot prevent.
- Browser auto-update — an administrator cannot pin a version even when a release breaks a business system
- Developer tools — the console can be used to work around what the extension does
- Disabling the extension itself — once a user turns it off, the control disappears
The one thing RBI cannot do
RBI sends only rendered pixels from the remote session to the device. As physical isolation that is strong, but control ends the moment those pixels are drawn on the local screen. Nothing stops a user from capturing the screen with an OS tool unless a separate agent is installed on the endpoint. The same applies to screen sharing in a video call.
In other words, local screen control only exists if something is present on the device. With an SEB, that something is already installed alongside the browser.
Three questions before deploying
- Is control enforced inside the browser engine? A proxy or extension cannot observe input behaviour inside TLS. The phrase “browser-based” does not distinguish between these designs, so verify in a PoC that prompt blocking and directional clipboard control actually work.
- Does it deploy without changing existing infrastructure or network? If anything beyond a policy server is required — extra servers, a hypervisor, a network redesign — the cost advantage of an SEB disappears.
- Does it run on an air-gapped, on-premises network? A cloud-dependent design cannot be applied in public sector or financial closed networks. Confirm that an offline patch distribution procedure exists.
In short
An SEB does not replace VDI or RBI. It fills a layer that previously had no means of control. A realistic migration path is a hybrid configuration: keep existing isolation for high-criticality areas, and control the majority of work, which runs mainly on the web and SaaS, at the browser layer.
The specific controls and system requirements for BrowZen are on the product page.
