MFA Prompt Loop in Microsoft 365: Admin-Side Causes (2026 Updated Guide)

Quick answer

If your users are stuck in an MFA prompt loop — entering the code, getting let in for a few seconds, then being prompted for MFA again — the cause is almost certainly on your side, not theirs. Specifically: Conditional Access policy interactions, sign-in frequency settings configured too aggressively, broken Primary Refresh Token state on the device, or a federated identity provider that’s not honouring the MFA claim. Tell users to stop reinstalling Authenticator. The fix is in your tenant configuration, and the diagnosis starts with the Entra ID sign-in logs.

Before you start

You’ll need at least the Conditional Access Administrator role to make changes to CA policies. Reports Reader is enough to diagnose. Have the affected user available — a real failed sign-in attempt with a known timestamp is much faster to diagnose than reproducing it yourself.

This guide is for the admin-side diagnosis. If you’re a user reading this and you don’t have admin access to your Microsoft 365 tenant, the end-user version of this article is at Microsoft 365 MFA prompt loop — and the honest summary is: there’s nothing you can do, your IT admin needs to fix this, send them this article.

What an MFA loop actually is

A genuine MFA loop has a specific signature. The user signs in successfully, completes MFA, sees Microsoft 365 (or Outlook, or Teams) for a few seconds or minutes, and is then re-prompted for sign-in or MFA. They complete it again. Same thing happens. Loop.

This is distinct from three things that look similar but aren’t:

  • MFA on first sign-in only. Normal behaviour. Not a loop.
  • MFA prompted across multiple devices throughout the day. Also normal — sign-in frequency policies are doing their job.
  • Outlook desktop repeatedly asking for password without ever getting through. A different family of problem; see Outlook keeps asking for password.

A real loop is when the same browser session, same device, same identity, repeatedly prompts for MFA within minutes of the previous successful authentication. That’s a token state failure, and the cause is almost always architectural rather than transient.

The diagnosis: read the sign-in logs

Don’t try to fix this from the user’s side. Go to Microsoft Entra admin centre → Identity → Monitoring & health → Sign-in logs. Filter by the affected user and a time range covering at least one full loop cycle. You’re looking for a pattern where multiple sign-in events appear within a short window — typically every few minutes — for the same application.

Open one of these events. Three things matter:

  1. The Conditional Access tab. Which policies were evaluated? Which one required MFA? Which one matched on something other than what you expected?
  2. The Authentication Details tab. Was MFA actually completed? What method? What was the time between auth completion and re-prompt?
  3. The Token Details / Original Transfer Method. This is hidden under the Activity Details section but tells you whether the token issued was rejected for a reason that would cause re-authentication.

In our experience, the actual cause is one of the seven scenarios below. Work through them in order. The Conditional Access tab will usually tell you which one before you finish reading.

Cause 1: Sign-in frequency configured too aggressively

The most common self-inflicted cause. Conditional Access has a Sign-in frequency session control that lets you require re-authentication after a configurable time period. The default behaviour without this control is roughly weekly token refresh; with this control, you can set anything from one hour to multiple days.

If you set it to one hour or less, users will experience exactly the loop pattern: sign in, work for an hour, get prompted again. If your policy applies sign-in frequency to all sign-ins (rather than to risky sign-ins, or specific resources), the loop is unavoidable.

Fix: In the policy with the Sign-in frequency control, either raise the value (Microsoft’s documentation recommends not going below a few hours for general productivity), or scope the policy to specific high-risk resources rather than all of Microsoft 365. Sign-in frequency is genuinely useful for Azure portal access, banking apps, and similar — it’s not useful for Outlook.

Cause 2: Two Conditional Access policies fighting each other

This one is brutal to diagnose without the sign-in log. You have two CA policies that each require MFA, and they’re not aware of each other. Policy A grants access if MFA is completed; Policy B has a session control that re-evaluates frequently and re-requests MFA. Each token issued by Policy A is invalidated by Policy B’s evaluation, and the user loops.

