“Zero Trust” has become one of those terms that sounds impressive in a boardroom but often means very different things depending on who you ask.
For some, it’s MFA.
For others, it’s Conditional Access.
For vendors, it’s a feature set.
And that’s exactly the problem.
In most environments I’ve worked in, Zero Trust isn’t being implemented—it’s being approximated. A few controls are enabled, a few policies are configured, and the assumption is that the organisation is now operating under a Zero Trust model.
But when you actually test those environments—when you look at real access paths, token behaviour, legacy protocols, and application integrations—you quickly realise something:
👉 The core principles of Zero Trust aren’t being enforced consistently.
This matters because Zero Trust isn’t about enabling features. It’s about fundamentally changing how access is granted, validated, and monitored.
In this article, I’m not going to explain what Zero Trust is.
Instead, I’ll focus on:
- What organisations consistently get wrong
- The gaps that exist in real-world implementations
- Why those gaps matter from an attacker’s perspective
- How to fix them in a practical, achievable way
Quick Fix Summary
If your Zero Trust implementation isn’t delivering real security:
- ✅ Enforce Conditional Access across all access paths (including legacy protocols)
- ✅ Eliminate persistent access (tokens, service principals, OAuth apps)
- ✅ Treat identity as your primary security boundary—not the network
- ✅ Continuously validate device and session state—not just at login
- ✅ Audit and remove exceptions aggressively
The Core Misunderstanding: Zero Trust Is Not a Product
One of the biggest misconceptions is that Zero Trust can be “implemented” by turning on a set of features.
It can’t.
Zero Trust is a model, and more importantly, a discipline.
It requires:
- Continuous validation
- Minimal implicit trust
- Strong identity controls
- Ongoing monitoring
What I see instead is:
- MFA enabled → “We’re Zero Trust”
- Conditional Access configured → “Done”
That’s not Zero Trust—that’s a starting point.
Where Zero Trust Implementations Actually Break Down
1. Conditional Access Isn’t Applied Everywhere
This is probably the most common gap.
Conditional Access policies are configured—but:
- Legacy authentication is still enabled
- Service accounts are excluded
- Certain applications bypass controls
Real-World Example
An environment had:
- MFA enforced via Conditional Access
- Strong device compliance policies
But:
- IMAP/POP was still enabled
- Legacy authentication bypassed MFA
Result:
👉 Account compromise without triggering modern controls
How to Check for Legacy Authentication
Get-AuthenticationPolicy
Or review in Entra:
- Sign-in logs → Filter by “Client App” → Look for legacy protocols
2. Identity Is Secured—But Access Isn’t
Another common issue is focusing heavily on identity protection, but ignoring what happens after authentication.
Once a user is authenticated:
- Access is often broad
- Permissions are rarely re-evaluated
- Sessions persist longer than expected
Zero Trust requires:
👉 Continuous validation—not just login checks
3. Tokens and Sessions Are Trusted Too Long
This is a big one—and often overlooked.
Users authenticate once, and tokens:
- Persist for hours (or longer)
- Are reused without re-evaluation
In some cases:
- MFA is never re-triggered
- Conditional Access isn’t re-applied
From an attacker’s perspective, this is gold.
Where This Becomes Risky
- Token theft scenarios
- Session hijacking
- Compromised devices
Even with MFA, access can persist.
4. Service Principals and OAuth Apps Are Ignored
Most Zero Trust discussions focus on users.
But in modern environments, applications often have:
- Equal or greater access
Service principals and OAuth apps:
- Operate outside normal user controls
- Often have persistent permissions
- Are rarely reviewed
Example Check
Connect-MgGraph -Scopes "Application.Read.All"Get-MgServicePrincipal | Select DisplayName, AppId
You’ll often find:
- Unknown apps
- Over-permissioned integrations
- No ownership
5. Devices Are Assumed Trusted (When They Shouldn’t Be)
Even with Intune in place, many environments:
- Trust compliant devices too broadly
- Don’t validate real-time state
- Allow exceptions that weaken controls
Zero Trust isn’t:
👉 “Trusted device = full access”
It’s:
👉 “Continuously validated device + user + context”
6. Exceptions Slowly Kill the Model
This is where most Zero Trust strategies quietly fail.
Over time:
- Users get excluded
- Apps get exceptions
- Policies get relaxed
Each exception seems justified.
But collectively?
👉 They reintroduce trust into a Zero Trust model.
How to Fix These Gaps (Without Starting Over)
This is where you can make real improvements without rebuilding everything.
Step 1: Audit All Access Paths
Start by identifying:
- Legacy protocols
- OAuth apps
- Service principals
- Conditional Access exclusions
You can’t fix what you don’t see.
Step 2: Enforce Conditional Access Consistently
Ensure policies apply to:
- All users (with minimal exceptions)
- All cloud apps
- All authentication methods
This is foundational.
Step 3: Reduce Session Lifetime and Enforce Revalidation
In Entra:
- Configure sign-in frequency
- Apply session controls
This limits:
- Token persistence
- Risk from compromised sessions
Step 4: Review and Reduce Permissions
Focus on:
- Least privilege
- Removing unused access
- Assigning ownership
This applies to:
- Users
- Apps
- Service principals
Step 5: Continuously Monitor and Adapt
Zero Trust isn’t static.
Regularly review:
- Sign-in logs
- App usage
- Access patterns
Because your environment—and attacker techniques—will evolve.
What Zero Trust Looks Like When It’s Done Properly
It’s not perfect.
It’s not frictionless.
But it is:
- Consistent
- Measurable
- Continuously improving
And most importantly:
👉 It reflects how your environment actually operates—not just how it’s supposed to.
Additional Tips / Pro Tips
Start with identity—but don’t stop there
Identity is the foundation, not the full solution.
Focus on reducing implicit trust
Every assumption should be challenged.
Test your controls regularly
Try to bypass them—you’ll learn more than from reports.
Keep exceptions visible and reviewed
They’re necessary—but dangerous if unmanaged.
Warnings
Zero Trust can create a false sense of security
Especially if implemented superficially.
Overcomplicating policies can backfire
Complexity often leads to misconfiguration.
Ignoring non-user access is a major gap
Apps and services are part of your attack surface.
FAQ Section
Why do most Zero Trust implementations fail?
Because they focus on enabling features rather than enforcing consistent access controls across all access paths.
Is MFA enough for Zero Trust?
No. MFA is a component, but Zero Trust requires continuous validation and broader access control.
What is the biggest gap in Zero Trust deployments?
Unmanaged access paths such as legacy authentication, OAuth apps, and service principals.
How do I validate my Zero Trust implementation?
By testing access scenarios, reviewing logs, and identifying gaps in enforcement.
Can Zero Trust be fully achieved?
Not completely—it’s an ongoing process rather than a fixed state.
Conclusion / Actionable Takeaways
Zero Trust isn’t misunderstood because it’s complicated.
It’s misunderstood because it’s often simplified.
And in doing so, organisations miss the point.
👉 Zero Trust isn’t about enabling controls—it’s about removing assumptions.
What to do next:
- Audit your environment for hidden access paths
- Remove or reduce exceptions
- Enforce Conditional Access consistently
- Review application and service permissions
- Continuously test and validate controls
From experience, the difference between a “Zero Trust environment” and a secure one comes down to one thing:
👉 How honest you are about the gaps that still exist.
Last Updated
April 2026 – Reflects current Microsoft 365, Entra ID, and modern Zero Trust implementation challenges.
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.