Fixing MFA and Passwordless Sign-In Failures: Registration, Methods Policy, and Number Match

The ticket says “I can’t log in.” That is the least useful sentence in identity support, because Microsoft Entra ID can refuse a sign-in at half a dozen different gates and every one of them looks the same to the user: a screen they can’t get past. Sometimes the password was fine but MFA registration never completed, so the user is trapped on “More information required” with no method to add. Sometimes the method was fine but the number-match push never arrived, or arrived and the user typed the wrong two digits. Sometimes a brand-new passkey enrolment is greyed out because the Authentication methods policy doesn’t allow it for that user’s group. Sometimes Conditional Access demands phishing-resistant MFA the user simply does not have. Same symptom, six root causes, six fixes — and the only way to tell them apart is to read the right signal.

This is the diagnostic playbook for that whole class of failure. We treat can’t-register, push-never-arrives, wrong-number-match, passkey-greyed-out, and Conditional-Access-blocked not as one bug but as distinct symptom classes, each with its own confirming evidence: a specific AADSTS code in the sign-in logs, a setting in the Authentication methods policy, or a row in the registration details report. Every diagnosis comes with the exact place to confirm it — an az rest/Graph call, a log filter, or a portal path — and the precise fix, laid out as scannable tables for the moment you reach for this with a locked-out VIP on the phone.

By the end you will stop guessing. When “I can’t log in” lands, you will know within two minutes whether you face an unregistered user, a method the policy doesn’t permit, a push suppressed by number-match changes, System-Preferred MFA picking a method the user can’t satisfy, a stale authentication strength, or simply a user who needs a Temporary Access Pass to bootstrap a passkey — the difference between a thirty-second fix and a two-hour escalation that resets MFA for an account that was never broken.

What problem this solves

Entra hides the machinery so that, when it works, a user types a password, approves a prompt, and they are in. That abstraction is a gift until it breaks — then the generic blue error screen tells the user (and the agent over their shoulder) almost nothing, because exposing why auth failed to a half-authenticated caller would be a security leak. The real reason is captured and precise, but it lives in the sign-in logs, the Authentication methods policy, and the registration details report — and if you don’t know which maps to which failure, you burn an hour clicking through the admin centre while the user waits.

What breaks without this knowledge is expensive: an agent “resets MFA” for a user whose MFA was fine (deleting working methods, creating a new registration gap), re-issues a password (when the password was never the problem), or files a support case and waits a day. Meanwhile the actual cause — a group excluded from the passkey policy, a per-user MFA state fighting Conditional Access, a number-match prompt the user keeps dismissing, or an MFA-registration policy blocking the very registration it requires — sits there, perfectly diagnosable, ignored.

Who hits this: every org past password-only, which is nearly all of them. It bites hardest during three transitions — turning on number matching (mandatory since February 2023, so “Approve/Deny” muscle memory breaks), rolling out passwordless/passkeys (registration prerequisites trip people constantly), and migrating off the legacy per-user MFA and SSPR policies to the unified Authentication methods policy (where settings silently move and old toggles stop applying). The fix is almost never “reset the user” — it is “find the gate refusing them and read what it’s actually saying.”

Every symptom class this article covers, the question it forces, and the one place to look first:

Learning objectives

By the end of this article you can:

• Map any “I can’t log in” MFA report to a specific gate — registration, method availability, delivery, number match, System-Preferred MFA, or Conditional Access — and name the most likely cause for each.
• Read the Entra sign-in logs to pull the exact AADSTS code and the Conditional Access result for a failed sign-in, and tell an interrupt (registration required) from a failure (method refused).
• Inspect and change the Authentication methods policy with Microsoft Graph (az rest) to confirm whether a method (Authenticator, FIDO2/passkey, SMS, TAP) is enabled, and for which groups.
• Diagnose why number matching “broke” pushes, why additional context isn’t showing, and why a user keeps failing the two-digit entry.
• Break a passkey/FIDO2 registration failure into its real cause: method disabled, AAGUID key-restriction, no Temporary Access Pass to bootstrap, browser/OS unsupported, or attestation enforced.
• Resolve the conflict between legacy per-user MFA, the SSPR policy, and the unified Authentication methods policy, and complete the migration cleanly.
• Diagnose a Conditional Access block driven by an authentication strength (phishing-resistant MFA) or an MFA registration policy, and fix it without locking out break-glass accounts.

Prerequisites & where this fits

You should already understand the Entra basics: a tenant is your directory; users sign in to it; MFA adds a second proof beyond the password; and an authentication method (Microsoft Authenticator push, passkey/FIDO2, SMS, voice, OATH/TOTP, Temporary Access Pass) is the thing that proves it. Background lives in Microsoft Entra ID Fundamentals: Tenants, Users, Groups & RBAC and the wider authentication picture in Authentication in Azure: SSO, MFA, Passwordless & Conditional Access. You should be comfortable running az in Cloud Shell, reading JSON, and calling Graph via az rest.

This sits in the Identity & access track, in its troubleshooting wing. It assumes the why of phishing-resistant MFA from Authenticator Passkeys and Number Matching: Stopping MFA Fatigue Attacks, and pairs with the rollout mechanics in Rolling Out FIDO2 Passwordless Authentication in Entra ID: Security Keys, Passkeys, and Windows Hello for Business and Rolling Out Phishing-Resistant Passwordless Auth: FIDO2, Passkeys, and Break-Glass Design, because half of these failures appear during a rollout. The enforcement layer is Conditional Access — deployed safely in Deploying Conditional Access Safely: Report-Only Rollout to Enforcement and at scale in Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters.

