The Question
Your SASE deployment is complete. The security controls are active. TLS inspection is enabled. ZTNA is routing user access to on-premises and cloud applications. The CISO is satisfied.
Then the Slack messages start. "The VPN replacement made SharePoint really slow." "Since we moved to the new security thing, Salesforce takes forever to load." "Something is wrong with the internet." The help desk begins receiving tickets. The volume climbs. A business unit VP sends an email to the CIO with the subject line "Security is killing productivity."
The security team investigates. Is the slowness real or perceived? Is it the SSE PoP? The user's local network? The last-mile connection between the PoP and the application? The application itself? The investigation takes three days and produces no conclusive answer.
The CIO calls a meeting. The CISO is on the defensive. A rollback is discussed.
This is the most common failure mode in SASE deployments that have successfully completed their technical implementation. The security controls work. The user experience is degraded — or appears to be degraded. Without data, the security team cannot defend the deployment. Without data, the business cannot determine whether the degradation is real or imagined, temporary or permanent, SASE-caused or coincidental.
DEM is not a premium add-on for SASE — it is the operational capability that determines whether your SASE deployment survives its first quarter.
Why This Matters Now
In late 2024, a global manufacturing company with 18,000 employees across 40 countries completed a Palo Alto Prisma SASE deployment. The deployment was technically sound. PoP selection had been optimized for workforce geography. Split tunneling was configured to exclude high-bandwidth, low-risk video conferencing traffic.
Within 30 days of the go-live, the company's European operations began reporting significant latency on SAP ERP sessions. The SAP environment was hosted in a private data center in Germany. European users had previously connected directly to the data center over a private WAN; post-SASE, their traffic was routed through the SSE PoP before reaching the application.
The project team could not determine whether the reported latency was a SASE routing issue or a PoP performance issue or an SAP application performance issue without DEM telemetry. The investigation consumed six weeks and required manual packet capture analysis at multiple network hops. The eventual conclusion was that a specific PoP was experiencing congestion during European business hours — a condition that could have been identified in hours with DEM telemetry and resolved with PoP steering within days.
The six-week investigation cost approximately $180,000 in internal and external engineering time. The remediation was a two-hour PoP steering configuration change. The ratio of investigation cost to remediation cost was a direct consequence of deploying SASE without DEM.
This case was typical of 2024–2025 SASE performance complaints that Stackcurve tracked. The technical fix was straightforward in every case. The cost was in the investigation.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluated DEM capabilities across the major SASE vendors as a distinct scoring dimension, separate from core SSE capability. The findings showed significant differentiation.
Zscaler Digital Experience (ZDX) is the most mature standalone DEM capability in the SASE market. ZDX provides hop-by-hop latency telemetry from endpoint to application, including PoP performance visibility, application response time, and device-level diagnostics. ZDX integrates with Zscaler's PoP steering controls, enabling automated remediation of PoP performance issues.
Palo Alto ADEM (Autonomous Digital Experience Management) integrates with Prisma SASE and provides both synthetic monitoring and real user monitoring. ADEM's AI-powered root cause analysis is a differentiator — it can classify performance issues by category (endpoint, network, PoP, application) without manual packet analysis.
Netskope's DEM capabilities are newer and less mature than Zscaler and Palo Alto. Netskope provides PoP latency monitoring and basic application performance telemetry, but the tooling for help desk-level troubleshooting is less developed.
Cato Networks provides performance analytics within the Cato Management Application, including visibility into PoP performance and WAN path quality. Cato's DEM capability is integrated with its SD-WAN architecture and is more complete than Netskope's but less mature than ZDX or ADEM for endpoint-to-application hop analysis.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most SASE buyers evaluate DEM as a feature to be confirmed ("yes, we have DEM") rather than a capability to be assessed for operational depth. The distinction matters because DEM is only useful if it can answer the questions that arise during a real performance incident.
What DEM Must Answer in Production
When a user reports that Salesforce is slow, DEM must be able to answer four questions within minutes:
- What is the latency from the user's endpoint to the nearest SSE PoP?
- What is the latency from the SSE PoP to the Salesforce data plane?
- What was the baseline latency for this user to Salesforce before SASE was deployed?
- Is this a condition affecting one user, a geographic region, or all users?
Without these four answers, the investigation begins from scratch every time. With them, the security team can isolate the problem category in under 10 minutes and either resolve it (PoP steering change, split tunnel exception) or correctly attribute it to a non-SASE cause (Salesforce service degradation, user's ISP, user's device).
Real User Monitoring vs. Synthetic Monitoring
Synthetic monitoring sends automated test sessions from simulated endpoints to target applications on a scheduled interval. It provides baseline performance data and detects PoP or application degradation before users report it.
Real user monitoring captures actual session performance metrics from production traffic. It reflects the user experience that real employees are having, including device-specific factors (CPU load, memory pressure) and application-specific factors (session token expiration, large payload transfers) that synthetic monitoring cannot replicate.
Both are necessary. Synthetic monitoring tells you when something has changed. Real user monitoring tells you which users are affected and whether the change is universal or user-specific.
PoP Performance Visibility
SASE changes the network path for every user. A PoP that performs well for 95% of users may perform poorly for users in specific geographic locations or on specific ISPs. Without PoP-level performance visibility, this condition is invisible until users report it.
DEM provides PoP performance telemetry that enables PoP steering — automatically routing users to a better-performing PoP when their assigned PoP is congested or degraded. Without DEM, PoP steering is a manual operation that requires an engineer to identify the problem, find the affected users, and reconfigure their PoP assignment.
The Helpdesk Deflection Value
Organizations with mature DEM can respond to "SASE made X slow" complaints with data within minutes. The help desk technician opens the DEM console, queries the affected user, and sees the hop-by-hop latency breakdown for their most recent session. If the latency is within baseline, the complaint is attributable to a non-SASE cause. If the latency is above baseline at the PoP hop, the technician escalates to network operations with a specific data point.
Without DEM, every performance complaint is an open investigation. The time-to-resolution for performance complaints without DEM is measured in days. With DEM, it is measured in hours or minutes.
The Pre-Deployment Baseline Requirement
DEM is only useful for comparison if a baseline exists. Organizations deploying SASE should install the DEM agent on a representative sample of endpoints before the SASE deployment begins, capture 30 days of baseline performance data for the key applications in scope, and use this baseline as the reference for post-deployment performance comparison.
Organizations that deploy DEM after SASE is live have no baseline. They can see current performance but cannot determine whether it represents an improvement or degradation from pre-SASE conditions.
Questions Your Buying Team Should Be Asking
1. What is the architectural model of your DEM capability — is it a separate agent, integrated with the SASE client, or agent-less? What telemetry does it capture at the endpoint versus the network layer?
Agent-less DEM is limited to network-layer telemetry. Agent-based DEM can capture device-level diagnostics — CPU load, memory pressure, disk I/O — that are necessary for distinguishing application-layer performance issues from device-level issues. Understanding the architecture tells you what questions DEM can and cannot answer.
2. Can your DEM solution establish a pre-deployment performance baseline before the SASE rollout begins, and how is that baseline stored and compared against post-deployment telemetry?
This question tests whether the vendor has thought about DEM as an operational lifecycle tool or as a post-deployment reporting feature. A vendor who has not considered baseline capture as part of the deployment process has not operationalized DEM.
3. What is the time-to-resolution workflow when DEM identifies a PoP performance issue — how does the DEM alerting system connect to your PoP steering controls?
The value of DEM is only realized if detection leads to remediation. Ask the vendor to walk through the specific workflow from DEM alert to PoP steering change, including whether the remediation can be automated or requires manual intervention.
4. What percentage of your enterprise customers have DEM deployed alongside their SASE deployment, and what do your customers report as the primary operational benefit?
Customer adoption rates for DEM tell you whether the vendor's customer base has found it operationally valuable or treats it as an unused feature. Low adoption suggests the product is immature or poorly integrated.
5. Can you provide a reference customer who can describe a specific performance incident that DEM helped them resolve, including the time-to-resolution and the remediation taken?
A specific incident reference is more valuable than a general endorsement. The details of the incident — what the problem was, how DEM identified it, what the fix was — reveal the operational maturity of the DEM capability in production conditions.
The Stackcurve Take
SASE deployments succeed when users accept them. Users accept them when performance is equivalent to or better than what they had before. Performance equivalence can only be demonstrated with data.
DEM is the data collection and analysis capability that makes this demonstration possible. It is also the operational tool that enables the security team to resolve performance issues before they become business escalations.
Organizations that deploy SASE without DEM are making a bet that the deployment will perform well from day one and that no user will report a performance issue that the security team cannot immediately diagnose without telemetry. That bet occasionally pays off. More often, it does not — and the cost of not having DEM is measured in project delays, business complaints, and in the worst cases, deployment rollbacks that consume months of project budget.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers DEM capability depth for each major SASE vendor. 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.