The Question
A CISO at a regional healthcare system recently told us she had spent $3.4 million on "zero trust" over 18 months. When her team mapped what had actually been purchased — a ZTNA proxy for remote access, an endpoint detection and response tool, and a privileged access management platform — against NIST SP 800-207, they found they had implemented one of four required pillars. The other three remained legacy architecture. The board had been told the organization was "zero trust."
This is not fraud. It is the inevitable outcome of a market in which "zero trust" has been stretched to mean whatever the vendor in front of you sells. Firewalls are marketed as zero trust. VPN replacements are marketed as zero trust. PAM tools, MFA solutions, endpoint agents, and network segmentation platforms are all marketed as zero trust. Each of these claims is technically defensible in isolation. Together, they have made zero trust one of the most expensive and least understood concepts in enterprise security procurement.
The NIST definition is precise. The market interpretation is not. And buyers who conflate the two spend significant capital on individual components while believing they have built something that the components alone cannot constitute.
Zero Trust is an architecture principle, not a product — and understanding the difference determines whether your investment builds a coherent defense or a marketing checkbox.
Why This Matters Now
In May 2023, OMB Memorandum M-22-09 set a September 2024 deadline for all US federal agencies to achieve specific zero trust architecture targets. The memo drew directly from NIST SP 800-207 and CISA's Zero Trust Maturity Model and required measurable progress across five pillars: identity, devices, networks, applications, and data. Agencies that couldn't demonstrate architecture-level progress — not product purchases — faced escalating oversight requirements.
The results of the federal evaluation were instructive for commercial buyers. Agencies that had invested heavily in individual zero trust-branded products frequently discovered they had not achieved the architectural outcomes the memo required. A PAM tool did not constitute a completed identity pillar. An EDR deployment did not satisfy the device pillar. ZTNA adoption covered part of the network pillar but left application and data pillars largely unaddressed.
The Government Accountability Office's 2025 assessment found that fewer than 30% of civilian agencies had achieved CISA's "Advanced" maturity level across all five pillars by the extended deadline. The most common failure mode: agencies had purchased individual zero trust-marketed products without an architecture blueprint that connected them. Products were deployed in parallel rather than in concert. Policy engines didn't share identity context. Device trust signals from EDR tools weren't consumed by the ZTNA access proxy. MFA was enforced at login but not at the transaction level.
Commercial enterprises face the same failure pattern without the regulatory forcing function. When the incident happens — and in a legacy-architecture environment, it will — the post-mortem typically reveals products that were deployed in silos, never integrated at the policy layer, and incapable of providing the continuous verification that zero trust is supposed to enforce.
What the CURVE™ Data Shows
The 2026 Stackcurve SASE/SSE CURVE™ Report evaluates ZTNA platforms — the network access layer of zero trust architecture — as a distinct category within the broader SSE landscape. Zscaler Private Access, Palo Alto Prisma Access, Cloudflare Access, and Netskope Private Access are among the leading evaluated platforms in the ZTNA category.
What the CURVE™ data makes clear is that ZTNA maturity varies significantly on the dimensions that matter for genuine zero trust architecture: device posture integration, continuous session re-evaluation, identity provider flexibility, and application-layer inspection depth. A platform that tops the ZTNA category on user experience and deployment simplicity may score materially lower on continuous verification — the architectural requirement that separates ZTNA from a slightly smarter VPN.
The CURVE™ report also scores vendors on their ability to integrate with the broader zero trust ecosystem — specifically how well their ZTNA platform consumes identity signals from leading IdPs (Okta, Microsoft Entra, Ping) and device signals from EDR platforms (CrowdStrike, SentinelOne). This cross-platform integration score is frequently the most differentiated metric across vendors that look identical on feature checklists.
The full vendor rankings are in the 2026 Stackcurve SASE/SSE CURVE™ Report — free to download.
The Gap Most Buyers Miss
Most enterprises have at least some of the components required for zero trust architecture. The gap isn't usually the absence of products — it's the absence of integration between them. NIST SP 800-207 describes zero trust as a system in which every access decision is made dynamically, using signals from multiple sources, enforced at the point closest to the resource. That requires four things working together:
1. Identity verification that is continuous, not point-in-time MFA at login is not zero trust. Zero trust requires that the identity signal remain valid throughout the session and that anomalies in identity context — unusual location, concurrent session detection, credential anomaly — trigger re-evaluation or session termination. This requires your IdP and your access proxy to be in continuous communication, not just synchronized at login time.
2. Device validation that is real-time, not policy-based Most enterprise MDM and EDR deployments check device compliance at enrollment or at scheduled intervals. Zero trust requires device health to be evaluated at the moment of each access request. A device that passed compliance check at 9 AM but triggered an EDR alert at 11 AM should not retain the same access privileges unless the alert is cleared. Achieving this requires your ZTNA platform to consume real-time device posture signals from your EDR — an integration that most enterprise environments have not implemented.
3. Least-privilege access enforced at the application layer, not the network layer Legacy VPN grants network access. ZTNA grants application access. But even ZTNA deployments frequently grant access to an application as a whole — including administrative interfaces, bulk export functions, and API endpoints — when genuine least-privilege would restrict access to specific functions based on role and context. Application-layer policy granularity is where most ZTNA deployments stop short.
4. Continuous traffic inspection after access is granted Access decision and traffic inspection are separate functions. ZTNA platforms determine whether a user gets access. SWG and CASB platforms inspect what that user does after access is granted. In most enterprise deployments, these functions operate independently. A user authenticated through ZTNA who then begins exfiltrating data is visible to the DLP engine only if that engine is in the traffic path and sharing context with the access control layer. Many deployments leave this integration unconfigured.
The organizational failure that compounds all four gaps: zero trust architecture requires joint ownership between the identity team, the endpoint team, the network security team, and the application team. In most enterprises, those teams have separate roadmaps, separate vendor contracts, and separate budget cycles. Zero trust doesn't emerge from parallel product purchases. It requires someone with organizational authority to drive cross-team integration — and most enterprises have not created that role.
Questions Your Buying Team Should Be Asking
1. Which of the four zero trust pillars does this product address, and which does it require from external integrations? Any vendor selling a zero trust-branded product should be able to map their platform precisely to NIST SP 800-207 pillars. Ask for that mapping before the demo. If the answer involves "our platform provides the full zero trust foundation," ask them to be specific about which functions require integration with your IdP, your EDR, and your CASB to deliver the stated capability. The integration dependencies are where implementation complexity lives.
2. How does your platform re-evaluate access decisions after the initial session is established? This is the continuous verification question. Ask specifically: what triggers a mid-session re-authentication or access revocation? The answer should include identity anomalies from the IdP, device posture changes from the EDR, and behavioral anomalies from the access proxy itself. If the answer is "session timeout policies," the platform is enforcing time-based re-authentication, not continuous verification.
3. What is the most granular level at which access policy can be applied — application, feature, or API endpoint? The difference between network-layer access control and genuine application-layer least-privilege is granularity. A mature ZTNA or SASE platform should be able to grant a user access to a specific application feature — a read-only view, a specific report, a subset of API calls — not just to the application as a whole. Ask vendors to demonstrate this with a real policy example.
4. Which identity providers and EDR platforms does your platform integrate with natively, and what signals does it consume from each? "Integration" means different things to different vendors. A SAML SSO handshake is technically an integration with your IdP but provides no ongoing device or session signals. Ask which specific signals the platform consumes: device compliance state, user risk score, concurrent session count, geolocation. The richer the signal set, the more meaningful the continuous verification claim.
5. How does your organization define zero trust project success, and how will you measure it? This is a question for your own team as much as for vendors. Before issuing any RFP, agree on measurable outcomes — mean time to detect lateral movement, percentage of applications protected by application-layer access control, percentage of access decisions informed by real-time device posture. Organizations that define zero trust success as "deployed ZTNA" will spend significant money and remain vulnerable to the failure modes the architecture was designed to prevent.
The Stackcurve Take
Zero trust is one of the few security frameworks that is simultaneously correct in principle and almost universally misapplied in practice. NIST SP 800-207 provides a rigorous, implementation-agnostic definition. CISA's maturity model provides a measurable progression. The federal mandate created a real-world test of whether the framework could be operationalized at scale. The results of that test suggest that product purchasing alone — without architectural integration and organizational alignment — produces individual capabilities that do not add up to zero trust outcomes.
For commercial enterprises, the practical implication is straightforward: start with the architecture blueprint, not the product shortlist. Map your current environment against the four pillars — identity, device, access, and inspection. Identify which integrations are missing. Then evaluate vendors on integration capability, not feature checklists. The platform that scores highest on a zero trust feature checklist is not necessarily the one that best connects with the rest of your architecture.
The 2026 Stackcurve SASE/SSE CURVE™ Report covers ZTNA platforms and their integration depth across identity, device, and inspection layers. 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.