Know which blade owns which decision, so you open the right one first:

Core concepts

Six mental models make every later diagnosis obvious.

Registration and authentication are different events that fail differently. Registration is the one-time act of adding a method at aka.ms/mysecurityinfo (Combined registration); authentication is using one to satisfy a sign-in. A user with no method can’t do MFA — but that shows up as an interrupt (“More information required”), not a denial. The first fork: does this user have a usable method at all, or one being refused? The registration details report answers the first; the sign-in logs the second.

The Authentication methods policy decides what’s allowed; Conditional Access decides what’s required. Two engines that fail in opposite ways. The methods policy is an allow-list — a method is absent if it isn’t enabled for the user’s group (symptom: “the option isn’t there”). Conditional Access is a gate — it can require a method or authentication strength the user doesn’t hold (symptom: “I got blocked”). Mixing these up sends you to the wrong blade for an hour.

Number matching changed the push contract, and it is not optional. Since February 2023, number matching is enforced for all Authenticator push tenant-wide — tap-to-approve is gone. The sign-in screen shows a two-digit number the user must read and type into the app; if they can’t see the screen or they guess, it fails. Many post-2023 “push is broken” tickets are really “the user doesn’t know to read the number.” Additional context (app name + location in the prompt) is a related, separately-toggled setting.

System-Preferred MFA promotes the strongest method automatically. Entra defaults to prompting the most secure method the user registered (passkey > Authenticator push > phone). Good security, but it surprises people — someone who “always used SMS” is suddenly asked for Authenticator because they once registered it, and if that registration is broken they’re stuck while a working SMS sits unused.

Passwordless registration has prerequisites and a chicken-and-egg trap. A passkey (a phishing-resistant FIDO2 credential on a security key, a platform authenticator, or device-bound in Authenticator) registers only if the methods policy enables it, the AAGUID key-restriction (if set) permits the model, and the user can already sign in strongly enough to reach registration. That last point is the trap — the escape hatch is a Temporary Access Pass (TAP), a time-limited passcode an admin issues to bootstrap the first strong credential.

The legacy MFA and SSPR settings still exist and still bite. Tenants ran per-user MFA (the old Enabled/Enforced state) and the SSPR registration policy for years; they coexist with the unified methods policy and contradict it — a user Enforced for per-user MFA can be double-prompted under CA, and a method registered only for SSPR may not count for MFA. The fix is the migration to the unified policy; until then, these overlaps cause “works for some users, not others.”

Every term above is defined for lookup in the Glossary at the end; the deep sections from here assume the six models.

The AADSTS error-code reference

Before the per-symptom anatomy, here is the lookup you scan first — the AADSTS codes you realistically see for MFA, registration and method failures, what each means on this platform, where to confirm it, and the first fix. The non-obvious ones are 50079 (registration required, no method) versus 50074/50076 (MFA required but not satisfied), 500121 (the catch-all for “push timed out / number wrong / denied”), and 530031 (auth-strength gap) versus 53003 (generic CA block). Treat the AADSTS code as the front door to the whole diagnosis.

Three reading notes that save the most time:

Symptom 1 — The user can’t register a method

The user lands on “More information required” (or aka.ms/mysecurityinfo) and either sees no way to add a method, or the add fails. Three causes — scan, then read the matching detail:

Cause 1 — The method isn’t enabled for the user

The tile is absent from Security info because the Authentication methods policy doesn’t target that user’s group for that method — the user isn’t broken, the policy never offered the option. Confirm by reading the method’s config and its target (Graph is the source of truth; the portal hides per-group detail):

# Read the Microsoft Authenticator method config (state + who it targets)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator" \
  --query "{state:state, includeTargets:includeTargets}"

If state is disabled, or includeTargets doesn’t contain a group the user is in, that’s why the tile is missing. Fix: enable the method and include the user’s group (or all_users):

az rest --method PATCH \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator" \
  --headers "Content-Type=application/json" \
  --body '{
    "@odata.type": "#microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration",
    "state": "enabled",
    "includeTargets": [ { "targetType": "group", "id": "<group-object-id>", "isRegistrationRequired": false } ]
  }'

The complete method set, with what each is for and the gotcha that most often hides the tile:

Cause 2 — A Conditional Access policy blocks the registration flow

The cruel one: a Conditional Access policy meant to secure sign-in accidentally blocks the user from registering the method it requires — either a broad “require MFA / compliant device for all apps” policy catches the registration interaction, or a purpose-built “MFA registration” policy is mis-scoped to require MFA to register MFA, an impossible loop for a user with no method yet. Confirm by reading the failed sign-in’s Conditional Access tab; the flow shows as the user action “Register security information.”

# Recent failed/interrupted sign-ins for one user, with the CA-relevant fields
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$top=10&\$filter=userPrincipalName eq 'amir@contoso.com'" \
  --query "value[].{time:createdDateTime, app:appDisplayName, code:status.errorCode, reason:status.failureReason}" -o table

In the portal, the event’s Conditional Access tab shows each policy as Success / Failure / Not applied; a policy in Failure against the registration action is your culprit.

