Plan a Microsoft 365 MFA rollout with Conditional Access and Authenticator

To roll out MFA across Microsoft 365, enable the methods you want in the Authentication methods policy (Microsoft Authenticator first), get users registered through combined security info registration and a registration campaign, and then require MFA for all users with a Conditional Access policy that uses the built-in Multifactor authentication strength. Run that policy in report-only mode, pilot it with a small group, enforce it in waves, and retire per-user MFA at the end. If you don't have Microsoft Entra ID P1, turn on security defaults instead; they require MFA registration for everyone and block legacy authentication, but can't be customized.

Who this is for and what you will have

This plan is for administrators of a Microsoft 365 tenant who need to move from partial MFA (or none) to MFA for every user without a flood of help desk calls. It suits small businesses on Business Premium as well as enterprises on E3 or E5. At the end you will have:

• A decision between security defaults and Conditional Access, with the licensing reason for it.
• Authentication methods configured in the unified Authentication methods policy.
• Users registered, with a report showing who is still not MFA capable.
• Conditional Access policies that require MFA for administrators and all users, validated before enforcement.
• Per-user MFA turned off, so there is only one place that controls MFA.

MFA is one layer of a wider identity plan. Pair it with blocking legacy authentication, because legacy protocols can't do MFA, and with just-in-time admin roles in PIM for privileged accounts.

Choose your enforcement model

Microsoft states that security defaults are probably not right for organizations with Entra ID P1 or P2, and that organizations replacing security defaults with Conditional Access must disable security defaults. When you do, Microsoft-managed Conditional Access policies are available to keep the same protections: blocking legacy authentication, requiring MFA for Azure management, for admins and for all users.

If you choose security defaults

Turn them on at Entra ID > Overview > Properties > Manage security defaults, set Security defaults to Enabled and select Save. You need at least the Conditional Access Administrator role. Once enabled:

• All users must register for MFA. The 14-day registration grace period was removed for new and existing tenants starting July 29, 2024.
• Administrators in a list of roles, including Global Administrator, Exchange Administrator, Security Administrator, SharePoint Administrator and User Administrator, must do MFA every time they sign in.
• Other users are prompted when Microsoft decides it is necessary, based on location, device, role and task.
• Legacy authentication and device code flow are blocked.
• Anyone using the Azure portal, Microsoft Entra admin center, Azure PowerShell or Azure CLI must complete MFA.

Users register the Microsoft Authenticator app using notifications, or a third-party OATH TOTP app. Microsoft warns not to disable methods in the MFA service settings while security defaults are on, because you can lock yourself out. After enabling, Microsoft recommends revoking existing tokens with Revoke-MgUserSignInSession so previously signed-in users have to authenticate and register.

The rest of this guide assumes Conditional Access.

Prerequisites

• Microsoft Entra ID P1 or P2 for every user in scope.
• Conditional Access Administrator and Authentication Policy Administrator roles, or equivalents.
• Two cloud-only emergency access accounts on the onmicrosoft.com domain, permanently assigned Global Administrator, using a FIDO2 passkey or certificate-based authentication.
• For hybrid identity, Microsoft Entra Connect syncing users, and the Directory Synchronization Accounts role excluded from MFA policies.
• For federated domains, an identity provider configured to send an MFA claim if MFA happens there.
• A communication plan. Microsoft publishes MFA communication templates at https://aka.ms/mfatemplates.

Mandatory MFA is already enforced for admin portals

Microsoft enforces MFA independently of your policies for accounts that sign in to the Azure portal, Microsoft Entra admin center and Intune admin center (from October 2024), the Microsoft 365 admin center (from February 2025), and for create, update and delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools and the Azure Resource Manager REST API (from October 1, 2025). It applies to every user account, including emergency access accounts, and there's no opt-out. Workload identities such as managed identities and service principals aren't affected, which is one more reason to move scripts off user accounts.

Phase 1: Configure authentication methods

Manage methods in the Authentication methods policy at Entra ID > Authentication methods > Policies. If your tenant still uses the legacy MFA and SSPR method settings, the automated migration guide on that page reads them and proposes an equivalent configuration. You can also migrate manually by setting Manage migration to Migration in progress, matching each method, and finishing with Migration Complete. The process is reversible.

Recommended starting configuration:

Microsoft recommends enabling more than one method so users have a backup, and suggests the Authenticator app for the best mix of usability and options.

Phase 2: Get users registered

Combined registration

Users register for MFA and self-service password reset together in the combined security info experience at https://myprofile.microsoft.com, under Security info. Send the link with your announcement so users can register before enforcement.

Protect the registration process

If an attacker has a user's password, they could register their own MFA method. Microsoft recommends securing security info registration with a Conditional Access policy that targets the Register security information user action and requires a trusted location or device. New hires and users who lost their phone can then onboard with a Temporary Access Pass issued by the help desk.

Run a registration campaign

The registration campaign prompts users to set up Microsoft Authenticator (or a passkey) after they complete MFA. Configure it at Entra ID > Authentication methods > Registration campaign:

• Microsoft managed state: Microsoft picks the target method and settings. For Authenticator, it nudges users who do MFA with SMS or voice, allows one day of snooze, and requires registration after three snoozes.
• Enabled state: you choose the method, a snooze period from 0 to 14 days, and whether snoozes are limited to three.

The Authenticator campaign only applies to users enabled for Authenticator push in the Authentication methods policy, with authentication mode Any or Push. It isn't shown on mobile devices, inside an existing SSO session, or when a Conditional Access policy blocks the security info registration page for that user.

Phase 3: Measure readiness

Open Entra ID > Authentication methods > Activity. The Registration tab shows how many users are capable of MFA, and User registration details lists each user with MFA Capable, Methods registered and related columns. The data can lag up to 36 hours.

