Every organisation claims to be moving toward Zero Trust. Most are just renaming their VPN.
There is a version of Zero Trust that lives in slide decks. It has a clean diagram with arrows, boxes labeled “identity” and “devices” and a caption that says “never trust, always verify.” Leadership approves the initiative. Someone gets assigned to own it. A vendor is selected. Eighteen months later the team is still on the same VPN, MFA is enforced for about 60% of users and the service accounts that have not been rotated since 2021 are still quietly sitting there with full database access.
This is not a technology problem. The tools exist. The frameworks exist. NIST published SP 800–207 defining Zero Trust Architecture clearly. CISA released a maturity model. The DoD published 91 specific implementation activities in January 2026. The documentation is thorough. The intent is not the issue.
The issue is that Zero Trust is not something you deploy. It is something you decide to believe about how trust works, and then build your entire architecture around that belief. Most teams have not made that decision yet. They have made a compromise instead: keep the old trust model, add some Zero Trust vocabulary and call it progress.
What “Never Trust, Always Verify” Actually Means in Practice
The phrase sounds simple. The implications are not.
Traditional security was built on a perimeter model. The thinking goes: if you are inside the network, you are trusted. If you authenticated once at the gate, you are trusted until your session ends. The castle-and-moat metaphor captures it well. The moat keeps threats out. Once you are inside the castle, you move freely.
The problem is that the castle wall is gone. It dissolved slowly over a decade of cloud adoption, remote work, third-party integrations and microservices. There is no inside anymore. Your database server in AWS, your developer’s laptop at a coffee shop, your payment gateway webhook and your internal admin dashboard are all, from an attacker’s perspective, roughly equally reachable. The moat protects nothing because there is no longer a meaningful boundary to protect.
Zero Trust’s response to this is a fundamental reframe: stop thinking about whether a request is coming from inside or outside the network. Start thinking about whether this specific identity, on this specific device, at this specific moment, should be allowed to do this specific thing.
That is not a configuration change. That is a different way of thinking about every access decision your system makes. And it has implications that ripple across your database design, your service-to-service communication, your deployment pipeline and your code review process.
The Three Principles and Where Teams Actually Fail Them
Zero Trust rests on three principles. They are straightforward to state and genuinely difficult to execute consistently.
Never trust, always verify. Every request is authenticated and authorised regardless of where it originates. A service running inside your private VPC is not automatically trusted to call another internal service. A developer who authenticated four hours ago is not automatically trusted to make a production database change now. Trust is granted per request, not per session or per network location.
Where teams fail: internal service-to-service calls. Most backends have at least a handful of services that call each other with no authentication at all, relying entirely on network-level isolation. If one of those services is compromised, an attacker inherits its ability to call everything else on the internal network. The service was trusted because it was inside. That is a perimeter model assumption hiding inside a cloud architecture.
Least privilege access. Users and systems receive only the permissions required to complete a specific task, for only as long as that task takes. No standing admin access. No service accounts with read permissions on tables they never query. No developer credentials that work in production just because they need them occasionally.
Where teams fail: service accounts. A 2026 implementation guide from a practitioner source puts it directly: service accounts are the most commonly neglected identity class. Most organisations have service accounts that were created once, never reviewed, never rotated and hold significantly more access than the service that uses them actually requires. Auditing and governing service accounts is tedious work that gets deprioritised in every sprint planning session. It also represents one of the most reliable paths an attacker can use to escalate privileges after initial access.
Assume breach. Design your systems under the assumption that an attacker already has a foothold somewhere inside. The goal is not to prevent all intrusions. The goal is to make sure that a compromised component cannot reach anything beyond its immediate purpose. Microsegmentation, limited blast radius, short-lived credentials and fast revocation are the operational expressions of this principle.
Where teams fail: lateral movement. When a breach happens in an organisation with a perimeter model, the attacker often has significant time to move sideways through the network before being detected. In a well-implemented Zero Trust architecture, a compromised service can reach only what it was explicitly granted access to. Lateral movement stalls because there is nowhere to move that has not already been locked down. Most organisations have neither the microsegmentation nor the monitoring in place to contain lateral movement effectively.
“The internal debate will no longer be whether to do Zero Trust. It will be how fast to remove each remaining pocket of implicit trust.” Keith McCammon, co-founder at Red Canary (acquired by Zscaler), SecurityWeek, January 2026.
The Numbers That Should Be Making You Uncomfortable
Zero Trust has moved from a recommendation to a commercial and regulatory expectation. The data in 2025 and 2026 makes this hard to ignore.
- The IBM Cost of a Data Breach Report 2025 puts the global average breach cost at $4.44 million. In the United States, that number hit a record $10.22 million, driven by regulatory penalties and slower detection
- Stolen credentials were the initial access vector in 22% of breaches according to the 2025 Verizon Data Breach Investigations Report (DBIR), which analysed over 22,000 security incidents. In Basic Web Application attacks specifically, the figure climbs to 88%
- 56% of organisations reported VPN-exploited breaches in the past year, a notable rise from the year before — Zscaler ThreatLabz 2025 VPN Risk Report of over 600 IT and security professionals
- 96% of organisations say they favour a Zero Trust approach but only 81% plan to implement it within 12 months — same Zscaler report
- Gartner predicts that by end of 2026, only 10% of large enterprises will have a mature and measurable Zero Trust programme in place, up from less than 1% in 2023
Read that last number again. 96% say they favour it. 10% will actually have it in a mature state. That is the gap between the slide deck and the architecture. It is the same gap that has existed for years and is only now starting to close under pressure from regulators, insurers and the sheer frequency of credential-based breaches.
Why Developers Keep Delaying It
Zero Trust is often framed as a security team problem. It is not. It is a backend engineering problem that the security team is trying to solve without the authority to change the code.
The decisions that determine whether Zero Trust principles are honoured or violated live in the application layer:
- Whether your service-to-service calls use mTLS or rely on network location
- Whether your JWT tokens have short expiry windows and are validated on every request
- Whether your database connections use per-service credentials or a shared application user
- Whether your secrets are rotated automatically or live as static strings in environment variables
- Whether your RBAC checks run on every endpoint or are assumed from login state
These are code decisions. They are architecture decisions. They require developers to build with Zero Trust in mind from the start, not bolt it on after a security audit flags problems.
The reason teams delay is not indifference. It is that Zero Trust thinking requires constant overhead on decisions that feel fine to skip. It is faster to use a shared database user than to provision per-service credentials. It is easier to trust an internal network call than to implement mTLS between services. It is simpler to issue a long-lived token than to build a refresh flow. Every shortcut feels reasonable in isolation. Collectively they produce a system where implicit trust is everywhere and the blast radius of any single compromise is the entire application.
What Shifting the Mindset Actually Looks Like
The mindset shift is this: every access decision your system makes is a trust decision. Treat each one as if it will be reviewed in an incident post-mortem.
In practice this means asking a specific set of questions at the design and code review stage:
- Does this service need access to this resource, or does it just have it because nobody restricted it?
- Does this token expire, and if a user’s role changes tomorrow, will the next request reflect that?
- If this service is compromised right now, what else can the attacker reach from it?
- Are we logging this access in a way that would let us reconstruct what happened if it is misused?
- Is this credential rotated, or is it static and effectively permanent?
These are not security team questions. They are engineering questions. They belong in the same conversation as performance, maintainability and test coverage.
The practical starting point for most teams is not a full Zero Trust programme. It is removing the most obvious pockets of implicit trust in the system you already have:
- Enforce MFA without exceptions. Not for most users. For every user, every access point, including developers, executives and legacy applications that require a proxy layer to support it.
- Audit and restrict service accounts. Find every service account. Assign an owner. Rotate credentials. Reduce permissions to the minimum the service actually requires. This is unglamorous work that directly reduces blast radius.
- Short-lived tokens everywhere. JWTs should expire. Sessions should expire. Production access granted to a developer for a debugging session should be revoked when the session ends, not when someone remembers to revoke it.
- Service-to-service authentication. Internal calls between services are not implicitly safe. Workload identity, mTLS or signed JWTs depending on your stack give each service a cryptographic identity that can be verified rather than assumed.
- Log everything. Zero Trust’s assume-breach principle is only actionable if you can reconstruct what happened. Every access request, every authentication event and every permission elevation should leave a trace.
This Is Not a One-Time Project
The most dangerous misconception about Zero Trust is that it has a completion date. It does not. Environments change, new services are added, threats evolve and what was a sufficient security posture last year develops gaps this year.
Zero Trust is a continuous practice. That means access certifications on a regular cycle, where resource owners confirm that current users still need the access they hold. It means policy reviews when roles change and when applications change. It means monitoring for the kind of quiet lateral movement that only becomes visible when you are actively looking for it.
Forrester Research, the firm that coined the term Zero Trust in 2010, found in a commissioned study that organisations using Microsoft’s Zero Trust approach saw a 50% lower chance of a data breach. That return does not come from deploying a product. It comes from building a security culture where implicit trust is treated as debt and every team takes responsibility for the access decisions baked into their code.
Zero Trust is not a destination. It is an architectural posture that your team either maintains or gradually erodes. Every shortcut taken under delivery pressure is a vote for erosion.
The VPN with updated branding will not protect you from the breach that exploits a service account nobody remembered to rotate. The Zero Trust slide deck will not save the credential that has been sitting in a config file with production read-write access since the last developer left.
The mindset shift is deciding that those things are your problem, as an engineer, today. Not next quarter. Not after the security audit. Today.
