Why most zero-trust programs stall after year one

In recent years, I’ve watched zero trust shift from just a security buzzword to a key focus for many companies. Organizations in almost every industry have put significant resources into identity platforms, access policies, endpoint checks, segmentation and modern authentication. Executives often approve budgets quickly because the idea is simple: never trust, always verify.

Most zero-trust programs seem successful during their first year.

Pilot projects move fast. More people start using multi-factor authentication. Identity systems connect better. Security dashboards get better. Leaders notice clear progress and real milestones.

But then things start to change.

Progress slows down. More exceptions pop up. Day-to-day work gets harder. Teams sometimes bypass controls just to keep things running. Policies become less consistent across different areas. Security teams still call it “zero trust,” but over time, the system starts to rely on old trust habits again.

This is where many organizations misjudge the effort. The real challenge isn’t starting zero trust—it’s keeping it going after the initial rollout.

From what I’ve seen, this is where a lot of zero-trust programs get stuck.

Why year one usually looks successful

The beginning of a zero-trust project is usually the easiest stage.

Most organizations start with visible controls that show quick results. The first big focus is usually updating identity systems. Adding multi-factor authentication, single sign-on, device checks and central access policies quickly improves security.

These projects are also pretty easy to explain to executives. Leaders understand the risks tied to identity. Compliance teams back stronger authentication. Vendors offer clear plans and maturity models.

Advice from the National Institute of Standards and Technology’s Zero-Trust Architecture framework has helped make these conversations more consistent across companies.

In the early stages, most organizations keep things manageable. Security teams focus on a few key apps or user groups. There aren’t many exceptions, and the work stays simple.

Where momentum begins to break down

The main challenge isn’t the technology—it’s scaling up.

As zero trust spreads through the organization, things get more complicated fast. Policies that worked for small rollouts become hard to keep up across hybrid setups, old systems, cloud platforms, third-party tools and teams with different goals.

In several places I’ve worked, the first signs of trouble weren’t security breaches — they were operational exceptions.

App teams needed temporary workarounds for older systems. Vendors asked for easier authentication for their integrations. Old applications couldn’t handle new security methods. Network teams kept extra access paths for troubleshooting or compatibility.

Each exception seemed reasonable on its own. But together, they started to weaken the overall system.

Research from CISA’s Zero-Trust Maturity Model backs this up, stressing that zero trust is an ongoing way of working.

Another big problem is split ownership. Security teams set the rules. Infrastructure teams handle connections and uptime. App owners care about features and deadlines.

The hidden operational cost of zero trust

One thing people rarely talk about is how zero trust can add extra work if it’s not set up carefully. Stronger checks and stricter rules look good on paper. But in practice, every new policy adds more work.

Security teams have to handle exceptions, look into access problems, keep integrations running, check data and work with many other teams.

If teams aren’t disciplined, things get complicated fast.

Research from Google’s BeyondCorp project pointed out early that zero trust isn’t just about stronger authentication.

What mature organizations do differently

Organizations that keep zero trust working well usually take a different approach from the start.

First, they focus on making things as simple as possible. Rather than creating custom rules for every situation, they standardize their systems and cut down on exceptions whenever they can.

Second, they see zero trust as an ongoing way of working, not just a project to finish.

Third, they make sure everyone knows their responsibilities from the start.

Fourth, they put a lot of effort into tracking and monitoring what’s happening in their systems.

Finally, experienced organizations know that zero trust isn’t about removing trust entirely. It’s about reducing hidden trust and always checking key assumptions.

Final thought

Zero-trust programs don’t usually fail because people stop caring about security. They stall because growing complexity makes it hard to keep the system consistent.

The first year often runs on excitement, executive support, and clear goals. After that, success depends on good management, discipline, handling exceptions and sticking to the rules over time.

Zero trust isn’t just a product or a one-time project. It’s a way of working that needs to stay steady, even as systems change, teams shift, and business demands grow.

Organizations that realize this early on are more likely to build zero-trust programs that grow stronger over time.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?