2026-06-25 · EU Cyber Resilience Act · Industrial

The closest simple model is not iptables.

It is more like airport security.

One checkpoint checks your passport. Another checks your boarding pass. Another checks liquids. Another checks whether you were randomly selected for additional screening. Passing one checkpoint does not exempt you from the others.

What happens when policies "conflict"?

Most Conditional Access conflicts are not really conflicts. They are accumulated requirements.

Case 1: one policy requires MFA, another requires compliant device

Final result:

User must complete MFA and use a compliant device.

No conflict. Both apply.

Case 2: one policy requires MFA, another blocks access

Final result:

Block.

Microsoft's policy enforcement flow says that if a policy is configured with the block grant control, enforcement stops and the user is blocked.

There is no useful sense in which an MFA policy can "win" against a block policy.

Case 3: one policy requires MFA, another requires phishing-resistant MFA

Final result:

User must satisfy the stronger effective requirement.

In practice, this depends on the exact authentication strength and sign-in context. The important point is that Entra does not choose one policy and ignore the other. It evaluates the applicable policies and the user must satisfy the resulting controls.

Case 4: one policy applies to all users, another excludes a group

The exclusion only affects the policy where the exclusion is configured.

This is a common mistake.

If a user is excluded from Policy A but included in Policy B, Policy B still applies. Exclusions are not global bypasses unless you build them that way across every relevant policy. Microsoft also calls out the governance problem around exclusions: when users are excluded, the policy intent is not enforced for them, so exclusions need visibility and regular review.

Includes and excludes are not magic

Inside a policy, includes and excludes decide whether that policy is in scope.

Example:

Policy name:

CA001 - Require MFA for all users

Assignments:

• Include: All users
• Exclude: Break-glass accounts
• Resource: All cloud apps
• Grant: Require MFA

For normal users, the policy applies.

For the excluded emergency accounts, that specific policy does not apply.

But if you have another policy:

CA002 - Block access from unsupported countries

and it includes all users with no emergency-account exclusion, then your break-glass account can still be blocked by CA002.

That may be exactly what you want, or it may lock you out during an incident.

Emergency access accounts need deliberate design. Microsoft recommends creating two or more emergency access accounts, keeping them cloud-only, using strong or passwordless authentication such as FIDO2 or certificate-based authentication, monitoring their sign-ins, and validating them regularly.

Do not treat "excluded from the MFA policy" as "excluded from Conditional Access".

It is not.

"All cloud apps" is powerful and dangerous

The fastest way to break a tenant is to create a policy like this:

• Users: all users
• Resources: all resources
• Grant: block access

That does exactly what it says.

Microsoft explicitly warns against broad "all users / all resources" configurations such as blocking all access, requiring compliant devices for everyone before enrollment is ready, or requiring app protection policies without ensuring users can satisfy them.

The same is true for device requirements.

This sounds reasonable:

Require compliant device for all users and all cloud apps.

But if your admin's device is not compliant, or your users have not enrolled yet, you may block access to the very portals needed to fix the situation.

Conditional Access is not hard because the UI is hard.

It is hard because broad statements have broad consequences.

Why Teams sometimes breaks when you targeted SharePoint

Another source of confusion: users think they are signing in to one app, but Microsoft 365 apps often depend on other services.

Teams is the classic example.

A user opens Teams and thinks:

I am signing in to Teams.

But Teams may need Exchange, SharePoint, Planner, Stream, Whiteboard, and other downstream resources. Microsoft's service dependency documentation calls this out and recommends using the Office 365 app target for common Microsoft 365 policies to avoid service dependency surprises.

So a policy targeted at SharePoint can affect the Teams experience.

That is not Conditional Access being random. It is the application stack being more connected than the user interface suggests.

When troubleshooting, do not only look at the app name the user mentions. Look at the sign-in logs, the resource, the audience, and the policies listed on the Conditional Access tab.

Network locations are public-network signals

Named locations are useful, but they are not internal firewall zones.

