Entra Per-User MFA to Conditional Access: Retire per-user MFA without leaving coverage gaps

Per-user MFA is the oldest way to switch on multifactor authentication in Microsoft Entra ID, and tenants that still run it alongside Conditional Access get duplicated prompts, legacy app passwords and users who look "Disabled" while being protected, or "Enforced" while being exposed. Microsoft's documentation now states plainly that Conditional Access is the best way to protect users with Entra MFA and that you should not enable or enforce per-user MFA if you use Conditional Access policies. This guide is a migration runbook for Entra administrators: how to report per-user MFA states, how to build the baseline Conditional Access policies that replace them, how to keep break-glass accounts safe, and how and when to switch per-user MFA off. It goes deeper than the MFA Guide and assumes you know the basics of the Conditional Access Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• There is no hard switch-off date, but there is a push. Microsoft has not published a retirement date for per-user MFA; it describes it as a configuration it no longer recommends and has added a Microsoft-managed Conditional Access policy that targets per-user MFA users and is turned on automatically after a report-only period.
• Coverage first, removal second. Build and enable a Conditional Access policy that requires MFA for all users and all resources, confirm it applies, and only then set per-user states to Disabled. The reverse order opens a window with no MFA.
• "Disabled" is the correct end state. Users protected by Conditional Access or security defaults show as Disabled in the per-user MFA view. That is expected, and it is what you are aiming for.
• App passwords are the hidden dependency. Enforced per-user MFA is what made app passwords necessary for legacy clients. Blocking legacy authentication with Conditional Access stops existing app passwords working, so find those clients before you flip the switch.
• Service settings do not migrate themselves. Trusted IPs and "remember multifactor authentication" live in the legacy MFA service settings; replace them deliberately with named locations and session controls rather than leaving them behind.

What is changing and why

Per-user MFA assigns a state to each user account: Disabled, Enabled or Enforced. It is binary and global: an enforced user is challenged on every interactive sign-in, everywhere, regardless of risk, device or application, and legacy clients need app passwords. Conditional Access replaces this with policy: assignments (users, groups, roles, workload identities), target resources, conditions (location, device platform, client app, risk) and grant or session controls such as authentication strength and sign-in frequency.

Microsoft's per-user MFA page says changing user states is not recommended unless your licences do not include Conditional Access and you do not want to use security defaults, and it warns against enabling or enforcing per-user MFA when Conditional Access is in use. The deployment planning page goes further: if users were enabled through per-user MFA, Microsoft recommends enabling Conditional Access for all users and then manually disabling per-user MFA. The Microsoft-managed policy "Multifactor authentication for per-user multifactor authentication users" exists to move tenants in that direction.

The security reasons are concrete. Use Conditional Access to require a phishing-resistant method for administrators, respond to sign-in risk and target workload identities, which per-user MFA settings are not designed to do. Moving also lets you retire app passwords, which are not revoked when the account password is reset.

Official timeline and current status

Per-user MFA has no published end-of-support date. The dated changes around it are listed below, each as stated on the Microsoft Learn page cited in Standards and references and checked on 8 November 2026.

Status on 8 November 2026: per-user MFA still works and can still be managed in the Entra admin center under Users, All users, Per-user MFA. Treat the managed policy as the practical deadline: if your tenant qualifies and you have not reviewed it, Microsoft will turn it on for you, and you want your own policies and exclusions in place before that happens.

Who and what is affected

Two groups need special handling. Emergency access accounts must be excluded from any policy that blocks or restricts sign-in, yet they also fall under Microsoft's mandatory MFA for Azure management, so they need a strong method of their own. Directory synchronisation accounts used by Entra Connect or Cloud Sync are excluded from the all-users MFA policy by Microsoft's own template.

Where identity fits: scripted user accounts

Per-user MFA estates often hide named user accounts that run PowerShell jobs or integrations, sometimes kept at Disabled so the job does not break. Microsoft's Conditional Access guidance is direct: policies scoped to users do not block service principal calls, and service accounts used in scripts should be replaced with managed identities where possible, with Conditional Access for workload identities applied to service principals. Treat each one as a non-human identity to migrate, not an MFA exception to keep. See the Azure Managed Identities Security Guide and Azure Mandatory MFA.

