2026-05-17 · Microsoft Entra · Conditional Access

Conditional Access für Leute, die in Firewall-Regeln denken

Ich sehe immer wieder gute Admins, die Conditional Access leicht falsch verstehen.

Nicht weil das Feature unmöglich wäre. Sondern weil das mentale Modell falsch ist.

Wenn du aus Firewalls, Routing, Proxy-Regeln, iptables oder alten Exchange Transport Rules kommst, suchst du instinktiv nach Reihenfolge:

Regel 1 matcht, mach das.
Regel 2 matcht, mach jenes.
First match wins.
Vielleicht überschreibt ein späteres Deny ein früheres Allow.
Vielleicht behebt das Hochziehen der Regel das Problem.

Conditional Access funktioniert nicht so.

Es ist kein Paketfilter. Es ist kein Top-Down-Regelwerk. Es ist kein „first match wins". Es ist eine Policy-Evaluation-Engine, die einen Sign-in nimmt, Fakten über diesen Sign-in sammelt, alle passenden Policies findet und dann das kombinierte Ergebnis durchsetzt. Microsoft beschreibt Conditional Access als Entras Zero-Trust-Policy-Engine und als ein „if-then"-System: wenn ein Nutzer auf eine Ressource zugreifen will, dann muss er die konfigurierten Access Controls erfüllen. Es wird außerdem nach der ersten Authentifizierung durchgesetzt, nicht davor.

Dieser eine Unterschied erklärt die meiste Verwirrung.

Die Kurzfassung

Für einen Sign-in fragt Entra ungefähr Folgendes:

Welche aktivierten Conditional-Access-Policies matchen diesen Nutzer, diese Ressource, diese App, dieses Gerät, diesen Standort, diesen Risk-State und diesen Client-Typ?

Dann:

Was fordert jede passende Policy?

Dann:

Kann der Sign-in das alles erfüllen?

Es gibt keine Policy-Priorität.

Es gibt keine „Allow"-Policy, die eine andere Policy überschreibt.

Es gibt kein „verschiebe diese Policy über die andere".

Wenn zwei Policies greifen, zählen beide. Wenn eine MFA verlangt und eine andere ein konformes Gerät, braucht der Nutzer beides. Microsoft sagt das explizit: mehrere Conditional-Access-Policies können gleichzeitig auf einen Nutzer wirken, und alle müssen erfüllt werden.

Eine Policy hat zwei Hälften

Eine Conditional-Access-Policy versteht sich leichter, wenn du sie in zwei Teile zerlegst.

1. Assignments: wann greift die Policy?

Das ist die Matching-Logik.

Assignments beantworten:

Welche Nutzer, Gruppen, Rollen, Gäste, Workload Identities oder Agents?
Welche Cloud-App, User-Action, Authentication Context oder Ressource?
Welches Netzwerk oder welche Named Location?
Welche Device-Plattform?
Welche Client-App?
Welche Risk-Condition?
Welcher Device-Filter?

Sieh das als „Scope" der Policy.

Eine Policy greift nur, wenn die konfigurierten Bedingungen erfüllt sind. Microsofts Troubleshooting-Doku sagt, dass Conditional-Access-Policies nur greifen, wenn alle Bedingungen erfüllt oder nicht konfiguriert sind.

Deshalb ist „policy not applied" im Sign-in-Log nicht automatisch ein Problem. Es kann einfach heißen, dass eine Bedingung nicht gematcht hat.

Beispiel:

Policy: gilt für alle Nutzer.
Ziel-Ressource: SharePoint.
Bedingung: nur außerhalb von Trusted Locations.
Nutzer meldet sich von der Büro-IP an SharePoint an.
Ergebnis: policy not applied.

Das ist korrekt. Die Location-Bedingung hat nicht gematcht.

2. Access Controls: was passiert, wenn sie greift?

Das ist die Enforcement-Logik.

Access Controls beantworten:

Access blockieren?
MFA verlangen?
Authentication Strength verlangen?
Konformes Gerät verlangen?
Hybrid-joined Gerät verlangen?
App Protection Policy verlangen?
Terms of Use verlangen?
Session Controls anwenden?

Grant Controls lassen sich kombinieren. Standardmäßig verlangen mehrere ausgewählte Grant Controls, dass alle erfüllt sein müssen. Du kannst auf „eines der ausgewählten Controls" umstellen, aber nur innerhalb derselben Policy.

Dieses Detail ist wichtig.

Innerhalb einer Policy:

MFA ODER konformes Gerät

ist möglich, wenn du „Require one of the selected controls" setzt.

