Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why Security Teams Are Adopting Browser-Based Isolation
Transcript
- Lucas: If these conversations are useful for what you're building or running, I hope today's topic lands. We're talking about something that sits at the intersection of productivity and paranoia: browser security. Luna: And specifically remote browser isolation — which is one of those terms that sounds like a product category but is really a architectural choice about where code executes. Lucas: Right. The core idea is simple: instead of letting a user's browser render potentially dangerous web content directly on their device, you render it on a remote server — in a container, a VM, or a cloud sandbox — and stream a pixel-perfect, interactive video feed back to the user. So the malicious JavaScript never touches the corporate endpoint. Luna: I've seen estimates that over 60 percent of malware infections now originate from web traffic — drive-by downloads, phishing pages, compromised ad networks. The browser has become the primary threat vector. Lucas: Exactly. Traditional approaches depended on signature-based web filters or URL reputation lists, but those miss zero-day exploits, brand-new phishing domains, and what we call browser-borne malware — payloads that only deliver when the page is rendered in a real browser engine. Isolation solves that by never trusting the browser to begin with. Luna: So there are two main flavors of remote browser isolation. Can we walk through them? Lucas: Absolutely. The first is clientless or cloud-based isolation. The user clicks a link from Slack or email, and that link opens inside a browser session hosted in the cloud provider's infrastructure — Google's BeyondCorp Enterprise, for example, or Cloudflare's Browser Isolation. The user never leaves their familiar browser interface — the actual execution happens on Google or Cloudflare's servers. Luna: And the second flavor is client-based isolation, where you deploy a lightweight agent or a dedicated browser on the endpoint itself that can sandbox tabs locally. Often that's paired with a cloud management plane for policy. Lucas: Yes. The trade-off is latency versus control. Clientless isolation adds some network round-trip delay — usually under 50 milliseconds in my experience — but it means zero software on the device. Client-based isolation can be snappier because rendering happens locally, but you're managing another agent, and if the endpoint is compromised, the isolation is only as strong as the kernel separation. Luna: And both approaches share a common challenge: handling modern web applications that rely on WebAssembly, WebGL, real-time video streams. You can't just render a static screenshot anymore. Lucas: Right. Early isolation solutions struggled with interactive apps like Figma or Google Maps. The pixel-streaming approaches have gotten much better — Cloudflare claims sub-30 millisecond latency on their network — but it's still not a perfect replication. If your workforce lives in heavy browser-based tools, you need to test carefully. Luna: Who is actually buying this right now? Is it mostly financial services and government, or are we seeing broader adoption? Lucas: Broad adoption is accelerating. Gartner estimates that by 2027, 40 percent of enterprise browser security decisions will include isolation — up from maybe 10 percent in 2023. The early adopters were indeed regulated industries — banks, healthcare, defense — because they have compliance requirements like PCI DSS or HIPAA that practically demand isolation for high-risk browsing. But now I'm seeing technology companies, retail, even education deploying it for contractor access and guest network scenarios. Luna: Contractor access is a great use case. You don't want to manage an endpoint for a 90-day project; you give them a login and all their web traffic runs through an isolation layer. That way their local machine never touches your internal apps. Lucas: Exactly. And that ties into zero trust network access — ZTNA. Isolation can be the enforcement point for web applications, while ZTNA handles the rest. Some vendors, like Menlo Security or Ericom, have been doing this for years. The newer entrants are the large cloud providers: Google with BeyondCorp Enterprise, Cloudflare with its Browser Isolation, and even Microsoft has announced plans with Edge for Business. Luna: Let's talk cost. Isolation isn't cheap — it consumes compute and bandwidth. How do CISOs justify the expense? Lucas: Good question. The typical pricing is per-user per-month, and it ranges from $2.50 to $8 per seat depending on features. For a 10,000-person company, that's $300,000 to $1 million annually. That's not trivial. But when you compare it to the cost of a single ransomware incident — which IBM's 2025 data breach report puts at an average of $4.9 million — the ROI becomes clearer. Luna: And there's also the operational savings from not having to patch browsers, not dealing with adware cleanup, and reducing the incident response load from the highest-frequency vector. Lucas: Right. The CISO we spoke to last month at a large insurance firm said they reduced help desk tickets related to browser issues by 40 percent in the first quarter after deploying isolation. Users couldn't install malicious extensions, couldn't download malware from compromised sites, and the IT team stopped chasing cleanup. That's a soft dollar saving, but it adds up. Luna: One critique I've heard is that isolation can break workflows that depend on browser automation or browser-based file uploads. What's your take? Lucas: It's a real concern. Isolation changes the DOM — the document object model — because the actual page is rendered server-side. That means browser extensions like password managers, ad blockers, or even developer tools often won't work. Some vendors allow selective bypass — you can create allowlists for trusted SaaS apps that don't need isolation — but that adds policy complexity. The key is to start with a pilot for the riskiest user group — say, procurement teams who click lots of external links — and expand only after you've addressed friction. Luna: So it's not a replacement for endpoint detection and response. It's a complementary layer. Lucas: Absolutely. Isolation doesn't stop malware that arrives via email attachments or USB drives. It doesn't detect insider threats. But it dramatically reduces the attack surface from the one application that employees use the most — the browser. And as more work moves to SaaS and web applications, that attack surface only grows. Luna: If today was actually useful to you, the way these stay ad-free is listener support — buy me a coffee dot com slash fexingo. Lucas: It's a small gesture that keeps us independent and focused on topics like this one. So thank you if you've already contributed. Luna: Alright, back to browser isolation. One emerging trend I'm watching is the convergence of isolation with cloud access security brokers — CASB — where the same proxy that enforces data loss prevention can also invoke isolation for risky sites. Do you see that as the future? Lucas: I do. The security industry consolidates every decade, and this cycle's theme is platform integration. Vendors like Netskope and Zscaler already offer isolation as part of their secure web gateway. Instead of buying a separate isolation product, you buy the SWG and turn on isolation for specific categories — like newly registered domains or sites in high-risk geographies. Luna: That makes the cost question easier too. If isolation is a feature toggle in a platform you already have, the marginal cost is lower. Lucas: Exactly. And that's why I think standalone isolation vendors will face pressure to differentiate. Menlo Security is pivoting to what they call 'adaptive isolation' — only isolating when the risk score of a page exceeds a threshold. Cloudflare offers isolation as a free add-on for their Zero Trust plan. The bundling is already happening. Luna: What about browser-native isolation? I know Microsoft is building features into Edge — called Edge for Business — that have built-in sandboxing and isolation controls. Lucas: That's a fascinating play. Microsoft Edge for Business includes what they call 'web content filtering' and 'targeted isolation' — it can isolate a specific tab without leaving the browser window. That approach doesn't require a separate proxy; it's built into the browser engine. The downside is it only works on Edge, and it requires an Azure Active Directory — now Entra ID — tenant. So it's a lock-in play. But for Microsoft-centric shops, it's compelling. Luna: So the key takeaway for someone evaluating isolation: test it against your top ten web applications, measure latency and breakage, and consider a dark launch — deploy it only for users who click on suspicious links — before a full rollout. Lucas: Exactly. Start small, get feedback, iterate. And remember that isolation is a control, not a silver bullet. It works best when paired with strong identity, endpoint detection, and user training. Luna: Good advice. Thanks, Lucas. Lucas: Thanks, Luna.