You’ve turned on MFA, joined devices, chosen the authentication method. But "prompt everyone for MFA all the time" is a blunt shield; it tires users and doesn’t fully stop an attacker. The real need is: ask the right person, under the right condition, for the right proof. The layer that does this is Microsoft Entra Conditional Access.
At its core Conditional Access is an if-then engine: if a user wants to reach this app under this condition, then require this proof (MFA, compliant device, etc.) or block access. Microsoft describes it as the "Zero Trust policy engine" — it combines identity, device, location and risk signals and decides in real time.
In this guide we cover the engine’s parts first, then the baseline policies every org should set up first, one by one. But a warning up front: Conditional Access is the one tool that, misconfigured, can lock you out of your own tenant. So we cover "how to set it up safely" as much as "how to set it up."
First, the basics: how does it work?
A Conditional Access policy has two halves: who/what it applies to (assignments) and what it does (access controls).
Assignments (if — signals):
- User / group / role: who you target; who you exclude.
- Target resource: cloud apps, Azure management, specific apps.
- Conditions: location (IP/country), device platform (Windows/iOS/Android), client app (modern/legacy), sign-in risk and user risk (ID Protection — P2).
Access controls (then — decisions):
- Block — the strictest decision.
- Grant, but with a condition: require MFA, require authentication strength (e.g. phishing-resistant), require a compliant device, require an Entra hybrid joined device, require an approved client app / app protection policy, require password change, require terms of use.
- Session controls: session lifetime, in-app restrictions (with Defender for Cloud Apps).
Important technical note: Conditional Access runs after first-factor authentication; it’s not a front-line/DoS defense, it’s a post-identity access control.
License: Conditional Access requires Entra ID P1 (included in Microsoft 365 Business Premium). Risk-based policies (sign-in/user risk) require P2 / ID Protection. Without a license, use Security Defaults — not granular but a good baseline.
The baseline policies to set up first
The following is the "must-have" set most orgs build their security baseline on. Set them all up in report-only first, excluding break-glass accounts.
- Require MFA for admins. Target privileged roles; require MFA — preferably phishing-resistant authentication strength. The attacker’s most valuable target is an admin account; this is the first policy. For method choice and strong MFA, see Entra MFA configuration.
- Require MFA for all users. Require MFA for all users + all cloud apps. This is also the right way to comply with the mandatory-MFA requirement. Exclude break-glass accounts.
- Block legacy authentication. Old protocols (IMAP/POP/SMTP AUTH) bypass MFA; they’re the main door for password-spray attacks. Target legacy clients and block. Before enabling, check sign-in logs for which accounts still use legacy.
- Require MFA for Azure management. Require MFA for Azure resource management (portal/CLI/PowerShell). Also overlaps with the Phase 2 mandate.
- Require a compliant or hybrid-joined device for key apps. Allow access to sensitive apps only from Intune-compliant or Entra hybrid joined devices. This is where you put device identity to work.
- (P2) Risk-based access. High sign-in risk → require MFA; high user risk → require a secure password change. With ID Protection signals, this is the layer that reacts automatically during an attack.
- Location-based rules. Define trusted networks with named locations; block access from countries you don’t operate in, or require extra MFA. Consider roaming/remote users before aggressive geo-blocking.
Tip: instead of writing from scratch, start with the portal’s policy templates; then adapt to your environment.
Safe setup discipline (not locking yourself out)
- Exclude break-glass (emergency access) accounts from every policy. At least two; protected with a strong method (passkey/CBA), credentials stored securely and tested regularly. Forget these and a bad policy can lock you out completely.
- Report-only first. Run a new policy in report-only before flipping it "On"; see who it affects and how in sign-in logs.
- Simulate with What If. Test what a policy would do for a specific user/app/condition without touching production.
- Pilot → staged → general. Enable on a small group first, then roll out. Don’t flip "On" for the whole tenant at once.
Also: keep your policies simple. Dozens of overlapping policies become an untroubleshootable tangle. A few, purposeful policies > many overlapping ones.
Field pitfalls
- Skipping the break-glass exclusion. The number-one way to lock yourself out with Conditional Access. Prepare the accounts first, then write policies.
- Blocking legacy auth without looking. See who uses it first; block directly and an old app/multifunction printer/service account can suddenly drop.
- Skipping report-only. Saying "I’m sure anyway" and flipping "On" is the most expensive habit.
- Over-aggressive geo-blocking. You lock out a traveling admin/VPN user. Instead of block, "extra MFA from this location" is often more correct.
- Policy inflation. Writing a separate policy for every need. Start with a template/baseline set, add as needed.
- Expecting risk-based policy without a license. Sign-in/user risk needs P2/ID Protection; these rules don’t work on P1.
Conclusion
Conditional Access is the brain of Entra security: it ties MFA, device identity and risk signals to "who, where, under what condition." The right start isn’t complex rules from scratch; it’s a few baseline policies — MFA for admins and all users, blocking legacy auth, MFA for Azure management, compliant/hybrid-joined device for sensitive apps, and (with P2) risk-based access. Build them all with break-glass exclusion, report-only and What If discipline; pilot first, then general. To bring SCCM-managed devices into this control via compliance, see SCCM to Intune co-management.
