Zero Trust is no longer a controversial idea. The industry settled that debate years ago. Identity matters. Perimeters are gone. Implicit trust is dangerous. Continuous verification is the goal.
And yet, if you ask most security leaders how effective their Zero Trust program really is, the answer tends to be a polite shrug followed by something like “we’re making progress.”
The latest Zero Trust research from HPE and Cybersecurity Insiders (https://www.hpe.com/psnow/doc/a00155604enw) confirms what many of us already see in the field. Organisations largely understand what Zero Trust demands, yet execution continues to lag. Not because of a lack of budget, belief, or board-level support, but because of something far more ordinary and far harder to fix: complexity.
I have seen this pattern repeat across manufacturing, critical infrastructure, financial services, higher education, and global enterprises of every size. The intent is there. The architecture diagrams look great. But the day-to-day reality tells a different story.
Zero Trust is not failing as a strategy. We are failing to operationalise it.
The execution gap is real and growing
One of the most striking findings in recent Zero Trust research is the size of the gap between belief and implementation. A large majority of organisations say concepts like Universal ZTNA are essential to their security strategy, yet only a small fraction have fully deployed them. That is not a philosophical disagreement. That is an execution failure.
What makes this uncomfortable is that most organisations rate their own Zero Trust effectiveness somewhere in the middle of the scale. Not broken. Not mature. Just stuck.
That middle ground is where risk quietly accumulates.
In my experience, this is the most dangerous place to be. You have enough controls to feel protected, but not enough consistency to actually reduce blast radius when something goes wrong. You believe you are enforcing least privilege, but exceptions have piled up. You believe access is verified continuously, but only for some users, some applications, in some locations.
Attackers do not need perfection. They only need inconsistency.
Complexity is the real enemy
When Zero Trust stalls, the instinctive response is often to blame skills shortages, legacy systems, or organisational silos. Those things matter, but they are rarely the root cause.
The real issue is architectural fragmentation.
Over the years, we have layered security tools to solve individual problems. VPNs for remote access. NAC for campus networks. CASB for SaaS. Firewalls for segmentation. Endpoint tools for posture. Identity systems bolted on top. Each tool justified at the time. Each one adds another policy engine, another console, another place where context gets lost.
I have lived through this firsthand. In large manufacturing environments, especially highly regulated ones, it is common to find multiple access control models running in parallel. One for the factory floor. One for corporate users. One for third parties. One for remote engineers. Each has different rules, different owners, and different risk assumptions.
On paper, everything looks covered. In practice, nothing is truly joined up.
This is where Zero Trust quietly breaks down. Continuous verification only works if identity, device posture, network context, and policy enforcement are connected. When those signals live in different systems, policy becomes static by default. Exceptions linger. Risk signals arrive too late to matter.
The problem is not that teams are doing nothing. It is that they are doing too much, in too many places, without a single source of truth.
Excess access is still everywhere
If there is one area where Zero Trust consistently fails in the real world, it is internal access.
Employee overprivilege remains widespread. SaaS permissions drift over time. Legacy applications retain broad access because nobody wants to touch them. Third-party access is often granted quickly and reviewed slowly, if at all.
I have lost count of the number of times I have heard “we trust our people” used as a justification for excessive access. Trust in people is not the issue. Trust in static access models is.
Most modern breaches do not start with sophisticated exploits. They start with valid credentials and excessive permissions. Attackers blend in because the environment allows them to.
Zero Trust was meant to fix this, but only if enforcement is universal. Partial Zero Trust is not Zero Trust at all. It is security theatre with better branding.
Zero Trust has grown up
What has changed in the last couple of years is how CISOs talk about Zero Trust.
It is no longer framed purely as a defensive strategy. It is increasingly positioned as a way to move faster, reduce friction, and simplify operations. That shift matters.
In my own career, especially during periods of major change like M&A activity or rapid cloud adoption, the biggest security challenge was never technology. It was speed. How quickly can we onboard new users, integrate new environments, and enable access without creating permanent risk?
Traditional perimeter models fail here. VPNs become bottlenecks. Manual access reviews slow everything down. Security becomes the department of “no”.
When Zero Trust is implemented properly, the opposite happens. Access becomes easier because it is more precise. Change becomes safer because policy is consistent. Security stops fighting the business and starts enabling it.
That is why we are seeing Zero Trust positioned as an operating model rather than a project.
Where most journeys actually start
Despite endless reference architectures, most Zero Trust journeys begin with one of two things.
Organisations either start by modernising access, usually replacing VPNs with ZTNA, or they start by consolidating platforms to reduce tool sprawl.
Both approaches make sense. Access is often the most visible pain point, especially for remote users and third parties. Platform consolidation is often driven by operational exhaustion. Too many tools, too many alerts, too little clarity.
The mistake I see is treating these as separate initiatives.
The organisations that make real progress are the ones that connect access modernisation to early platform unification. They use ZTNA not just to replace VPNs, but as a forcing function to rethink policy, identity, and enforcement across the environment.
Why SASE matters more than the acronym suggests
SASE has suffered from its own hype cycle, but stripped of marketing, the underlying idea is sound.
Zero Trust defines what needs to happen. SASE defines how you deliver it at scale.
By converging networking and security into a cloud-delivered policy fabric, SASE removes many of the seams where Zero Trust breaks down. Policy follows identity instead of IP addresses. Enforcement happens close to users and applications instead of being dragged back through data centres. One framework covers remote users, branch sites, and increasingly campus environments.
I have seen firsthand how this convergence reduces friction between network and security teams. When both operate from the same policy model, arguments disappear. Visibility improves. Change accelerates.
This is not about chasing a single vendor strategy for its own sake. It is about reducing the number of translation layers between intent and enforcement.
Universal ZTNA is the missing link
Traditional ZTNA solved an important problem, but it stopped short. It focused almost exclusively on remote users.
Universal ZTNA extends the same Zero Trust principles to every access path. Remote. Branch. Campus. On-site. Third party. Managed or unmanaged.
This matters more than many people realise.
As long as you run separate access models for different locations, you will never have a consistent policy. As long as campus access is treated as inherently trusted, attackers will aim for it.
Universal ZTNA is not just another product category. It is the execution engine that finally makes Zero Trust universal rather than situational.
Zero Trust does not stop at access
Another important shift is the expansion of Zero Trust beyond initial access decisions.
Mature programs apply the same logic across identity, devices, networks, applications, and data. These are not separate disciplines. They are different enforcement points of the same policy.
In the most advanced environments I have worked with, Zero Trust becomes almost invisible. Users experience fewer interruptions, not more. Security incidents are contained faster because context is shared. Audits become easier because policy is consistent.
That is the goal. Invisible security that works everywhere without special cases.
AI is no longer optional
One uncomfortable truth is that manual security processes cannot scale. Not with hybrid work. Not with cloud. Not with the volume of telemetry modern environments generate.
AI is increasingly becoming the connective tissue that makes Zero Trust viable at scale. Not by replacing human judgment, but by augmenting it. Surfacing anomalies. Automating routine decisions. Adapting policy in real time as risk changes.
Used properly, AI turns Zero Trust from a static framework into a living system.
The real takeaway
The message from the data is clear, and it aligns closely with what many of us see every day.
Zero Trust works best when it is unified.
Simplify the architecture. Unify enforcement everywhere. Amplify with intelligence.
Stop adding tools. Start connecting the ones you already have. Focus less on coverage metrics and more on consistency.
Zero Trust is not a destination. It is a discipline. And like any discipline, it only works when it is practiced continuously, everywhere, without exception.
That is the execution gap we need to close.
Join our LinkedIn group Information Security Community!
