Remote Browser Isolation Explained: When You Need It and When You Don't

RBI runs web content in a disposable cloud container and streams safe output to the user. Three approaches exist: pixel-pushing (most secure, worst UX), DOM reconstruction (best UX, less secure), and network-level isolation (middle ground). Most SSE vendors include basic RBI but charge extra for full coverage. Target RBI at uncategorized URLs, high-risk categories, and untrusted email links — not all web traffic. If your SWG handles 95% of threats through URL filtering and TLS inspection, RBI covers the remaining 5% where you cannot categorize the risk.

Remote Browser Isolation (RBI) executes web content in a disposable cloud environment and delivers only safe rendered output to the user's endpoint. The browser the user sees is a projection — all JavaScript execution, plugin rendering, and file downloads happen in an ephemeral container that gets destroyed when the session ends. If the page carried a zero-day exploit, a drive-by download, or a credential-harvesting script, it detonated inside that container and never touched the endpoint.

RBI exists because URL filtering and TLS inspection cannot catch everything. SWGs block known-bad sites and inspect encrypted traffic, but they rely on categorization databases and signature-based detection. An uncategorized site hosting a watering-hole attack, a compromised legitimate domain serving malicious ads, or a brand-new phishing page that has not been flagged yet — these all pass through URL filtering. RBI eliminates the binary choice between blocking a site entirely and allowing unrestricted access. You render it safely instead.

How RBI works: three isolation approaches

Not all RBI is equal. The three implementation approaches trade off security, performance, and user experience differently. Understanding which approach your vendor uses — and whether you can configure it per policy — matters more than whether the feature exists on a datasheet.

Pixel-pushing (pixel streaming)

The cloud container runs a full headless browser, renders the page, and streams a video-like pixel representation to the user's browser. The endpoint receives only image data — no HTML, no JavaScript, no DOM, no active content of any kind. This is the most secure approach because nothing from the original page reaches the endpoint. The trade-off is latency: pixel-pushing adds 50–200ms of perceivable delay depending on PoP distance, and interactive elements like scrolling, form filling, and copy-paste feel sluggish. Bandwidth consumption is higher because you are streaming rendered frames rather than compressed markup.

DOM reconstruction (DOM mirroring)

The container renders the page, strips all active content (JavaScript, iframes, plugins), and sends a sanitized HTML/CSS reconstruction to the user's browser. The endpoint renders clean markup natively, so scrolling, text selection, and copy-paste work normally. Latency is lower than pixel-pushing because the payload is lighter. The trade-off is security: the reconstruction process must correctly identify and strip every potentially malicious element. Sophisticated attacks that embed payloads in CSS, SVG, or font files can sometimes survive sanitization. DOM reconstruction is good enough for most web browsing but is not the right choice for high-risk scenarios like rendering phishing pages or known-compromised domains.

Network-level isolation (draw/command remoting)

A middle-ground approach where the container sends rendering commands (draw instructions) rather than raw pixels or DOM. The endpoint's RBI client interprets these commands to reconstruct the visual output locally. This reduces bandwidth versus pixel-pushing while maintaining stronger isolation than DOM reconstruction. Ericom (now part of Cradlepoint/Ericsson) and some vendors use this approach. The downside is it requires a proprietary client-side component, which adds deployment complexity.

When you need RBI

RBI is not meant for all web traffic. Running every page through isolation would destroy user experience and cost a fortune in compute. Target RBI at the traffic your SWG cannot confidently categorize or safely inspect.

• Uncategorized URLs — sites not yet in your SWG's URL database. These represent 2–5% of web traffic in most enterprises and are disproportionately risky because threat actors register new domains specifically to avoid categorization.
• High-risk URL categories — newly registered domains, parked domains, dynamic DNS, and personal sites. These categories have the highest false-negative rates in URL filtering.
• Untrusted email links — URLs from inbound email that rewriting or sandboxing flagged as suspicious but not definitively malicious. Routing these through RBI lets users access the content without risk.
• Unmanaged device access — BYOD users accessing corporate SaaS through a browser without an endpoint agent. RBI provides a security boundary when you cannot trust the device.
• High-value user groups — executives, finance, and M&A teams who are targeted by spear-phishing and watering-hole attacks more frequently than the general population.

When you don't need RBI

If your SWG has TLS inspection enabled, a current URL database, inline sandboxing, and you are comfortable blocking uncategorized sites outright — you may not need RBI at all. Most SWG deployments block 98%+ of web threats without isolation. RBI covers the residual gap.