Fix: Audit your CA policies. Identity → Conditional Access → Policies → Insights and reporting can show you which policies are co-firing. The architecturally correct answer is: one policy enforces MFA for the relevant scope, and other policies grant or deny based on the result, rather than re-requiring MFA. Multiple “Require MFA” policies on overlapping scopes is a smell.

Cause 3: AzureADPrt: NO on the device

If the user’s device shows AzureAdPrt: NO in dsregcmd /status, the device cannot acquire and hold a Primary Refresh Token. Without a PRT, every sign-in is treated as a cold authentication, and Conditional Access policies that require MFA will fire on every cold authentication. The user experiences this as a loop.

Fix: Repair the PRT state. The mechanics are the same as the CAA50021 admin checklist — delete the MS-Organization-Access certificate, run dsregcmd /leave from elevated command prompt, reboot, and have the user re-sign-in to register cleanly. PRT state and CAA50021 share the same root cause family.

Cause 4: The “trusted IPs” trap (legacy MFA settings)

Microsoft Entra has two distinct settings for trusted networks: the modern Named locations in Conditional Access, and the legacy Multi-factor authentication trusted IPs under per-user MFA service settings. These are not the same thing, they don’t always cooperate, and they can produce loops if both are configured with conflicting values.

If you have legacy trusted IPs configured (visible at the bottom of the Per-user MFA → service settings page, the old portal), but your office IP isn’t in them, and you also have a Conditional Access policy that uses trusted Named Locations, the policies can disagree about whether the user is on a trusted network and require MFA for every authentication request.

Fix: Microsoft’s current recommendation is to stop using the legacy trusted IPs setting entirely. Move all trust decisions to Named Locations under Conditional Access. The legacy setting predates Conditional Access by years and is mostly a trap for tenants that have been around long enough to have inherited it.

Cause 5: Continuous Access Evaluation revoking tokens

Continuous Access Evaluation (CAE) is the feature where Entra can revoke an access token mid-session if it detects a state change (user disabled, password changed, IP location changed, etc.). When CAE revokes, the client must re-authenticate. Almost always this is correct — but if your network setup causes the user’s apparent IP to change frequently (hopping between Wi-Fi and a VPN, or behind a load-balancer that doesn’t have a stable egress IP), CAE may revoke on every IP change.

Fix: This is rare but real. Check the sign-in logs for the affected user — under Activity Details, the Original Transfer Method field will show “CAE-revoked” or similar if this is the cause. The fix is to stabilise the user’s network egress, or to scope the CAE strict location enforcement to specific high-risk apps rather than all of Microsoft 365.

Cause 6: Federated identity provider not returning the MFA claim

If your tenant federates authentication to AD FS, Okta, Ping, or another IdP, MFA can be completed at the IdP and passed to Microsoft Entra as a claim in the SAML token. If the IdP isn’t configured to send the multipleauthn claim (or equivalent), Entra doesn’t recognise that MFA was performed, and Conditional Access requires it again — causing the loop.

Fix: This is on the IdP configuration side. For AD FS, check the issuance transform rules to confirm the MFA claim is being passed through. For Okta, check the Microsoft Office 365 application configuration to confirm MFA is being asserted. The Microsoft Learn article on supported claims for federated identity lists the specific claims required.

Cause 7: Modern Authentication disabled on Exchange Online

Almost no current tenant should still have this issue, because Microsoft retired Basic Authentication for Exchange Online in late 2022 and forced everyone onto Modern Auth. But if your tenant has somehow ended up with Modern Auth disabled for Exchange Online (or for specific protocols), Outlook will fall back to legacy authentication, which doesn’t support modern MFA flows, which causes loops as Outlook tries to authenticate, fails, retries, and prompts again.