For IP-based named locations, Entra sees the public IP address used to reach Microsoft, not the client's private RFC1918 address inside your LAN. Microsoft's network-signal documentation says that for devices on a private network, the relevant address is the public address used by the network to connect to the internet, not the internal client IP.

So do not put 10.0.0.0/8 into a trusted location and expect Entra to know where the laptop sits in your building.

It cannot see that.

It sees the egress path.

Device platform is not a security boundary

Conditional Access can use device platform as a signal.

But be careful.

Microsoft states that device platform detection uses information provided by the device, such as user-agent strings, and that this information is not verified.

So a policy like this:

Block Linux.

may be useful as a rough control, but it is not the same as a cryptographic device trust decision.

For real device trust, use device compliance, hybrid join where appropriate, device filters, and Intune-backed state.

The two tools that reduce guessing

1. What If

The What If tool lets you simulate a sign-in scenario for a user, workload identity, or agent identity and see which policies would apply. It is useful when designing or troubleshooting complex cases. Microsoft notes that only enabled and report-only policies are included in the evaluation, and that the tool does not test Conditional Access service dependencies.

So What If is good.

But it is not the whole truth for Teams-style dependency problems.

2. Sign-in logs

The sign-in logs are where you see what actually happened.

For a failed or surprising sign-in, open:

Entra admin center → Monitoring & health → Sign-in logs → selected sign-in → Conditional Access tab

There you can see which policies applied, which did not, and why. Microsoft's troubleshooting documentation recommends this path for unexpected sign-in outcomes and shows that the Conditional Access tab can identify the policy or policies that caused the interruption.

This is the fastest way to stop guessing.

Report-only is not optional for serious changes

Report-only mode lets you evaluate most Conditional Access policies before enforcing them. During sign-in, report-only policies are evaluated but not enforced, and the results are logged in the sign-in log details.

That is the right deployment pattern:

1. Build the policy.
2. Put it in report-only.
3. Watch who would be affected.
4. Fix exclusions and scope.
5. Move to a pilot group.
6. Then move to production.

The worst pattern is:

1. Build a broad policy.
2. Turn it on.
3. Learn from the outage.

That also works, but the lesson is more expensive.

My practical naming model

I like policy names that tell me four things:

Number - Scope - Condition - Control

Example:

• CA001 - All users - Legacy auth - Block
• CA010 - Admin roles - All apps - Require phishing-resistant MFA
• CA020 - All users - Microsoft 365 - Require MFA
• CA030 - Unmanaged devices - SharePoint - Session restrictions
• CA040 - High sign-in risk - All apps - Require MFA
• CA050 - Unsupported countries - All apps - Block

The number is not priority. It is only sorting.

That distinction matters. A junior admin should not think CA001 runs before CA050. It does not. The number just makes the list readable.

The baseline I would explain to a new admin

Do not start with 30 clever policies.

Start with a few boring ones:

Microsoft also provides Conditional Access templates aligned with common recommended policies, which can be useful as a starting point, not as a substitute for understanding the design.

The mistakes I keep making mentally

The first mistake is thinking:

Why did this policy not apply?

when the better question is:

Which condition was not satisfied?

The second mistake is thinking:

Which policy won?

when the better question is:

Which policies applied, and what combined requirements did they create?

The third mistake is thinking:

I excluded the user from Conditional Access.

when the better statement is:

I excluded the user from this one policy.

The fourth mistake is thinking:

Teams policy.

when the better thought is:

Teams plus its downstream resources.

The fifth mistake is thinking:

Trusted LAN.

when the better thought is:

Public egress IP or Global Secure Access signal.

The mental model that finally sticks

For every sign-in, imagine Entra building a checklist.

Each matching Conditional Access policy adds items to the checklist.

• One policy adds MFA.
• One policy adds compliant device.
• One policy adds terms of use.
• One policy adds session restrictions.
• One policy says block.

The user gets access only if the checklist can be satisfied.

If "block" is on the checklist, the conversation is over.

That is Conditional Access.

Not top-down firewall rules.

A checklist built from every policy that applies.