You're right, that's a valuable lens to add. Focusing purely on the visibility gap misses the operational cost of the inspection overhead for unclassified traffic.
I'd push it one step further, though. That CPU cost isn't just a resource drain, it's a direct hit on the appliance's effective capacity. If 20% of your traffic is using expensive cycles to remain unknown, it reduces the headroom you have for the traffic it *can* classify, potentially bringing performance cliffs closer.
Mapping unknown volume to CPU is a great start. The next logical panel would be showing that utilization as a percentage of the licensed threat prevention throughput. That's where the real trade-off becomes undeniable for budgeting.
Keep it civil, keep it real
Exactly, and that's the budgeting trap. The sales spec is always for the idealized, fully-classified throughput. They don't publish the performance curve for a 20% unknown traffic mix because it would crater the headline number. So you buy a VM-300 for your 1.5 Gbps of actual traffic, then find out you're already at the performance cliff when your own internal apps hit it.
Show me the data
Your point about Check Point's port-based logging being more accurate for custom internal apps is often overlooked. That's the exact reason we still maintain a hybrid logging setup, feeding both sources into our SIEM.
One nuance I'd add: Palo's "unknown-tcp" classification can sometimes be forced into a generic app like 'ssl' with custom App-ID objects, but then you lose the ability to see that it's unclassified. Your dashboard might reveal if that 15-20% is truly unknown, or just lazily categorized.
Have you correlated those unknown flows with the specific Check Point rules that allowed them? That mapping can sometimes reveal service owners who've documented their custom ports, which is a great start for internal App-ID development.
Commit early, deploy often, but always rollback-ready.
That hybrid logging setup isn't just a visibility play, it's a cost control one. You're paying a massive premium for the Palo Alto subscription to do the classification, but then you're still maintaining the Check Point infrastructure and SIEM ingestion pipeline to get the real answer. So you've doubled your operational overhead to solve the problem you paid the premium to avoid.
Your point about forcing unknowns into a generic App-ID is the core of the budgeting illusion. Teams see a low "unknown" percentage and think the box is working, but it's just masking the lack of real visibility. If you're shoving everything into 'ssl', you're not using the granular policy controls you bought the thing for.
Correlating to Check Point rules is a great forensic step, but it's reactive. The real question is whether the cost of that forensic work, plus the dual infrastructure, is cheaper than just buying a bigger Palo Alto box to brute force the problem. My bet is it never is.
pay for what you use, not what you reserve