Über zwei Policies hinweg:

Policy A verlangt MFA
Policy B verlangt konformes Gerät

ergibt:

MFA UND konformes Gerät

weil beide Policies erfüllt sein müssen.

Genau dort werden viele Designs versehentlich strenger als beabsichtigt.

Wo die Firewall-Analogie zerbricht

Eine Firewall-Regel sagt meist sowas wie:

Source, Destination, Protocol, Port, Action.

Conditional Access sagt eher:

Sammle für diesen Sign-in-Kontext alle passenden Anforderungen der Organisation, und entscheide dann, ob der Nutzer sie alle erfüllen kann.

Das heißt: diese Firewall-Instinkte führen dich in die Irre:

Firewall-Instinkt	Conditional-Access-Realität
Regel-Reihenfolge zählt	Policy-Reihenfolge zählt nicht
First match wins	Alle passenden Policies greifen
Allow überschreibt Deny bei richtiger Sortierung	Eine greifende Block-Policy blockt
Source-IP ist das Hauptsignal	Identity, Device, App, Risk, Location, Client und Session zählen alle
Eine Regel erlaubt oder verbietet Traffic	Eine Policy kann erst nach Zusatz-Anforderungen erlauben
Testen heißt Pakete schicken	Testen heißt What If, Sign-in Logs und Report-only-Auswirkung prüfen

Das nächstliegende einfache Modell ist nicht iptables.

Es ist eher Flughafensicherheit.

Ein Checkpoint prüft den Pass. Einer das Ticket. Einer Flüssigkeiten. Einer prüft, ob du zufällig für eine zusätzliche Kontrolle gezogen wurdest. An einem Checkpoint vorbeizukommen befreit dich nicht von den anderen.

Was passiert, wenn Policies „kollidieren"?

Die meisten Conditional-Access-„Konflikte" sind keine echten Konflikte. Es sind aufaddierte Anforderungen.

Fall 1: eine Policy verlangt MFA, eine andere ein konformes Gerät

Endergebnis:

Nutzer muss MFA abschließen und ein konformes Gerät nutzen.

Kein Konflikt. Beide greifen.

Fall 2: eine Policy verlangt MFA, eine andere blockt Access

Endergebnis:

Block.

Microsofts Policy-Enforcement-Flow sagt: wenn eine Policy die Block-Grant-Control hat, stoppt die Enforcement und der Nutzer wird geblockt.

Es gibt keinen sinnvollen Weg, in dem eine MFA-Policy gegen eine Block-Policy „gewinnen" könnte.

Fall 3: eine Policy verlangt MFA, eine andere phishing-resistente MFA

Endergebnis:

Nutzer muss die stärkere effektive Anforderung erfüllen.

In der Praxis hängt das von der genauen Authentication Strength und vom Sign-in-Kontext ab. Der Punkt ist: Entra wählt nicht eine Policy aus und ignoriert die andere. Es wertet die greifenden Policies aus, und der Nutzer muss die resultierenden Controls erfüllen.

Fall 4: eine Policy gilt für alle Nutzer, eine andere schließt eine Gruppe aus

Der Ausschluss wirkt nur in der Policy, in der er konfiguriert ist.

Das ist ein häufiger Fehler.

Wenn ein Nutzer aus Policy A ausgeschlossen, aber in Policy B enthalten ist, greift Policy B trotzdem. Exclusions sind keine globalen Bypässe, außer du baust sie über alle relevanten Policies hinweg ein. Microsoft adressiert auch das Governance-Problem rund um Exclusions: wenn Nutzer ausgeschlossen werden, wird die Policy-Absicht für sie nicht durchgesetzt, deshalb brauchen Exclusions Sichtbarkeit und regelmäßiges Review.

Includes und Excludes sind keine Magie

Innerhalb einer Policy entscheiden Includes und Excludes, ob diese Policy im Scope ist.

Beispiel:

Policy-Name:

CA001 - MFA für alle Nutzer verlangen

Assignments:

Include: Alle Nutzer
Exclude: Break-Glass-Accounts
Ressource: Alle Cloud-Apps
Grant: MFA verlangen

Für normale Nutzer greift die Policy.

Für die ausgeschlossenen Notfall-Accounts greift genau diese Policy nicht.

Aber wenn du eine weitere Policy hast:

CA002 - Access aus nicht unterstützten Ländern blocken

und die alle Nutzer ohne Notfall-Account-Exclusion einschließt, kann dein Break-Glass-Account trotzdem von CA002 geblockt werden.

Das kann genau das sein, was du willst. Es kann dich aber auch im Vorfall aussperren.

