Latest / Cybersecurity Business with Fexingo: Security Companies, Breaches, and Enterprise Defense / Why Security Teams Are Using Browser Isolation
Transcript
- Lucas: If I told you that one of the fastest-growing security categories is essentially a tool that lets you open a webpage without actually opening that webpage — would that sound like a gimmick or a breakthrough? Luna: It sounds like the kind of pitch you'd hear at a cybersecurity conference and immediately wonder about the latency. Lucas: Exactly. And that's the tension. We're talking about browser isolation — specifically remote browser isolation, or RBI. The idea is straightforward: instead of letting a user's browser directly render potentially dangerous web content, you run the browser in a cloud container, and stream only a safe visual representation to the endpoint. Luna: So the actual HTML, JavaScript, all the active content — it never touches the corporate device. That's the core promise. Lucas: Right. And look, if this conversation is useful for you — whether you're building security products or running a team — honestly, if today's episode was worth a coffee to you, you can find us at buy me a coffee dot com slash fexingo. It's a small way to keep the show ad-free and focused on the stuff that matters. Luna: Yeah, and we really appreciate that. Okay — so back to isolation. The two main technical approaches worth knowing. Lucas: There's DOM isolation and pixel-push streaming. DOM isolation strips out active content from the page and only sends the document object model — so the page structure — to the user's browser. It's lighter weight but can break some modern web apps that rely on JavaScript. Pixel-push is heavier — it renders the entire page server-side and sends the user a video-like stream of pixels. That's more compatible but uses more bandwidth and introduces noticeable latency. Luna: And latency is the killer. I've talked to security teams that trialed RBI and had executives complain about the lag on interactive sites like Salesforce or Workday. Lucas: That's exactly where the technology is still maturing. Some vendors now use a hybrid approach — they render the page server-side but then send compressed image tiles, so the user experiences near-native scrolling. The best implementations can get latency down to under 50 milliseconds for most interactions. Luna: Fifty milliseconds is the threshold where most users don't notice. But that's in ideal network conditions. On a VPN from a remote office, it can degrade fast. Lucas: Absolutely. So the question becomes: who is actually deploying this today? And the answer is surprisingly broad. Financial services firms are heavy adopters because they have extremely regulated environments where a single drive-by download from an ad network could lead to a compliance breach. Manufacturing companies are using it to protect their OT networks — they want operators to be able to look up supplier documentation online without risking the production floor. Luna: And I've seen it used in healthcare too — for clinicians accessing external medical reference sites from hospital workstations that can't have any unapproved software. Lucas: Exactly. And the use case that's really driving adoption right now is protecting high-risk users — executives, finance teams, anyone who's a likely phishing target. Instead of just blocking risky sites, you let them browse anything but through an isolation layer. That way, even if they click on a malicious link, the browser session is contained. Luna: Which raises an interesting trade-off. If you isolate everything, you add latency to every browsing session. If you isolate selectively, you need a classification engine to decide which sites are risky. And classification engines have their own error rates. Lucas: That's the architectural debate. The vendor pitch is often 'isolate all web traffic,' but in practice most enterprises start with a targeted policy — maybe 20 percent of their users, or 10 percent of web categories. The sweet spot seems to be sites with high user-generated content — forums, wikis, pastebins — places where malicious code is more likely to be injected. Luna: And then there's the third-party access angle. A lot of companies have contractors or vendors who need to access internal web apps from unmanaged devices. Browser isolation lets you provide that access without giving them a VPN or installing any software on their machine. Lucas: That's a huge one. It's basically a zero-trust approach to web access. You're not trusting the device, you're not trusting the network — you're just delivering a visual stream of the application. Some vendors call it 'clientless remote access.' Luna: Okay, so let's talk numbers. What's the market looking like? Lucas: The browser isolation market was estimated at around one point five billion dollars in 2025, and some analysts project it to grow at a compound annual growth rate of about 20 percent over the next five years. That's faster than the overall cybersecurity market, which is growing at roughly 12 percent CAGR. Luna: Twenty percent is impressive, but it's still a relatively niche category compared to something like endpoint detection and response, which is a multi-billion dollar market already. Lucas: Right, but the difference is that browser isolation is positioned as a replacement for part of the secure web gateway market — the legacy proxy-based web filtering that's been around for 20 years. If even 10 percent of the SWG market shifts to isolation, that's billions in new spending. Luna: And the incumbents are paying attention. The major secure access service edge vendors — the big SASE players — have all either built or acquired browser isolation capabilities in the last two years. Lucas: That's the tell. When the platform vendors start embedding a point solution, it means the technology has crossed the chasm from early adopter to mainstream. But there are still open questions around data sovereignty — if you're isolating all web browsing in the cloud, where is that cloud? For European companies with GDPR requirements, they need isolation instances in specific regions. Luna: And there's the question of vendor lock-in. If you isolate all your web traffic through one cloud provider, switching becomes non-trivial. You've essentially moved your web security architecture into their data center. Lucas: Exactly. So the smart approach is to think of browser isolation as one tool in a layered defense, not a silver bullet. Most security teams I talk to are pairing it with endpoint detection and response, email security, and strong identity controls. Isolation handles the web vector, but phishing often comes through email first. Luna: And attackers adapt. If they know a target is using browser isolation, they'll try to deliver the payload through a different channel — maybe a document attachment or a USB drop. Lucas: Right. So the question for a security architect is: where does isolation add the most value relative to the latency and cost? And I think the answer is becoming clearer — it's for high-risk browsing scenarios, unmanaged device access, and for protecting users who can't be trained to avoid every malicious link. Luna: So let's bring it back to the listener. If someone is evaluating browser isolation for their organization, what's the one metric they should track? Lucas: User sentiment. Not just security incidents prevented — which are hard to measure — but actual user productivity. If you deploy isolation and your help desk tickets spike because people can't access their cloud apps, you've created a security solution that undermines business operations. The best implementations are invisible to the user. Luna: Invisible security. That's the goal, right? The user just clicks and the page loads. Lucas: Exactly. And that's where the technology is heading. The next frontier is ai optimized isolation — using machine learning to predict which parts of a page need to be responsive and which can be static, to reduce latency even further. Luna: I've seen some vendors demoing that. They claim they can deliver a pixel-push experience that's indistinguishable from native for 90 percent of web interactions. Lucas: Ninety percent might be optimistic, but the direction is right. And as more organizations embrace zero-trust principles, the idea that you never trust the browser — you isolate it — will become more standard. Luna: It's interesting to think about where this fits alongside other trends. We did an episode on cyber deception grids a while back — that's another 'assume breach' technology. Browser isolation is almost the opposite: it assumes the browser is compromised and contains it proactively. Lucas: That's a really good way to frame it. Deception lures attackers into a trap. Isolation never lets them into the environment in the first place. They're complementary — you could absolutely run both. Luna: Alright, so to wrap up: browser isolation is a maturing technology that's finding its place in enterprise security stacks. The key is targeted deployment, careful latency management, and integration with existing tools. Lucas: And the next time you hear about a zero-day exploit in a web browser, remember that isolation is one of the few defenses that doesn't care what the exploit does — because the exploit is running in a container that gets thrown away after the session. Luna: That's a powerful thought. Thanks Lucas. Lucas: Thanks Luna. And to our listeners — if today's topic sparked an idea, we'd love to hear about it. We'll be back next time.