PARTIAL Is the New NO: How SASE Vendors Hide Limitations in Plain Sight

The Dirty Secret of SASE Vendor Comparisons

When you ask a SASE vendor whether they support a specific capability, the answer is rarely a clean YES or NO. Instead, you get something like: "Yes, we support that — with some limitations." In vendor datasheets, this translates to a checkmark. In RFP responses, it becomes "supported." In reality, it means PARTIAL — a category that can range from "almost fully functional" to "technically exists but is practically useless."

At SASECompare, we have tested 8 major SASE vendors across 101 specific security checks. Every answer is classified as YES (fully supported with evidence), PARTIAL (supported with meaningful limitations), or NO (not supported). The results reveal a pattern that every SASE buyer needs to understand: vendors are leaning heavily on PARTIAL to inflate their capability claims.

This is not a minor data quality issue. It is the central challenge of SASE vendor evaluation in 2026.

The Numbers: Who Hedges the Most?

Across all 101 answered questions, here is how often each vendor's answers fall into the PARTIAL category:

Fortinet leads with 31% of its answers classified as PARTIAL. That means nearly one in three capabilities comes with a caveat. Check Point follows closely at 30%. At the other end, Palo Alto Networks has only 15% PARTIAL answers — roughly half the rate of the most hedging vendors.

The gap between the top and bottom of this list is significant. When Fortinet claims to support a capability, there is a 1-in-3 chance that support comes with strings attached. When Palo Alto makes the same claim, the odds of caveats drop to roughly 1-in-7.

Why PARTIAL Is Dangerous for Buyers

The problem with PARTIAL is not that it exists — many capabilities genuinely have limitations. The problem is that PARTIAL is invisible in most evaluation processes.

Consider a typical SASE RFP. You send a spreadsheet with 50 requirements. The vendor returns it with checkmarks. But a checkmark for a YES capability and a checkmark for a PARTIAL capability look identical. The vendor has no incentive to distinguish between them, and most procurement teams lack the technical depth to probe each answer.

The result: organizations select vendors based on inflated capability claims, then discover the limitations months into deployment when it is expensive and politically difficult to switch.

Here are four specific areas where PARTIAL answers are masking serious gaps.

Case Study 1: TLS Inspection on Mobile Without MDM

This is arguably the most critical gap in SASE today. Can the vendor inspect TLS traffic on mobile devices without requiring full MDM enrollment? This matters because BYOD programs increasingly need security inspection without the privacy invasion of device management.

The answer across the industry is brutal:

Every single vendor is either PARTIAL or NO. Not one can deliver full TLS inspection on unmanaged mobile devices. Yet if you asked any of these vendors in a sales call, most would tell you mobile inspection is "supported." Technically true. Practically misleading.

The PARTIAL answers here typically mean the vendor can do basic URL filtering or DNS-level inspection on mobile, but cannot perform full TLS decryption and content inspection without MDM profiles or device certificates that require management enrollment. For organizations with large BYOD mobile populations, this is the difference between real security and security theater.

Dig deeper into the full results: TLS Inspection on Mobile

Case Study 2: Certificate-Pinned Application Inspection

Modern applications increasingly use certificate pinning to prevent man-in-the-middle inspection — which is exactly what SASE TLS inspection does. Can vendors handle cert-pinned apps?

Six vendors say PARTIAL. Two say NO outright. The PARTIAL answers typically mean the vendor can bypass cert-pinned apps (let them through without inspection) or handle a small list of known pinned applications. But "handling" cert-pinned apps by not inspecting them is not the same as inspecting them — it is an explicit security gap.

This is a textbook example of how PARTIAL obscures reality. The honest answer for most vendors is: "We cannot inspect cert-pinned traffic. We can detect it and either block it or let it through uninspected." That is functionally a NO for organizations that need content inspection of these applications.

Case Study 3: Desktop GenAI Application DLP

With the proliferation of desktop AI applications like ChatGPT for Mac, Claude, and Copilot, can SASE vendors apply DLP policies to data sent through native desktop apps (not just browser-based access)?

Seven out of eight vendors answer PARTIAL. Only Cloudflare achieves a full YES. The PARTIAL answers here typically mean the vendor can inspect traffic from desktop GenAI apps if the traffic flows through their proxy, but cannot handle scenarios where the app uses non-standard protocols, direct API connections, or local processing. For a CISO trying to prevent sensitive data from leaking through desktop AI tools, seven vendors are telling you: "We mostly handle it, probably, in most cases."

That is not a confidence-inspiring answer when the threat is data exfiltration through AI tools.

See the full GenAI DLP comparison: GenAI DLP

Case Study 4: WebSocket and HTTP/2 Inspection for ChatGPT