Emergency-Access-Accounts brauchen bewusstes Design. Microsoft empfiehlt: mindestens zwei Emergency-Access-Accounts anlegen, cloud-only halten, mit starker oder passwordless Authentifizierung wie FIDO2 oder zertifikatsbasierter Authentifizierung absichern, Sign-ins überwachen und regelmäßig validieren.

Behandle „aus der MFA-Policy ausgeschlossen" nicht als „aus Conditional Access ausgeschlossen".

Das ist es nicht.

„All cloud apps" ist mächtig und gefährlich

Der schnellste Weg, einen Tenant kaputt zu machen, ist eine Policy wie diese:

Nutzer: alle Nutzer
Ressourcen: alle Ressourcen
Grant: Access blockieren

Sie macht genau, was sie sagt.

Microsoft warnt explizit vor breiten „All users / all resources"-Konfigurationen, etwa kompletten Block, Compliance-Gerät-Pflicht für alle bevor das Enrollment bereit ist, oder App-Protection-Pflicht ohne dass die Nutzer sie erfüllen können.

Dasselbe gilt für Geräte-Anforderungen.

Das klingt vernünftig:

Konformes Gerät für alle Nutzer und alle Cloud-Apps verlangen.

Aber wenn das Gerät eines Admins nicht konform ist oder Nutzer noch nicht enrolled sind, blockst du genau die Portale, mit denen du die Situation beheben könntest.

Conditional Access ist nicht schwer, weil die UI schwer wäre.

Es ist schwer, weil breite Aussagen breite Folgen haben.

Warum Teams manchmal kaputt geht, obwohl du SharePoint targetest

Noch eine Verwirrungsquelle: Nutzer denken, sie melden sich an einer App an, aber Microsoft-365-Apps hängen oft von anderen Services ab.

Teams ist das klassische Beispiel.

Ein Nutzer öffnet Teams und denkt:

Ich melde mich an Teams an.

Aber Teams braucht je nach Funktion Exchange, SharePoint, Planner, Stream, Whiteboard und weitere nachgelagerte Ressourcen. Microsofts Service-Dependency-Doku weist darauf hin und empfiehlt, für gängige Microsoft-365-Policies das Office-365-App-Target zu nutzen, um Überraschungen zu vermeiden.

Eine Policy auf SharePoint kann also die Teams-Experience beeinflussen.

Das ist kein zufälliges Verhalten von Conditional Access. Es ist der App-Stack, der enger verzahnt ist als die UI vermuten lässt.

Beim Troubleshooten nicht nur auf den App-Namen schauen, den der Nutzer nennt. Sign-in Log, Resource, Audience und die Policies im Conditional-Access-Tab anschauen.

Network Locations sind Public-Network-Signale

Named Locations sind nützlich, aber keine internen Firewall-Zonen.

Für IP-basierte Named Locations sieht Entra die öffentliche IP, mit der du Microsoft erreichst, nicht die private RFC1918-Adresse im LAN. Microsofts Network-Signal-Doku sagt: für Geräte in einem privaten Netz ist die relevante Adresse die öffentliche Adresse, mit der das Netz ins Internet geht, nicht die interne Client-IP.

Also: nicht 10.0.0.0/8 in eine Trusted Location packen und erwarten, dass Entra weiß, wo dein Laptop im Gebäude sitzt.

Das sieht es nicht.

Es sieht den Egress-Pfad.

Device-Plattform ist keine Sicherheitsgrenze

Conditional Access kann Device-Plattform als Signal nutzen.

Aber Vorsicht.

Microsoft sagt: die Plattform-Erkennung nutzt vom Gerät geliefertes Material, etwa User-Agent-Strings, und das ist nicht verifiziert.

Eine Policy wie:

Linux blocken.

ist als grobe Kontrolle nützlich, aber kein kryptografisch belastbares Device-Trust.

Für echtes Device-Trust: Device-Compliance, Hybrid Join wo passend, Device-Filter und Intune-gestützter State.

Die zwei Tools, die Ratespielchen reduzieren

1. What If

Das What-If-Tool lässt dich einen Sign-in-Fall für einen Nutzer, eine Workload Identity oder eine Agent Identity simulieren und sehen, welche Policies greifen würden. Es hilft beim Design und beim Troubleshooten komplexerer Fälle. Microsoft weist darauf hin, dass nur aktivierte und Report-only-Policies in die Evaluation einfließen und dass das Tool keine Conditional-Access-Service-Dependencies testet.

What If ist also gut.

Aber nicht die ganze Wahrheit bei Teams-typischen Dependency-Problemen.

