We’re evaluating network security for a few remote sites with 5–10 users each. Currently they have on-prem firewalls (older FortiGates), but managing policies and VPNs across them is becoming a chore. I’ve been reading about Prisma Access as a full SASE solution and I’m curious if anyone is using it **as the only firewall** at small branches.
Specifically:
- Do you run Prisma Access directly on a generic router (or CPE) at the branch, with no next-gen firewall hardware on-site?
- How do you handle local device-to-device traffic (e.g., printing, local file shares)? Does it hairpin through the cloud or can you keep it local?
- Any gotchas with site reliability or latency-sensitive apps (VoIP, video calls)?
- What’s the operational lift compared to managing traditional firewall appliances?
I’ve been digging into the docs and it seems possible with the “Prisma Access Mobile Users and Branch Offices” deployment, but real-world feedback would be great. For context, our data stack is mostly cloud-based (Snowflake, SaaS apps), so heavy on outbound internet traffic, minimal on-prem servers.
--diver
Data is the new oil - but it's usually crude.
You can certainly use it as the sole firewall, and we did a proof-of-concept for a similar scenario. But your point about local device traffic is the key constraint.
Prisma Access will hairpin that local printing or file share traffic through the cloud if you define it in your security policy. To keep it purely local, you must create a separate, non-Prisma Access path in your local router's configuration and accept that this traffic won't be inspected by the NGFW. This creates a policy management split that can get messy.
Operationally, it's simpler for outbound cloud traffic. However, factor in the bandwidth cost: all inspected traffic now consumes your Prisma Access bandwidth pool. For small sites, that's often fine, but the cumulative cost across dozens of sites can surprise you at renewal.
Buy once, cry once.
You've put your finger on the operational heart of it - that split policy management is the real catch. We found the same thing in our rollout. The clean, single-pane-of-glass vision gets fuzzy when you have to maintain local ACLs on those generic routers for the print server, and suddenly you're managing two distinct rule sets.
Your bandwidth cost reminder is spot on, too. It's easy to overlook how local backup jobs or even Windows updates, now tunneled, can chew through that pool. For tiny sites, we ended up keeping a basic, dumb firewall on-site just to handle local segmentation and keep that local traffic entirely off the Prisma bill. It felt like a step backwards, but it kept the accounting simple.
Let's keep it real.
Yeah, the policy split is the real headache. We tried the generic router with local ACLs route for a bit, and keeping those rules in sync with our Prisma tenant after every minor network change became a real chore.
I'll add one more nuance to the bandwidth cost point: watch out for encrypted traffic. When your Prisma nodes decrypt and inspect all that tunneled HTTPS, the processed bandwidth can be significantly higher than the raw throughput, especially with lots of small, chatty connections. That can push a small site's usage into the next pricing tier faster than you'd think from just looking at line speed.
Automate all the things.
That's exactly it. You keep a dumb box on-site to avoid the policy mess, but then you lose inspection on local traffic. It's a trade-off you have to accept.
We tracked metrics for a similar setup. The local-only firewall saw 60-70% of total site traffic from printing and local backups. Paying the Prisma tax on that would have doubled our bandwidth costs for zero security benefit.
So you're not stepping backwards, you're just being pragmatic. The single pane of glass is a vendor fantasy for these edge cases.
Metrics don't lie.
You've correctly identified the two major operational shifts. The bandwidth cost surprise is often the larger one, as it converts a fixed CAPEX router cost into a variable OPEX based on volume.
My own analysis for a 30-site rollout showed that the policy split management added about 15% more time per change cycle. But the bandwidth overage, particularly from tunneled OS updates and cloud backup syncs, created a 22% budget variance at the first true-up. The math for local traffic is rarely zero-sum.
The pragmatic approach is to model the total expected traffic volume, then compare the Prisma consumption price against the depreciated cost of a managed edge appliance. For sites under 10 users, the appliance often wins on a 3-year TCO once you exceed 30% local traffic.
independent eye
Your analysis on the traffic split is correct, but I'd push back on the implicit assumption that minimal on-prem servers means minimal local traffic. In a 5-10 user site, Windows Update Delivery Optimization, Apple's Content Caching, and even peer-to-peer video calls can generate a surprising amount of east-west chatter that your router will try to send locally. If your generic CPE isn't configured with very specific local subnets and bypass rules, this traffic will still get captured by the Prisma tunnel.
You're right that the Prisma Access for Branch Offices deployment model allows it. The operational lift compared to a FortiGate is lower for cloud-bound policy management, but you're trading appliance troubleshooting for WAN and tunnel troubleshooting. For latency-sensitive apps, you're now adding the round-trip to the nearest Prisma Access node. This can be sub-10ms, but you need to verify the node locations against your site geography. The gotcha isn't average latency, it's 99th percentile latency during node failovers or congestion events, which will impact VoIP more than a local appliance ever would.
Given your cloud-heavy stack, the math might work. But you must model the traffic volume including the local chatter I mentioned. The TCO often breaks even only if you can truly get local traffic below 20%. Have you done a packet capture on one of your existing FortiGates to measure the actual ratio of internet-bound versus local-subnet traffic?
--perf