Zero Trust: What it promises, what’s actually deployed, and why most implementations miss the point

I wanted to check where the Zero Trust world actually stands, not from a marketing point of view, but from a technology and real world deployment perspective. What are corporations actually implementing? How close are they to the ideal? And more importantly, why do so many of them struggle to get meaningful outcomes?

I started with NIST SP 800–207. It’s an older standard now, about six years old, and it’s not exactly light reading. But the fundamentals it lays out are still relevant.

That said, it’s important to treat it as a reference model, not a fixed blueprint. In practice, every organization’s Zero Trust end state will look different. The real issue is not deviation but lack of a clearly defined destination.

The Idealistic View vs The Reality

The idealized vision of Zero Trust is elegant: no implicit trust, every access request verified, least privilege everywhere, full visibility across users, devices, workloads, and data.

Some corporations are stitching technologies together to get close to that vision. But for most, this requires knowledge, upkeep, mature processes, and organizational discipline.

Without those foundations, you can implement ZTA today and, a few years down the line, find yourself undoing parts of it and going back to basics.

The Two Paths: SASE or Build Your Own

For most corporations, the practical choice comes down to two options.

The first is adopting one of the major SASE platforms — Netskope, Zscaler, or Palo Alto Networks, which bundle a range of Zero Trust capabilities into a managed, integrated solution.

They’re expensive, but they reduce integration overhead and can accelerate adoption. The trade-off, as ISC2 points out, is vendor lock-in, although in practice, many organizations accept that trade-off.

The second path is stitching solutions together: integrating APIs, building custom logic, and tailoring controls. This offers flexibility and avoids lock-in, but it is harder to maintain over time.

When a vendor changes an API and something breaks in production, that burden sits with your team. And in reality, not every organization has the processes in place to stay ahead of those changes.

In practice, many organizations end up somewhere in between these two approaches.

The real issue, however, is not which path you choose. It’s layering technology without a clear strategy or defined end-state. That’s how you end up with fragmented infrastructure and increasing complexity.

And complexity, in many environments, becomes one of the biggest obstacles to maintaining effective security.

The Foundational Sins

This is where many implementations struggle, and it has little to do with vendor choice.

Sin one: No asset inventory. Security starts with visibility. If you don’t have a reliable understanding of what exists in your environment, securing it becomes significantly harder. Whether through a CMDB or continuous discovery tooling, some form of accurate inventory is essential.

Sin two: Broad, legacy-style policies. User access still tied to static constructs. Firewalls deployed but not fully leveraging identity or application awareness. Service-to-service communication defined by overly permissive rules.

At that point, the model may be labeled “Zero Trust,” but in practice it often resembles a traditional perimeter approach with incremental improvements.

What ZTA Can Actually Look Like Today

You don’t need to assemble dozens of tools to get meaningful outcomes.

User access should ideally be governed through a consistent policy model aligned with the PEP/PDP concepts described by NIST SP 800–207. When policy logic is fragmented or inconsistently applied across environments, security becomes harder to manage and reason about.

SASE platforms address some of this by centralizing policy and enforcement, although in practice, consistency still depends on how they are implemented.

For organizations without SASE budgets, alternatives exist. Identity aware controls on network infrastructure, combined with centralized management and logging, can still provide meaningful improvements.

SaaS access introduces additional complexity. Routing all traffic through a central data center may work in limited scenarios, but for distributed workforce, it often creates latency and reliability challenges. This is where cloud delivered approaches tend to provide better user experience, Netskope, Palo Alto and Zscaler offer some of these solutions separately.

Within the data center, segmentation remains key. Kubernetes environments offer advantages through label-based policies and integration with service meshes. For more traditional environments, tools like Akamai segmentation (Guardicore) enable micro-segmentation without major architectural redesign.

These tools also improve visibility into traffic flows and dependencies. They don’t replace the need for a proper inventory process, but they can significantly accelerate understanding of the environment.

Before You Go Shopping

This is the most important part.

Before buying anything, define a strategy. Understand your current state. Map your gaps. Identify what you’re trying to achieve.

Then approach the problem methodically, aligning tools to actual requirements rather than perceived needs.

Frameworks like:

• NIST SP 800–53
• Cloud Security Alliance Cloud Controls Matrix

can help structure that process.

You wouldn’t start a project without requirements and a plan. Security should be no different.

Implementing controls without a defined destination often leads to fragmented, complex, and difficult to maintain environments, even if individual components provide some level of risk reduction.

Closing Thought

Zero Trust is not something you “buy” or implement in a single phase. It’s a progression.

But without a clearly defined destination, that progression becomes inefficient, harder to measure, and in some cases reversible.

Coordinate first. Build the foundations. Then make technology decisions based on what you actually need.