2. Sign-in Logs

In den Sign-in Logs siehst du, was wirklich passiert ist.

Für einen fehlgeschlagenen oder unerwarteten Sign-in:

Entra Admin Center → Monitoring & health → Sign-in logs → ausgewählter Sign-in → Conditional Access-Tab

Dort siehst du, welche Policies griffen, welche nicht und warum. Microsofts Troubleshooting-Doku empfiehlt genau diesen Weg für unerwartete Sign-in-Ergebnisse und zeigt, dass der Conditional-Access-Tab die Policy oder Policies identifiziert, die die Unterbrechung verursacht haben.

Das ist der schnellste Weg, das Raten zu beenden.

Report-only ist nicht optional bei ernsten Änderungen

Im Report-only-Modus kannst du die meisten Conditional-Access-Policies prüfen, bevor du sie durchsetzt. Während des Sign-ins werden Report-only-Policies ausgewertet, aber nicht erzwungen, und die Ergebnisse landen in den Sign-in-Log-Details.

Das ist das richtige Rollout-Muster:

Policy bauen.
In Report-only stellen.
Schauen, wer betroffen wäre.
Exclusions und Scope korrigieren.
Auf eine Pilotgruppe ausrollen.
Dann in Produktion.

Das schlechteste Muster ist:

Breite Policy bauen.
Anschalten.
Aus dem Ausfall lernen.

Funktioniert auch. Die Lektion ist nur teurer.

Mein praktisches Namensschema

Ich mag Policy-Namen, die mir vier Dinge sagen:

Nummer - Scope - Bedingung - Control

Beispiel:

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

Die Nummer ist keine Priorität. Sie ist nur Sortierung.

Diese Unterscheidung ist wichtig. Ein Junior-Admin sollte nicht denken, CA001 läuft vor CA050. Tut es nicht. Die Nummer macht nur die Liste lesbar.

Die Baseline, die ich einem neuen Admin erklären würde

Fang nicht mit 30 cleveren Policies an.

Fang mit ein paar langweiligen an:

Policy	Zweck
Legacy Authentication blocken	Alte Clients können moderne Controls nicht sauber
Starke MFA für Admins	Admin-Kompromittierung tut mehr weh
MFA für Nutzer	Basis-Identitätsschutz
Konformes oder verwaltetes Gerät für sensible Apps	Device-Trust dort, wo es zählt
Risk-basierte Sign-ins einschränken	Wenn ihr Entra ID Protection habt
Session-Restrictions für unverwaltete Geräte	Browser-Zugriff erlauben, ohne das volle Data-Leak-Risiko
Standorte blocken, aus denen ihr nie arbeitet	Nützlich, aber Reisen und False Positives einplanen
Emergency-Access-Accounts anders behandeln	Sie sind keine normalen Admin-Accounts

Microsoft liefert außerdem Conditional-Access-Templates, die an gängige Empfehlungen angelehnt sind. Als Startpunkt gut, nicht als Ersatz dafür, das Design zu verstehen.

Die Denkfehler, die ich selber wieder mache

Der erste Fehler ist die Frage:

Warum hat diese Policy nicht gegriffen?

Die bessere Frage ist:

Welche Bedingung war nicht erfüllt?

Der zweite Fehler ist die Frage:

Welche Policy hat gewonnen?

Die bessere Frage ist:

Welche Policies griffen, und welche kombinierten Anforderungen entstanden daraus?

Der dritte Fehler ist der Satz:

Ich habe den Nutzer aus Conditional Access ausgeschlossen.

Der bessere Satz ist:

Ich habe den Nutzer aus dieser einen Policy ausgeschlossen.

Der vierte Fehler ist der Gedanke:

Teams-Policy.

Der bessere Gedanke ist:

Teams plus seine nachgelagerten Ressourcen.

Der fünfte Fehler ist der Gedanke:

Trusted LAN.

Der bessere Gedanke ist:

Public-Egress-IP oder Global-Secure-Access-Signal.

Das mentale Modell, das endlich hängen bleibt

Stell dir für jeden Sign-in vor, dass Entra eine Checkliste baut.

Jede greifende Conditional-Access-Policy fügt der Checkliste Punkte hinzu.

Eine Policy fügt MFA hinzu.
Eine fügt konformes Gerät hinzu.
Eine fügt Terms of Use hinzu.
Eine fügt Session-Restrictions hinzu.
Eine sagt block.

Der Nutzer bekommt nur Zugriff, wenn die Checkliste erfüllbar ist.

Steht „block" auf der Liste, ist das Gespräch beendet.