Finding affected systems and identities

Inventory before you change anything. You need four lists: users by per-user state, clients using legacy authentication or app passwords, the legacy service settings in force, and accounts that must be excluded.

1. Per-user states. In the Entra admin center go to Users, All users, Per-user MFA (Authentication Policy Administrator or higher). Filter by status to count Enabled and Enforced users. At scale, read the Microsoft Graph beta resource GET /users/{id}/authentication/requirements, which returns the perUserMfaState property, and export the results. Read-only queries are enough for discovery.
2. Sign-ins not covered by Conditional Access. In the sign-in logs, filter for successful interactive sign-ins where Conditional Access status is "Not applied". Any user in that set who is protected only by per-user MFA will lose MFA the moment you disable the state unless a policy catches them.
3. Legacy authentication. Filter sign-in logs by client app for the legacy protocols (Exchange ActiveSync, IMAP, POP, authenticated SMTP, other clients). These are the clients that use app passwords.
4. Legacy MFA service settings. Open the additional cloud-based MFA settings and record trusted IP ranges (up to 50, public ranges only for cloud MFA), whether users may create app passwords, and the "remember multifactor authentication" setting and duration.
5. Exclusion candidates. List emergency access accounts, the Directory Synchronization Accounts role holders, and every user account used non-interactively.

Migration options

Option A: Conditional Access baseline (licensed tenants)

This is Microsoft's recommended path and the right choice for any tenant with Entra ID P1 or P2. The minimum policy set:

• Require MFA for all users: Include All users; exclude the emergency access group and the Directory Synchronization Accounts role; optionally exclude guests if a separate guest policy covers them. Target All resources with no app exclusions. Grant: Require authentication strength, Multifactor authentication.
• Block legacy authentication: All users, All resources, client apps Exchange ActiveSync and Other clients, grant Block.
• Stronger MFA for administrators: Target directory roles, require the Phishing-resistant MFA authentication strength. See the Phishing-Resistant MFA Guide.
• Protect registration: Microsoft recommends securing the "Register security information" user action with Conditional Access that requires a trusted device or location, with Temporary Access Pass for first registration.
• Risk-based policies (P2): require MFA and reauthentication for medium or high sign-in risk, and remediation for high user risk. See Microsoft Entra ID Protection.

Option B: Security defaults (unlicensed tenants)

Security defaults require all users to register for MFA, require administrators to use MFA at every sign-in for 14 listed roles, block legacy authentication and protect Azure management. They cannot be combined with your own Conditional Access policies: Microsoft says organisations that implement Conditional Access policies to replace security defaults must disable security defaults. Users under security defaults also show as Disabled in the per-user view.

Option C: Accept the Microsoft-managed policy

For a small qualifying tenant, enabling the managed per-user MFA policy is a fast interim step. It is not a full baseline: it targets only per-user MFA users, so new joiners outside that set get nothing. Microsoft suggests duplicating the policy and changing its assignments if you want to extend it. Review its exclusions before Microsoft enables it.

Testing and rollback

Run the migration in phases with a defined pilot group. Every policy change is reversible in minutes, but a user state change takes effect at the next token refresh, so plan communications.

1. Prepare break-glass accounts. At least two cloud-only accounts on the .onmicrosoft.com domain, permanent Global Administrator, passkey (FIDO2) or certificate-based authentication, excluded through a dedicated group. Test sign-in and the alert before any policy goes live. See the Break-Glass Account Guide.
2. Create policies in Report-only. Microsoft's template creates the all-users MFA policy in Report-only first. Review the report-only result in sign-in log details and the Conditional Access insights workbook for at least one full business cycle, and use the What If tool for edge cases such as guests and sync accounts.
3. Turn on block legacy authentication for a pilot group, after notifying app password users and moving them to modern clients.
4. Enable the all-users MFA policy. Confirm in sign-in logs that pilot users show Conditional Access status Success with an MFA requirement satisfied.
5. Disable per-user MFA in waves. Set pilot users from Enforced or Enabled to Disabled in the Per-user MFA page or through the Graph beta perUserMfaState property. Watch for unexpected single-factor sign-ins for 48 hours, then widen the wave.
6. Replace service settings. Remove trusted IPs and switch off "remember multifactor authentication" once named locations and session controls are in place; disable app password creation.

