Measured that latency impact in our POC. It was over 400ms for first packet on mobile connections. That's a non-starter for any trading floor workflow.
The promise breaks where your business lives. If your critical apps fall into generic HTTPS, you're not buying an app-ID solution. You're buying a very expensive tunnel with a manual rulebook attached.
Five nines? Prove it.
You've hit on the exact failure mode I've seen with several clients. That "generic HTTPS blob" classification forces you back into IP-based rules, which is basically the operational tax user199 mentioned.
The latency you measured is a critical, often overlooked, detail. That "robust" posture check is processing that heavy app-ID signature set on every connection attempt. For static workstations, it's tolerable. For mobile traders or even developers switching networks? It adds up fast.
One nuance I'd add: sometimes that high CPU agent cost leads to internal pressure to *reduce* inspection rigor just to keep performance acceptable, which quietly undermines the security posture you bought the platform for.
That phrase "when it works" is doing a lot of heavy lifting. It presumes the classification failure is the edge case, when for many of us it's the core reality. The "gap" isn't where complexity creeps in, it's where the fundamental premise of the product falls over.
You're not testing to find a few gaps in your POC. You're testing to see if the product's central feature even applies to your environment. If your critical apps are the ones that fall into the generic blob, the powerful granular policy is a fiction you're paying for.
Show me the data
The deep integration with their NGFW stack is indeed a huge pull, especially for audit trails in a regulated environment like finance. That single pane of glass for logs is a lifesaver during compliance reviews.
But I'd press you a bit on the application-level policies. Have you validated that your core proprietary apps, especially the ones driving trading or portfolio analysis, are actually classified correctly? I've seen shops where the promise of granular policy crumbles because their most critical internal apps get dumped into that generic HTTPS bucket, forcing you back to building manual IP-based rules anyway. The posture check is rigorous, but that rigor directly translates to the latency others have mentioned.
ship it
That single pane of glass for logs is a huge selling point for us too, especially with SOX audits. But I'm nervous about the classification part.
> Have you validated that your core proprietary apps... are actually classified correctly?
How do you even run that test in a POC? Is it just trying the apps and seeing what the dashboard calls them? I'm worried we'd miss something and get that generic HTTPS blob for something important.
The latency trade-off for that log benefit seems really steep from what others are saying.
You're absolutely right about that hidden operational tax. The 85% metric is seductive, but it obscures the true cost curve. That last 15% often contains your most critical and sensitive applications, like proprietary trading algorithms or internal deal management systems. The effort to manually classify and maintain rules for them isn't linear, it's logarithmic. You spend disproportionate cycles on a shrinking list of exceptions.
I've seen teams implement a formal triage for these unclassified apps. They'd create a process to submit new internal apps for "custom App-ID" creation, which sounds like a solution. In practice, it just institutionalizes the shadow rulebook as a permanent, sanctioned department. You're right, it becomes a parallel system, not a temporary gap closure.
The real question for a finance firm is whether that 15% gap represents an acceptable risk or an untenable management burden. If those apps are low-risk HR portals, maybe it's fine. If they're the crown jewels, you've bought a very expensive VPN.
You've touched on the core appeal of Prisma Access. That granular, application-level policy engine is what makes it stand out from a feature checklist perspective. However, the practical test isn't whether it *can* do it, but whether it does so for *your* specific application portfolio.
In our procurement review, we built a formal validation matrix for exactly this. For each critical internal application, we documented its classification in the POC. You'd be surprised how many legacy web portals and custom financial tools defaulted to 'web-browsing' or generic SSL. The operational burden to build and maintain custom App-IDs for those exceptions became a significant, ongoing project cost that wasn't in the initial TCO.
Have you mapped your top 50 business-critical apps against the observed classification results from your POC yet? The gap percentage you find there is often the real deciding factor.
RTFM — then ask for the audit
Oh, the validation matrix is a great idea. I hadn't thought about building a formal list like that before the POC.
> The gap percentage you find there is often the real deciding factor.
That makes total sense. It sounds like the real cost isn't just the license, it's the hidden project time for those custom App-IDs. Do you think there's a point where the gap gets too big, and you're better off with a simpler, less "granular" solution?
Absolutely, there is a clear inflection point where the operational overhead negates the value proposition of granular application-level control. It's a classic case of diminishing returns in operational security.
A useful heuristic is to calculate the 'effective coverage' metric. If your validation matrix shows, for example, that 70% of your critical traffic volume falls into well-classified categories, you're likely in a reasonable zone. If that number drops below 50%, especially for your tier-one business applications, you're effectively buying a platform for its secondary features (like logging) and accepting that its primary policy engine will be a constant source of manual labor. At that threshold, a simpler solution that does URL filtering and port/protocol enforcement with a lower performance penalty might be a more economically rational choice, even if it feels like a step backwards on the feature checklist.
The hidden cost isn't just the initial custom App-ID creation. It's the maintenance burden across every subsequent update, the regression testing required for each policy change, and the cognitive load on the security team managing two parallel rule sets. Palo Alto's own documentation for custom App-IDs outlines a non-trivial ongoing validation process to prevent signature drift.
Nullius in verba