Das ist Conditional Access.

Keine Top-Down-Firewall-Regeln.

Eine Checkliste, gebaut aus jeder Policy, die greift.

Conditional Access for people who think in firewall rules

I keep seeing smart admins get Conditional Access slightly wrong.

Not because the feature is impossible. It is mostly because the mental model is wrong.

If you come from firewalls, routing, proxy rules, iptables, or old Exchange transport rules, you instinctively look for order:

Rule 1 matches, do this.
Rule 2 matches, do that.
First match wins.
Maybe a later deny overrides an earlier allow.
Maybe moving the rule up fixes it.

Conditional Access does not work like that.

It is not a packet filter. It is not a top-down ruleset. It is not "first match wins". It is a policy evaluation engine that looks at a sign-in, collects facts about that sign-in, finds every policy that applies, and then enforces the combined result. Microsoft describes Conditional Access as Entra's Zero Trust policy engine and as an "if-then" system: if a user wants to access a resource, then they must satisfy the configured access controls. It is also enforced after first-factor authentication, not before it.

That one difference explains most of the confusion.

The short version

For one sign-in, Entra asks roughly this:

Which enabled Conditional Access policies match this user, this resource, this app, this device, this location, this risk state, and this client type?

Then:

What does every matching policy require?

Then:

Can the sign-in satisfy all of that?

There is no policy priority.

There is no "allow" policy that cancels another policy.

There is no "move this policy above the other one".

If two policies apply, both matter. If one matching policy requires MFA and another matching policy requires a compliant device, the user needs MFA and a compliant device. Microsoft states this explicitly: multiple Conditional Access policies can apply to a user at the same time, and all applicable policies must be satisfied.

The policy has two halves

A Conditional Access policy is easier to understand if you split it into two parts.

1. Assignments: when does this policy apply?

This is the matching logic.

Assignments answer:

Which users, groups, roles, guests, workload identities, or agents?
Which cloud app, user action, authentication context, or resource?
Which network or named location?
Which device platform?
Which client app?
Which risk condition?
Which device filter?

Think of this as the "scope" of the policy.

A policy only applies when the configured assignment conditions are satisfied. Microsoft's troubleshooting guidance says Conditional Access policies only apply when all conditions are satisfied or not configured.

That is why "policy not applied" in the sign-in log is not automatically a problem. It can simply mean one of the conditions did not match.

Example:

Policy says: apply to all users.
Target resource: SharePoint.
Condition: only outside trusted locations.
User signs in to SharePoint from the office IP.
Result: policy not applied.

That is correct. The location condition did not match.

2. Access controls: what happens when it applies?

This is the enforcement logic.

Access controls answer:

Block access?
Require MFA?
Require authentication strength?
Require compliant device?
Require hybrid joined device?
Require app protection policy?
Require terms of use?
Apply session controls?

Grant controls can be combined. By default, multiple selected grant controls require all selected controls. You can change that to require one of the selected controls, but that is inside one policy only.

That detail matters.

Inside one policy:

MFA OR compliant device

is possible if you configure "Require one of the selected controls".

Across two policies:

Policy A requires MFA
Policy B requires compliant device

means:

MFA AND compliant device

because both policies must be satisfied.

That is where many designs accidentally become stricter than intended.

The firewall analogy breaks here

A firewall rule usually says something like:

Source, destination, protocol, port, action.

Conditional Access says something more like:

For this sign-in context, collect every matching organizational requirement, then decide whether the user can satisfy all of them.

That means these firewall instincts can mislead you:

Firewall instinct	Conditional Access reality
Rule order matters	Policy order does not matter
First match wins	All matching policies apply
Allow can override deny if ordered correctly	A matching block policy blocks
Source IP is the main signal	Identity, device, app, risk, location, client, and session all matter
A rule either permits or denies traffic	A policy can permit only after extra requirements are satisfied
Testing means sending packets	Testing means checking What If, sign-in logs, and report-only impact

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:

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

The worst pattern is:

Build a broad policy.
Turn it on.
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:

Policy	Purpose
Block legacy authentication	Old clients cannot do modern controls properly
Require strong MFA for admins	Admin compromise hurts more
Require MFA for users	Basic identity protection
Require compliant or managed device for sensitive apps	Device trust where it matters
Restrict risky sign-ins	Use risk signals if you have Entra ID Protection
Apply session restrictions for unmanaged devices	Allow browser access without allowing full data leakage
Block locations you never operate from	Useful, but handle travel and false positives
Protect emergency access accounts differently	They are not normal admin accounts

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.