ChatGPT and similar AI tools use WebSocket connections and HTTP/2 streaming for real-time responses. Can SASE vendors inspect this traffic for DLP violations?

Six out of eight vendors say PARTIAL. Only Zscaler and Cloudflare deliver a YES. The PARTIAL answers typically mean the vendor can detect WebSocket or HTTP/2 connections but cannot perform inline content inspection of the streaming data. In practice, this means a user could paste sensitive source code into ChatGPT via a WebSocket connection and the SASE platform would see the connection but not the content.

The PARTIAL Spectrum: Not All Hedging Is Equal

It is important to acknowledge that not all PARTIAL answers are created equal. There is a real difference between:

• PARTIAL (nearly YES): The capability works in 90% of scenarios with a minor documented limitation
• PARTIAL (barely functional): The capability technically exists but requires significant workarounds or only covers a narrow use case
• PARTIAL (effectively NO): The vendor has a roadmap item or a beta feature that does not work in production

Our data captures this nuance in the detail text for each answer, but the PARTIAL label itself does not. This is why aggregate scores that treat all PARTIAL answers as equivalent can be misleading — and why the specific capability areas you care about matter more than totals.

That said, the vendors with the most PARTIAL answers — Fortinet (31%), Check Point (30%), and Cloudflare (27%) — consistently show patterns of capabilities that exist with meaningful limitations, not minor edge cases. When nearly a third of a vendor's answers come with caveats, the probability that your specific use case hits one of those caveats rises sharply.

The Correlation Between PARTIAL and Maturity

There is a clear pattern in the data: the vendors with the fewest PARTIAL answers tend to be the ones with the most mature SASE platforms.

Palo Alto Networks (15% PARTIAL) and Zscaler (17% PARTIAL) have been building cloud-native security platforms for over a decade. They have had time to close gaps, harden edge cases, and turn PARTIAL capabilities into full YES answers. Fortinet (31% PARTIAL) and Check Point (30% PARTIAL) are newer to cloud-delivered SASE, having transitioned from on-premises appliance architectures. Their higher PARTIAL rates reflect platforms that are still maturing.

This is not a criticism — platform maturity takes time. But it is a data point that buyers should weigh when vendors claim feature parity. The features may technically exist, but the depth of implementation differs significantly.

What to Do About It

If you are evaluating SASE vendors, here is how to cut through PARTIAL answers and get to the truth.

1. Ban Checkmarks from Your Evaluation

Do not accept binary yes/no RFP responses. Require vendors to provide one of four answers: YES (fully supported in production), PARTIAL (supported with specific limitations they must document), NO (not supported), or ROADMAP (planned but not yet available). Force them to describe every PARTIAL answer in writing.

2. Identify Your Non-Negotiable Capabilities

Before talking to vendors, define 10-15 capabilities where PARTIAL is not acceptable. These are your hard requirements — capabilities where anything less than full support is a disqualifier. Typical non-negotiables include TLS inspection coverage, DLP for sanctioned and unsanctioned apps, and mobile device support without MDM.

3. Test PARTIAL Claims in a POC

For any capability marked PARTIAL, build a specific test case into your proof of concept. Do not let vendors demo their best scenarios. Test the edge cases: cert-pinned apps, mobile devices without MDM, WebSocket traffic, non-browser desktop applications. The POC is where PARTIAL answers reveal their true nature.

4. Ask for Customer References on Specific Capabilities

Do not ask for generic references. Ask for a customer who is using the specific PARTIAL capability you care about in production. If the vendor cannot produce one, that PARTIAL is closer to NO than YES.

5. Weight Your Scoring Model

If you must use a scoring model, do not give PARTIAL answers half credit. Instead, score them based on how well the limitation maps to your environment. A PARTIAL answer that does not affect your use case scores the same as YES. A PARTIAL answer that hits your exact scenario scores the same as NO. This forces evaluators to actually read the details rather than averaging away the nuance.

6. Use Independent Data

Vendor-provided capability matrices are marketing documents. Independent sources — analyst reports, community forums, and platforms like SASECompare — provide a check against vendor claims. Cross-reference at least two independent sources for any capability that is critical to your decision.

The Bottom Line

PARTIAL is the most important word in SASE vendor evaluation, and it is the one most buyers overlook. Across 101 security checks, the gap between the most transparent vendor (Palo Alto at 15% PARTIAL) and the most hedging (Fortinet at 31% PARTIAL) is enormous. That gap translates directly into deployment surprises, security gaps, and wasted evaluation cycles.

The next time a vendor tells you a capability is "supported," ask the follow-up question: "Fully, or partially?" Then make them explain exactly what partially means. Your security posture depends on it.

Analysis based on SASECompare data as of March 2026. All vendor scores are derived from evidence-backed assessments with cited sources. Explore the full comparison data at [SASECompare](/comparisons).