Rollback: if a wave breaks access, set the affected Conditional Access policy back to Report-only or Off rather than re-enforcing per-user MFA for everyone. If you must restore per-user MFA for a user, note Microsoft's warning that a re-enabled user who does not re-register stays at Enabled and does not move to Enforced on their own; an administrator must set Enforced directly. Microsoft also advises against setting users to Enforced manually unless they are registered or you accept interruptions to legacy protocols.

Detection and measurement

• Per-user residue: count of users with perUserMfaState Enabled or Enforced. Target zero.
• Uncovered sign-ins: percentage of successful interactive sign-ins with Conditional Access status "Not applied". Target zero outside break-glass use.
• Single-factor success: successful interactive sign-ins satisfied by single-factor authentication, by user, per week.
• Legacy authentication attempts: sign-ins from legacy client apps, which should show only as blocked after cut-over.
• Break-glass alert health: a Severity 0 alert on any sign-in by emergency access accounts, tested at least every 90 days as Microsoft recommends.
• Policy change audit: alert on audit log changes to Conditional Access policies, including entries beginning "Microsoft-managed:".

Risks of doing nothing

• Silent gaps: users with per-user state Disabled and no Conditional Access policy have no MFA at all, and the per-user view cannot show you that, because Disabled is also the correct state for users protected by policy.
• App passwords as a bypass: app passwords for legacy clients survive password resets and cannot satisfy any modern control. Password spray (ATT&CK T1110.003) against legacy endpoints leading to cloud account abuse (T1078.004) is the classic route.
• Prompt fatigue: duplicated challenges from per-user MFA and policy train users to approve prompts, which feeds MFA request generation attacks (T1621). See the MFA Fatigue and Bypass Guide.
• Someone else's change window: the Microsoft-managed policy can be enabled for qualifying tenants after its report-only period, on Microsoft's schedule rather than yours.
• Audit gap: you cannot show a single, reviewable control for NIST SP 800-53 IA-2(1) and IA-2(2) when MFA comes from two models.

Common failure patterns

• Disabling per-user MFA first and building the policy afterwards, leaving a window with no MFA.
• Excluding a large "service accounts" group from the all-users policy instead of migrating those accounts to workload identities.
• Keeping trusted IPs so office sign-ins skip MFA, which makes any compromised internal host or proxy a bypass.
• Excluding break-glass accounts but never testing them, so the first real use fails on mandatory MFA for Azure management.

Framework mapping

Practitioner checklist

• Export every user's perUserMfaState and record Enabled and Enforced counts as your baseline.
• Create and test two cloud-only break-glass accounts with passkey or certificate-based authentication, plus a Severity 0 sign-in alert.
• Find every legacy authentication client and app password user in sign-in logs and move them to modern clients.
• Build the all-users MFA, block legacy authentication and admin phishing-resistant policies in Report-only.
• Review the Microsoft-managed per-user MFA policy, set its exclusions, and decide whether to enable it early or turn it off in favour of your own policy.
• Enable policies, confirm coverage in sign-in logs, then set per-user states to Disabled in waves.
• Replace trusted IPs and "remember MFA" with named locations and session controls, then disable app password creation.
• Migrate scripted user accounts to managed identities or service principals and apply Conditional Access for workload identities.
• Track the six metrics above monthly until per-user residue and uncovered sign-ins reach zero.

Standards and references

• Microsoft Learn: Enable per-user Microsoft Entra multifactor authentication to secure sign-in events
• Microsoft Learn: Require multifactor authentication strength for all users
• Microsoft Learn: Microsoft-managed Conditional Access policies
• Microsoft Learn: Plan a Microsoft Entra multifactor authentication deployment
• Microsoft Learn: Configure Microsoft Entra multifactor authentication settings
• Microsoft Learn: Enforce Microsoft Entra multifactor authentication with legacy applications using app passwords
• Microsoft Learn: Security defaults in Microsoft Entra ID
• Microsoft Learn: Manage emergency access admin accounts

Related NHI Mgmt Group resources: Conditional Access Guide · Entra Legacy MFA and SSPR Policy Migration · Azure Mandatory MFA · Cloud Provider Mandatory MFA · Top 10 MFA Mistakes