How to Migrate from Per-User MFA to Conditional Access

Identity Security
May 01, 2026•9 min read

How to Migrate from Per-User MFA to Conditional Access

Many organizations manage MFA at the per-user level: IT manually enables MFA for each user, manages authentication methods individually, and handles exceptions case-by-case. This approach is administratively burdensome and inflexible.

Conditional Access automates MFA enforcement, applies policies based on context (location, device, risk), and eliminates manual per-user management. Migrating from per-user MFA to Conditional Access is one of the highest-impact security improvements you can make.

This guide walks you through the migration step-by-step, minimizing user disruption.

Why Migrate from Per-User MFA to Conditional Access?

Problems with Per-User MFA

Administrative burden: IT manually enables MFA for hundreds of users, manages exceptions, responds to “I can’t sign in” requests.

Inflexible enforcement: Everyone gets the same MFA requirement regardless of context. Executive accessing from home gets challenged; employee in coffee shop doesn’t (if not explicitly enabled).

Exception sprawl: “Just this once” exceptions accumulate. Special cases (contractors, partners, admins) never get removed.

No risk assessment: MFA is always required, even for low-risk sign-ins from recognized locations and devices.

Benefits of Conditional Access

Centralized policy management: Single location to view and manage MFA policies across the entire organization.

Context-aware: Challenge users only when necessary (high-risk sign-in, unknown device, unusual location).

Automation: No manual per-user configuration; policies apply automatically.

Reduced user friction: Low-risk sign-ins succeed without MFA; only risky scenarios are challenged.

Scalability: Adding 100 new users doesn’t require manual MFA setup; policies apply automatically.

Pre-Migration Assessment

Before migrating, understand your current state:

Step 1: Identify Users with Per-User MFA Enabled

In Microsoft 365 Admin Center:

  1. Users > Active Users
  2. Click Multi-factor authentication (top right menu)
  3. Review users with MFA status:
    • Enabled: MFA is active
    • Enforced: MFA is required (can’t skip)
    • Disabled: MFA not configured

Record the count of enabled/enforced users.

Alternatively, use PowerShell:

$users = Get-MsolUser -All | where {$_.StrongAuthenticationRequirements -ne $null}
$users | Select UserPrincipalName, @{Name="MFAStatus";Expression={$_.StrongAuthenticationMethods.IsDefault}} | Export-Csv -Path "C:\MFA_Users.csv"

Step 2: Identify Authentication Methods

Review what authentication methods users have registered:

$users = Get-MsolUser -All | where {$_.StrongAuthenticationRequirements -ne $null}
foreach ($user in $users) {
  $methods = $user.StrongAuthenticationMethods | Select -ExpandProperty MethodType
  Write-Output "$($user.UserPrincipalName): $($methods -join ',')"
}

This helps you understand what MFA methods users rely on (phone call, text, app-based authenticator, hardware key).

Step 3: Understand Current Exclusions

Check Microsoft Entra ID > Conditional Access:

  1. Are there existing Conditional Access policies?
  2. Are there exclusions or exemptions for specific users?
  3. Are security defaults enabled?

If no conditional access policies exist, you’ll migrate from per-user MFA directly to Conditional Access.

Migration Plan

Phase 1: Prepare Conditional Access Environment (Week 1)

Step 1: Enable Microsoft Authenticator App

Before requiring Conditional Access, ensure users can register MFA methods:

  1. Microsoft 365 Admin Center > Settings > Org settings > User experience features
  2. Enable Allow users to register their security information

This allows users to self-register MFA methods at myapps.microsoft.com > Account > My sign-ins.

Step 2: Create Admin Emergency Access Account

Create a break-glass account in case you accidentally lock yourself out:

  1. Microsoft Entra ID > Users > + New user
  2. User name: [email protected]
  3. Password: Generate strong password; store in secure location
  4. Assign: Global Admin role
  5. Important: Do NOT configure MFA or Conditional Access for this account
  6. Store credentials in your disaster recovery system

This account is your only way to modify Conditional Access if something goes wrong.

Step 3: Review Current MFA Methods

Send communication to all users:

Subject: “Security Update: Preparing Multi-Factor Authentication Upgrade”

Message: “We’re upgrading our security to use Conditional Access, which provides better protection while reducing interruptions. No action is required—your current MFA methods will continue working. We’ll provide updates as we implement this change.”

This creates awareness without generating support tickets.

Phase 2: Pilot Conditional Access (Week 2-3)

Step 1: Create Baseline Conditional Access Policy

