Remote browser isolation (RBI) loads web pages in a separate, disposable environment away from the user's device and sends the user only a safe rendering. Malicious code stays in that environment. CISA calls it a strategic architectural decision that is more complex and costly up front than other browser defenses, so weigh it against your risk.
How does browser isolation work?
CISA's Capacity Enhancement Guide on securing web browsers and defending against malvertising, aimed at federal agencies, describes it in two steps. Web browser isolation creates a logical barrier between the browser and the operating system, on the premise that all web traffic is untrusted. Keeping the browser separate decreases the impact of exploits by limiting malicious code to a temporary environment.
Remote browser isolation goes further. It moves the processing of web data off the local system to a secure, virtualized environment or an isolated cloud platform with sandbox-like containers. The web transfer happens inside that container, malicious code is removed if present, and the cleaned transmission is forwarded to the user. CISA notes that isolation can be combined with web content filtering, data loss prevention, secure email and web gateways, and that it is available from third-party providers or as a software service.
The CISA guide distinguishes this from site isolation, the process separation that most web browsers already do on the user's machine.
What benefits does CISA list?
According to the guide, isolation:
- keeps potentially malicious code and content in the protected platform, apart from the host operating system;
- reduces the need for website allowlists and blocklists and for browser security training;
- lets administrators tune policy, from isolating a portion of traffic to isolating every download, attachment and link;
- reduces file risk when paired with a file transfer solution for permitted downloads;
- creates logs of risky browsing that can inform insider threat work; and
- can disrupt the link between existing malware on the network and its command and control site.
These are CISA's listed benefits, not guaranteed results. The guide reads as advocacy for one option among several, and your outcome depends on the product and policy you choose.
What are the costs and limits?
CISA is candid that browser isolation is more complex to design, implement and maintain than the other recommendations in the same guide, and potentially carries the greatest initial cost of the three. It suggests lifecycle cost may be lower through reduced incident response, fewer ad-blocking tools to maintain and bandwidth savings, and that in most cases it should be part of a broader architectural change or network refresh. That is an estimate you should test with your own numbers.
Other practical limits follow from the design:
- Rendering and compatibility. Pages are shown through a proxy of the real page, so some interactive sites, video, web apps and developer tools behave differently.
- Downloads and uploads. Users still need files. Whatever file path you allow becomes the new risk surface.
- Privacy and data handling. Browsing content passes through the isolation provider, so review where it is processed and logged.
- Coverage. It protects the browser path only. It does not protect against stolen credentials, malicious email attachments opened outside the browser or vulnerable servers.
- Single point of dependence. If the isolation service fails, so does web access, unless you design a fallback.
A constructed example
A company with 800 staff sees repeated incidents from risky links in the accounts and recruiting teams, who open many unknown sites and documents. Rather than isolate everyone, it routes those two teams, plus web access from administrator accounts, through isolation, and leaves a standard hardened browser for the rest. Downloads for the recruiting team go through a scanning step. Six months in, helpdesk tickets are dominated by two internal web apps that misrender, so the company adds them to a bypass list for managed devices. The scoped approach cost less and covered the highest-risk paths.
How does it compare with the alternatives?
The same CISA guide recommends standardizing and securing browsers, deploying ad blocking and using protective DNS to block malicious domains, and rates these as simpler. For many organizations, a hardened, patched, centrally managed browser with protective DNS closes most of the common paths, and isolation is an added layer for the highest-risk users and sites.
How to check or apply this
- Start with the basics: a single supported browser, automatic updates, managed extensions and protective DNS.
- Identify who and what is highest risk: roles that open unknown links and documents, administrators, high-risk categories of sites.
- Pilot isolation for that group with a bypass process for broken sites and measure ticket volume.
- Decide the file transfer policy before launch: what can be downloaded, scanned and where it lands.
- Review the provider's data handling, logging, availability and exit options.
- Measure outcomes, such as blocked incidents and support cost, and review after six months.
Quick check
Is browser site isolation the same as remote browser isolation?
No. Site isolation separates sites into processes on the user's own device. Remote browser isolation moves the page processing off the device into a separate environment.
Does remote browser isolation replace patching?
No. It covers the web browsing path. Endpoints, servers and applications still need patching, strong authentication and monitoring.
Sources
Last reviewed: 18 October 2026.
