The Question
A SASE proof of concept is supposed to answer a specific question: will this platform perform adequately in our environment, with our users, against our threat profile? In practice, most enterprise SASE PoCs answer a different question entirely: can this platform perform well when the vendor controls the test design, selects the user group, chooses the success metrics, and provides on-site engineering support for the duration of the evaluation?
The answer to that second question is almost always yes. And the result is a PoC that provides high confidence in a vendor's ability to perform under ideal conditions and very little information about how the platform will behave under the conditions your users will actually experience.
Vendor-designed PoCs are not fraudulent. They are rational. Every vendor will design a test that emphasizes strengths and minimizes exposure of limitations. The problem is that most enterprise buying teams lack the specific technical knowledge to redesign the test on their own terms — and the vendor's sales engineering team is present, helpful, and very good at steering the evaluation toward favorable ground.
A SASE PoC designed by the vendor tells you whether the vendor can perform in ideal conditions — a PoC designed by you tells you whether the vendor can perform in your conditions.
Why This Matters Now
In the second half of 2024, two separate enterprise SASE deployments at mid-market financial services firms made headlines in security industry publications for the same reason: post-deployment latency complaints from users that were significantly worse than the PoC results had suggested. In both cases, the PoC had been conducted with a small group of technically sophisticated users at headquarters, using a curated set of applications. Production deployment expanded to branch offices, remote workers, and a full application portfolio — and the latency profile was meaningfully different.
One of the affected firms published a post-mortem in a CISO community forum. The key finding: the PoC had measured latency for the 10 most-used SaaS applications, all of which the vendor had optimized for in their PoP configuration. Production traffic included 40 additional applications, several of which routed suboptimally through the vendor's backbone, adding 80–120ms of latency that users noticed immediately.
This pattern is consistent enough that it has become a standard item in enterprise SASE procurement risk registers. The PoC-to-production gap is not primarily a vendor honesty problem — it is a PoC design problem. Vendors perform well on the tests they design. Enterprises perform well on the deployments they design. Closing that gap requires the enterprise to own the test design from the beginning.
The 2025 Gartner SSE Magic Quadrant noted that "proof-of-concept evaluation quality" was among the top three factors cited by enterprise buyers who reported post-deployment dissatisfaction, ahead of both pricing disputes and support quality concerns.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report assessed each major platform's PoC methodology transparency — including whether vendors publish their recommended PoC frameworks, whether they support buyer-designed test cases, and how their platforms perform on independently administered latency benchmarks versus self-reported metrics.
Cato Networks and Zscaler both publish detailed PoC guides that include latency measurement methodology and DLP test case frameworks. Both platforms showed the smallest gap between PoC latency results and independent third-party benchmarks in the Stackcurve evaluation. Palo Alto Prisma SASE and Cisco showed larger PoC-to-independent-benchmark gaps, reflecting the complexity of their multi-component architectures and the tendency of vendor-led PoCs to focus on the strongest individual components rather than the integrated stack behavior.
Netskope performed most consistently on DLP accuracy tests when buyers used the NIST SP 800-188 data classification framework as the test case basis — a finding that suggests the importance of standardized test case methodology over vendor-provided scenarios.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
The standard vendor PoC has structural weaknesses that most buying teams don't catch until after deployment. Understanding these weaknesses is the first step to designing around them.
Test population selection
Vendor PoCs typically run with 50–200 technically sophisticated users at a single location, often headquarters. This group is ideal for the vendor: these users are technically tolerant, they're close to a major metropolitan area (where PoP density is highest), and they're using corporate devices on optimized networks.
Your production deployment will include branch office workers on consumer broadband, remote workers on hotel WiFi, and users in geographies where your chosen vendor's PoP coverage is thinner. Design your PoC to include users in your worst-connectivity locations, not your best.
Application coverage
No vendor can optimize for every application. Vendor-designed PoCs use a curated application set that the platform handles well. Your production traffic includes the 40 applications your IT team has never formally assessed.
Before the PoC begins, produce a traffic analysis showing your actual top-50 applications by traffic volume and user session count. Require the vendor to include all 50 in the test scope. The latency profile for applications the vendor hasn't specifically optimized for will be different from the curated test set.
Failure mode testing
PoCs almost never test failure modes. What happens when an SSE PoP experiences an outage? Does traffic fail open (users get internet access without inspection) or fail closed (users lose internet access entirely)? How quickly does the platform failover to an alternate PoP? What is the user experience during failover?
This matters significantly for branch office deployments. Design specific test cases that simulate PoP unavailability and measure failover time, failover behavior, and recovery behavior. Require the vendor to demonstrate this in the PoC environment.
DLP accuracy on your data types
Standard vendor DLP demos use generic test data: credit card numbers in the 4111-1111-1111-1111 test format, Social Security Numbers in 123-45-6789 format. These are the easy cases. Your production DLP requirement is more complex: detecting internal financial projections in Excel attachments, identifying PII in unstructured text documents, catching proprietary source code in email bodies.
Build your DLP test cases from actual samples of the data types you need to protect — with PII values replaced by realistic synthetic data. Run these test cases against the DLP engine before signing. Accuracy rates for your specific data types will differ, sometimes significantly, from the vendor's published generic DLP performance metrics.
Independent latency measurement
Require independent latency measurement. Don't accept the vendor's self-reported metrics. Install a third-party network performance monitoring tool before the PoC begins and measure p50, p95, and p99 latency for your top 10 applications at baseline (without SSE in the path) and during the PoC (with SSE in the path). The delta is what matters.
Questions Your Buying Team Should Be Asking
1. Will you support a buyer-designed PoC with test cases, user populations, and success metrics that we define — and can you provide a written commitment to this before the PoC begins?
Vendors who resist buyer-designed PoC frameworks are revealing that their performance is most favorable under their own conditions. This resistance is itself a data point. Vendors who readily accept buyer-defined test parameters have confidence in their platform's performance across diverse conditions.
2. For our top 50 applications by traffic volume, can you provide PoP-proximity analysis showing the expected routing path and estimated latency impact for each application from our three largest user population locations?
This question requires the vendor to commit to a latency projection before the PoC begins — creating a measurable standard against which actual PoC results can be compared. Vendors who cannot or will not provide this analysis cannot be held accountable for latency performance post-deployment.
3. How does your platform behave when an SSE PoP is unavailable — does traffic fail open or closed, what is the failover time, and can you demonstrate this behavior in the PoC environment?
The answer to this question has direct implications for your acceptable use policy and your incident response procedures. Fail-open configurations maintain productivity at the cost of uninspected traffic. Fail-closed configurations maintain security posture at the cost of a productivity outage. Know which you're buying before you sign.
4. Can you provide three reference customers in our industry with similar WAN profiles who we can contact independently — not references you've pre-briefed, but contacts we can call and ask any question we want?
The distinction between pre-briefed and independent references is significant. Request the names and direct contact information, and reach out independently with one specific question: "What went wrong in the first 90 days of your deployment, and how did the vendor respond?"
5. For our DLP requirements, can we run your DLP engine against a set of test files we create — using synthetic data that matches our actual data types — before the formal PoC begins, and can you commit to accuracy rate targets for those specific data types?
Pre-PoC DLP accuracy testing for your specific data types is the most reliable way to assess whether the platform's data protection capability matches your actual requirement rather than a generic benchmark.
The Stackcurve Take
A well-designed SASE PoC is one of the most valuable investments a buying team can make — not because it will definitively predict production performance, but because the discipline of designing buyer-centered test cases forces clarity about what your actual requirements are.
The process of defining your traffic profile, your application portfolio, your failure mode tolerance, your DLP data type requirements, and your latency sensitivity thresholds is worth doing regardless of the vendor outcome. These are requirements that should drive your configuration and policy decisions after deployment.
The single most important PoC design principle: measure what matters in your environment, not what the vendor's marketing materials say matters. Latency at your branch locations. DLP accuracy for your data types. Admin console behavior for your actual policy complexity. Failover behavior under the outage scenarios your users will realistically experience.
Vendors who perform well on buyer-designed PoCs with realistic test conditions are the vendors who will perform well in production. The buying team's job is to create the conditions under which that signal is observable.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers PoC evaluation frameworks, latency benchmarking methodology, and DLP accuracy testing standards across all major SASE platforms. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.