Fix. Issue a Temporary Access Pass (Symptom 3) as the bootstrap so the user can satisfy the policy and register, and exclude the registration user-action from device-compliance grants. The Conditional Access mechanics here are exactly what Deploying Conditional Access Safely: Report-Only Rollout to Enforcement walks through — run the policy report-only first and read who it would have blocked.

Cause 3 — The legacy per-user MFA / SSPR split confuses registration

In tenants that haven’t finished the migration, a method registered for SSPR (password reset) may not count for MFA, or per-user MFA interrupts with the old registration UX instead of Combined registration — users register “something” and it doesn’t help where they need it. Confirm by checking the migration state:

# Read the top-level Authentication methods policy (includes migration state)
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy" \
  --query "{policyVersion:policyVersion, migrationState:policyMigrationState}"

If policyMigrationState is preMigration or migrationInProgress, the legacy policies still partly govern behaviour.

Fix. Move each method into the unified Authentication methods policy, verify parity, then set the migration to complete (migrationComplete). After migration, registration is unified and a method counts for both MFA and SSPR wherever it’s enabled — ending the split where a method registered under the legacy SSPR policy didn’t satisfy an MFA prompt.

Symptom 2 — The push never arrives (or number match fails)

The user reaches the approval step but the push never shows, or it shows and the two-digit number entry fails. Since number matching is enforced, this class changed shape in 2023. Five causes follow — notifications off/stale app, number-match confusion, a blocked push-service path, missing additional context, and clock-skewed TOTP (rows 5–7 and 12–13 of the centerpiece playbook).

Cause 1 — Notifications are off or the app is out of date

The plainest and most common cause: Authenticator notifications are disabled, the app predates number matching, the device is in Focus/Do-Not-Disturb, battery optimisation restricts it (Android), or the account was removed. A 500121 in the sign-in log with the user never completing corroborates a delivery problem (not a denial). Confirm and fix on the device: allow Authenticator notifications (disable Focus/DND), update the app, exclude it from battery optimisation, and re-add the account if missing (re-register via mysecurityinfo).

Cause 2 — Number-match confusion (the post-2023 classic)

Number matching is enforced, so the browser shows a two-digit number the user must read and type into the app. Users trained on tap-to-approve don’t look at the browser, sign in on the same phone (so they can’t see the number while in the app), or simply guess — the app says “that didn’t work,” and they conclude push is broken. Confirm: this is a coaching diagnosis — if the user describes only “Approve/Deny,” their app is stale (Cause 1); if they see a keypad but keep failing, it’s match confusion. The sign-in log shows 500121.

Fix. Coach the flow: read the two-digit number from the device showing the sign-in screen (usually the browser), then type it in Authenticator. There is no setting to “turn off” number matching — it is permanent, so stop hunting for the toggle; if the user has no screen to read the number from, fall back to voice or a verification code.

Cause 3 — The push-service path is blocked on the network

Push delivery rides APNs (Apple) and FCM (Google) plus Microsoft endpoints, so a locked-down corporate network or a misbehaving MDM/proxy can block it — pushes arrive on cellular but never on Wi-Fi. Confirm by reproducing on cellular (disable Wi-Fi); if the push arrives, the network is the cause. Fix by allowing the push endpoints in the firewall/proxy and excluding Authenticator from MDM traffic interception; as a fallback, a code-based method (TOTP / verification code in the app) needs no inbound push.

Cause 4 — Additional context is off, so users distrust the prompt

Additional context shows the application name and sign-in location in the prompt. Without it, a legitimate prompt looks identical to a malicious one, so security-aware users deny real sign-ins — less “push broken” and more “push denied wrongly.” Confirm by reading the Authenticator policy’s displayAppInformationRequiredState and displayLocationInformationRequiredState:

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator" \
  --query "featureSettings"

Fix. Enable both context settings and target the relevant group. The threat model behind this — why context plus number matching defeats push-bombing — is the subject of Authenticator Passkeys and Number Matching: Stopping MFA Fatigue Attacks.

Cause 5 — Clock skew breaks the TOTP fallback

When the user falls back to a verification code (TOTP / OATH), the 30-second code is time-based, so a phone clock off by more than ~30–90 seconds makes every code “incorrect” — looking like a broken method. Confirm by comparing device time to network time; fix by turning on automatic date and time so the clock syncs, then retry. This affects code-based methods only — push and passkey aren’t time-code-based.

Symptom 3 — Passkey or FIDO2 registration is greyed out or fails

The user tries to add a passkey (in Authenticator, on a security key, or a platform authenticator) and the option is missing, disabled, or registration errors. Four causes follow — the method disabled in policy, an AAGUID key-restriction excluding the device, no way to bootstrap (chicken-and-egg), and an unsupported browser/OS/attestation (rows 2–4 of the centerpiece playbook).

Cause 1 — The passkey method is disabled in policy

Passkey/FIDO2 is off until you explicitly enable it in the Authentication methods policy, so by default the “Add passkey” path doesn’t exist. Confirm by reading the FIDO2 method config:

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2" \
  --query "{state:state, attestation:isAttestationEnforced, restrictions:keyRestrictions, targets:includeTargets}"

state: disabled is the cause. Fix: enable FIDO2 and target the group — and set the two enforcement knobs (attestation and key restrictions) deliberately:

