Your vendor told you their product is Zero Trust. They were selling you something else entirely.
Zero Trust has become one of the most abused terms in enterprise security. It started as a rigorous architectural philosophy : a fundamental rethinking of how organisations protect their systems and data. Today, it has been reduced to a marketing label slapped on firewalls, VPNs, identity tools, and SASE platforms, none of which, by themselves, deliver what Zero Trust actually requires.
According to a 2024 Forrester Research survey, 76% of enterprises claim to have a Zero Trust strategy. But when audited against NIST’s published Zero Trust Architecture criteria, fewer than 15% have implemented even the foundational pillars. The gap between claiming Zero Trust and doing Zero Trust is enormous and it matters, because organisations that believe they have Zero Trust protection and don’t are more exposed than organisations that know they haven’t started yet.
This article makes the argument plainly Zero Trust is not a product you can buy, it is an architectural commitment your organisation has to build. We’ll show you what real Zero Trust actually looks like, why most implementations fall short, and give you a self-assessment to find out honestly where your organisation actually stands.
The Claim Everyone Believes : And Why It’s Wrong
The claim is simple and everywhere: “We have Zero Trust.”
Walk through any enterprise security conference, read any vendor case study, or sit through any CISO presentation to a board, and you’ll encounter it constantly. Organisations say it with confidence. Boards accept it as reassurance. Security budgets get approved on the strength of it.
The problem is that the vast majority of organisations saying “we have Zero Trust” have bought a Zero Trust product, usually an identity platform, a next-generation firewall, or a cloud access security broker : and treated the purchase as equivalent to the implementation.
It isn’t. Not even close.
Zero Trust is not a technology. It is a security philosophy built on a single foundational idea: trust nothing and verify everything, every time, regardless of where the request comes from.
The traditional security model, called perimeter security operates on the opposite assumption. It draws a boundary around your organisation’s network, trusts everything inside that boundary, and blocks everything outside. If you’re on the corporate network, you’re trusted. If you’re not, you’re blocked.
That model made sense when employees worked in offices, data lived in on-premise data centres, and applications ran behind corporate firewalls. It doesn’t make sense anymore.
Today, employees work from anywhere. Data lives in cloud platforms, SaaS applications, and third-party services. Applications are accessed from personal devices on public networks. The perimeter you spent 20 years building a wall around doesn’t exist anymore, and attackers figured that out long before most security teams did.
Zero Trust accepts this reality. Instead of trusting location (are you on our network?) Zero Trust requires every access request to be continuously verified based on identity, device health, behaviour, and context, regardless of where the request originates.
That verification isn’t a one-time login. It’s continuous. Every time a user accesses a resource, every time a device connects to a system, the access is re-evaluated against current context. A user who authenticated correctly this morning doesn’t automatically get access to a sensitive file this afternoon if something about their behaviour or device has changed.
That’s the philosophy. Now here’s why most “Zero Trust” deployments aren’t delivering it.
The Evidence: Why Most Zero Trust Claims Don’t Hold Up
The Vendor Redefinition Problem
The security industry did something clever with Zero Trust: it took a complex architectural framework and converted it into a product category. Now virtually every security vendor claims their product “enables Zero Trust” or is “Zero Trust ready.”
The result? Organisations buy an identity platform, hear their vendor tell them it “delivers Zero Trust,” and file the initiative as complete. The identity platform is valuable : multi-factor authentication and single sign-on are genuine security improvements. But they address one dimension of Zero Trust (identity verification) while leaving every other dimension untouched.
A well-configured identity platform does not:
- Enforce least-privilege access across all systems and data
- Continuously verify device health before granting resource access
- Apply micro-segmentation to limit how far an attacker can move if they do get in
- Monitor all network traffic : east-west, not just north-south : for unusual behaviour
- Revalidate trust continuously throughout a session, not just at login
Buying a Zero Trust product is like buying a front door lock and telling people your house is secure. The front door is important. It’s also only one part of the picture.
The “We Set It and Forgot It” Problem
Zero Trust is not a deployment : it is an ongoing operational posture. Real Zero Trust requires:
- Access policies that are reviewed and updated regularly as roles, systems, and risks change
- Device posture assessments that run continuously, not just at first login
- Network segmentation that evolves as your infrastructure evolves
- Anomaly detection that gets smarter over time as it learns normal behaviour
- Regular red team exercises to test whether the controls are actually working
Most organisations deploy their Zero Trust tools, declare victory, and move on to the next initiative. Two years later, the identity platform is configured the way it was on day one. Stale access policies have accumulated. Hundreds of accounts have more permissions than they need. The micro-segmentation that was planned never got implemented because it was too complex to retrofit onto a legacy network.
The controls age. The threats evolve. The gap widens.
The Coverage Gap Problem
Perhaps the most telling sign that an organisation’s Zero Trust is more aspiration than reality is when you ask: “Which systems and users does your Zero Trust architecture cover?”
Almost always, the honest answer is: the new stuff.
The cloud applications, the new SaaS platforms, the recently deployed identity provider : these are covered. But the legacy on-premise applications running on servers that are 12 years old? The manufacturing systems that were never connected to the corporate identity provider? The third-party contractors who access sensitive systems through a VPN that hasn’t been audited in three years?
These are the gaps where real breaches happen. Attackers are not targeting your most modern, well-defended systems. They are looking for the old, forgotten, under-monitored corners of your environment that your Zero Trust architecture doesn’t reach.
Real Zero Trust covers everything : or it acknowledges what it doesn’t cover and treats those gaps as known, active risks with compensating controls. “We have Zero Trust for our cloud environment” is not the same as “we have Zero Trust.”
KEY TAKEAWAYS : Why Zero Trust Claims Fall Short
- 76% of enterprises claim Zero Trust; fewer than 15% pass a NIST-criteria audit (Forrester, 2024)
- Vendors have redefined Zero Trust as a product category, but no single product delivers the full framework
- Zero Trust is a continuous operational posture, not a one-time deployment
- Most implementations cover new systems but leave legacy environments, contractors, and on-premise infrastructure unprotected
- The gap between claiming Zero Trust and doing it creates a false sense of security that is worse than knowing you haven’t started
What Real Zero Trust Actually Looks Like
Genuine Zero Trust architecture is built on five interconnected pillars. Not one of them. All five. The pillars reinforce each other, weaknesses in one create exploitable gaps that the others can’t compensate for.
Pillar 1 : Identity Is Verified Continuously, Not Just at Login
Real Zero Trust treats every access request as if it comes from an untrusted network, even if the user authenticated correctly five minutes ago. This means:
- Multi-factor authentication (MFA) is enforced without exception for all users, all systems, all the time
- Access decisions are made based on real-time context: who is asking, from what device, from what location, at what time, to access what resource
- Privileged access : admin accounts, service accounts, executive accounts : is managed through a Privileged Access Management (PAM) solution with just-in-time access (permissions granted for a specific task, then automatically revoked)
- Sessions are monitored continuously and can be terminated automatically if behaviour becomes anomalous mid-session
Pillar 2 : Devices Are Assessed Before They Get Access
The identity of the user is only half the picture. The device they’re using is the other half.
A legitimate employee logging in from a compromised device is a security event, not a trusted access request. Real Zero Trust requires device health to be assessed : and verified : before access is granted:
- Is the device enrolled in your device management system?
- Is the operating system patched and up to date?
- Is endpoint security software running and current?
- Has the device shown any signs of compromise?
If the device doesn’t pass, access is denied or limited : regardless of whether the user’s credentials are correct.
Pillar 3 : Access Is Limited to Exactly What’s Needed
The principle of least privilege means every user and every system gets the minimum access required to do their job, nothing more. Not “probably enough.” Not “the standard access level.” The minimum.
In practice this means:
- Regular access reviews that identify and remove permissions that are no longer needed
- Role-based access control that is actually maintained, not just set up once and forgotten
- No standing privileged access : admin rights are granted when needed and revoked when the task is done
- Data classified by sensitivity, with access restricted to those with a verified, current need
Pillar 4 : Networks Are Segmented So Breaches Can’t Spread
Even with strong identity and device controls, some breaches will happen. Zero Trust accepts this and designs for it, if an attacker gets into one part of your environment, they should not be able to move freely to any other part.
Micro-segmentation divides your network into small, isolated zones. A breach in one zone cannot automatically reach another zone : each lateral movement attempt is treated as a new access request that must be separately verified.
This is the control that most organisations either skip entirely or implement incompletely. Legacy network environments weren’t designed for segmentation. Retrofitting it is complex and requires significant planning. It’s also one of the most effective single controls for limiting breach damage, which is precisely why attackers spend so much time on lateral movement techniques.
Pillar 5 : Everything Is Logged and Monitored
You cannot defend what you cannot see. Real Zero Trust requires comprehensive logging and monitoring across all five pillars : not just authentication events, but network traffic, data access, device activity, and application behaviour.
This data feeds into your detection and response capability. Anomalies that would be invisible without logging, a user accessing data at 3am, a device querying systems it has never accessed before, an application making unusual outbound connections : become detectable signals.
The logs also provide the audit trail that regulators, insurers, and internal governance teams increasingly require. Zero Trust without logging is security theatre with better marketing.
The Self-Assessment: Are You Doing This or Just Claiming To?
Answer these questions honestly. Each one corresponds to a real Zero Trust requirement : not a vendor checklist, but the actual architectural commitments that distinguish real implementations from claimed ones.
| Question | Yes | Partially | No |
| Is MFA enforced for 100% of users across 100% of systems : including legacy applications? | |||
| Are access policies reviewed and updated at least quarterly? | |||
| Is device health assessed before every access request : not just at first enrolment? | |||
| Do privileged accounts use just-in-time access with automatic revocation? | |||
| Has your organisation completed a full access entitlement review in the last 6 months? | |||
| Is micro-segmentation in place across both cloud and on-premise environments? | |||
| Are legacy systems and contractor access included in your Zero Trust scope? | |||
| Is all network traffic : internal east-west traffic, not just perimeter : monitored? | |||
| Could you produce a complete audit log of who accessed what, when, and from which device, for any date in the last 12 months? | |||
| Has your Zero Trust implementation been tested by an independent red team exercise in the last 12 months? |
Scoring:
- 8–10 Yes answers: Genuine Zero Trust implementation : focus on maintaining and evolving coverage
- 5–7 Yes answers: Meaningful progress with identifiable gaps : prioritise the “No” answers
- 3–4 Yes answers: Product ownership without architecture : foundational gaps need addressing before expanding
- 0–2 Yes answers: The vendor told you something that wasn’t accurate : start with identity and device controls
If you answered “Partially” or “No” to the legacy systems question and the contractor access question, those are your most urgent risks. Attackers will find them before your next audit does.
The Path Forward: How to Build Zero Trust for Real
Real Zero Trust is a multi-year journey, not a procurement event. But the starting point is always the same: an honest assessment of where you actually are, not where your vendor’s marketing materials say you are.
From that honest baseline, a practical Zero Trust roadmap looks like this:
Year 1 : Identity and Device Foundation Get your identity controls right before everything else. Deploy MFA without exceptions. Implement a Privileged Access Management solution. Establish your device management baseline and begin device health assessments at login. These are the highest-impact controls and the necessary foundation for everything that follows.
Year 2 : Access Governance and Segmentation Conduct a full access entitlement review. Implement least-privilege policies. Begin micro-segmentation in your highest-risk environments : start with the systems handling the most sensitive data and expand from there. This phase is slower and harder because it requires touching live systems, but the damage-limitation value is enormous.
Year 3 : Continuous Monitoring and Coverage Expansion Mature your logging and monitoring capabilities. Extend Zero Trust coverage to legacy systems and contractor access : the environments most commonly excluded from early implementations. Commission your first independent red team exercise to test what you’ve built. Begin the cycle of continuous improvement that real Zero Trust requires indefinitely.
The organisations that will have genuine Zero Trust maturity in three years are the ones that start with an honest assessment today : not the ones that buy a product and file the initiative as complete.
Conclusion
Zero Trust is one of the most powerful security frameworks available to enterprise organisations. It is also one of the most widely misrepresented.
The vendors aren’t entirely wrong : the products they sell are useful tools that contribute to a Zero Trust architecture. What they often fail to communicate clearly is that the tools are components, not the architecture itself. Buying components is not the same as building the structure.
The organisations at greatest risk right now are not the ones who know they haven’t implemented Zero Trust. Those organisations know their gaps. The organisations at greatest risk are the ones who believe their vendor’s claim : who think they have Zero Trust protection because they have a Zero Trust product, and who won’t discover the difference until after a breach.
Take the self-assessment above seriously. Be honest about the answers. The uncomfortable ones are the starting point for the work that actually matters.
Frequently Asked Questions
Zero Trust is a security approach built on one rule: never automatically trust anyone or anything, regardless of whether they’re inside or outside your network. Every access request : from an employee, a device, an application, or a system : must be verified based on current context before being granted. Unlike traditional security, which trusts everything inside the corporate network, Zero Trust treats every request as potentially suspicious until proven otherwise.
No : and this is the most important thing to understand about Zero Trust. Zero Trust is a security architecture and philosophy, not a product. Many vendors sell products that contribute to a Zero Trust architecture : identity platforms, endpoint management tools, network segmentation technologies : but no single product delivers Zero Trust by itself. Organisations that buy a “Zero Trust product” and consider the initiative complete have addressed one component of a multi-pillar framework, not the framework itself.
According to NIST’s Zero Trust Architecture guidelines, the five core pillars are: (1) Identity : continuously verifying who is requesting access; (2) Devices : assessing device health before granting access; (3) Access : applying least-privilege principles so users and systems get only the minimum access they need; (4) Network : segmenting the network so a breach in one area can’t spread freely; and (5) Visibility : logging and monitoring all activity across every pillar. Real Zero Trust requires all five, not just one or two.
Traditional perimeter security draws a boundary around your network and trusts everything inside it. If you’re on the corporate network, you’re trusted. Zero Trust rejects this model entirely. Instead of trusting location, Zero Trust verifies every individual access request : regardless of where it comes from : based on identity, device health, and current behaviour. The shift matters because the traditional perimeter no longer exists: employees work from anywhere, data lives in the cloud, and the “inside” of the network now includes coffee shops, home offices, and personal devices.
A genuine Zero Trust implementation is a 2–3 year journey for most enterprise organisations. Year 1 focuses on identity and device controls : the foundation everything else depends on. Year 2 addresses access governance and network segmentation, the harder work of limiting blast radius. Year 3 matures monitoring capabilities and expands coverage to legacy systems and third-party access that were excluded from earlier phases. Organisations that try to compress this into a single procurement cycle or a 6-month project typically end up with one or two pillars in place and significant gaps they aren’t aware of.
NIST’s Special Publication 800-207, Zero Trust Architecture, is the most authoritative published framework for Zero Trust implementation. It defines Zero Trust as a set of principles : not a product or a single technology : and describes the logical components of a Zero Trust architecture in detail. Key NIST requirements include continuous verification of identity and device health, least-privilege access enforcement, comprehensive logging and monitoring, and coverage across all enterprise resources including on-premise and cloud environments. The full document is available free at nist.gov and should be the starting point for any serious Zero Trust programme.
The most reliable test is an independent red team exercise : a controlled simulation in which security professionals attempt to breach your environment using the techniques attackers actually use. Specifically, test for: ability to bypass identity controls, ability to access systems from unmanaged devices, ability to move laterally after gaining initial access, and ability to access systems that are outside your declared Zero Trust scope (legacy applications, contractor access). Self-assessment checklists are a useful starting point, but only an independent exercise tells you whether the architecture holds up under real attack conditions.