
I know, the title of this blog is a bold statement. Most of the time in security, that means marketing. This isn’t that. It comes from spending time inside real Microsoft 365 environments and seeing the same issue over and over again.
Over the last few years, identity has become the front door into every organisation. That’s not a new take, we’ve all been saying it for a while now. But what’s changed is where the real control sits.
In Microsoft 365, that control layer is Conditional Access. It’s the thing deciding who gets in, when MFA is triggered, when access is blocked, and ultimately how exposed your environment actually is.
On paper, it looks solid. You’ve got policies in place, MFA enforced in the right places, location rules, device requirements. You can open the portal, look at your policies, and feel like things are under control.
The reality is most teams don’t actually know how those policies behave when everything is combined.
And that’s the problem.
As soon as you move beyond a simple setup, the number of possible access paths in a tenant explodes. Every combination of user, application, device, location, authentication flow, and policy condition creates a different path into the environment. In most real-world tenants, you’re not dealing with dozens of paths, you’re dealing with thousands or millions.

At that point, trying to reason about access through spreadsheets, one-off What-if? tests, or portal reviews just doesn’t work. It’s not just a tooling problem, it’s a scale and interpretation problem.
There’s a concept Nassim Taleb talks about in The Black Swan around systems that appear stable, right up until they’re not. The risk isn’t in the paths you’ve already considered, it’s in the ones you didn’t know existed.
That’s exactly what we see with Conditional Access. Not obvious gaps, but edge cases created by how policies combine over time.
Most organisations can’t confidently answer a very simple question: if someone has valid credentials, under what conditions can they get in without being challenged?
That’s not a comfortable place to be.
We’ve been working on this problem for a while at Overe, and it’s led us to build something we haven’t really seen done properly elsewhere.
This isn’t about adding another standalone tool or running isolated simulations. It’s about understanding how access behaves across the entire environment, consistently, and as part of a broader system that already manages posture, enforcement, and response.
Instead of testing individual scenarios or relying on predefined assumptions, we analyse the environment as a whole and surface where real-world behaviour doesn’t match what your policies are intended to enforce. The focus isn’t on configuration, it’s on outcome, and on doing that in a way that consistently handles edge cases that are easy to miss.
This isn’t a standalone analysis tool. It’s part of a broader system that continuously evaluates posture, enforcement, and response together.
What this gives you is clarity you can actually act on. You can see whether unintended access paths exist, how broad they are, and whether they represent real risk or something you’ve consciously accepted. More importantly, it gives you a clear path to validate and fix those gaps, not just identify them within the Overe Platform.
And interestingly, the outcome isn’t always “you’ve got a problem”. In some environments, everything lines up and controls are being enforced exactly as expected. That’s just as valuable. It gives you confidence that what you’ve built is actually holding up in practice, not just in theory. This is exactly what we see when Overe is fully utilised by our customers.
We’ve already been running this across a range of customers, from smaller tenants through to much larger environments, and in a lot of cases it’s surfacing things that weren’t obvious beforehand. In others, it’s validating that the current setup is solid. Both are useful, and both lead to better decisions.
Alongside this, we’ve validated the approach with Microsoft MVPs, enterprise security teams, and penetration testers. In multiple cases, gaps were identified live in environments that had already been through traditional reviews. The consistent feedback has been that this level of visibility is typically achieved today through time-intensive, manual analysis, if at all.
For now, we’re offering a limited number of complimentary assessments to existing customers while we continue to refine how this is delivered.
There’s nothing extra to deploy, no new integrations to worry about. If you’re already using Overe, you can request an assessment and we’ll walk you through exactly what we’re seeing and what it means.
This is something we’re bringing directly into the product. The goal is to make this continuous, so you’re not relying on periodic reviews or one-off assessments, but always know how your policies behave as your environment evolves.
It’s not enough to configure Conditional Access and assume it’s doing the right thing. You need to be able to verify it continuously.
In an environment as complex and constantly changing as Microsoft 365, this simply can’t be done manually.
It requires continuous analysis running in the background, consistently validating how policies behave over time. Not as a one-off exercise, but as an ongoing layer of assurance.
Because what breaks these environments isn’t the obvious.
It’s everything else.
Paul Barnes
Co-Founder & CEO, Overe