az rest --method PATCH \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/Fido2" \
  --headers "Content-Type=application/json" \
  --body '{
    "@odata.type": "#microsoft.graph.fido2AuthenticationMethodConfiguration",
    "state": "enabled",
    "isAttestationEnforced": false,
    "isSelfServiceRegistrationAllowed": true,
    "keyRestrictions": { "isEnforced": false, "enforcementType": "allow", "aaGuids": [] },
    "includeTargets": [ { "targetType": "group", "id": "<group-object-id>" } ]
  }'

The full FIDO2/passkey policy knobs and what each one breaks if set wrong:

Cause 2 — An AAGUID key-restriction excludes the device

Each FIDO2 model has an AAGUID (a 128-bit identifier). With key restrictions set to allow a specific list, any model not on it is refused — classically the Authenticator app’s own device-bound passkey AAGUID, which teams forget to add, so enabled-but-restricted looks identical to “broken.” Confirm via keyRestrictions: isEnforced: true, enforcementType: allow, and the user’s AAGUID absent from aaGuids is the block.

Fix. Add the AAGUID(s) to the allow-list (allow admits only listed models, so forgetting one silently blocks it), switch to a block-list (block refuses only listed models, admits the rest), or set isEnforced: false for a broad rollout.

Cause 3 — The bootstrap chicken-and-egg (no TAP)

To register a passkey securely a user often needs to already be authenticated strongly — but a brand-new or freshly-reset user has no strong method yet, so they can’t sign in to reach registration and can’t register because they can’t sign in. Onboarding stalls here for every new passwordless user. Confirm: the user has no usable method (registration report empty) and Conditional Access requires strong auth to reach registration — 53004 (“must set up strong auth”) or a registration interrupt with nothing to satisfy it.

Fix. Issue a Temporary Access Pass (TAP) — a time-limited passcode that itself satisfies MFA, letting the user sign in once and register a passkey. Enable TAP in the policy, then issue one:

# 1) Ensure TAP is enabled in the Authentication methods policy
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/TemporaryAccessPass" \
  --query "{state:state, defaultLifetimeMinutes:defaultLifetimeInMinutes, isUsableOnce:isUsableOnce}"

# 2) Issue a TAP for the user (admin needs Authentication Administrator)
az rest --method POST \
  --url "https://graph.microsoft.com/v1.0/users/amir@contoso.com/authentication/temporaryAccessPassMethods" \
  --headers "Content-Type=application/json" \
  --body '{ "lifetimeInMinutes": 60, "isUsableOnce": false }'

The response includes the temporaryAccessPass value — hand it to the user over a verified channel. The TAP settings and what each controls:

The TAP-to-passkey onboarding is exactly the flow detailed in Rolling Out FIDO2 Passwordless Authentication in Entra ID: Security Keys, Passkeys, and Windows Hello for Business.

Cause 4 — Browser, OS, or attestation isn’t supported

The FIDO2 registration ceremony runs in the browser against the OS/authenticator, so an unsupported browser/OS combination, a key the org’s attestation enforcement rejects, or a platform that can’t do device-bound passkeys yet all error mid-ceremony. Confirm by the WebAuthn/browser error or that it fails only on certain devices (if isAttestationEnforced: true, keys lacking valid attestation metadata are refused). Fix by using a supported current browser/OS; for trusted keys without attestation, set isAttestationEnforced: false deliberately, and match the authenticator to the platform — device-bound passkeys in Authenticator, security keys, or platform authenticators (Windows Hello / Apple / Google), as covered in Rolling Out Phishing-Resistant Passwordless Auth: FIDO2, Passkeys, and Break-Glass Design.

Symptom 4 — System-Preferred MFA prompts a method the user can’t use

The user complains Entra asks for a method they “don’t use” — typically Authenticator when they expected SMS. System-Preferred MFA (on by default) prompts the strongest registered method, so a once-registered, now-broken Authenticator shadows a working phone. Confirm by reading the user’s registered methods (the registration details report, or Graph):

# What methods has this user actually registered?
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/users/amir@contoso.com/authentication/methods" \
  --query "value[].{type:'@odata.type'}" -o table

Check the System-Preferred setting on the Authenticator policy:

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator" \
  --query "featureSettings.numberMatchingRequiredState"

Fix. The right fix is to repair or remove the broken strongest method so System-Preferred promotes the working one — not to disable System-Preferred (which is a security regression). If a user genuinely should use a weaker method, remove the stronger registration. The promotion order Entra uses (strongest first):

So a user who registered Authenticator long ago (now broken) but still has working SMS is correctly prompted for the Authenticator they can’t satisfy — repair or remove it and SMS gets promoted. A user prompted for a passkey they “forgot” simply has the strongest method they own. Only-SMS users get SMS; that’s working as intended.

Symptom 5 — Conditional Access blocks the sign-in

The user authenticates fine but is blocked by a grant they can’t satisfy — most often a Conditional Access authentication strength demanding phishing-resistant MFA the user doesn’t have, or an MFA-required grant on a resource. The status code is 53003 (generic block) or 530031 (auth-strength gap).

Confirm. Open the failed sign-in and read the Conditional Access tab — it names every policy, the grant control, and whether it passed, failed, or was report-only:

