Every cyber insurance questionnaire asks about MFA, and every breach report says the same thing: most account takeovers hit accounts without it. MFA itself isn't hard. Rolling it out to a whole company without locking out the CEO on a Saturday is where the planning goes.
Security defaults or Conditional Access?
| Security defaults | Conditional Access | |
|---|---|---|
| License | Free, every tenant | Entra ID P1 (included in Business Premium) |
| What you get | MFA registration for everyone, MFA for admins, legacy auth blocked | Policies by user, app, device, location, and risk signals |
| Exclusions | None, so it's all or nothing | Per policy, including break-glass accounts |
| Best for | Tenants on Business Basic or Standard | Business Premium tenants, and anyone who needs exceptions |
If you have Business Premium, use Conditional Access and turn security defaults off. The two can't run together. If you don't, turn security defaults on today. It's far better than nothing.
Step 1: Break-glass accounts first
Before any policy that can block sign-ins, create two emergency access accounts:
- Cloud-only accounts on your
.onmicrosoft.comdomain, not synced from AD - Global Administrator, with long random passwords stored offline
- Protected with a phishing-resistant method (a FIDO2 security key), since Microsoft now enforces MFA for admin portals
- Excluded from your Conditional Access policies, and monitored: any sign-in to them should alert someone
Step 2: Choose your methods
Configure the Authentication methods policy in Entra ID. Microsoft has retired the old per-user MFA and SSPR method settings in favor of this one policy.
- Microsoft Authenticator with number matching is the baseline for most users.
- Passkeys and FIDO2 keys for admins and anyone high-risk.
- SMS and voice only as a fallback, if at all. They're the weakest options.
- Turn on system-preferred MFA so users get the strongest method they've registered.
Step 3: Registration before enforcement
Enforcing MFA on users who haven't registered is how you flood the help desk. Instead:
- Announce the change a week ahead, with screenshots of what users will see.
- Use a registration campaign (a nudge at sign-in) to get people onto Microsoft Authenticator.
- Track progress in Entra ID -> Authentication methods -> User registration details, and chase the stragglers individually.
Connect-MgGraph -Scopes "AuditLog.Read.All"
Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
Where-Object { -not $_.IsMfaRegistered } |
Select-Object UserPrincipalName, IsAdmin | Sort-Object UserPrincipalNameStep 4: Enforce in stages
- Report-only first. Create the "require MFA for all users" policy in report-only mode and check the sign-in logs for a week to see who it would affect.
- Admins first, then a pilot group, then everyone.
- Block legacy authentication at the same time. MFA does nothing against protocols that can't prompt for it.
- Plan for the edge cases: shared or service accounts, scanners that send mail, conference-room devices, and users without smartphones.
What users will hit
- "I got a new phone." Have a documented process to re-register a user after verifying who they are. This is where social engineering attacks aim.
- Prompts in the middle of the day. Usually token lifetime or sign-in frequency settings. Don't train users to approve prompts they didn't expect.
- Outlook desktop prompting repeatedly. Often an old Office build or a stale cached credential, not MFA itself.