• Known-safe corporate SaaS — M365, Google Workspace, Salesforce, and other sanctioned applications already have CASB inline policies. Adding RBI here adds latency with no security benefit.
• Internal applications behind ZTNA — private apps accessed through ZTNA micro-tunnels never touch the public internet. RBI is irrelevant for this traffic.
• Bandwidth-sensitive environments — video conferencing, streaming media, and large file transfers should bypass RBI. The compute and bandwidth overhead would be prohibitive.
• Environments that block uncategorized sites — if your security policy blocks rather than allows uncategorized URLs, you have already solved the problem RBI addresses, at the cost of user friction from false positives.

SSE vendor RBI landscape

Every major SSE vendor offers RBI, but inclusion, depth, and pricing vary significantly. The trend since 2024 is toward bundling basic RBI in the base SSE license and charging for advanced features like full pixel-pushing or unlimited isolation sessions.

The death of standalone RBI

Until 2022, RBI was a standalone market. Menlo Security, Ericom, and Authentic8 sold dedicated browser isolation platforms that sat alongside your SWG or proxy. Organizations deployed them as bolt-on security layers — a separate vendor, separate console, separate agent or browser extension.

That market is effectively dead. Ericom was acquired by Cradlepoint (Ericsson) in 2023. Menlo Security remains independent but faces margin pressure as SSE vendors bundle RBI for free. Authentic8's Silo remains relevant for niche government and intelligence use cases but is not a mainstream enterprise play. The integration economics are brutal: why pay $5–8/user/month for standalone RBI when your SSE vendor includes it at no incremental cost?

The practical implication: evaluate RBI as a feature within your SSE platform, not as a separate procurement. If your shortlisted SSE vendor's RBI is weak, that is a scoring factor against them — not a reason to add a standalone RBI vendor to the architecture. Adding a standalone layer introduces an extra TLS inspection point, a second management console, and a second set of policies to maintain. The operational overhead is not worth it unless you have a very specific requirement (e.g., Authentic8 Silo for classified browsing) that no SSE vendor can meet.

Performance and UX reality check

RBI vendors claim 'imperceptible latency' and 'native browsing experience.' In production, the reality is more nuanced.

• Pixel-pushing adds 50–200ms of visible latency on top of your existing SWG inspection. For text-heavy sites this is acceptable. For interactive web apps with drag-and-drop, real-time collaboration, or heavy scrolling, users notice and complain.
• Copy-paste breaks or degrades in most pixel-pushing implementations. Users cannot select text naturally — they interact with a pixel stream, not a DOM. Vendors add clipboard bridging, but it is clunky compared to native behavior.
• Printing from isolated sessions requires the page to be re-rendered and exported as PDF through the isolation layer. It works, but it is slow and sometimes mangles layouts.
• File downloads are sandboxed — downloaded files pass through the isolation layer's scanning before reaching the endpoint. This adds seconds to every download. Some implementations CDR (Content Disarm and Reconstruct) the files, stripping macros and active content.
• DOM reconstruction has fewer UX issues but lower security guarantees. If your threat model includes targeted attacks against your organization specifically, pixel-pushing is the safer bet despite the UX cost.

Decision framework

Use this framework to determine whether RBI belongs in your deployment and how aggressively to apply it.

1. Start with your SWG baseline. Enable TLS inspection, update your URL database, configure inline sandboxing. Measure your block rate and false-positive rate for 30 days.
2. Identify the gap. What percentage of web traffic is uncategorized? How many users click email links to unknown domains? How many helpdesk tickets come from blocked-site false positives?
3. If uncategorized traffic is under 1% and you are comfortable blocking it, skip RBI. Your SWG handles the risk.
4. If uncategorized traffic is 2–5% and blocking it generates user complaints, enable RBI for uncategorized URLs only. This is the sweet spot for most deployments.
5. If you have high-value targets (executives, finance, legal) or a threat model that includes targeted attacks, add RBI for those user groups across all URL categories.
6. If you support BYOD or unmanaged devices, use clientless RBI as your primary security control — it provides a security boundary without requiring an endpoint agent.
7. Never enable RBI for all traffic for all users. The performance cost is too high and the incremental security benefit over targeted isolation is marginal.

Sources & further reading

• Gartner, "Market Guide for Remote Browser Isolation" — gartner.com/reviews/market/remote-browser-isolation
• NIST SP 800-46 Rev. 2, "Guide to Enterprise Telework, Remote Access, and BYOD Security" — nist.gov/publications/guide-enterprise-telework
• Zscaler, "Cloud Browser Isolation" — zscaler.com/technology/browser-isolation
• Netskope, "Remote Browser Isolation" — netskope.com/products/remote-browser-isolation
• Cloudflare, "Browser Isolation" — cloudflare.com/products/zero-trust/browser-isolation

Related on sase.cloud

One email per publish. Unsubscribe anytime.