# Pull the sign-in and surface the CA failure reason + status code
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$top=5&\$filter=userPrincipalName eq 'amir@contoso.com' and status/errorCode ne 0" \
  --query "value[].{time:createdDateTime, code:status.errorCode, reason:status.failureReason, ca:conditionalAccessStatus}" -o table

A conditionalAccessStatus of failure, with 530031, means an authentication strength wanted a stronger method than the user holds.

Fix. Either give the user a qualifying method (register a passkey so they can satisfy a phishing-resistant strength), or — if the policy is over-scoped — correct it. Always exclude break-glass accounts from every blocking policy so a CA mistake never locks you out entirely. The grant controls that produce these blocks and how to satisfy each:

The auth-strength built-ins, and which methods satisfy each — so you know instantly whether a user can pass:

Getting the right users to hold the right strength is the subject of Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters.

Architecture at a glance

Picture the sign-in as a relay of five gates between the user and the app, each MFA failure class living at exactly one gate. First the password gate (out of scope — assume it’s right). Then the registration gate: “does this identity have a usable, registered method?” — if not, Entra doesn’t deny, it interrupts with “More information required” and routes to Combined registration. Third is method availability: a registered user can only use methods the Authentication methods policy enables for their group — a disabled or un-targeted method is simply absent. Fourth is delivery and proof: the method must work end-to-end — the push arrives and the user reads the number-match digits, or the passkey ceremony completes, or the TOTP code is in time. Fifth is Conditional Access: even a perfectly proven sign-in is blocked if a grant — most sharply an authentication strength — demands a stronger method than the user holds.

The whole method is “which gate refused, and what is it saying?” The AADSTS code names the gate: 50079/50072 is the registration gate (no method), 500121 is the delivery/proof gate (method exists, not completed), 530031 is the Conditional Access gate (method too weak). Crucially, the registration gates interrupt rather than block — the logs mark them “interrupted,” not “failure,” your fastest tell that the user must finish a flow, not be granted something. Every path converges on the same three instruments — the sign-in logs, the Authentication methods policy, and the registration details report.

Real-world scenario

Nimbus Financial, a 1,400-seat fintech in Central India, ran a six-week programme to move admins and finance to phishing-resistant sign-in: passkeys in Microsoft Authenticator, enforced by a Conditional Access authentication strength. The identity team was three engineers, already past number matching and mid-migration from the legacy per-user MFA/SSPR policies to the unified Authentication methods policy.

Week three is when tickets spiked. Forty-odd newly onboarded finance staff reported the same thing: “I can’t finish setting up my login.” The help-desk reflex was to reset MFA, which made it worse — it deleted whatever the users had started and dropped them to zero. By Thursday the queue had a VP of Finance in it.

The breakthrough was reading the sign-in logs instead of trusting the symptom. Every stuck user showed the same pattern: an interrupt (not a failure) routing to Register security information, and on that event a Conditional Access policy in Failure — the team’s own “Require phishing-resistant MFA for Finance” strength was scoped to all Finance apps including the registration interaction. New users had no passkey yet (that’s what they were registering), so the strength they couldn’t meet was blocking the very page where they’d meet it. Classic chicken-and-egg, dressed up as “MFA is broken.” A smaller cluster failed differently: their “Add passkey” was greyed out — the team had enabled passkeys in Authenticator but set AAGUID key-restrictions to an allow-list of two hardware keys and forgotten the Authenticator-app AAGUID.

The fix landed in two moves. Immediately: issue Temporary Access Passes (60-minute, multi-use) so users could satisfy MFA once, reach registration, and enrol a passkey — and add the Authenticator AAGUID to the allow-list so the device-bound passkey could register. Structurally: re-scope the strength so the registration action is reachable with a TAP (and go report-only for a week first next time), and finish the migration so the SSPR split stopped registering methods that didn’t count for MFA. Onboarding went from ~5 stuck users a day to zero; the new runbook reads, in bold, “Issue the TAP first. A user with no method cannot pass a policy that requires one.”

The incident as a timeline, because the order of moves is the lesson:

Advantages and disadvantages

The unified, policy-driven Entra authentication model both causes this class of problem and makes it diagnosable. Weigh it honestly:

The model is right for any org serious about identity assurance: the controls that bite (number match, passkeys, auth-strengths) are exactly the ones that stop real attacks. The disadvantages are all manageable once you know they exist — issue the TAP, add the AAGUID, scope the strength to leave registration reachable, finish the migration.

Hands-on lab

Inspect the live policy that governs all of this, then safely toggle a method and issue a Temporary Access Pass — all free-tier-friendly on a test user. You need Authentication Policy Administrator (or higher) and a non-admin test user. Run in Cloud Shell (Bash). Nothing here costs money; Entra MFA configuration is included with the directory.

Step 1 — Sign in and confirm your context.

az login --only-show-errors -o none
az ad signed-in-user show --query "{me:userPrincipalName}" -o table

Step 2 — Read the top-level Authentication methods policy and its migration state.

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy" \
  --query "{version:policyVersion, migration:policyMigrationState}"

Expected: a policyMigrationState of preMigration, migrationInProgress, or migrationComplete. If it isn’t migrationComplete, legacy settings still partly apply.

Step 3 — Inspect each method’s state and targeting.

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations" \
  --query "value[].{method:id, state:state}" -o table

Expected: rows for MicrosoftAuthenticator, Fido2, Sms, TemporaryAccessPass, etc., each enabled or disabled. This is the allow-list every “missing tile” traces back to.

