Remote Browser Isolation Guide: How Isolation Works and When It Helps

The web browser runs untrusted code from the internet on the same machine that holds corporate credentials, sessions and data, and filtering cannot classify every site before a user visits it. Remote browser isolation (RBI) moves that code execution off the endpoint into a disposable remote browser and sends the user only a safe rendering of the page. This guide explains how isolation works, the main rendering methods and their trade-offs, the use cases where RBI earns its cost, how it compares with enterprise browsers and local sandboxing, and where it does not help. It is for security architects and network or endpoint engineers deciding whether and where to deploy isolation; general browser hardening and extension control are covered in the Enterprise Browser and Browser Security Guide.

Key takeaways

• Isolation assumes all web content is untrusted. Instead of deciding whether a page is safe, RBI executes it remotely and discards the container when the session ends.
• The rendering method sets the security level. Pixel streaming sends no page code to the device; DOM reconstruction sends sanitised code and gives better compatibility; vector rendering sits between them.
• Selective isolation is the normal pattern. Isolating uncategorised, newly registered and risky sites, plus specific sensitive apps, gives most of the benefit at a fraction of the cost and user friction.
• RBI does not stop credential phishing on its own. A user can still type a password into an isolated phishing page unless keyboard input is restricted for that category.
• Enterprise browsers are an alternative, not a duplicate. They enforce policy locally on the device; RBI removes execution from it. Choose by what you need to protect: the endpoint or the data.

How remote browser isolation works

CISA's Capacity Enhancement Guide on securing web browsers describes browser isolation as creating a logical barrier between the browser and the operating system on the premise that all web traffic is untrusted, so that malicious code is confined to a temporary environment. Remote isolation goes further: the processing of web content moves off the local system to a virtualised environment or cloud platform, and only cleaned output is forwarded to the user.

1. Steering: the request reaches the isolation service through a secure web gateway policy, an endpoint agent, a PAC file, or a rewritten link (for example a link in email that opens in isolation). In Cloudflare's implementation, isolation is an action in a gateway HTTP policy (Isolate or Do Not Isolate) and applies to requests that accept HTML.
2. Remote execution: a browser in a container at the provider (or on premises) loads the page and runs its JavaScript, plugins and media.
3. Rendering to the user: the local browser receives a representation of the page and sends back clicks and keystrokes.
4. Policy enforcement: copy, paste, upload, download, printing and keyboard input can be allowed or blocked per policy.
5. Disposal: the remote container is destroyed when the session closes, along with anything the page dropped into it.

Because the isolation service must see page content, TLS is decrypted at the provider, using a root certificate the endpoint trusts. That makes the isolation provider part of your trusted computing base: its logging, data residency and administrative access need the same scrutiny as any SSE component. See the SASE and SSE Guide.

Rendering methods: pixel pushing, DOM reconstruction and vector rendering

How the remote page reaches the user is the main technical difference between products, and the trade-off is always between how much active content reaches the endpoint and how faithfully the page behaves.

The descriptions above follow Cloudflare's published explainer, which notes that pixel pushing needs high bandwidth and that DOM reconstruction can let untrusted third-party code reach the device. Its claims for vector rendering are the vendor's own and should be tested in a pilot. When evaluating any product, ask which method is used for which content type: many products mix methods, for example streaming for risky categories and reconstruction for trusted SaaS.

Do not confuse RBI with in-browser site isolation. Chromium Site Isolation, on by default on desktop since Chrome 67, puts each site in a separate sandboxed process to defend against Spectre-style side channels and, since Chrome 77, against compromised renderer processes. It is valuable, but the code still runs on the endpoint, so a full browser sandbox escape still reaches the device.

Use cases where isolation helps

Cloudflare's isolation policy settings illustrate the controls available in most products: copy (remote to client) and paste (client to remote) can be allowed, limited to within the isolated browser, or denied; file downloads can be allowed, denied or opened only for viewing in the remote browser; uploads, keyboard input and printing can be allowed or denied. Its documentation also notes a limit worth checking in any product: the download and upload settings do not stop files moving between the internet and the remote browser itself, which needs separate gateway file-type policies.

For the contractor case, isolation protects the data from the device; it does nothing about the contractor's identity lifecycle. See the Third-Party Access Guide. For administrators, isolation complements but does not replace privileged access workstations. See the Privileged Session Management Guide.

RBI, enterprise browsers and other alternatives

Several technologies compete for the same budget. They answer different questions, and the right choice depends on whether the main threat is code reaching the endpoint or data leaving it.

• Enterprise browsers: products such as Chrome Enterprise Premium apply DLP rules to file uploads, downloads, paste, print and URL visits, can watermark sensitive pages and restrict screenshots, and report events centrally. That covers much of the data protection case for managed devices without remote rendering. See the Browser Security Buyer's Guide.
• Local isolation is in decline: Microsoft has deprecated Microsoft Defender Application Guard for Edge, and states it is no longer available from Windows 11 version 24H2; Microsoft points to Windows Sandbox or Azure Virtual Desktop for container isolation. Organisations still relying on it need a replacement plan.
• VDI: if users need whole legacy applications isolated, a virtual desktop may be the simpler answer. See the Virtual Desktop (VDI) and DaaS Security Guide.

