Extending Zero-Day Browser Protection to NGFW Users with Prisma Access RBI

[shv]

Extending Zero-Day Browser Protection to NGFW Users with Prisma Access RBI

The web browser is no longer just an application; it is the modern operating system. With 85% of enterprise work occurring within a browser tab, employees rely on these tools for nearly every daily task. For most organizations the security model behind that browser is a next-generation firewall at the gateway, URL filtering to block the sites we already know are bad, and threat prevention signatures to catch the malware we've already seen. That model has served us well for years. The trouble is that "already seen" is exactly where it runs out of road. A phishing page registered an hour ago, a drive-by exploit riding a legitimate ad network, a malicious script tucked inside a site your users visit every day, none of these have a signature yet, and the attacker is counting on that head start.

Palo Alto Networks Remote Browser Isolation (RBI) closes that gap by changing the question entirely. Instead of inspecting web content and gambling on whether it's safe, RBI simply keeps it off the endpoint. The page loads and executes in a browser running in a Palo Alto Networks secure cloud environment, and all your user receives is a live rendering of it. Credential harvesters, ransomware droppers, whatever the site is really carrying, it runs over there, not on the endpoint.

The Gap We're Closing

Palo Alto Networks RBI, through Prisma Access, has protected users connecting through Mobile Users (GlobalProtect), Explicit Proxy, and Remote Networks for a while now. However, a significant segment of our customer base remained underserved: organizations utilizing NGFW as their internet gateway at branches, campuses, and data centers. These are customers who already trust us with the hard part of the network, running Advanced Threat Prevention, DNS Security, and WildFire. Yet when it came to browser isolation, they had no path to it without standing up something new.

So the question we set out to answer was a practical one. Could we extend RBI to NGFW users without asking them to rearchitect the network or push a new agent onto every endpoint? It turns out we can, and the way we do it leans on plumbing most of these customers already understand.

How It Works

Prisma Access has long supported Remote Networks, enabling site-to-cloud connectivity via IPSec tunnels. By routing internet-bound traffic through Prisma Access, we apply comprehensive inspection and policy enforcement to that traffic. Branch connectivity teams have used it for years. We're reusing that same well-worn path.

Figure: NGFW + Prisma Access + RBI – Traffic Flow

The NGFW establishes a Remote Networks IPSec tunnel to Prisma Access. Once it's up, internet traffic from behind that firewall rides the tunnel into Prisma Access, where URL filtering, threat prevention, and RBI apply the same way they would for any other Prisma Access user.

For the user, nothing really changes. They open a browser, go to a site, and if it falls under RBI policy the page renders in isolation with the usual notification. Whether someone is a mobile user on GlobalProtect or sitting at a branch behind an NGFW, the experience lines up.

For the administrator, setup follows two simple, complementary steps; 

1. On the NGFW, you point internet-bound traffic into the IPSec tunnel toward Prisma Access.
2. In Strata Cloud Manager, you set the isolation policy that greets that traffic and applies RBI, the profiles, the URL Access rules, the isolation settings. 

And here's the part that ties it together: both the NGFW and Prisma Access can be managed and configured from Strata Cloud Manager, so the firewall, the tunnel, and the isolation policy all live behind one centralized management plane. It's the same RBI policy your Prisma Access users already run, from the same single pane of glass, so isolation for your NGFW sites sits right alongside everything else you already control. And because policy can key off user identity, you can be as targeted as you like, isolating an entire branch, a specific department, or just your contractors and high-risk roles.

Use Cases

High-risk and Everyday Browsing: Even routine web activity—news, forums, and sports—can be breeding grounds for malvertising and drive-by exploits. Apply RBI to those categories and the browsing happens remotely. The endpoint is watching a rendering, not running the code.

Phishing and credential harvesting: A branch employee clicks a link in an email that points to a phishing page spun up an hour ago, with no reputation or threat history to flag it. Under RBI the page opens in isolation, and any credentials the user types never make it to the real site. The attack is defused before it has a chance to work.

Last-mile data controls inside the isolated session: This is where RBI does more than just wall off malware. Because the session runs in our cloud browser, you get fine-grained control over what a user can actually do on the page. You can allow a .txt upload but block an .xlsx, restrict downloads by file type, turn off print, gate clipboard copy and paste, and even lock keyboard input for read-only sessions. You can also let people view files, an attachment, a shared document, entirely inside isolation so the file is seen but never lands on the device. For teams worried about data leaving through the browser, these are often the controls that matter most.

AI application governance: As ChatGPT, Gemini, and Copilot work their way into daily habits, the risk of sensitive data walking out through a chat box goes up. Running these sessions through RBI lets you keep the tools available while applying the same last-mile controls, blocking a file upload, stopping a paste of source code, filtering what goes in, without slamming the door on the productivity people came for.

Why This Matters Now

The center of gravity for attacks has moved to the browser. It's where credential theft starts, where a lot of ransomware gets its first foothold, and where data quietly leaves. Signatures still earn their keep, but leaning on them alone in 2026 is a bet against the odds.

For anyone already running Palo Alto Networks NGFW, this is the shortest route to browser isolation that doesn't involve ripping anything out. The firewall stays where it is. The IPSec tunnel to Prisma Access is a known quantity. The isolation policy lives in SCM next to everything else you already manage. The payoff is straightforward: users behind an NGFW get the same zero-day browser protection that used to require a Prisma Access agent.

There's a consolidation story here too. Plenty of organizations already bolt on a standalone browser isolation product from a separate vendor, which means a separate console, a separate contract, and a separate support path sitting off to the side of the firewall they trust. Folding isolation into the platform they already run collapses all of that into one place. One vendor, one policy model, one pane of glass for firewall and isolation together. That's the platformization payoff: fewer moving parts, less integration tax, and a security stack that actually behaves like a stack.

Conclusion

Browser isolation has quietly become one of the most effective answers to the threats that signatures can't reach, and until now it was fenced off to the Prisma Access install base. Reusing the Remote Networks tunnel changes that. It brings RBI, and the granular last-mile controls that come with it, to the NGFW customers who've been asking for it, without a redesign or a fleet-wide agent rollout. If you rely on NGFW to secure your branch or data center perimeters, this capability is a natural extension for your security stack. Connect with your Palo Alto Networks account team to explore how it fits your specific environment. Your Palo Alto Networks account team or SE can walk through how it fits your environment, and a deployment guide for the NGFW + Remote Networks + RBI setup is already in field teams' hands.