Fix: Confirm Modern Auth is enabled. From Exchange Online PowerShell: Get-OrganizationConfig | Format-List OAuth*. Both OAuth2ClientProfileEnabled should be True. If False, enable it. The legacy Set-OrganizationConfig -OAuth2ClientProfileEnabled $true toggle is still there.

What this looks like in the sign-in logs

The signature pattern in Sign-in logs for a real MFA loop case is:

  • Same user, same client app (e.g. “Microsoft Outlook”), same IP, same device.
  • Multiple events within 1–10 minutes of each other.
  • Status: Success on the first event, then alternating success/failure, or all success.
  • Conditional Access tab on each event shows the same policy applying and requiring MFA.

If your pattern doesn’t look like this — for example, if the events are spread hours apart, or come from different devices — you’re probably not looking at a real loop. You may be looking at normal MFA prompts for users who are signing in across multiple devices throughout the day.

What not to do

  • Don’t tell the user to reinstall Microsoft Authenticator. It does not affect the loop.
  • Don’t tell the user to clear cookies. It does not affect the loop.
  • Don’t disable MFA “as a test”. This is a security regression and won’t survive a sensible security review. If you must rule out MFA as the variable, use a Conditional Access exclusion for the one user, not a tenant-wide disable.
  • Don’t delete and recreate the user. This will probably fix the loop because it resets every state, but it also wipes their data.
  • Don’t reset their password. Same logic. The password isn’t the problem.
  • CAA50021 admin checklist — when device PRT state is the underlying issue
  • Microsoft 365 MFA prompt loop (end-user) — what the user sees and the limited set of things they can try
  • Conditional Access blocked sign-in — when CA blocks rather than loops

Official references

FAQ

Why does the loop only happen for some users and not others?

Conditional Access policies are scoped to specific users, groups, or roles. The users in the loop are inside the scope of the offending policy; users outside the scope behave normally. Identifying which group or role distinguishes the affected users is half the diagnosis.

Will deleting and recreating the Conditional Access policy fix it?

Sometimes — but only if the policy was in a corrupted state, which is rare. More commonly, deleting and recreating an identical policy reproduces the loop. Fix the misconfiguration, don’t recreate the policy.

My users say the loop only happens in Outlook, not in the web. Why?

Outlook desktop authenticates differently from the browser — it uses Modern Auth via OAuth2, which has different session lifetime behaviour. If the loop is desktop-only, suspect Cause 3 (PRT state) or Cause 7 (Modern Auth disabled) first. Browser sessions get web-based session cookies that survive longer.

Is “remember MFA on this device” supposed to stop the loop?

That setting (in legacy MFA service settings) tells Entra not to re-prompt for MFA on a remembered device for a configurable number of days. It can mask a loop temporarily — but if your underlying CA policy still requires MFA on every authentication, the remembered-device setting is overridden by the CA policy. Don’t rely on it as a fix.

Can I just exempt a user from Conditional Access while I diagnose?

Yes — temporarily. Add the user to the policy’s exclusion list, confirm the loop stops, and now you’ve confirmed the policy is involved. Don’t leave the exclusion in place; remove it once you’ve identified and fixed the policy issue.

My loop appeared overnight. What changed?

Check your Conditional Access policy audit log: Entra → Identity → Monitoring & health → Audit logs, filter by category “Policy”. Look for any policy modifications in the last 72 hours. If your tenant uses Intune, also check whether a compliance policy was tightened. If neither shows changes, check whether Microsoft pushed a service-side update that affects MFA behaviour — these are rare but documented in Microsoft 365 message centre.

Does this guide apply to per-user MFA as well as Conditional Access MFA?

The mechanics are slightly different. Per-user MFA (the legacy model where individual users have MFA enabled directly) doesn’t use Conditional Access policies, so the loop pattern from Causes 1, 2, and 6 doesn’t apply. But Causes 3, 4, 5, and 7 still do. Microsoft has been pushing tenants to migrate from per-user MFA to CA-based MFA for years; if you haven’t yet, this is one more reason to.

↑ Back to top