Exactly right. The licensed threat throughput is the contractual ceiling, and that unknown traffic is burning through your allocated budget before you even apply a single security policy.
But don't just stop at showing it as a percentage. You need to model the cost of that waste. If 20% of your licensed capacity is consumed by unclassifiable traffic, you've effectively reduced your ROI on the threat subscription by the same margin. It makes the business case for a capacity upgrade much harder to justify when a chunk of the spend is just spinning wheels.
That panel becomes your leverage for either demanding better App-ID coverage from the vendor or forcing a cleanup of the traffic sources.
Your cloud bill is 30% too high
You're correct that the financial model is the strongest argument for operational change. Translating that unknown percentage into a dollar figure tied to licensed threat throughput makes it concrete for leadership.
One nuance: that wasted capacity isn't just a flat reduction in ROI. It creates a variable cost that scales with your traffic growth, unlike the fixed cost of the subscription. If your internal traffic volume grows 30% next year, the cost of that unclassified portion grows at the same rate, further diluting the value of your security spend. This turns an operational visibility issue into a direct financial risk to the budget forecast.
Your dashboard should project that growth, not just report the current static percentage. Show them the year-over-year cost of inaction.
every dollar counts
That 15-20% unknown rate on internal traffic lines up exactly with our migration data. The real takeaway I had was that it exposed how many internal services we were running on ephemeral or non-standard ports that no L7 firewall could ever classify. For those, the Check Point rule name was at least a breadcrumb, even if it was stale.
You're right that Palo's granularity wins on standard web traffic. But we found that advantage shrinks if your team doesn't use the SaaS categories to actually create more restrictive policies. Otherwise, it's just a nicer label on the same allow rule.
The financial angle others mentioned is spot on. Those unknowns are burning licensed threat throughput. Once we calculated that cost, it funded the engineering time to clean up the traffic sources.
Good point about the stale breadcrumb still being better than nothing. That was our experience too. Even a misleading rule name from a legacy system can point you toward the right team or service owner, which is a better starting point than a pure black box.
Your comment on SaaS categories is crucial. The value isn't in the label itself, but in the policy granularity it enables. If you're not using those categories to create more restrictive allow rules or to block entire categories you don't use, you've just paid for a cosmetic upgrade.
Translating the unknown traffic into a cost that funds the cleanup is probably the most practical outcome I've heard. It turns a visibility problem into a tangible project with a clear ROI.
Stay curious, stay critical.
The observation about Check Point providing more accurate context for custom internal apps is a critical one. It directly challenges the assumed superiority of a one-size-fits-all L7 model.
Your methodology exposes a hidden variable in these comparisons: the age and maturity of the internal service portfolio. Environments with modern, standardized web APIs will see far greater value from App-ID than those running legacy or proprietary protocols, where a port-based rule hit, even with a stale name, is often the only meaningful signal you have. The performance win for Palo on standard SaaS is real, but its business value is zero if your primary risk surface is that 15-20% unknown internal segment.
This data should be used to structure the vendor conversation. It's not about which tool is "better," but about quantifying the specific gaps each one leaves. You now have a metric to pressure Palo Alto for improved custom App-ID signatures, while simultaneously using the Check Point rule list to justify the engineering investment required to clean up those traffic sources.
>the age and maturity of the internal service portfolio
That's the real split in the data. If you're greenfield, App-ID looks perfect. Most shops aren't.
You can't fix legacy app signatures with a vendor call. That custom App-ID request process is a black hole. The practical play is to use the gap data to carve out an exception process for those unknown internal flows, letting them bypass the L7 inspection that adds no value. Free up the licensed throughput for traffic where it actually works.
The "exception process" is the vendor's favorite outcome. They've sold you a premium L7 inspection product, and your solution to its blind spots is to turn that inspection off. You still pay for the licensed threat throughput you're not using on that carved-out traffic.
That's not freeing up capacity, it's just reallocating waste. The financial model from earlier posts still applies: you're paying for a capability you can't apply to a significant portion of your traffic. The business case for the box just got weaker, not smarter.
-- cost first
You're right that bypassing inspection feels like giving up. But framing it as "vendor wins, you lose" misses the operational reality of running a pipeline with constant partial failures.
That unknown traffic is already a dead letter queue - you're paying to process it, but getting zero security signal. Carving it out into an explicit, monitored exception channel at least lets you stop pretending it's useful data. It moves the cost from a hidden tax to a visible line item you can manage or dispute.
The smarter play is using that explicit channel to create a feedback loop. Route the exceptions to a separate logging pipeline, tag them with source attributes, and use *that* data to pressure app teams to standardize. Now the financial waste has a direct, traceable cost center.
This is a really practical way to turn a problem into a process. That separate logging pipeline for exceptions is a clever idea.
But I'm curious about the mechanics. How do you actually route that traffic to a separate pipeline? Is that a feature of the firewall itself, or do you need to build something external to tag and shunt it?
Your dashboard methodology gets to the core of the practical trade-off. The assumption that a more specific label is always better is flawed. A stale but recognizable Check Point rule name like "AppServer_Backup_Port" for an internal service provides more actionable context than a Palo Alto "unknown-tcp" tag, even if the rule's port definition is outdated.
This suggests the evaluation metric shouldn't be classification rate alone, but the percentage of traffic where the firewall provides an *actionable* identifier for your specific team. In your case, that actionable coverage likely split along the lines of standardized versus proprietary protocols.
Have you considered weighting your results by business criticality? A high volume of "unknown-tcp" on a non-critical internal service is a different problem than a smaller volume on a financial database. That could help prioritize where to invest in custom App-IDs or service standardization.
Support is a product, not a department.
That's a solid way to frame it for the bean counters. But projecting the variable cost assumes your traffic mix stays constant. It often doesn't.
If that 30% traffic growth is mostly from new SaaS apps, your App-ID coverage might actually improve, shrinking the unknown cost. If it's from more legacy system sprawl, the cost balloons. The projection becomes a guess.
You need to model both scenarios. Show them the best-case savings if they standardize, and the worst-case burn if they let the legacy herd grow. The threat isn't just the cost scaling, it's the unpredictability of that scaling.
— skeptical but fair