Zero trust started life as a vendor talking point and has spent the last four years being awkwardly translated into actual programmes of work. As of mid-2026, most enterprises I deal with have either finished their initial rollout, are deep into the second wave, or have quietly admitted defeat on the original timelines. None of these states are uncommon.

The honest story is that the technology has matured faster than the operating models have. The tools are good. The processes around them are still working themselves out.

What’s working

Identity-aware proxy patterns have become the default access fabric for internal applications. The shift from VPN-first access to identity-first access is largely done across the enterprises I see, and the operational benefits are real. Joiners and leavers are handled cleanly. Contractor access is bounded and time-limited by default. Audit trails are coherent. The friction in the developer workflow that was a real concern in 2022-23 has mostly been engineered out.

Device posture checks have become useful rather than annoying. The early generation of these tools were notorious for blocking legitimate work and producing false positives that drained help desk capacity. The current generation handle exceptions sensibly, support BYOD scenarios that don’t require full device management, and integrate with the conditional access stack at a level of granularity that actually matches business risk.

Segmented network policies for legacy applications are the unglamorous part of zero trust, and the place where most of the genuine risk reduction has happened. Putting a domain controller behind an authenticated proxy, terminating direct workstation-to-workstation traffic, and forcing east-west traffic through inspection points produces tangible improvements in the blast radius of any single compromise. The CISOs I respect think this is where most of the real work has been.

Where it’s still painful

Application-level zero trust beyond identity is the hard problem and it’s still hard. Once a user has authenticated to an application, the granular permission model inside the application is rarely as tight as the network access model outside it. A compromised but authenticated user can still do substantial damage in most enterprise apps. Solving this requires application changes that vendors are slow to ship and internal teams are slow to demand.

The data-layer story has the same problem. Database access through a zero trust gateway is fine for query traffic but doesn’t extend cleanly to ETL pipelines, data warehouse loads, or analytics workflows that need bulk data movement. The exceptions accumulate and the policy model gets baroque. A surprising amount of internal data movement still happens through service accounts with broad standing access. Fixing this is a multi-year programme that most enterprises haven’t really started.

Third-party SaaS integration is messy. The number of SaaS applications a typical enterprise consumes has grown faster than the integration capacity to bring them into a unified zero trust posture. Some apps support modern federation cleanly. Some don’t. The ones that don’t accumulate risk and audit findings.

What teams that have made it work share

A few patterns recur across the rollouts I’d call genuinely successful.

They started with the boring things. Identity hygiene, group structure cleanup, joiner-mover-leaver process maturity. These aren’t zero trust controls per se, but every zero trust capability depends on them being solid. Teams that tried to skip this layer ended up with sophisticated tools attached to messy underlying state.

They sequenced rollout by risk and value, not by technology layer. The temptation to go layer by layer — network first, then identity, then application — produces inferior outcomes than starting with high-value, high-risk asset categories and putting the full stack of controls around them as a unit. Bank applications, customer data systems, payroll — protect these properly first, then expand. Don’t try to apply weak controls universally before strong controls anywhere.

They invested in the operations side. Zero trust shifts a substantial amount of work from network teams to identity teams, from perimeter monitoring to behavioural analytics, from periodic audits to continuous access decisions. Teams that didn’t restructure their operations to match the new control model ended up with tools nobody owned.

For the more complex pieces — federating modern AI tooling into the access model, integrating Microsoft Copilot and similar agents into the zero trust posture, building operational governance for AI-assisted workflows — many enterprises are bringing in specialist consultants to do the integration work. This is one area where the gap between the technology capability and internal expertise is widest.

Where it’s going

The interesting development in late 2025 and early 2026 has been the emergence of practical AI-assisted access decisions. Behavioural analytics that use models to identify anomalous access patterns are no longer experimental. They’re production controls in several major Australian enterprises and they’re producing genuinely useful signal.

The risk is the same risk as everywhere else AI is being deployed in production: the false positive rate matters, the explainability of denial decisions matters, and the operational overhead of investigating triggered events matters. Done well, these systems materially improve the security posture. Done badly, they create a new operational tax without proportionate benefit.

The honest summary for 2026: zero trust has stopped being a slogan and started being a discipline. The teams who got it right invested in fundamentals before they invested in tooling. The ones who tried to buy their way through it are still untangling.