To export the users who aren't ready yet:

Connect-MgGraph -Scopes 'AuditLog.Read.All'
 
Get-MgReportAuthenticationMethodUserRegistrationDetail -All -Filter "isMfaCapable eq false" |
    Select-Object UserPrincipalName, UserDisplayName, IsAdmin, UserType,
        @{n='Methods';e={$_.MethodsRegistered -join ', '}} |
    Export-Csv .\not-mfa-capable.csv -NoTypeInformation

isMfaCapable is true only when the user has registered a strong method that the Authentication methods policy allows; isMfaRegistered is true even if the method isn't allowed. A user who is registered but not capable has a method that the policy doesn't currently allow.

Phase 4: Build the Conditional Access policies

Create these in report-only mode first. Each needs your emergency access accounts excluded.

Require MFA for administrators

Start with admins, because their accounts carry the most risk. Microsoft provides a Conditional Access template that requires MFA for admins. Target the directory roles your administrators hold and require MFA for all resources.

Require MFA for all users

1. Browse to Entra ID > Conditional Access > Policies and select New policy.
2. Under Users or workload identities, include All users. Exclude your emergency access accounts and, for hybrid identity, the Directory Synchronization Accounts directory role. Optionally exclude guests if a separate guest policy covers them.
3. Under Target resources > Resources (formerly cloud apps), include All resources (formerly 'All cloud apps'). Microsoft recommends this baseline without app exclusions.
4. Under Grant, select Grant access, then Require authentication strength and the built-in Multifactor authentication strength.
5. Set Enable policy to Report-only and create the policy.

If you use external authentication methods, Microsoft notes they are currently incompatible with authentication strength; use the Require multifactor authentication grant control instead.

Block legacy authentication

Legacy clients can't satisfy MFA, so they bypass the intent of the policy. Add a policy that blocks Exchange ActiveSync and Other clients, as covered in the guide to blocking legacy authentication.

Phase 5: Pilot, then enforce in waves

Microsoft's deployment guidance is a pilot group followed by waves sized to your support capacity:

1. Review report-only results for a week or more. In a sign-in event, the Report-only tab shows Report-only: User action required where the user would have been prompted for MFA, and Report-only: Failure where the sign-in would have been blocked.
2. Change the all-users policy to target a pilot group (IT staff and a few volunteers from each department) and set it to On.
3. Add groups wave by wave, checking the not-MFA-capable export before each wave so you can contact users who haven't registered.
4. When every user is included, switch the include back to All users.

Plan session lifetime

Prompting too often trains users to approve requests without thinking. Microsoft recommends relying on devices with Primary Refresh Tokens for a better experience and reducing session lifetime with sign-in frequency only for specific business cases.

Phase 6: Retire per-user MFA

Once the Conditional Access policy covers everyone, browse to Entra ID > Users > All users, select Per-user MFA, and disable per-user MFA for every user who shows Enabled or Enforced. Microsoft's guidance is to enable Conditional Access for all users first and then disable per-user MFA manually. Users protected by Conditional Access correctly show Disabled there.

Verification

• Sign-in logs: sign-in events include authentication details when a user was prompted for MFA, and show which Conditional Access policies were in use.
• Authentication methods activity, Usage tab: Sign-ins by authentication requirement shows single-factor versus multifactor interactive sign-ins. Single-factor sign-ins should trend toward zero apart from excluded accounts.
• Registration export: the not-MFA-capable list should only contain disabled, service or excluded accounts.

Troubleshooting

A user isn't prompted for MFA after enforcement. They may already have an MFA claim in their session token, or they're excluded. Check the Conditional Access tab on the sign-in event to see which policies applied.

Security defaults are still on after you build Conditional Access policies. Microsoft states that organizations replacing security defaults with Conditional Access must disable security defaults. Turn them off at Entra ID > Overview > Properties > Manage security defaults, and enable your Conditional Access policies straight away so there's no gap in protection.

A script or app starts failing after MFA is required. Apps using the Resource Owner Password Credentials (ROPC) flow can't do MFA and throw exceptions. Move the app to a managed identity, service principal, or an interactive flow.

Users aren't nudged to set up Authenticator. Check that they are enabled for Authenticator push, that they completed MFA with SMS or voice (for the Microsoft managed state), and that no Conditional Access policy blocks the security info registration page for them.

Federated users complete MFA at their identity provider but are prompted again. The federated identity provider must send an MFA claim that Entra ID accepts.

An admin is told to set up MFA before using the Azure portal or Microsoft 365 admin center. Mandatory MFA applies regardless of your policies. Have the admin register a method, or issue a Temporary Access Pass so they can register one.

Checklist

• Enforcement model chosen; security defaults disabled if Conditional Access replaces them.
• Two emergency access accounts with passkeys or certificate-based authentication, excluded from policies that block sign-in.
• Authentication methods policy configured and legacy method settings migrated.
• Users told what's happening and given the registration link.
• Security info registration protected; Temporary Access Pass available to the help desk.
• Registration campaign running; not-MFA-capable export reviewed before each wave.
• Admin and all-user MFA policies validated in report-only, then enforced in waves.
• Legacy authentication blocked.
• Per-user MFA disabled for all users.

References

• Deployment considerations for Microsoft Entra multifactor authentication
• Security defaults in Microsoft Entra ID
• Require MFA for all users with Conditional Access
• How to migrate to the Authentication methods policy
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• Authentication methods activity
• userRegistrationDetails resource type
• Get-MgReportAuthenticationMethodUserRegistrationDetail
• Plan for mandatory Microsoft Entra multifactor authentication
• Manage emergency access admin accounts
• Conditional Access report-only mode