Passwords alone are the weakest link in most Microsoft 365 tenants. A single Conditional Access policy that requires multifactor authentication (MFA) for everyone closes the biggest gap, and Microsoft documents it as the recommended baseline. This guide walks through creating that policy safely, so you don’t lock yourself out.
Before you start
- Role: You need at least the Conditional Access Administrator role in the Microsoft Entra admin center.
- Emergency access accounts: Make sure you have at least one break-glass account. You will exclude it from the policy so a misconfiguration can never lock every admin out.
- Hybrid identity: If you use Microsoft Entra Connect or Cloud Sync, plan to exclude the Directory Synchronization Accounts directory role too.
Step 1: Open Conditional Access
- Sign in to the Microsoft Entra admin center at
entra.microsoft.com. - Go to Entra ID > Conditional Access > Policies.
- Select New policy.
- Give it a clear name that follows your naming standard, for example “CA001 – Require MFA – All users”.
Step 2: Choose who the policy applies to
Under Assignments > Users or workload identities:
- Include: All users.
- Exclude: your emergency access (break-glass) accounts, plus the Directory Synchronization Accounts role if you run hybrid identity.
- Optional: exclude guest users only if you will cover them with a separate guest-specific policy.
Step 3: Target all resources
Under Target resources > Resources (formerly cloud apps) > Include, select All resources. Don’t add app exclusions. Microsoft’s baseline recommendation is all users, all resources, MFA required, with no gaps for attackers to route around.
Step 4: Require multifactor authentication
- Under Access controls > Grant, select Grant access.
- Choose Require authentication strength.
- Pick the built-in Multifactor authentication strength and select Select.
Heads-up: External authentication methods are currently not compatible with authentication strength. If you rely on one, use the Require multifactor authentication grant control instead.
Step 5: Start in report-only mode
- Set Enable policy to Report-only.
- Select Create.
Report-only mode evaluates the policy against real sign-ins without enforcing it. Review the results first to see who would have been prompted, and catch surprises such as legacy apps or shared accounts.
Step 6: Review, then turn it on
Once the report-only results look right, open the policy and change Enable policy from Report-only to On. Before doing so, confirm that every user has registered an MFA method, and announce the change so people aren’t caught off guard.
Optional: exempt trusted locations
If you want to skip MFA prompts from a trusted office network, set the Network condition to include any network or location and exclude All trusted networks and locations. Weigh this carefully: it trades some protection for convenience.
Common pitfalls
- Service accounts and service principals: user-targeted Conditional Access policies don’t block service principal calls. Use Conditional Access for workload identities to cover them, and replace service accounts in scripts or code with managed identities where possible.
- Forgotten break-glass exclusion: the most common cause of tenant-wide lockout. Test before enforcing.
- Skipping report-only: enforcing immediately is how help desks get flooded.
Quick checklist
- Emergency access accounts excluded
- All users and all resources targeted
- Built-in MFA authentication strength required
- Report-only results reviewed
- Policy switched to On