Step 4 — Check whether your test user has any registered method (the registration gate).

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/users/<test-user-upn>/authentication/methods" \
  --query "value[].'@odata.type'" -o table

Expected: a list (possibly just passwordAuthenticationMethod — a password-only user hits the registration interrupt at MFA).

Step 5 — Confirm TAP is enabled, then issue one for the test user.

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/TemporaryAccessPass" \
  --query "{state:state, default:defaultLifetimeInMinutes}"

az rest --method POST \
  --url "https://graph.microsoft.com/v1.0/users/<test-user-upn>/authentication/temporaryAccessPassMethods" \
  --headers "Content-Type=application/json" \
  --body '{ "lifetimeInMinutes": 60, "isUsableOnce": false }' \
  --query "{tap:temporaryAccessPass, startsAt:startDateTime, lifetime:lifetimeInMinutes}"

Expected: a temporaryAccessPass value. The test user can now sign in with it and register a passkey — the bootstrap that breaks the chicken-and-egg. (If TAP state is disabled, enable it first via PATCH, as in Symptom 4.)

Step 6 — Read the test user’s recent sign-ins and surface any AADSTS codes.

az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$top=5&\$filter=userPrincipalName eq '<test-user-upn>'" \
  --query "value[].{time:createdDateTime, code:status.errorCode, reason:status.failureReason, ca:conditionalAccessStatus}" -o table

Expected: recent attempts with their errorCode — the gate-identifier you map with the AADSTS reference table.

Validation checklist. You read the policy and migration state, enumerated allowed methods, confirmed whether a user has a usable method, issued a TAP to bootstrap passwordless, and pulled the AADSTS codes that name each gate — the whole diagnostic loop without touching production users.

Cleanup. Revoke the test TAP if you won’t use it (delete the method by its id), and revert any method state you changed for the lab:

# List the user's TAP method ids, then delete the one you issued
az rest --method GET \
  --url "https://graph.microsoft.com/v1.0/users/<test-user-upn>/authentication/temporaryAccessPassMethods" \
  --query "value[].id" -o tsv
# az rest --method DELETE --url ".../temporaryAccessPassMethods/<id>"

Cost note. Nothing in this lab incurs charges — MFA, the Authentication methods policy, TAP and sign-in logs are part of the directory. (Some advanced controls such as Conditional Access and Identity Protection require Entra ID P1/P2 licensing, covered under Cost & sizing.)

Common mistakes & troubleshooting

This is the playbook — the part you bookmark, a scannable table you can read with a locked-out VIP on the phone. It spans the basic failures (push off, wrong number, method disabled) and the advanced ones (CA blocks registration, AAGUID restriction, mid-migration split, System-Preferred shadowing); the full reasoning for each row is in the matching Symptom section above.

The full reasoning for each row lives in the matching Symptom section above; the table is the scannable centerpiece. Two entries hide a subtlety worth stating outright:

• Row 1 (registration loop) is the most-misdiagnosed. It looks like “MFA is broken,” but the user is being interrupted, not failed — a Conditional Access policy is blocking the Register security information action, and the reflex “reset MFA” makes it worse. Read the Conditional Access tab, then issue a TAP so the user can satisfy the grant and register.
• Row 3 (AAGUID) catches teams that did everything else right. Enabling passkeys-in-Authenticator but leaving an allow-list that omits the Authenticator-app AAGUID greys out registration with no error explaining why; the only tell is keyRestrictions showing isEnforced:true, enforcementType:allow, AAGUID absent.

Best practices

• Read the sign-in log before you touch the user. The AADSTS code and Conditional Access tab name the failing gate in seconds; “reset MFA” without reading the log destroys working state and often fixes nothing.
• Issue the TAP first for passwordless onboarding. A user with no method cannot pass a policy that requires one — bake a 60-minute, multi-use Temporary Access Pass into the onboarding runbook.
• Scope auth-strength policies to leave registration reachable. Never let a “require phishing-resistant MFA” strength block the Register security information action — that’s the page where users get the method.
• Add every authenticator’s AAGUID you intend to support. If you enforce a FIDO2 allow-list, include the Authenticator-app AAGUID and each key model — an omitted AAGUID silently greys out registration.
• Finish the migration to the unified methods policy and retire the legacy per-user MFA and SSPR policies; don’t run both engines, or a per-user Enforced account plus a CA MFA grant double-prompts.
• Keep System-Preferred MFA on; fix the method, not the feature. Repair or remove the broken stronger method — disabling System-Preferred is a security regression.
• Coach number matching as a first-line script. Most post-2023 “push broken” tickets are users not reading the two-digit number; a one-line script resolves them without escalation.
• Enable additional context (app + location) to fight fatigue attacks and stop security-aware users denying their own legitimate sign-ins.
• Always exclude break-glass accounts from blocking policies — two cloud-only, monitored emergency accounts, so a policy mistake never locks the whole tenant out.
• Use report-only before enforcing any new grant. The report-only column shows exactly who would have been blocked, including the registration interaction — your last safety net.

Security notes