Navigate to Microsoft Entra ID > Security > Conditional Access > + New policy

Policy Name: “Pilot - Require MFA for All”

Assignments:

  • Users: Select a pilot group (50-100 users) or specific department
  • Cloud apps: Select Microsoft 365 apps (or choose specific: Exchange Online, SharePoint, Teams)

Conditions:

  • Sign-in risk: Leave blank (we’ll add this later)
  • Client apps: All client apps
  • Locations: All locations

Grant controls:

  • Check Require multi-factor authentication

Session controls:

  • Sign-in frequency: Leave blank (default)
  • Persistent browser session: Leave blank (allow persistent sessions)

Enable policy: Select Report-only

Create

Step 2: Monitor Pilot Phase

Leave in Report-only mode for one week. This logs policy triggers without blocking users.

  1. Conditional Access > Click your policy > Workbook

  2. Review:

    • Policy trigger rate: How many sign-ins match the policy condition?
    • User impact: Which users are affected?
    • Client apps: Which apps are triggering the policy?

  3. Look for concerning patterns:

    • High impact on production apps
    • Specific users having issues
    • Unexpected client apps

Step 3: Gather User Feedback

Send survey to pilot users:

  • “Did you notice any changes to your sign-in experience?”
  • “Did you have to set up multi-factor authentication?”
  • “Any issues or concerns?”

This helps identify unforeseen problems before enterprise-wide rollout.

Step 4: Enable Pilot Policy

After one-week review:

  1. Return to Conditional Access > Select your policy > Edit
  2. Change Enable policy to On
  3. Save

Users in the pilot group now require MFA.

Phase 3: Disable Per-User MFA (Week 3-4)

Once Conditional Access is enforcing MFA, disable per-user MFA to avoid confusion.

Step 1: Audit Per-User MFA Status Again

$users = Get-MsolUser -All | where {$_.StrongAuthenticationRequirements -ne $null}
Write-Output "Users with per-user MFA enabled: $($users.Count)"

Step 2: Disable Per-User MFA for Pilot Users

For pilot users only:

  1. Microsoft 365 Admin Center > Users > Multi-factor authentication
  2. Select pilot users
  3. Click Disable

This removes per-user MFA enforcement. Conditional Access takes over.

Step 3: Communicate to Pilot Users

Subject: “Multi-Factor Authentication Update Complete”

Message: “Your account has been updated to use our new Conditional Access security system. Your MFA experience remains the same—you’ll be asked to provide a second authentication factor in specific scenarios. Thank you for being part of our security upgrade pilot.”

Phase 4: Enterprise Rollout (Week 4-8)

Step 1: Expand Conditional Access Policy

  1. Conditional Access > Edit your pilot policy
  2. Assignments > Users > Change from pilot group to All users
  3. Add Exclusion: Emergency access account
  4. Save

Step 2: Disable Per-User MFA for All Users

$users = Get-MsolUser -All | where {$_.StrongAuthenticationRequirements -ne $null}
foreach ($user in $users) {
  Set-MsolUser -UserPrincipalName $user.UserPrincipalName -StrongAuthenticationRequirements @()
  Write-Output "Disabled MFA for $($user.UserPrincipalName)"
}

Note: This disables per-user enforcement. Users retain registered MFA methods and can still use them with Conditional Access.

Step 3: Monitor Enterprise Rollout

  1. Review Conditional Access > Workbook daily for first 2 weeks
  2. Monitor help desk tickets for MFA-related issues
  3. Check Risky sign-ins for unexpected blocks

Step 4: Create Additional Policies

Once baseline MFA policy is stable, add additional policies:

Policy 2: Block Legacy Authentication

  1. Conditional Access > + New policy
  2. Name: “Block Legacy Authentication”
  3. Conditions:
    • Client apps: Legacy authentication clients (IMAP, POP3, SMTP, Exchange Web Services)
  4. Grant: Block
  5. Enable policy: On

This prevents attackers from using outdated protocols that can’t support MFA.

Policy 3: Require Compliant Device for Sensitive Apps

  1. Conditional Access > + New policy
  2. Name: “Require Compliant Device - Sensitive Apps”
  3. Cloud apps: Exchange Online, SharePoint, Teams
  4. Grant: Require device to be marked compliant
  5. Enable policy: Report-only initially

This requires corporate-managed devices for email and documents.

Policy 4: High-Risk Sign-In Challenge (requires E5 licensing)

  1. Conditional Access > + New policy
  2. Name: “Challenge High-Risk Sign-Ins”
  3. Conditions:
    • Sign-in risk: High
  4. Grant: Require MFA or password change
  5. Enable policy: On