Decision guidance: small organisations with managed devices usually get more from a hardened, centrally managed browser plus SWG filtering, and use RBI only for uncategorised sites if their SSE platform includes it. Large or high risk organisations (finance, government, critical infrastructure) commonly combine an enterprise or managed browser on corporate devices with RBI for risky categories, email links and unmanaged third-party access. CISA's guide frames isolation as having the greatest initial cost of its browser recommendations but potentially lower lifecycle cost, and suggests considering it as part of a wider architecture change or network refresh rather than as a standalone purchase.

Limits and what isolation does not solve

• Credential phishing: an isolated phishing page still collects whatever the user types. Disable keyboard input or force read-only mode for uncategorised and newly registered domains, and use phishing-resistant MFA. See the Phishing-Resistant MFA Guide.
• Session tokens and cookies: when users sign in to SaaS through isolation, the session lives in the remote browser. That keeps cookies off the endpoint, but it also means the isolation provider holds live sessions. See the Token and Session Security Guide.
• Allowed downloads and pastes: anything the policy lets through reaches the device. File isolation needs content disarm and reconstruction or sandbox detonation behind it.
• Bypass: if users can reach the internet directly (personal hotspot, unmanaged browser, native apps), isolation is optional. Enforce steering on the endpoint and block unmanaged browsers on corporate devices.
• Breakage: video conferencing, WebRTC, complex single page apps, hardware keys and some accessibility tools may misbehave in isolation. Maintain a reviewed "Do Not Isolate" list rather than letting users disable isolation.
• Infostealers already on the device: isolation does not clean an infected endpoint, and a keylogger still records what is typed into the isolated page. See the Infostealer Threat Guide.

Implementing isolation: phased rollout

1. Define the target: choose two or three use cases from the table above and record what success means (fewer endpoint detections from web sources, contractor access without data on the device).
2. Measure the baseline: from SWG and EDR data, find how much traffic goes to uncategorised or newly registered sites and how many endpoint detections start in the browser.
3. Pilot with IT and security staff: isolate uncategorised and high risk categories only, with downloads set to view in the remote browser. Log every breakage report and the site.
4. Tune and widen: build the Do Not Isolate list for business-critical sites that break, under change control. Extend to one business unit, then to email link isolation for high risk groups.
5. Add data controls: for generative AI, file sharing and contractor apps, enable paste, upload and download restrictions, communicated in advance to users.
6. Clientless access for third parties: place the isolated browser in front of sensitive web applications behind SSO and MFA, with copy, print and download off.
7. Rollback: keep isolation as a policy action, so a single rule change returns a category to direct browsing; scope rules to groups so a pilot can be withdrawn without affecting others.

Detection, logging and measurement

What to log: isolation policy matches (user, URL, category, action), blocked actions (download, upload, paste, keyboard, print), Do Not Isolate overrides and who approved them, and isolation service admin changes. Send them to the SIEM alongside SWG and EDR events.

• Browser-originated endpoint detections: EDR detections where the browser is the parent process, before and after rollout.
• Isolation coverage: share of requests to uncategorised and high risk categories that were isolated rather than allowed directly.
• Blocked data movements: monthly paste, upload and download blocks, broken down by destination category.
• Exception list size and age: number of Do Not Isolate entries and how many have not been reviewed in 90 days.
• User experience: breakage tickets per thousand users and median page load time in isolation.

Common failure patterns

• Isolating everything on day one: universal isolation produces latency and breakage complaints, and the programme is scaled back to nothing. Start selective.
• Read-write isolation on phishing-prone categories: users still type passwords into isolated phishing pages because keyboard input was left on.
• Growing exception lists: each broken site is added to Do Not Isolate permanently, until the high risk categories are mostly exempt.
• Protecting the browser while credentials leak elsewhere: in the Cisco Breach 2022, a corporate password saved in the browser synced to a personal Google account that the attacker controlled. Managed browser profiles that block sync of corporate credentials address this; isolation alone would not.
• Unmanaged devices with direct access: in the Snowflake Breach, infostealers on contractor and personal laptops harvested credentials used against customer accounts. Clientless isolation for unmanaged access keeps data off such devices, but it does not stop a credential being stolen from them, so MFA and network restrictions remain essential.

Framework mapping

Practitioner checklist

• Pick two or three specific isolation use cases and a baseline metric for each before buying.
• Ask every provider which rendering method is used for which content and test your critical sites with each.
• Isolate uncategorised, newly registered and high risk categories first, with downloads view-only.
• Disable keyboard input (read-only) on unknown destinations reached from email links.
• Block paste and upload to generative AI and personal file sharing sites unless sanctioned.
• Put clientless isolation in front of sensitive web apps used by contractors on unmanaged devices.
• Keep the Do Not Isolate list under change control with a 90 day review.
• Enforce steering on corporate devices so isolation cannot be bypassed through another browser.
• Replace Microsoft Defender Application Guard where it is still in use.
• Review the isolation provider's logging, data residency and admin access as part of supplier assurance.

Standards and references

• CISA: Capacity Enhancement Guide, Securing Web Browsers and Defending Against Malvertising
• MITRE ATT&CK: Drive-by Compromise
• MITRE D3FEND: Execution Isolation
• NIST: SP 800-53 Rev. 5
• Chromium: Site Isolation
• Microsoft Learn: Microsoft Defender Application Guard for Edge
• Cloudflare Docs: Isolation policies
• Google: Chrome Enterprise Premium data protection rules

Related NHI Mgmt Group resources: Enterprise Browser and Browser Security Guide · Secure Web Gateway and Web Filtering Guide · SASE and SSE Buyer's Guide · ZTNA Guide · CASB Guide