• Least-privilege admin roles. Issuing TAPs and editing methods needs Authentication Administrator / Authentication Policy Administrator, not Global Admin; scope helpdesk to Authentication Administrator (non-privileged users only) and protect privileged-role activation behind PIM for Entra Roles: Just-in-Time Activation, Approvals, and Security Alerts.
• TAP is a powerful bypass — treat it like a credential. It satisfies MFA, so keep lifetimes short, prefer one-time where the flow allows, hand it over only via a verified channel, and alert on issuance — a leaked TAP is a full account takeover.
• Phishing-resistant by default for admins. Require the phishing-resistant MFA strength for every privileged role — passkeys/FIDO2/WHfB resist the relay and fatigue attacks that defeat push and SMS (Authenticator Passkeys and Number Matching: Stopping MFA Fatigue Attacks).
• Retire SMS and voice as primary methods — they are SIM-swappable and OTP-phishable; move users up the strength ladder to Authenticator passwordless and passkeys.
• Don’t let the help-desk become the weak link. Social-engineering a reset is a known attack path; require identity proofing before any method reset, and log every reset and TAP issuance.
• Monitor registration events as security signals — a method registered from an unexpected location or right after a password reset can be an attacker establishing persistence.
• Keep the methods policy as reviewed code (Graph/IaC in source control), so a risky change like disabling number context or widening a TAP window is caught in review.

Notice these controls pull in the same direction: a phishing-resistant strength for admins, short-lived monitored TAPs, additional context on push, least-privilege reset roles, and registration-anomaly alerting each secure the tenant and prevent the very lockouts and confusion this article troubleshoots.

Cost & sizing

The “bill” here is mostly licensing, not consumption. Core MFA and the Authentication methods policy are free — number matching, passkeys, TAP and sign-in logs cost nothing, so every Symptom-1-through-4 fix is on the included tier. But Conditional Access requires Entra ID P1 (where authentication strengths and the MFA-registration policy live — Symptom 5), and Identity Protection (risk policies, registration-anomaly detection) requires P2; without P1 you fall back to legacy per-user MFA and Security Defaults, which can’t demand phishing-resistant MFA. Longer sign-in log retention means routing to a Log Analytics workspace at the usual per-GB ingestion cost. The cost drivers and what each buys you (INR-leaning, 1,000-seat org):

The sizing rule: most users need P1 (CA + auth-strengths), only privileged and high-risk users strictly need P2, and device-bound passkeys in Authenticator give phishing-resistant MFA at zero hardware cost — buy security keys only where a phone won’t do.

Interview & exam questions

1. A user is stuck on “More information required” and can’t add any method. Where do you look first and what’s the likely cause? Open the sign-in logs → Conditional Access tab on the interrupted event; the likely cause is a CA policy blocking the Register security information action (e.g. requiring MFA to register MFA). Fix by issuing a TAP and re-scoping the policy so registration is reachable.

2. What’s the difference, in the logs, between a user who has no MFA method and one whose method just failed? No method triggers a registration interrupt — 50079/50072, marked “interrupted.” A failed method shows 500121 (challenge not completed) or 50074/50076 (MFA required, not satisfied) as an actual failure. Interrupt = register; failure = deliver/complete.

3. Since when is number matching mandatory, and what does it change for the user? Enforced for all Authenticator push since February 2023. The user can no longer tap Approve/Deny; the sign-in screen shows a two-digit number they must read and type into the app, and there is no toggle to disable it.

4. A user’s “Add passkey” is greyed out even though FIDO2 is enabled tenant-wide. Why? Most likely a key-restriction allow-list that omits the device’s AAGUID — commonly the Authenticator-app AAGUID never added to aaGuids. Confirm via keyRestrictions on the FIDO2 config; fix by adding the AAGUID or relaxing enforcement.

5. What is a Temporary Access Pass and which problem does it specifically solve? A time-limited passcode that itself satisfies MFA, solving the passwordless bootstrap chicken-and-egg: a new or reset user with no strong method uses it to sign in once and register a passkey. It needs Authentication Administrator and should be short-lived and monitored.

6. System-Preferred MFA is prompting a user for Authenticator when they expected SMS. Is that a bug, and how do you fix it? Not a bug — it prompts the strongest registered method, and Authenticator outranks SMS. If that registration is broken, repair or remove it so the working method is promoted; don’t disable System-Preferred globally (a security regression).

7. A Conditional Access sign-in fails with AADSTS530031. What does that specifically mean? A CA authentication strength required a stronger method than the user holds — typically phishing-resistant (passkey/FIDO2/WHfB) when they only have push or SMS. Fix by registering a qualifying method or correcting scope. (Generic 53003 is a non-specific block.)

8. Why might a method a user registered not count for MFA? Mid-migration, a method registered under the legacy SSPR policy may not count for MFA until the unified policy is fully in force (policyMigrationState = migrationComplete). Finish the migration to unify registration across MFA and SSPR.

9. A subset of users get prompted for MFA twice. What’s the classic cause? Legacy per-user MFA has the account Enforced and a CA policy also requires MFA — the engines stack. Set per-user MFA to Disabled and let Conditional Access be the single authority.

10. Which Entra licence tier do you need to require phishing-resistant MFA on an app, and what’s the non-obvious cause of TOTP codes always being rejected? You need Entra ID P1, because Conditional Access (where authentication strengths live) requires P1; without it you’re limited to Security Defaults / legacy per-user MFA, which can’t demand a phishing-resistant strength (P2 adds risk-based policies on top). Separately, TOTP codes that always fail are usually clock skew — the code is time-based, so a device clock off by more than the window makes every code “incorrect”; enable automatic date and time.