This detects sign-in anomalies (impossible travel, new device) and requires additional verification.

Handling Special Cases

Contractor or Third-Party Accounts

Create conditional access exemption:

  1. Conditional Access > Edit policy
  2. Assignments > Users > Exclude
  3. Create security group “Contractors”
  4. Add to exclusions

This requires separate MFA governance for contractor accounts (perhaps per-user MFA remains enabled for them).

Accounts Without MFA Methods Registered

If users haven’t registered MFA methods, Conditional Access blocks access. Handle this:

Option 1: Provide self-service registration

Send users to myapps.microsoft.com:

  1. Click Account > My sign-ins
  2. Click Additional security verification or Protect your account
  3. Register MFA methods

Option 2: Use Intune to push authenticator

If users have corporate devices enrolled in Intune:

  1. Deploy Microsoft Authenticator via Intune
  2. Configure for passwordless phone sign-in
  3. Users approve the sign-in request on their phone instead of entering a password

Option 3: Temporary per-user MFA

For holdout users, temporarily enable per-user MFA while they register methods.

Admin Accounts

Create stricter policies for privileged accounts:

  1. Conditional Access > + New policy
  2. Name: “Require Compliant Device - Admin Accounts”
  3. Users: Create group “Microsoft 365 Admins”
  4. Grant: Require multi-factor authentication AND require device compliance
  5. Enable policy: On

This ensures admins use corporate-managed devices.

Rollback Plan

If Conditional Access causes widespread issues:

  1. Disable the policy (set to Report-only or delete)
  2. Re-enable per-user MFA:
    Set-MsolUser -UserPrincipalName [email protected] -StrongAuthenticationRequirements @(New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement -Property @{RelyingParty="*";State="Enabled"})
  3. Investigate root cause
  4. Plan revised rollout addressing the issue

Success Metrics

Track these metrics during and after migration:

Week 1-2 (Pilot Phase):

  • Pilot policy trigger rate: Target 30-50% of sign-ins
  • Pilot user MFA success rate: >95%
  • Help desk tickets related to MFA: <5% increase

Week 4-8 (Enterprise Rollout):

  • Enterprise policy trigger rate: 40-60%
  • Overall MFA success rate: >98%
  • Sign-in latency: <2 second additional delay
  • Legacy authentication blocks: Tracked and approved

Ongoing:

  • Risky sign-in detections: Monitor for anomalies
  • Conditional Access policy modification frequency: Quarterly reviews
  • User satisfaction: Annual survey; >80% satisfaction target

Troubleshooting Common Issues

Issue: Users Locked Out After Policy Enablement

Cause: Users haven’t registered MFA methods

Solution:

  1. Use emergency access account to disable policy
  2. Send users to MFA registration
  3. Re-enable policy

Issue: Specific App Broken by Conditional Access

Cause: Legacy app doesn’t support modern authentication

Solution:

  1. Exclude the app from conditional access policy (if low-risk)
  2. Migrate app to modern authentication protocol
  3. Or create separate device-specific policy for legacy app

Issue: High False Positive Rate (Legitimate Users Blocked)

Cause: Policy conditions too strict

Solution:

  1. Review policy workbook; identify false positives
  2. Adjust conditions (e.g., exclude trusted locations)
  3. Reduce sign-in risk threshold

Migration Checklist

  • [ ] Week 1: Create emergency access account
  • [ ] Week 1: Enable authenticator self-registration
  • [ ] Week 2: Create baseline Conditional Access policy in report-only mode
  • [ ] Week 3: Monitor pilot phase; enable policy; disable per-user MFA for pilots
  • [ ] Week 4: Expand policy to all users
  • [ ] Week 4: Disable per-user MFA for all users
  • [ ] Week 5-8: Create additional policies (legacy auth block, compliant device, risk-based)
  • [ ] Ongoing: Monthly policy reviews; quarterly updates

Conclusion

Migrating from per-user MFA to Conditional Access reduces IT burden, improves security flexibility, and provides better protection against context-specific risks. The phased approach—pilot first, monitor thoroughly, expand methodically—ensures minimal user disruption and maximum success.

Most organizations complete this migration in 4-8 weeks. The benefits—reduced administrative overhead, better security posture, and improved user experience—justify the effort.

Ready to migrate to Conditional Access? Schedule a consultation at 365securityassessment.com to develop a migration plan tailored to your organization’s environment and user base.

mfa migrationconditional accessper-user mfaidentity security
Back to Blog