Why a baseline, and not “just MFA”
Turning on MFA for every user is the first thing any tenant should do — and it is exactly where most stop. The problem is that MFA, on its own, is a single control, and attackers don’t attack the control: they attack what surrounds it.
Legacy authentication (IMAP, POP, SMTP AUTH, older Exchange ActiveSync) doesn’t support modern authentication, so MFA evaluation simply never happens. A stolen session token stays valid for hours or days after MFA was satisfied. An unmanaged laptop reaches the same data as a corporate device. And if an attacker manages to register their own MFA method on an account, MFA starts working for them.
Conditional Access is the policy engine that closes each of these gaps. A baseline is a small, deliberate set of policies that together cover what a single control cannot. This post describes 10 policies that form a solid baseline for any M365 tenant, with the configuration, the licensing prerequisite, and how to test each one.
Summary of the 10 policies:
| # | Policy | Target | Control | License |
| 1 | Require MFA for all users | All users / all apps | Grant: MFA | P1 |
| 2 | MFA + compliant device (admins) | Admin roles | Grant: MFA + compliant | P1 + Intune |
| 3 | Block legacy authentication | All users / legacy clients | Grant: Block | P1 |
| 4 | MFA on risky sign-ins | Sign-in risk High/Medium | Grant: MFA | P2 |
| 5 | Password change on risky users | User risk High | Grant: Pwd change + MFA | P2 + SSPR |
| 6 | Restrict risky locations | Named locations | Grant: Block / MFA | P1 |
| 7 | Block unmanaged devices | All / sensitive apps | Grant: compliant OR hybrid | P1 + Intune |
| 8 | Reduce session exposure | Admins / all | Session: sign-in freq + no persist | P1 |
| 9 | Protect security-info registration | Register security info | Grant: MFA (+ trusted / TAP) | P1 |
| 10 | App protection (MAM) on mobile | iOS / Android | Grant: app protection policy | P1 + Intune |
2Prerequisites and licensing
Conditional Access isn’t free, and some policies require more than others. Before you start, confirm:
- Entra ID P1 — prerequisite for using Conditional Access. Covers policies 1, 2, 3, 6, 7, 8, 9 and 10.
- Entra ID P2 — required for the risk-based policies (4, sign-in risk, and 5, user risk), which depend on Identity Protection.
- Microsoft Intune — required for device compliance (policies 2 and 7) and for App Protection Policies / MAM (policy 10).
- Security Defaults OFF — the tenant cannot have Security Defaults enabled to use Conditional Access. Disable it under Entra ID > Properties > Manage security defaults before creating the policies.
If you only have P1, you can still implement 8 of the 10 policies — the risk-based ones (4 and 5) wait until P2 is available.
Before you turn anything on: break-glass and report-only
Two rules come before the 10 policies. Skipping either one is how you lock yourself out of your own tenant.
Break-glass accounts (emergency access)
- Create 2 cloud-only Global Administrator accounts, used exclusively for emergencies, in an onmicrosoft.com domain.
- Long, random passwords — ideally backed by FIDO2 — stored offline in a physically secure location. Generating and storing those passwords is on you, not on any tool.
- Excluded from EVERY Conditional Access policy. No exceptions. If a new policy is created, it excludes the break-glass accounts too.
- Monitored: create an alert in Sentinel/Entra for any sign-in from these accounts, because legitimate use is extremely rare.
Report-only rollout
- Every new policy is born in Report-only mode, never straight to On.
- Let it run for a few days and review the impact under Sign-in logs > Report-only tab, and use the What If tool to simulate specific users.
- Only promote to On after confirming that no legitimate user — not the break-glass accounts, not service accounts, not automations — would be unexpectedly blocked.
With that in place, the 10 policies below can be built safely.
The 10 policies
Each policy below follows the same structure: the goal, the configuration as it appears in the portal, how to test it, and the main gotcha. Field names follow the Entra ID Conditional Access interface.
Policy 1 — Require MFA for all users
Ensure every interactive user authentication goes through MFA. This is the floor of the baseline.
| Users | All users (exclude the break-glass accounts). |
| Target resources | All resources (all cloud apps). |
| Conditions | None. Optionally, exclude trusted/named locations to reduce prompts on the corporate network. |
| Grant / Session | Grant — Require multifactor authentication (or Require authentication strength = MFA). |
| License | Entra ID P1. |
How to test Sign in as a regular user in a private browser session; the MFA prompt should appear. Use What If pointed at that user to confirm the policy applies.
Gotcha Exclude the break-glass accounts. If you use a trusted-location exclusion, make sure the corporate network is correctly registered under Named locations — otherwise users at home get treated as trusted by mistake.
Policy 2 — Require MFA + compliant device for administrators
Raise the bar for privileged accounts: on top of MFA, require the action to come from a managed, compliant device.
| Users | Directory roles — select the privileged roles (Global Administrator, Privileged Role Administrator, Security Administrator, Exchange/SharePoint Admin, and so on). Exclude break-glass. |
| Target resources | All resources (all cloud apps). |
| Conditions | None. |
| Grant / Session | Grant — Require multifactor authentication AND Require device to be marked as compliant. Select “Require all the selected controls”. |
| License | Entra ID P1 + Microsoft Intune (for compliance). |
How to test With a test admin account on an unmanaged device, try to reach the portal — it should be blocked. On a compliant device, it should pass after MFA.
Gotcha Make sure admins already have compliant devices BEFORE promoting to On, or you lock out your own team. Report-only is mandatory here. Consider also accepting Hybrid joined as an alternative to compliant.
Policy 3 — Block legacy authentication
Eliminate legacy authentication protocols that do not support MFA and are the preferred path for password spray.
| Users | All users (exclude break-glass and, temporarily, service accounts that still depend on legacy — migrate them first). |
| Target resources | All resources (all cloud apps). |
| Conditions | Conditions — Client apps: check “Exchange ActiveSync clients” and “Other clients”. These two represent legacy authentication. |
| Grant / Session | Grant — Block access. |
| License | Entra ID P1. |
How to test Before turning it on, go to Sign-in logs and filter by Client app on the legacy categories to map who still uses it. Once On, a basic IMAP/POP client should fail.
Gotcha Map legacy usage first — SMTP AUTH from printers, scanners and older applications will break. Migrate them or create a controlled exception before blocking broadly.
Policy 4 — Require MFA on risky sign-ins (Sign-in risk)
Force an additional verification when Identity Protection scores the sign-in as risky — impossible travel, anonymous IP, and similar signals.
| Users | All users (exclude break-glass). |
| Target resources | All resources (all cloud apps). |
| Conditions | Conditions — Sign-in risk: select High and Medium. |
| Grant / Session | Grant — Require multifactor authentication (and, optionally, Require authentication strength). Also recommended: Session — Sign-in frequency = Every time. |
| License | Entra ID P2 (Identity Protection). |
How to test Simulate it with What If using a risk level, or generate a sign-in from an anonymous VPN/Tor IP in a test environment and confirm the MFA challenge.
Gotcha Configure this through the Conditional Access policy — Microsoft’s current recommendation — rather than the legacy Identity Protection policy. Without P2, this policy does not work.
Policy 5 — Force secure password change on risky users (User risk)
When an identity is flagged as compromised (high user risk), force a secure password change to evict the attacker.
| Users | All users (exclude break-glass). |
| Target resources | All resources (all cloud apps). |
| Conditions | Conditions — User risk: select High. |
| Grant / Session | Grant — Require password change, combined with Require multifactor authentication. |
| License | Entra ID P2 + SSPR enabled (and password writeback, in a hybrid environment). |
How to test Use What If with user risk High, or manually raise the risk level of a test account in Identity Protection and confirm the password change requirement.
Gotcha Without SSPR configured, the password change requirement locks the user out. In a hybrid environment, password writeback is mandatory for the change to propagate to on-premises AD.
Policy 6 — Restrict risky / untrusted locations
Reduce the geographic surface: block countries where the organization does not operate, and/or require MFA outside trusted locations.
| Users | All users (exclude break-glass). |
| Target resources | All resources (all cloud apps). |
| Conditions | Conditions — Locations: define Named locations first. Recommended pattern: block a named location containing the countries you never expect traffic from, OR require MFA whenever the location is not a trusted location. |
| Grant / Session | Grant — Block access (for blocked countries) or Require multifactor authentication (for anything outside trusted). |
| License | Entra ID P1, plus Named locations configured. |
How to test Register a test named location, point the policy at it, and simulate with What If using an IP from that country.
Gotcha Location is a weak signal: VPNs and travel route around it, so use it as an extra layer, never as the only control. Be careful with broad country blocks that hit employees who are traveling.
Policy 7 — Block access from unmanaged devices
Stop unmanaged or unknown devices from reaching corporate resources, using native Conditional Access alone.
| Users | All users (exclude break-glass). Start by targeting the most sensitive apps and expand from there. |
| Target resources | All resources, or specific sensitive apps (Exchange, SharePoint) in a first phase. |
| Conditions | No additional condition required — the managed-device requirement is enforced in the Grant. |
| Grant / Session | Grant — Require device to be marked as compliant OR Require Microsoft Entra hybrid joined device. Select “Require one of the selected controls” to accept either. An unmanaged device satisfies neither and is blocked. |
| License | Entra ID P1 + Intune (compliance) and/or Hybrid join. |
How to test On an unmanaged device, try to reach a target app — it should block. On a compliant or hybrid joined device, it should pass.
Gotcha This policy BLOCKS, it does not limit — BYOD desktops lose access entirely. Partial access (read-only web, no download) is the subject of another post, since it requires App Enforced Restrictions or Defender for Cloud Apps. For mobile BYOD, use Policy 10 (MAM) instead of blocking.
Policy 8 — Reduce session exposure (sign-in frequency)
Limit the window in which a session — or a stolen token — stays valid without reauthentication.
| Users | All users for persistent browser; a shorter sign-in frequency targeted at admins and sensitive apps. |
| Target resources | All resources, or sensitive apps for the more aggressive frequency. |
| Conditions | Optional: apply when the device is not compliant/managed, or on browser sessions. |
| Grant / Session | Session — Sign-in frequency (12–24h for admins, or periodic for users) AND Persistent browser session = Never persistent, especially on unmanaged devices. |
| License | Entra ID P1. |
How to test After applying, confirm that a browser session does not stay signed in after closing and reopening, and that reauthentication is required at the interval you set.
Gotcha Too short a frequency creates prompt fatigue and pushes users into bad habits. Balance it: aggressive for admins and sensitive data, moderate for everyone else. It mitigates token theft, but it does not replace device compliance.
Policy 9 — Protect MFA / security-info registration
Protect the act of registering security methods — the point that, if left exposed, lets an attacker plant their own MFA method (the vector covered in post COD 010).
| Users | All users (exclude break-glass). |
| Target resources | User actions — Register security information. |
| Conditions | Optional: combine with Locations (require a trusted location) and/or a compliant device for the registration. |
| Grant / Session | Grant — Require multifactor authentication, ideally combined with trusted location or compliant device for the act of registering. |
| License | Entra ID P1. |
How to test With a test user, go register a new method at mysignins; the action should require MFA or a trusted context before allowing the registration.
Gotcha Chicken-and-egg problem: a new user with no methods at all cannot satisfy “require MFA” to register their first method. Solve it with a Temporary Access Pass (TAP) at onboarding, or scope the requirement to access from outside a trusted location. This is the direct countermeasure to the MFA-registration persistence scenario.
Policy 10 — Require app protection (MAM) on mobile
On BYOD mobile devices, protect corporate data inside the app (MAM) instead of blocking access — covering the gap Policy 7 leaves on mobile.
| Users | All users (exclude break-glass). |
| Target resources | All resources, or Office 365 / Exchange / SharePoint. |
| Conditions | Conditions — Device platforms: iOS and Android. Client apps: Browser, and Mobile apps and desktop clients. |
| Grant / Session | Grant — Require app protection policy, optionally combined with Require approved client app. |
| License | Entra ID P1 + Intune, with App Protection Policies configured for the apps (Outlook, Teams, OneDrive) and licensed users. |
How to test On a phone without the managed app or without APP applied, access should be barred until an approved app with the protection policy is used; with APP applied, access passes.
Gotcha It only works on iOS/Android, and only with apps that support APP. Configure the App Protection Policies in Intune BEFORE turning on the grant, or mobile users lose access.
Implementation order and dependencies
Order matters, both to avoid lockouts and to capture value early. Suggested sequence, always in report-only first:
- Foundation: (3) Block legacy authentication and (1) Require MFA for all users — the largest risk reduction for the least friction.
- Privilege: (2) MFA + compliant device for admins, once admins actually have compliant devices.
- Risk (if you have P2): (4) sign-in risk and (5) user risk.
- Surface: (6) locations and (7) unmanaged devices — these need Named locations and Intune ready.
- Session and identity: (8) sign-in frequency, (9) security-info registration and (10) mobile MAM.
Dependencies to resolve first: Named locations registered (6), Intune compliance profiles published (2, 7), App Protection Policies created (10), SSPR and password writeback (5), and Temporary Access Pass enabled for onboarding (9).
How to test the baseline without locking yourself out
- Use the What If tool (Entra ID > Conditional Access > What If) to simulate specific users, apps and conditions before enabling anything.
- Keep everything in Report-only and review Sign-in logs > Report-only tab for a few days, looking for legitimate users who would be blocked.
- ALWAYS keep a break-glass session open in another window when promoting policies to On, so you can roll back if something jams.
- Promote one policy at a time to On and watch the impact before moving to the next.
- Document each policy — goal, scope, exclusions. Future audits and troubleshooting will thank you.
Next steps
This baseline closes the most exploited gaps around MFA, but Conditional Access is a continuous journey. From here:
- Authentication Strengths: evolve admin MFA toward phishing-resistant methods (FIDO2, Windows Hello, certificate-based).
- Partial access from unmanaged devices: App Enforced Restrictions (SharePoint/Exchange) for limited web access — the subject of an upcoming post in this series.
- Guest and external coverage: dedicated MFA policies and B2B governance.
- Workload identities: extend Conditional Access to service principals (requires a specific license).
- Continuous review: run Access Reviews, revisit exclusions, and validate the baseline against new techniques periodically.
A Conditional Access baseline isn’t a project that ends — it’s how you turn “we have MFA” into an identity perimeter that actually holds the tenant.