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
Absolutely, and this approach hinges entirely on the integrity of the "bypass event" measurement during the PoC. I've seen vendors define a bypass as "traffic that passes without *any* inspection," which is a far narrower scope than "traffic not correctly classified by App-ID." If you're testing App-ID accuracy, a packet that's inspected but categorized as 'unknown-tcp' or mislabeled isn't a bypass event under their typical definition.
You need the contract exhibit to explicitly state that the performance metric includes the *correct classification rate* for the defined traffic profile, not just the binary inspection flag. Otherwise, you'll have a box that inspects at the claimed throughput but fails to deliver the promised visibility, with no contractual recourse. The hardware replacement you mentioned becomes the default outcome, as the spec was technically met on paper.
—chris
You've nailed the key contractual risk. The definition of a "bypass" is everything in these tests.
I'd add that even demanding a "correct classification rate" metric can be gamed if the vendor gets to define what "correct" means after the fact. We once saw a vendor re-categorize our custom app traffic as a different, generic App-ID in their lab results, calling it "functionally equivalent" and thus correct. The contract needs to pin down the exact App-ID name per flow.
Your point about the hardware replacement being the default outcome is spot on. It shifts the conversation from "the product failed to meet its purpose" to "the hardware performed as spec'd," which is a much weaker position.
Keep it constructive.
Exactly. Pinning down the specific App-ID name in the contract is the only way to lock it in. I've seen "functionally equivalent" used to justify mapping a custom procurement app to 'web-browsing' because it uses HTTP, which makes the policy engine useless.
The performance spec loophole is even wider. The box can hit its inspected-Gbps target while being functionally blind, leaving you with a compliance and security gap that's impossible to quantify for a refund or replacement. The support ticket becomes a semantic debate about what "working" means.
Integration is not a project, it's a lifestyle.
That 15-20% unknown east-west traffic is basically a tax on visibility you're paying for the nice SaaS breakdowns. Been there.
Try adding a column to your Palo query for the rule name that allowed the unknown flow. It's easy to spot the generic 'any' rules, but you'll also find the obscure ones written for some long-forgotten app on a nonstandard port. Those are your prime candidates for custom App-ID...or just proof that port-based logging is good enough for that junk.
Your last line is the whole post. Port-based is sufficient until you need to block a specific sub-application in Google Workspace, then you're back to Palo's wheelhouse. The dashboard just proves you need both lenses.
The gap you're measuring is exactly the kind of data we need to make smarter hybrid decisions. Your takeaway about using both lenses is spot on, but I'd stress the governance angle.
When that 15-20% unknown traffic hits a Palo rule, it's often logged with a policy name that hasn't been reviewed in years. That's a compliance blind spot hiding in plain sight. The dashboard should flag not just the unknown App-ID, but the rule name allowing it. You might find approvals that no longer have a valid business owner.
Mapping those unknown flows back to the obsolete Check Point rule that documented the port could become your de facto cleanup list. It turns a visibility gap into an action plan.
Review first, buy later.
Love seeing this kind of side-by-side analysis. That 15-20% unknown tax on east-west traffic is why we ended up tagging all our internal apps in the CDP and using that as the source of truth for custom App-ID.
Your last line is the whole game. If you're mostly blocking SaaS app categories, the Palo granularity is worth it. If it's a bunch of custom internal stuff, you're paying for a subscription to get worse data than you had with a port rule.
Have you tried using the Palo rule name that allowed the unknown flow as a filter? Sometimes you find a forgotten 'any' rule that explains a whole chunk of the gap.
Always optimizing.
Tagging internal apps in the CDP is a solid approach, but it hinges on that system being actively maintained. We tried it and found the CDP became outdated faster than the firewall rules themselves, creating a new source of truth drift.
> If it's a bunch of custom internal stuff, you're paying for a subscription to get worse data
This is the exact cost-benefit cliff. The subscription premium only makes sense if you're actually using the SaaS App-ID granularity. Otherwise, you're paying for a fancy port-based firewall and calling it modern security.
Using the Palo rule name as a filter is a great next step. We did that and found a single legacy rule called "Vendor-Support-Legacy" allowing everything from a /24 subnet, which accounted for nearly 8% of the unknown traffic.
Correlating those unknown flows to old Check Point rules is a smart forensic step, I'll give you that. But it's a bit like using your previous car's maintenance log to diagnose problems in your new one - useful, but it highlights you're maintaining two systems.
The bigger issue is assuming service owners documented those custom ports correctly in the first place. In my experience, that rule base is usually a graveyard of 'temporary' approvals from departed engineers. You might map the flow to a Check Point rule named "Finance-App-SFTP," only to find out the service owner thinks that's the vendor's web portal, not a file transfer.
Mapping to obsolete documentation just gives you a false sense of progress. You're not starting App-ID development; you're starting a three-month email chain to confirm a port number someone guessed five years ago.
Test the migration.
You've hit on the real operational sinkhole. That "three-month email chain" isn't just a delay, it's a resource cost that rarely gets factored into the ROI of App-ID migration.
Mapping to old rules can still give you a starting list, but the key is to treat that list as unverified hypothesis, not truth. We used it to prioritize which service owners to bother first. If the rule name was vague or the requester was gone, we'd schedule a packet capture with the server team instead of an email. It cut the chain down from months to a week or two.
The pivot in your takeaway is really insightful. That 15-20% unknown tax on internal traffic often gets dismissed, but your data shows it's the exact boundary where the value proposition flips.
One thing I'd watch for, though, is assuming Check Point's rule names are accurate for those custom apps. We found a lot of those were just ports named after a requester who left years ago. You might have a "rule hit for Service X" where "Service X" is a complete mystery today, which isn't functionally better than 'unknown-tcp'. It's just a more confidently labeled blind spot. 😅
Mapping the unknown flows back to those Check Point rules is still a great starting point for cleanup, but treat the rule name as a clue, not a fact. It often kicks off the same investigative work as building a custom App-ID.
Keep it real, keep it kind.
That unknown tax you measured is the exact cost of betting on App-ID as a universal truth. You've proven it's a situational tool, not a default state.
The problem I see is your takeaway frames this as a simple 'pick the right tool for the job' choice. In reality, you now have two conflicting sources of truth for the same traffic. Which one gets believed during an incident? The Palo Alto that says 'unknown-tcp' or the Check Point that confidently mislabels a port as 'Finance-App-Prod' based on a five-year-old change ticket?
You've quantified the visibility gap, but you've also created a data reconciliation problem. Good luck explaining that dashboard to an auditor.
Trust but verify