Zero trust has a definition problem. The term originated in a 2010 Forrester report by John Kindervag, and the core idea was straightforward: stop assuming that anything inside the network perimeter is trustworthy. Verify every request, regardless of where it originates.
Fifteen years later, "zero trust" appears in the marketing copy of hundreds of security products. Firewalls are zero trust. Identity platforms are zero trust. Endpoint agents are zero trust. The term has been stretched so far that it risks meaning nothing at all. Our Zero Trust Adoption Survey 2024 found that 82% of organizations say they have a zero trust strategy, but only 14% have fully implemented one. That gap tells you everything about where we are.
What zero trust actually requires
Strip away the branding and zero trust is an architectural pattern with a few non-negotiable components. NIST SP 800-207 provides the most widely referenced framework, and it defines zero trust around these principles:
- All data sources and computing services are considered resources
- All communication is secured regardless of network location
- Access to individual resources is granted on a per-session basis
- Access is determined by dynamic policy, including client identity, application, and behavioral attributes
- The enterprise monitors and measures the security posture of all owned and associated assets
- Authentication and authorization are strictly enforced before access is allowed
None of these principles mention a specific product category. Zero trust is not a thing you buy. It is a way of designing systems.
The five pillars in practice
Most implementations break zero trust into five pillars: identity, devices, networks, applications, and data. The maturity of each pillar varies wildly across organizations.
Identity: the strongest pillar
Identity is where most organizations have made the most progress. Multi-factor authentication is nearly universal among survey respondents (94% adoption), and conditional access policies based on user risk scores are common. Single sign-on has simplified the identity layer for SaaS applications. The remaining gaps are in service-to-service identity (workload identity) and privileged access management, where adoption drops to 47% and 52% respectively.
Devices: uneven coverage
Device trust is straightforward for managed corporate laptops and increasingly difficult for everything else. BYOD policies, contractor devices, and IoT endpoints all create gaps in device posture assessment. Organizations that mandate device certificates or health attestation before granting access report significantly fewer endpoint-related incidents, but implementing that mandate across a diverse device fleet takes years, not months.
Networks: microsegmentation stalls
This is the pillar where the gap between strategy and implementation is widest. Microsegmentation, the practice of creating fine-grained network boundaries around individual workloads, is conceptually appealing and operationally painful. Sixty-one percent of respondents are still in pilot or planning phases. The friction comes from application dependency mapping: you cannot segment a network effectively until you understand every communication flow, and most organizations do not have that visibility.
Applications: the API gap
Application-level zero trust means every API call and every service interaction is authenticated and authorized. Service meshes like Istio and Linkerd have made this more practical for containerized workloads. But most enterprise application portfolios include legacy systems that were never designed for per-request authentication. Wrapping those systems in an API gateway with policy enforcement is a common workaround, but it introduces latency and complexity that development teams resist.
Data: the forgotten pillar
Data classification and data-level access controls are the least mature pillar across our survey respondents. Most organizations can tell you who has access to an application. Far fewer can tell you who has access to specific data within that application, or what happens to that data after it is accessed. Data loss prevention tools help at the perimeter, but the real challenge is implementing data-centric security policies that follow the data regardless of where it moves.
Why programs stall
The survey data points to three consistent patterns among organizations whose zero trust programs have stalled:
- No dedicated ownership. Zero trust spans networking, identity, endpoint, and application security. Without a single team or individual accountable for the overall program, it fragments into isolated projects that never connect.
- Trying to do everything at once. The most successful programs started with one pillar (usually identity), reached meaningful maturity, and then expanded. The stalled programs tried to advance all five pillars simultaneously.
- Treating it as a technology project. Zero trust requires policy decisions that affect how people work. Which users need access to which resources? Under what conditions? What happens when access is denied? These are organizational decisions, not technical ones. Programs that skip the policy work and jump to tool selection tend to end up with expensive shelfware.
A realistic path forward
If you are early in your zero trust program, or if yours has stalled, the data suggests a pragmatic approach: pick the pillar where you have the most organizational momentum, set measurable milestones, and build credibility through visible progress before expanding scope. The organizations in our survey that reached full implementation did not get there by buying a zero trust platform. They got there by making hundreds of incremental policy decisions over several years.
The full survey data and methodology are available in the Zero Trust Adoption Survey 2024.