Most bad Conditional Access decisions start with the wrong mental model.
People talk about Entra ID Conditional Access as if it were a firewall for Microsoft 365. That sounds plausible right up until you try to explain real behaviour with it.
If Conditional Access is a firewall, why does a user sometimes complete first-factor authentication and then get blocked? Why does one app path behave differently from another? Why can a policy change take effect in ways that feel delayed or uneven? Why do multiple policies stack in a way that feels stricter than anyone expected?
The answer is that Conditional Access is not a firewall. It is a policy engine in the Entra sign-in and token issuance path, which turns out to be a much more useful way to think about it.
If you model it like a perimeter control, you end up expecting universal coverage, top-down rule behaviour, and immediate inline enforcement. That is not how the system works, and it is one reason so many Conditional Access estates become confusing over time.
What Conditional Access actually is
At a high level, Conditional Access is Microsoft Entra’s policy engine for deciding what must be true before access is granted and what sort of session should follow.
Microsoft describes the model in straightforward if-then terms:
- if a sign-in request matches a policy’s assignments and conditions
- then Entra applies the configured access controls
That sounds simple, but the details matter.
A Conditional Access policy can evaluate signals such as:
- who the identity is
- what app or resource is being accessed
- what device or device state is involved
- what network or location context is present
- what client app or authentication path is in use
- whether risk signals are present
And the outcome is not just “allow” or “deny.” It can mean:
- block access
- require MFA
- require a compliant device
- require a hybrid joined device
- require a specific authentication strength
- require an approved client or app protection policy
- shape the resulting session with session controls
That is already more nuanced than “MFA policy”, and it is very different from a network firewall.
Where Conditional Access sits in the request path
The easiest way to reason about Conditional Access is to place it in the sign-in flow rather than in some imagined network perimeter.
A simplified version looks like this:
Rendering diagram…
That placement is the key.
Conditional Access is not sitting inline in front of every packet the way a firewall would, and it is not watching every API call in the way an application authorisation layer might. It is attached to authentication and token issuance events, and then it can influence the resulting session.
That is why the phrase “identity firewall” sounds helpful for about ten seconds and then starts misleading people.
Why “not a firewall” changes everything
Once you stop thinking about Conditional Access like a perimeter device, a lot of its strange-seeming behaviour becomes easier to explain.
Coverage is conditional, not universal
Conditional Access only applies where the Entra sign-in and token flow is in a position to evaluate the request meaningfully.
That means coverage depends on things like:
- which resource is actually being targeted
- which authentication path is being used
- whether the relevant client and protocol support the controls you care about
- whether the needed signals exist at evaluation time
So even a policy that looks broad on paper does not automatically behave like a universal inline gate.
Enforcement is tied to sign-in and token behaviour
Because Conditional Access is part of sign-in and token issuance, timing matters.
If a user already has a valid session or token, a policy change does not necessarily feel as immediate as a network deny rule would. Some applications will re-evaluate quickly. Others may continue until a refresh or re-authentication event forces a new decision.
This is one reason admins think Conditional Access “failed” when what actually happened is that they expected inline traffic enforcement from a system that works at a different layer.
Resource and client path matter
The same business service can present more than one access path.
A browser sign-in, a native client, a mobile app, a legacy protocol, or an app-to-app dependency can produce meaningfully different outcomes. That does not mean the engine is inconsistent. It means the path being evaluated is not identical.
Again, this makes sense once you model Conditional Access as a sign-in and session policy layer rather than a universal traffic control.
How policy logic actually works
A lot of confusion comes from how people picture policy matching.
They imagine a top-down list of rules where the first match wins and the rest stop mattering. That is familiar from firewalls, proxies, and other network controls. Conditional Access does not work like that.
Within one policy
A policy applies only if the request matches the configured assignments and conditions.
So inside one policy, the logic is effectively:
- the included user or group must match
- the included target resource must match
- the configured conditions must match
- and exclusions inside that policy override inclusions
That last point matters. Within a single policy, exclude wins.
Across multiple policies
This is the bit that surprises people most.
If multiple Conditional Access policies apply, all of the applicable policies still have to be satisfied.
So if one policy requires MFA and another requires a compliant device, the result is not “whichever one matched first.” The result is that the user needs both MFA and a compliant device.
A simple picture helps here:
Rendering diagram…
That is a much better fit for an identity policy engine than a firewall, but it also means people bring the wrong expectations into design and troubleshooting.
A useful way to phrase it is that Conditional Access is not a rule ladder. It is a set of independently evaluated policies whose applicable requirements accumulate.
Grant controls and session controls are different jobs
Another place people flatten the model too much is treating every control as if it does the same thing.
It doesn’t.
Grant controls
Grant controls answer:
- what must be true before access is granted?
Examples include:
- require MFA
- require a specific authentication strength
- require a compliant device
- require a hybrid joined device
- require an approved client app
- require app protection policy
- block access outright
Inside one policy, there is also an important distinction between:
- require all selected controls
- require one of the selected controls
That AND/OR choice exists inside a policy, but it does not change the fact that multiple applicable policies still accumulate across the set.
Session controls
Session controls answer:
- once access is granted, what kind of session should the user get?
That includes things like:
- sign-in frequency
- persistent browser session behaviour
- app enforced restrictions
- Defender for Cloud Apps-related session shaping
- continuous access evaluation-related behaviour
A quick split looks like this:
Rendering diagram…
That difference matters because a lot of people think Conditional Access ends at “prompt or block.” It doesn’t. It can also shape what the resulting session looks like.
The pieces people keep conflating
A lot of confusion comes from mixing Conditional Access with neighbouring systems and assuming they all do the same job.
Conditional Access vs Security Defaults
Security Defaults are Microsoft’s opinionated baseline protections.
Conditional Access is the customisable policy engine.
Those are not the same design tool, and they should not be reasoned about the same way.
Conditional Access vs Intune compliance
Intune is what determines whether a device is compliant.
Conditional Access can use compliance as a signal or requirement.
That means Intune produces device posture, while Conditional Access consumes it. They are tightly related, but they are not interchangeable.
Conditional Access vs risk engines
Risk signals such as user risk or sign-in risk come from other parts of the Entra and Identity Protection stack.
Conditional Access does not generate those detections. It uses them to decide what to do.
So again, detection and enforcement are separate layers.
Conditional Access vs app authorisation
Conditional Access is good at deciding what must happen before access is granted and how the resulting session should be shaped.
It is not the same thing as fine-grained application authorisation. It is not there to decide every business action an authenticated principal can perform inside an app.
That distinction becomes very important once people start expecting CA to behave like a universal policy engine for everything.
Service dependencies make the model even less firewall-like
This is one of the most underappreciated parts of the whole system.
Microsoft documents service dependencies where one application flow depends on another underlying service, and Conditional Access behaviour surfaces through that dependency in ways that surprise people.
That means someone can think they are signing in to one app and still encounter the effects of policies tied to another service in the dependency chain.
This is not random. It is a consequence of how the resource and token flows actually work.
It is also one reason broad claims like “we tested Teams” are much weaker than they sound unless you understand the services and dependencies involved.
Three examples that explain the model better than theory does
Example 1: MFA for Exchange Online in the browser
A user signs in to Outlook on the web.
Entra sees:
- the identity
- the target resource
- the client path
- the location and device context
Conditional Access evaluates the applicable policies. If MFA is required, the user is prompted before the token is issued.
That does not mean every future mail action is now being evaluated like a packet flow through a firewall. It means the sign-in and session setup passed through Conditional Access.
Example 2: Require compliant device for SharePoint
A user on an unmanaged laptop tries to access SharePoint Online.
Entra evaluates the sign-in. If the policy requires a compliant device and the device state cannot satisfy that requirement, access is blocked or restricted depending on the design.
Again, the point is not “the network path was blocked.” The point is that the sign-in and token issuance path would not grant the required level of access under that context.
Example 3: A policy changes, but users do not all feel it instantly
An admin tightens a policy in the middle of the day.
Some users feel it immediately because they re-authenticate or hit a new token boundary. Others appear to continue working for a while.
If you model Conditional Access like a firewall, this feels broken. If you model it as a sign-in and token policy engine, it is much easier to understand.
The misconceptions worth killing early
There are a handful of ideas that cause a disproportionate amount of trouble:
- Conditional Access is a firewall for Microsoft 365
- Conditional Access is just MFA policy with a nicer UI
- first matching policy wins
- all cloud apps means uniform and immediate control everywhere
- device platform means trusted device identity
- if a user got through, the policy engine must have failed
- if a policy changes, every access path should reflect it instantly
If you clear those up first, the rest of the system starts making more sense.
A better way to think about Conditional Access
A much more useful model is this:
Conditional Access is the layer that asks:
- who is trying to sign in?
- to what resource?
- from what device, network, and client context?
- under what risk posture?
- what controls must be satisfied before Entra will issue or refresh access?
- and what kind of session should exist afterward?
That is a very different question from:
- should this packet flow through the network?
Once you hold that model, a lot of the surprises start to look less mysterious.
What comes next
Once you stop treating Conditional Access like a firewall, another reality becomes obvious.
The system can still feel random, and not because the engine is random. It feels that way because the effective result depends on more than the policy list. Apps change, dependencies change, groups change, exclusions drift, devices fall out of compliance, locations shift, and token/session behaviour adds timing effects.
That is where the next post goes.
Because most Conditional Access gaps do not appear after someone obviously edits the perfect-looking policy. They appear after something nearby changes and the effective access posture moves with it.
Next in the series: Why Conditional Access Feels Random: How Gaps Appear from Unrelated Changes