These map mainly to SC-300 and AZ-500 (with passwordless/FIDO2 in SC-900 at awareness level):

Quick check

1. A user is stuck on “More information required” and there’s no way to add a method. What single report/tab tells you whether a Conditional Access policy is blocking registration, and what’s the usual fix?
2. True or false: you can disable number matching tenant-wide if it’s confusing your users.
3. “Add passkey” is greyed out for a user even though FIDO2 is enabled for everyone. Name the most likely cause and where to confirm it.
4. A brand-new user can’t sign in strongly enough to register their first passkey. What do you issue, and which role do you need to issue it?
5. AADSTS 530031 appears on a blocked sign-in. What does it specifically tell you, versus a plain 53003?

Answers

1. The sign-in logs → open the interrupted event → Conditional Access tab; a policy in Failure against the Register security information action is the blocker. The usual fix is to issue a Temporary Access Pass and re-scope the policy so the registration action is reachable (test it report-only first).
2. False. Number matching has been enforced for all Authenticator push since February 2023 and cannot be turned off. “Push broken” after that date is usually the user not reading and typing the two-digit number from the sign-in screen.
3. A key-restriction allow-list (AAGUID enforcement) that doesn’t include the device’s AAGUID — classically the Authenticator-app AAGUID omitted when enabling passkeys-in-Authenticator. Confirm via keyRestrictions on the FIDO2 method config (az rest GET .../Fido2).
4. Issue a Temporary Access Pass (TAP) — a time-limited passcode that satisfies MFA so the user can sign in once and register a passkey. You need Authentication Administrator (or higher) to issue it.
5. 530031 specifically means a Conditional Access authentication strength required a stronger method (typically phishing-resistant: passkey/FIDO2/WHfB) than the user holds. A plain 53003 is a generic Conditional Access block with no implication about method strength.

Glossary

• Authentication method — a way to prove identity at sign-in (Microsoft Authenticator push, passkey/FIDO2, SMS, voice, OATH/TOTP, Temporary Access Pass); registered per user.
• Authentication methods policy — the unified allow-list (Entra → Protection → Authentication methods) that decides which methods are enabled, and for which groups; the source of every “missing tile.”
• Registration interrupt — a sign-in event (e.g. AADSTS 50079/50072) that interrupts the user to finish registering a method, rather than failing the sign-in.
• Number matching — the enforced (since Feb 2023) requirement to type a two-digit number shown on the sign-in screen into the Authenticator app to approve a push; replaces tap-to-approve.
• Additional context — the Authenticator policy setting that shows the application name and sign-in location in the push prompt, to fight fatigue attacks and accidental denials.
• System-Preferred MFA — the default behaviour where Entra prompts the user’s strongest registered method (passkey > Authenticator passwordless > push > OATH > SMS).
• Passkey / FIDO2 — a phishing-resistant credential bound to the real domain, on a security key, a platform authenticator (Windows Hello / Apple / Google), or device-bound in Microsoft Authenticator.
• AAGUID — the 128-bit identifier of a FIDO2 authenticator model; used in key restrictions to allow or block specific devices.
• Key restrictions — the FIDO2 policy setting that enforces an allow-list or block-list of AAGUIDs; an over-tight allow-list silently blocks registration.
• Attestation enforcement — the FIDO2 setting that requires an authenticator’s attestation metadata; refuses keys that can’t attest.
• Temporary Access Pass (TAP) — a time-limited passcode that satisfies MFA, used to bootstrap a user’s first strong credential; issued by an Authentication Administrator.
• Authentication strength — a named set of methods a Conditional Access grant will accept (MFA, Passwordless MFA, or Phishing-resistant MFA); failing it yields AADSTS 530031.
• Per-user MFA (legacy) — the old per-account Enabled/Enforced MFA state that predates Conditional Access; can double-prompt and conflict with CA. With the legacy SSPR registration policy, it is superseded by policyMigrationState reaching migrationComplete on the unified policy.
• AADSTS code — the precise Entra sign-in error identifier (e.g. 50074, 50079, 500121, 530031) found in the sign-in logs; the front door to every diagnosis.
• Registration details report — Entra → Authentication methods → Activity → Registration; shows who has registered which methods and their capability flags.

Next steps

You can now localise any “I can’t log in” MFA report to a specific gate and fix it. Build outward:

• Next: Authenticator Passkeys and Number Matching: Stopping MFA Fatigue Attacks — the threat model behind number matching and passkeys, and why these controls exist.
• Related: Rolling Out FIDO2 Passwordless Authentication in Entra ID: Security Keys, Passkeys, and Windows Hello for Business — the full passwordless rollout, including TAP-to-passkey onboarding.
• Related: Rolling Out Phishing-Resistant Passwordless Auth: FIDO2, Passkeys, and Break-Glass Design — break-glass-safe enforcement so a strength policy never locks you out.
• Related: Deploying Conditional Access Safely: Report-Only Rollout to Enforcement — test policies report-only so they never block registration or your admins.
• Related: Designing Conditional Access at Scale: A Persona-Based Policy Framework with Authentication Context and Filters — get the right users holding the right authentication strength.
• Related: PIM for Entra Roles: Just-in-Time Activation, Approvals, and Security Alerts — protect the privileged roles that issue TAPs and edit these policies.