How to require MFA for all users with Conditional Access

Requiring MFA for all users with Conditional Access is a single policy — all users, all cloud apps, grant Require multifactor authentication — built in report-only mode, preceded by a registration campaign so users have a method when the prompt lands, and enforced once the report-only data shows no surprises. Microsoft already enforces MFA for admin portals; this policy is what closes the gap for everyone else and every app.

The policy is the first item in any Conditional Access baseline. Pair it with blocking legacy authentication, or the MFA requirement has a hole in it the width of an IMAP client.

Prerequisites

Entra ID P1 (Business Premium, E3, E5, F-plans) and security defaults switched off.
Conditional Access Administrator role.
Two break-glass accounts that will be excluded.
The Authentication methods policy migrated off the legacy per-user MFA and SSPR settings (Entra → Protection → Authentication methods → Policies), with Microsoft Authenticator enabled and SMS/voice ideally off for new registrations. Users on legacy per-user MFA Enforced status should be set to Disabled there — Conditional Access takes over.
A communication to users a week ahead: what will happen, how to install Authenticator, where My Security Info is. The passwordless authentication guide explains why Authenticator (or a FIDO2 key) beats SMS.

Steps

Progress 0/5

1.Run a registration campaign↓
2.Create the policy in report-only↓
3.Create the admin policy alongside it↓
4.Read the report-only results↓
5.Enforce↓

Progress is saved in this browser only.

1. Run a registration campaign

Authentication methods → Registration campaign nudges users who have not registered Authenticator at sign-in, with a snooze you can limit. Turn it on for all users two weeks before enforcement. Check progress in Entra → Protection → Authentication methods → User registration details; export the unregistered list and chase it through managers, not helpdesk.

2. Create the policy in report-only

Entra → Protection → Conditional Access → New policy:

Name: CA-GRANT-MFA-AllUsers.
Users: All users. Exclude: break-glass accounts; a CA-Exclusions-MFA group for the handful of documented exceptions (empty is the goal).
Target resources: All cloud apps. Do not exclude apps here to be kind — that is how the intranet ends up unprotected.
Conditions: none for the baseline policy. Do not scope it to "untrusted locations"; an attacker with a stolen password on the office Wi-Fi is exactly who you want to stop.
Grant: Require multifactor authentication (or Require authentication strength → Multifactor authentication, which is equivalent today and easier to tighten later).
Session: leave defaults for the all-users policy.
Enable policy: Report-only.

3. Create the admin policy alongside it

A second policy targeting directory roles (Global, Privileged Role, Security, Exchange, SharePoint, Conditional Access, User, Authentication Administrator and so on) with Require authentication strength → Phishing-resistant MFA and a shorter sign-in frequency. Details in Conditional Access for admin accounts. Build it now so admins are not the weakest accounts in the tenant.

4. Read the report-only results

A week of data: Sign-in logs → filter Conditional Access: Report-only → Failure shows who would have been blocked and why — nearly always user has not registered a method or a service account signing in with a password. Fix those (registration chase, move automation to app registrations with certificates as in service principal best practices) rather than adding exclusions. The testing guide covers the What If tool for specific cases.

5. Enforce

Switch to On on a Tuesday morning with helpdesk briefed. Expect a bump in "how do I set up the app" tickets for a day, then silence.

Verify

Sign-in logs: interactive sign-ins show MFA requirement satisfied by claim in the token or MFA completed in Azure AD under Authentication details; nothing succeeds with Single-factor authentication except break-glass accounts (which should not be signing in at all).
The Conditional Access Insights and reporting workbook shows the policy applied to close to 100% of interactive sign-ins.
Secure Score reflects the change within a couple of days.

Roll back

Set the policy to Report-only. Do not delete it. If a specific population is stuck — a factory floor with no phones, say — scope a temporary exclusion group with an owner and an expiry date, and solve the method problem (shared FIDO2 keys, Windows Hello for Business, TAP-issued registration at induction) rather than leaving the exclusion in place.

Frequently asked questions

Should I use security defaults or a Conditional Access policy to require MFA?

Security defaults if you have no Entra ID P1 licence — it is free and enforces MFA for everyone plus blocks legacy auth. Conditional Access if you have P1 (Business Premium, E3, E5): it lets you exclude break-glass accounts, exempt service accounts you cannot avoid, require stronger methods for admins, and run report-only first. You cannot run both.

Does requiring MFA for all users break service accounts and scripts?

Any account that signs in interactively with a password and no second factor will be prompted, and non-interactive scripts using that account will fail. The fix is to stop using user accounts for automation — app registrations with certificates or managed identities — not to exclude the accounts. Where a vendor forces a user account, exclude it narrowly and put a date on the exclusion.

What is the difference between 'Require MFA' and 'Require authentication strength'?

Require MFA accepts any registered second factor, including SMS and voice. An authentication strength lets you choose which methods count — for example 'Passwordless MFA' or 'Phishing-resistant MFA' (FIDO2, Windows Hello for Business, certificate-based). Use plain MFA for the all-users policy and a phishing-resistant strength for admins.