Browser Isolation Without the Vendor Lock

Remote browser isolation is a billion-dollar market (roughly $1 billion in 2025, growing north of 30% a year) built on a simple idea: don't let the browser run on the user's machine. Run it somewhere else, stream the pixels back, and if the browser gets compromised, the attacker is trapped in a disposable box with nothing useful in it.

The idea is excellent — and the threat is real. Phishing has become the single most common way attackers break in, behind 16% of breaches in IBM's 2025 report, and the browser is where almost all of it lands. Gartner now treats the browser as a security control point in its own right, predicting that 25% of organizations will deploy a secure enterprise browser by 2028, up from under 10% today.

The problem isn't the idea. The problem is that vendors like Menlo Security, Zscaler, and Island charge $10–30 per user per month, route all your browsing traffic through their cloud, and lock you into their ecosystem. For a 500-person company, that's $60,000–$180,000 a year — for a browser.

What Browser Isolation Actually Does

Browser isolation runs web browsers in an environment completely separate from the user's device. All code execution, rendering, and downloads happen in the isolated environment. The user sees a visual stream of the session. If the browser is compromised, the attacker has no path to the user's machine.

Every browser is an attack surface. JavaScript execution, WebAssembly, PDF rendering, image decoders, font parsers — modern browsers have a massive surface area. Zero-day exploits targeting Chrome and Firefox appear regularly. Browser isolation eliminates the risk by moving the entire browser runtime off the endpoint.

• Drive-by downloads — malicious code executes in the isolated VM, not on the user's laptop. Even if the exploit succeeds, it's trapped.
• Phishing pages — credential harvesting pages run in isolation. Combined with URL policies, you can let users browse freely while containing the risk.
• Data exfiltration — the isolated browser has no access to the corporate network, local files, or other applications. There's nothing to steal.
• Zero-day protection — even unpatched browser vulnerabilities can't reach the endpoint. The isolation boundary is the defense, not the browser's own security.

Why Containers Aren't Enough

Most vendor RBI solutions use containers for isolation. Containers share the host kernel, which means a kernel exploit can escape the container and reach the host. For high-security environments, this is an unacceptable risk.

Container escapes are not theoretical. CVE-2024-21626 (Leaky Vessels) allowed container escape via runc. CVE-2022-0185 allowed privilege escalation from a container to the host kernel. These vulnerabilities affect every container-based isolation product.

VMs are fundamentally different. Each VM runs its own kernel. The isolation boundary is enforced by the CPU itself (Intel VT-x, AMD-V). A compromised process inside a VM cannot access the host kernel, other VMs, or the host network — there is no shared kernel to exploit.

The OpenFactory Approach

Build a purpose-built Linux VM with a hardened browser, deploy one per user or per session, and get full hardware-level isolation. No vendor cloud, no per-seat licensing, no traffic leaving your network.

Instead of paying a vendor to run browsers in their cloud, build your own browser isolation VMs with OpenFactory:

• Hardware-level isolation — each browser session runs in its own KVM virtual machine with a separate kernel. No shared kernel, no container escape risk.
• Purpose-built images — the VM contains only what's needed: a hardened Linux base, a locked-down browser, and nothing else. Minimal attack surface.
• Your infrastructure — browser traffic stays on your network. No routing through a vendor's cloud. No third-party trust. No data sovereignty concerns.
• Flat cost — no per-user, per-month licensing. Build the image once, deploy as many instances as you need.
• Disposable sessions — destroy and rebuild the VM after each session. Every session starts from a clean, known-good state.

Vendor RBI vs. Self-Hosted VMs

Who Needs This

Browser isolation is critical for healthcare (HIPAA), government (FedRAMP), finance (PCI DSS), OSINT and threat intelligence teams, and any organization that needs to give contractors or BYOD users secure web access without exposing the corporate network.

• Healthcare — HIPAA requires protecting PHI from browser-based threats. Isolated browser VMs ensure that even compromised sessions can't reach patient data systems.
• Government & Defense — FedRAMP and CMMC environments need air-gapped or fully isolated browsing. Self-hosted VMs keep all traffic on-premise with no vendor cloud dependency.
• OSINT & Threat Intelligence — analysts browsing hostile infrastructure need disposable, isolated browsers that leave no trace and can't be fingerprinted back to the organization.
• BYOD & Contractors — give external users secure web access through isolated browser sessions without installing agents or trusting their devices.
• Financial services — PCI DSS environments benefit from isolating web access to prevent browser-based attacks that could reach cardholder data systems.

How to Build It

OpenFactory builds a complete browser isolation VM as a bootable image in minutes. Describe what you need — a hardened desktop with Firefox, locked down to specific domains, with no persistent storage — and the system generates a deployable ISO.

1. Go to console.openfactory.tech and describe your browser isolation requirements in plain language, or pick from existing scenarios.
2. Customize the security level, allowed domains, browser configuration, and any additional tooling.
3. Build and download the ISO. Deploy it as a VM on your hypervisor (KVM, VMware, Hyper-V) or bare metal.
4. Spin up one instance per user, per session, or per department — destroy and rebuild as needed.

How do you keep sessions clean and right-sized?

Two operational habits keep a self-hosted fleet honest. First, treat every VM as ephemeral: tear it down and rebuild from the golden image after each session instead of trusting a “reset.” A drive-by that lands mid-session dies with the VM, and the next user always starts from a known-good state. Second, size for concurrency, not headcount — you only need enough memory and vCPU for the browsers running at the same time. A pool of disposable VMs recycled on logout serves far more users than your seat count, which is exactly the math vendors charge per-seat to obscure.

The same isolation model now matters for software, not just people. If you run autonomous AI agents that open URLs and click around the web, each one is an untrusted browser session that should live in its own VM — see sandboxing AI agents for that pattern. Need it audited and supported at scale? Our enterprise tier covers fleet management, and pricing stays flat regardless of how many isolated browsers you spin up.

No vendor contract. No per-seat licensing. No routing your employees' browsing through someone else's infrastructure. Your browser VMs, your network, your rules.