Browser isolation neutralises zero-day threats by never letting malicious code reach the endpoint in the first place. Instead of trying to detect what is dangerous, isolation assumes everything could be. Web content runs in a disposable cloud container, and users receive only a visual stream of the rendered page. The result: even if an attacker exploits an unknown vulnerability, the attack stays locked inside a container that gets destroyed the moment the session ends.
This guide explains how pixel-based rendering works, why detection-based security keeps falling short, and what mid-market IT teams need to know before choosing an isolation approach. We cover the main isolation methods, practical deployment patterns, and the compliance angle for European organisations operating under NIS2 and GDPR.
Featured snippet: how does browser isolation stop zero-day threats
- A user clicks a link or navigates to a website.
- The page loads inside a secure, disposable container in the cloud.
- All code, scripts, and active content execute within that container, completely isolated from the user’s device.
- The user receives only a visual stream of the rendered page and interacts normally through clicks, scrolling, and typing.
- When the session ends, the container is destroyed along with any threats it encountered.
- No malicious code ever touches the endpoint, regardless of whether the threat was known or unknown.
Why detection-based security keeps failing
Most web security tools work by recognising threats. Secure Web Gateways filter URLs based on reputation databases. Antivirus software matches files against known signatures. Sandboxing solutions detonate suspicious payloads in controlled environments. Each of these methods depends on one assumption: that the threat can be identified before it causes harm.
Zero-day vulnerabilities break that assumption. By definition, a zero-day is a flaw that is unknown to the software vendor and has no available patch. Detection tools cannot flag what they do not yet know exists.
The Chrome zero-day CVE-2026-2441, disclosed in February 2026, demonstrated this gap clearly. The vulnerability, a use-after-free flaw in the CSS engine, allowed attackers to execute arbitrary code inside the browser sandbox simply by luring a user to a prepared page. Every Chromium-based browser on Windows, macOS, and Linux was affected. Even with automatic updates enabled, many organisations remained exposed for days while patches rolled out.
This is not an isolated incident. Google patched eight actively exploited Chrome zero-days in 2025 alone. The pattern is structural: browsers execute complex, untrusted code from millions of sources, and the attack surface grows with every new web standard and JavaScript API.
For mid-market IT teams managing hybrid workforces, this creates a difficult position. Blocking unfamiliar sites frustrates employees and pushes them toward shadow IT. Allowing broad access without isolation leaves the organisation exposed to threats that no detection tool can catch in time.
What browser isolation actually does
Browser isolation removes the fundamental risk by separating where web code executes from where the user works. Instead of downloading and running a website’s HTML, CSS, and JavaScript on the local machine, a cloud-based container handles all of that processing remotely.
The user never interacts with the actual code. They see a visual representation of the page, streamed back to their browser, and their inputs like clicks, keystrokes, and scrolling are forwarded to the container. The experience feels like normal browsing. The security model is fundamentally different.
When the session ends, the container is destroyed. Any malware, exploit code, or tracking scripts that were loaded during the session disappear with it. The next session starts from a clean, verified image.
This approach makes the question of “is this website safe?” irrelevant. Every site is treated as potentially dangerous, and no site can harm the endpoint.
Three isolation methods compared
Not all browser isolation works the same way. The market has settled around three main approaches, each with different trade-offs between security, performance, and user experience.
DOM reconstruction
DOM reconstruction loads a web page in a remote environment, strips out active elements like scripts and certain CSS, and sends a sanitised version of the Document Object Model to the local browser.
The upside is low bandwidth usage and minimal latency. The downside is that the sanitising process is imperfect. Sophisticated attackers can hide malicious code in DOM structures that look benign to the reconstruction engine. Complex web applications that rely heavily on JavaScript can also break when scripts are stripped too aggressively, causing layout issues or missing functionality.
DOM reconstruction works well for low-risk browsing scenarios where speed matters more than absolute containment.
Pixel-based rendering (visual streaming)
Pixel-based rendering, sometimes called pixel pushing, is the strongest form of isolation available. The entire web page is rendered inside a cloud container, and the user receives only a stream of visual frames, comparable to watching a video. No HTML, no JavaScript, no CSS reaches the local browser.
| Criterion | DOM reconstruction | Pixel-based rendering |
|---|---|---|
| Isolation level | Logical (code is sanitised) | Physical (air gap between code and endpoint) |
| Zero-day protection | Limited to sanitisation logic | Complete, code never reaches the device |
| Bandwidth requirement | Low | Higher, though modern compression and edge computing reduce the gap significantly |
| User experience | Near-native, but site breakage can occur | Smooth with modern implementations, full interactivity including copy, paste, print |
| Best fit | Low-risk browsing, high-speed requirements | High-security environments, sensitive data access, untrusted sites |
Modern pixel-based implementations have solved the early usability problems that gave isolation a bad reputation. Transparent text overlay layers allow users to select and copy text naturally. Clipboard bridging works securely between container and endpoint. File downloads pass through content disarm and reconstruction before reaching the user’s device. With edge computing and optimised video compression, latency has dropped to levels where most users cannot tell they are browsing through an isolated session.
For organisations handling sensitive data, operating under strict compliance requirements, or needing to protect users who regularly access uncategorised or risky web content, pixel-based rendering provides the highest level of certainty.
Network vector rendering
Network vector rendering (NVR) takes a hybrid approach. Instead of sending pixel frames, the server sends drawing commands to the local browser. This reduces server-side compute requirements and lowers latency compared to pure pixel streaming, while maintaining stronger isolation than DOM reconstruction.
NVR has gained traction in specific enterprise use cases, but its adoption remains narrower than the other two methods. For most mid-market organisations, the choice comes down to DOM reconstruction for lighter use cases and pixel-based rendering for maximum protection.
Why the browser became the primary attack surface
Roughly 85% of business tasks now happen inside a web browser. Email, collaboration tools, CRM systems, financial platforms, HR portals, even code editors run as web applications. The browser has become an operating system within the operating system.
This concentration of activity makes the browser the single most valuable target for attackers. Phishing links open in the browser. Drive-by downloads exploit browser vulnerabilities. Malicious advertisements execute JavaScript in the browser. Data exfiltration from SaaS applications happens through the browser.
Traditional perimeter defences were not built for this reality. Firewalls protect network boundaries that no longer exist when employees work from home, airports, and client offices. VPNs bring remote users “inside” the network perimeter, which actually expands the attack surface rather than containing it.
Browser isolation addresses this directly by ensuring that the browser, the most exposed application on any device, cannot be used as a pathway into the corporate network.
How isolation fits into a SASE architecture
Browser isolation delivers the most value when it is not deployed as yet another standalone tool. Adding an isolated browser on top of existing VPNs, firewalls, and separate web filters just creates another console to manage and another policy silo to maintain.
The more practical approach is to integrate isolation into a Secure Access Service Edge (SASE) platform where it works alongside Zero Trust Network Access, a Secure Web Gateway, Firewall-as-a-Service, and SD-WAN. In this model, isolation becomes one enforcement point within a unified policy framework.
Here is what that looks like in practice:
A user authenticates through ZTNA. Their identity is verified, their device posture is checked, and they receive access only to the specific applications their role requires. When they browse the web, traffic passes through the Secure Web Gateway. Known-safe destinations load normally. Uncategorised or risky destinations are automatically routed through browser isolation. The user sees no difference, but malicious content never reaches their machine.
If the user downloads a file during an isolated session, the file passes through content disarm and reconstruction, stripping out macros, embedded scripts, and other potentially dangerous elements before delivery.
For agentless devices like printers, IoT sensors, and industrial machines that cannot run a browser isolation agent, NIAC hardware provides inline network isolation that enforces the same Zero Trust controls at the network level.
This integrated approach means one console, one policy set, and one audit trail. For MSPs managing multiple customers, the multi-tenant architecture makes it possible to apply consistent isolation policies across all clients without juggling separate products.
Practical deployment scenarios
Hybrid work and BYOD
Personal laptops and phones are the hardest devices to secure. You cannot guarantee their patch level, endpoint protection, or configuration. Browser isolation solves this without requiring an agent. Users access corporate web applications through an isolated session from any device, any browser, any location. If the device is compromised, the isolation layer prevents the compromise from reaching corporate resources.
Phishing protection
Phishing remains the most common initial attack vector. With browser isolation, every link in every email opens in a container. If the destination is a credential harvesting page, the user sees the page but the attack cannot interact with the local machine or access browser-stored credentials. If the link triggers a drive-by download, the malware executes in the container and gets destroyed when the session ends.
Protecting OT and healthcare environments
Medical devices, industrial controllers, and production equipment often run outdated software that cannot be patched or protected with modern endpoint agents. Jimber’s NIAC hardware isolates these devices at the network level, allowing only defined communication flows while blocking lateral movement. Combined with browser isolation for the operators and engineers who access these systems, the entire IT-OT bridge is secured without disrupting production.
Public terminals and shared workstations
Libraries, government service desks, and shared office computers pose unique risks. Each user session runs through an isolated container that is destroyed after use. The next user starts from a clean state. No cookies, no cached credentials, no lingering malware.
The compliance angle: NIS2, GDPR, and demonstrable protection
European regulations do not prescribe specific technologies, but they do require demonstrable risk management and proportionate controls. Browser isolation supports this in concrete ways.
NIS2 expects organisations to reduce their attack surface and contain incidents effectively. Isolation provides structural evidence that web-based threats cannot reach the corporate network, regardless of whether a user clicks a malicious link or visits a compromised site.
GDPR requires that personal data access be limited and appropriate. When browser isolation is combined with ZTNA-based least-privilege access, you can demonstrate that users reach only the applications and data their role requires, through sessions that are logged and auditable.
For auditors, this creates a clean evidence package: identity verification, device posture checks, isolated browsing sessions, content sanitisation for downloads, and a centralised log of every access decision.
How Jimber makes browser isolation workable
Jimber delivers browser isolation as part of its cloud-managed SASE platform. Web content runs in a secure container, and users receive a visual stream of the rendered page. They can still select text, copy, paste, save, and print. In practice, users do not notice the isolation layer, but no malicious code ever reaches their device.
This is not a standalone product bolted onto an existing stack. Jimber integrates Remote Browser Isolation with Zero Trust Network Access, Secure Web Gateway, Firewall-as-a-Service, and SD-WAN in one console. Policies are written once and applied consistently across all users, devices, and sites.
For devices that cannot run agents, NIAC hardware provides inline isolation at the network level, creating a safe bridge between IT and OT environments. The platform is multi-tenant and built for MSPs, with transparent pricing and API-first control for automation.
The result: browser isolation that reduces risk without adding operational complexity. One platform. One policy model. One audit trail.
FAQ
Does browser isolation slow down browsing?
Modern pixel streaming technology introduces minimal latency. For complex web applications, isolation can actually improve perceived performance by offloading heavy JavaScript execution to powerful cloud servers rather than running it on ageing endpoint hardware.
Can users still copy text and download files?
Yes. Transparent overlay technology allows text selection and copy-paste. File downloads pass through content disarm and reconstruction, which strips potentially dangerous elements like macros and embedded scripts before delivering a clean file to the user.
Do I need to install an agent on every device?
No. Browser isolation can work through a browser extension on managed devices or through a web portal for BYOD and contractor access. Agentless devices like printers and IoT equipment can be isolated at the network level with NIAC hardware.
How does browser isolation relate to a Secure Web Gateway?
They work together. The SWG handles URL categorisation, policy enforcement, and known threat blocking. Browser isolation handles everything the SWG cannot predict, especially zero-day threats and uncategorised sites. Integrating both in one platform avoids policy drift and duplicate management.
Is browser isolation only for large enterprises?
No. Cloud-delivered isolation scales without requiring on-premises infrastructure. Mid-market teams and MSPs can deploy it quickly as part of a broader SASE rollout.
How does browser isolation support NIS2 compliance?
Isolation provides evidence that web-based attack vectors are structurally contained. Combined with ZTNA, device posture checks, and centralised logging, it supports the demonstrable risk reduction and incident containment that NIS2 expects.
Protect your team from the threats you cannot predict
Zero-day vulnerabilities will keep coming. Detection tools will keep catching up too late. Browser isolation removes the dependency on detection entirely, and makes it possible to say “yes” to web access without accepting the risk.
Book a demo and see how Jimber’s isolation-based SASE platform protects your users, your data, and your compliance posture from one console.
