Your point about the quarterly audit checkbox resonates. We observed a similar pattern after shifting our focus to concurrent sessions. However, the cost benchmarking revealed a secondary benefit we hadn't anticipated.
While the day-to-day management in Panorama became minimal, the centralized logging and reporting for compliance audits (PCI in our case) became far more efficient. The operational savings weren't in policy *changes*, but in the reduction of man-hours required to aggregate and normalize security event data from 80+ locations during an audit. The per-location model made this trivial; consolidating logs from disparate, non-integrated firewalls for the same audit would have required a dedicated SIEM project.
So the premium isn't just for a deployment engine used once. It's also for a compliance reporting engine you use under duress. The question becomes whether that specific reporting efficiency is worth the annual premium versus building a separate, centralized log pipeline. For us, the math still favored Prisma Access, but only after we factored in the avoided cost of that SIEM integration.
That's a solid point about audit efficiency, and it's often the hidden cost that gets missed in the ROI. I've seen that exact scenario.
But you have to be careful. You're essentially paying for Panorama as a SIEM-lite. If your compliance needs evolve and you *do* eventually need a real SIEM for other use cases, you've now paid twice - once for the premium in your licensing, and again for the actual SIEM project. The integrated reporting only saves you money if you never outgrow it.
For PCI, it's often enough. The moment you need to tie firewall logs to endpoint or cloud activity, it isn't.
Build once, deploy everywhere
That's a really interesting angle I hadn't considered. Paying for Panorama as a SIEM-lite.
So you're saying if compliance needs expand beyond firewall logs, that whole efficiency benefit disappears. That makes the initial cost justification pretty fragile.
Has anyone tried using something lighter, like a simple log aggregator, just for the compliance piece to avoid the Panorama premium? Or is the integration too tight for that to work?
Agree on the hybrid approach. That's exactly what we landed on after fighting the per-location model.
Your 20% discount is the standard play. They won't change the model until you have a real alternative lined up.
One caveat: keeping Panorama for HQ/DC while using ZTNA for stores creates a policy split. Your critical sites and remote sites now live in different security consoles. That's an operational tax of its own. You're trading a cost anchor for a management anchor. Make sure your team is ready for two workflows.
Show me the bill
That's a crucial operational detail that gets overlooked. The split-console tax isn't just about training, it's about orchestration. When you need to push a unified security rule that applies to both your DC and a store POS system, you're now writing and synchronizing policies across two different platforms. That creates drift.
We solved this by treating the ZTNA console as the source of truth for user-to-app policy and using a basic API feed from Panorama into our configuration management database. It's not perfect, but it prevents the two teams from building contradictory rules. The real cost is building that integration glue.
Extract, transform, trust
You can pull it from the ACC under Monitoring > Logs, but you're right, the interface stats don't tell the full story for the tunneled traffic.
Use the query filter:
`(log-type starts-with traffic) and (application eq ssl) and (port.dst eq 443)`
That gets you the encrypted dataplane flow from the GP gateway. Just remember that's the tunneled traffic only. If you've got a bunch of non-SSL direct-to-internet traffic, you'll need a separate query for that, which is why the single interface stat never matches up.
It's one of those Panorama quirks where you're better off building a custom report and saving it forever than trying to remember the filter syntax each quarter.
APIs are not magic.
Agreed, but that peak commit cuts both ways. You're paying for that holiday surge all year, even in the dead of February. It's like buying a bus for the one week your in-laws visit.
For a small chain, sure, the math usually works. Until you have a location-specific outage that drops 20% of your users for a month. Suddenly you're still paying for seats in an empty theater.
Deploy with love