What is browser isolation?

Browser isolation runs a web page in a separate, disposable environment — a cloud server, a virtual machine, or a container — instead of directly on your device, so that whatever code the page contains never actually executes on your real hardware. What reaches you is a safe representation of the page, usually a stream of pixels or a sanitized reconstruction of the page's content, not the page's original, potentially malicious code itself.

The three types, and how they actually differ

All three share the same core idea — separating page execution from the environment you actually care about protecting — they just differ in how far away that separation happens, which drives a direct trade-off between latency and isolation strength.

Remote Browser Isolation (RBI)

The actual browser runs on a vendor's cloud infrastructure (Zscaler, Menlo Security, and Cloudflare Browser Isolation are among the most widely deployed), entirely off your organization's network. This is the most common enterprise deployment, since it needs no local install beyond a lightweight client or a proxy configuration change. It's also the type with the most latency, since every click, scroll, and keystroke has to round-trip to the vendor's servers and back before you see the result.

On-premises isolation

Functionally identical to RBI, except the isolation servers live in infrastructure your own organization controls rather than a third-party vendor's cloud. Banks, government agencies, and other organizations with strict data-residency or compliance requirements often choose this specifically so browsing sessions never touch a vendor's servers at all. The trade-off is real operational overhead — your own IT team has to run, patch, and scale that infrastructure instead of a vendor handling it.

Local isolation

The isolated environment (a container or a lightweight VM, as in Windows Defender Application Guard or a Docker-based browser sandbox) runs on your own device rather than a remote server. It's isolated from your main operating system, but it's still your hardware doing the work, which means far less latency than either remote option. A container-escape or VM-breakout vulnerability could theoretically still reach the host device — a failure mode that simply doesn't exist when the isolated browser is running on physically separate hardware entirely, which is the real security trade-off of choosing the lowest-latency option.

Delivery method is a separate axis on top of all three: pixel streaming sends you a live video feed of the remote browser and never lets any of the page's actual code or DOM reach your device, which is the safest approach but the most bandwidth- and latency-heavy. DOM reconstruction (sometimes called page mirroring) instead rebuilds a sanitized version of the page's structure locally, which feels faster and more native to use but means some interpretation of the page's content happens on your own device after all — a slightly larger attack surface than pure pixel streaming, in exchange for a meaningfully better user experience.

How it actually protects you

Because the page's JavaScript, embedded exploits, or malicious downloads execute inside the isolated environment rather than on your device, a zero-day browser exploit or a drive-by-download attack has nothing to actually infect — the code ran somewhere disposable that gets discarded after the session. This is specifically why organizations deploy it against browser-based malware and unknown, unpatched exploits: it doesn't need to recognize the specific threat in advance, since the threat never reaches anything worth attacking in the first place.

It's not bulletproof — the 2024 QR code bypass

In December 2024, Mandiant's red team demonstrated a technique that gets a command-and- control channel through all three types of browser isolation at once. Isolation blocks typical HTTP-based command-and-control specifically because only the visual output of a page is streamed to the local device — the actual HTTP response is never delivered, which normally starves an attacker's malware of any channel to receive instructions. Mandiant's proof-of-concept sidesteps this by encoding commands into a QR code displayed visually on the page. Since isolation is specifically designed to let visual content through — that's the entire point of the pixel stream — the QR code reaches the local device intact, where malware captures a screenshot and decodes it.

The technique has real limits: Mandiant's own write-up caps each QR code at 2,189 bytes of data, with transfer rates around 438 bytes per second once latency is factored in — slow enough that moving a 323 KiB payload took over twelve minutes in testing, far too slow for large-scale data theft. Mandiant integrated the proof-of-concept with Cobalt Strike, a widely used (and frequently abused) penetration-testing framework, specifically to demonstrate it as a viable, if narrow, command channel rather than a theoretical curiosity.

What browser isolation never protected against

Isolation was never designed to stop phishing, and this is the most common misunderstanding about what it actually covers. A convincing fake login page renders perfectly through isolation — the visual content still needs to reach you for the page to be usable at all — and your keystrokes still need to be forwarded back into it for you to type a password. Isolation stops malicious code from running on your machine; it does nothing to stop you from being deceived by what you're looking at.