Microsoft Authenticator Not Receiving Notifications: A Read-First Sign-In Log, Device, and Policy Triage

Helpdesk: "Priya got a new iPhone over the weekend. Her laptop says 'Approve sign-in request' and nothing shows up on the new phone. Jordan is travelling and his Android phone never gets prompts. Every prompt Alex gets says it expired, and the VPN users say Authenticator 'stopped showing the number' since we updated the NPS server. Can you just reset MFA for all of them?"

Don't reset MFA yet. "Microsoft Authenticator not receiving notifications" is usually one broken layer in a documented chain, not a broken app: the push is going to another registered device (often the old phone) → the sign-in never asked for a push at all (a claim, a remembered device, or a higher-ranked method was used) → the user isn't in scope for Authenticator in the Authentication methods policy, or the mode doesn't allow what they expect → the phone can't receive or display it (notification settings, clock, OS push channel, app version) → Entra deliberately didn't send it (anomalous or unfamiliar sign-in, NPS extension, risky user). The sign-in log's Authentication Details tab, the user's registered Authenticator methods, the Authentication methods policy, and Microsoft's Authenticator troubleshooting pages are the sources for that chain. A forum tip that says "just require re-register MFA" deletes more than you think.

If the sign-in log shows error 53003 and a Conditional Access block rather than an MFA failure, start with AADSTS53003 Blocked by Conditional Access. If the person locked out is an admin and you're about to touch MFA settings for everyone, read Entra ID break-glass accounts after mandatory MFA first. This post covers "the user expects an Authenticator push, it doesn't arrive (or arrives expired, or shows no number), and you need a read-first path before you delete their methods."

TL;DR

• Read the sign-in log before the phone. The Authentication Details tab says why MFA failed: "unable to send the mobile app notification to the device," "user didn't respond to mobile app notification," "user declined the authentication," "user is blocked," "user doesn't have any verification methods registered." Each one points at a different layer.
• Count the user's Authenticator registrations. Get-MgUserAuthenticationMicrosoftAuthenticatorMethod lists each registered app by device name and app version. Microsoft: a push goes to the device where Authenticator was last used, and deleting the app from the old phone isn't enough. The old device has to be removed from Security info too.
• Read the Authentication methods policy. Is Microsoft Authenticator enabled, are they in an included group (and not an excluded one), and is the mode Any, Push, or Passwordless? Combined registration of Authenticator works only in Any or Push.
• Some "missing" pushes are by design. Since August 2023, anomalous sign-ins and sign-ins from unfamiliar locations don't generate notifications. The user opens Authenticator and pulls down to refresh (or taps Refresh) to see and approve the request.
• "Always expired" = the phone clock. Microsoft: set the device clock to automatic and restart. Microsoft doesn't support Authenticator versions more than 12 months old, and versions without number matching won't work for push.
• "Require re-register MFA" is not a refresh button. It deletes the user's phone numbers, Microsoft Authenticator apps, and software OATH tokens, and deactivates hardware OATH tokens. Remove only the stale device method when that's the finding.

Where in the chain did it break?

Step 1: Capture the exact symptom (read-only)

Write these facts on the ticket before anyone deletes a method:

Step 2: Read the sign-in log first (read-only)

In the Microsoft Entra admin center, open Entra ID → Users → Sign-in logs (or Monitoring & health → Sign-in logs), find the event, and read three tabs:

1. Basic info: the error code. 50074 means strong authentication was required and the user didn't pass the MFA challenge. 50076 means a configuration change (such as Conditional Access or per-user enforcement) or a new location requires MFA. 50079 means the user must register for MFA.
2. Conditional Access: which policy required MFA. If the result is a block (53003), this isn't an Authenticator ticket.
3. Authentication Details: the method attempted, whether it succeeded, and the result detail.

Microsoft's documented result details, and what they usually mean for this ticket:

Two documented caveats before you trust a single row:

• The Authentication Details tab can be incomplete at first. Microsoft notes that "satisfied by claim in the token" can display incorrectly and the Primary authentication row may be missing until log data is fully aggregated. Re-open the event later if it looks odd.
• A sign-in can look single-factor even when MFA is required, because an earlier MFA claim was accepted. Check both the MFA details and the root authentication method. Don't rely only on authenticationRequirement.

# Read-only (Microsoft Graph PowerShell)
# Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
# Note: downloading sign-in logs through Graph requires Microsoft Entra ID P1 or P2.

Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'priya@contoso.com'" -Top 20 |
  Select-Object CreatedDateTime, AppDisplayName, ClientAppUsed, ConditionalAccessStatus,
    @{n='ErrorCode';e={$_.Status.ErrorCode}},
    @{n='FailureReason';e={$_.Status.FailureReason}},
    @{n='AdditionalDetails';e={$_.Status.AdditionalDetails}}

Sign-ins from the NPS extension or the AD FS adapter appear in the sign-in logs with radius or adfs as the resource ID, and Microsoft notes several fields aren't populated for them. Don't treat empty columns there as a separate fault.

Step 3: Read the user's registered methods and devices (read-only)

The most common new-phone story is in Microsoft's own FAQ: a push is sent to the device where Authenticator was last used. If the old phone still has the app, the new phone sees nothing. Adding Authenticator to a new device doesn't remove it from the old one, and deleting the app from the old device isn't enough. The old device must also be unregistered (in Security info for work or school accounts).

# Read-only: every Authenticator registration for the user
# Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All'
Get-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId 'priya@contoso.com' |
  Select-Object Id, DisplayName, PhoneAppVersion, CreatedDateTime

How to read it:

Then read the registration summary Microsoft keeps per user:

# Read-only: registered methods, default, and system-preferred method
# Connect-MgGraph -Scopes 'AuditLog.Read.All'   # roles such as Reports Reader or Global Reader
Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "userPrincipalName eq 'priya@contoso.com'" |
  Select-Object UserPrincipalName, IsMfaRegistered, MethodsRegistered,
    UserPreferredMethodForSecondaryAuthentication,
    IsSystemPreferredAuthenticationMethodEnabled, SystemPreferredAuthenticationMethods

MethodsRegistered should include microsoftAuthenticatorPush if push is registered. Microsoft notes this report doesn't work for disabled users.

Restored from backup? Microsoft Support: backup and restore works only on the same device type (iOS to iOS, Android to Android). For work or school accounts, only the account name is restored, and the user has to sign in again (an "Action required" or "Sign in to restore your account" tile). A restored tile that hasn't been re-verified is not a working push registration.

Android with Company Portal: Microsoft notes that Company Portal versions below 2111 (5.0.5333.0) block Authenticator registration until Company Portal is updated.

Step 4: Read the Authentication methods policy (read-only)

In Entra ID → Authentication methods → Policies → Microsoft Authenticator, read:

# Read-only: the Microsoft Authenticator policy (state, include/exclude targets, feature settings)
# Connect-MgGraph -Scopes 'Policy.Read.AuthenticationMethod'
Invoke-MgGraphRequest -Method GET `
  -Uri 'https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/microsoftAuthenticator'

Also read the migration state in Authentication methods → Policies. Microsoft documents three: Pre-migration and Migration in Progress (legacy MFA and SSPR settings are still respected) and Migration Complete (only the Authentication methods policy is used). Microsoft ended management of methods in the legacy MFA and SSPR policies on September 30, 2025. If your tenant is mid-migration, "Notification through mobile app" in the legacy MFA policy can still explain why one user gets pushes and another doesn't.

Two documented limits that look like random failures:

• Registration can fail if many groups are included in the policy or a registration campaign. Microsoft recommends one consolidated group per method. Policy saves can fail above 20 KB.
• Conditional Access on "Register security info" still applies. Microsoft's Authenticator guidance notes users must satisfy any policy that targets that user action to register a method, so a new-phone registration from an untrusted network or device can be blocked by your own registration policy.

Step 5: Is a push what the sign-in actually asks for? (read-only)

System-preferred authentication is Microsoft managed by default and prompts users with the most secure method they've registered. Microsoft's current order puts Temporary Access Pass, passkeys (including Windows Hello for Business and passkeys in Authenticator), and certificate-based authentication (moved to third on March 18, 2026) ahead of Authenticator notifications, which rank ahead of TOTP codes and phone/SMS.

So a user with a passkey or CBA registered may never see a push, because the sign-in offers the higher-ranked method first. That's not a delivery failure. They can choose Sign in another way. Check SystemPreferredAuthenticationMethods in Step 3, and Entra ID → Authentication methods → Settings → System-preferred authentication for the state and any include/exclude group. Microsoft notes a policy change for a group might not apply on the user's very next sign-in, only after that.

Microsoft also notes system-preferred authentication doesn't override Conditional Access authentication strengths. If a policy requires phishing-resistant MFA for a resource, an Authenticator push doesn't meet that strength, so the sign-in asks for a phishing-resistant method instead.

Number matching is always on for push, and users can't opt out. Microsoft: it applies when the user is prompted for an Authenticator push, regardless of their default method.

Step 6: The phone and the app (read-only on the device)

Microsoft Support's Authenticator troubleshooting list, in ticket order:

Wearables: number matching isn't supported on Apple Watch or Android wearables, so users have to approve on the phone. Mirrored banners on a watch aren't a working approval path.

Step 7: Documented "no notification" cases (read-only)

# Read-only, on the NPS server: is the TOTP override set?
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\AzureMfa' -Name 'OVERRIDE_NUMBER_MATCHING_WITH_OTP' -ErrorAction SilentlyContinue

Step 8: Risk and blocks (read-only)

Microsoft removed the legacy Block/unblock users, Fraud alert, and Notifications MFA features on March 1, 2025. They were replaced by Report suspicious activity (Authentication methods → Settings).

When a user reports a prompt as suspicious, Microsoft sets them to High user risk. That shows in ID Protection → Risk detections as User Reported Suspicious Activity, in the sign-in log as MFA denied, and in the audit log. If you have risk-based Conditional Access, that user may now be blocked or forced to reset their password. The ticket "Authenticator stopped working after I hit report on a strange prompt" is that chain, not the app. Remediate the risk (password reset via SSPR or admin, per Microsoft's guidance) before you touch their methods.

Step 9: Change one thing (only after the read)

After Steps 1–8 agree on the layer:

1. Old phone still registered: have the user remove the old device in Security info and add Authenticator on the new phone by QR code. If you remove it as an admin, delete only that registration (the row you identified in Step 3):

   # Change (only after the read): remove ONE stale Authenticator registration
   # Connect-MgGraph -Scopes 'UserAuthenticationMethod.ReadWrite.All'
   Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -UserId 'priya@contoso.com' -MicrosoftAuthenticatorAuthenticationMethodId '<Id from Step 3>'

1. No usable method left (lost phone, no backup method): issue a Temporary Access Pass, a time-limited passcode the user signs in with to register a new method. Microsoft documents it for exactly this recovery case.
2. Not in scope for Authenticator: add the user's group to the Microsoft Authenticator policy (or fix the exclusion) rather than enabling a new method tenant-wide.
3. Phone-side finding: fix the one setting (clock, notifications, app update, Company Portal update, work-profile biometric).
4. NPS / RD Gateway: change the one registry value Microsoft documents and restart the NPS service.
5. Last resort: Require re-register MFA (Entra ID → Users → user → Authentication methods). Microsoft: it deactivates hardware OATH tokens and deletes phone numbers, Microsoft Authenticator apps, and software OATH tokens. Use it when every registration is suspect, not to fix one stale phone. Revoke sessions is a different action: it invalidates refresh tokens and forces reauthentication.

Retest with a fresh sign-in in a private browser window, then read the new sign-in event's Authentication Details before you close the ticket.

When a change is justified

FAQ

Why do Authenticator notifications go to my old phone?
Microsoft: the push goes to the device where Authenticator was last used. Installing the app on a new phone doesn't remove the old registration, and deleting the app from the old phone isn't enough. Remove the old device in Security info, then add the account on the new phone by QR code. Admins can confirm with Get-MgUserAuthenticationMicrosoftAuthenticatorMethod.

Why does the request only appear when I open Authenticator?
Since August 2023, anomalous sign-ins and sign-ins from unfamiliar locations don't generate notifications. Open Authenticator, pull down to refresh (or tap Refresh), and approve. If no request appears at all, check the sign-in log result detail.

Why do Authenticator requests always say expired?
Microsoft Support: Authenticator needs an accurate device clock. Set the clock to automatic, restart the phone, and try again.

Should I use "Require re-register MFA" to fix it?
Only when every registration is suspect. Microsoft: it deletes phone numbers, Microsoft Authenticator apps, and software OATH tokens, and deactivates hardware OATH tokens. For a single stale phone, remove only that registration. For a lost phone with no backup method, use a Temporary Access Pass.

Why doesn't the VPN prompt show a number?
The NPS extension doesn't support number matching. Version 1.2.2216.1 or later asks for a TOTP code if the user has one registered. Without one, users see Approve/Deny. TOTP needs PAP on the NPS server, and Microsoft documents an RD Gateway case where you set OVERRIDE_NUMBER_MATCHING_WITH_OTP to FALSE.

Related posts

• AADSTS53003 Blocked by Conditional Access (when the sign-in log shows a CA block, not an MFA failure)
• Entra ID break-glass accounts after mandatory MFA (keep a way in before you change MFA settings broadly)
• Conditional Access without the Monday lockout (report-only → enforce, so MFA policy changes don't become a wave of "Authenticator is broken" tickets)

Free checklist

Authenticator tickets spike the week a "require MFA" or authentication-strength Conditional Access policy goes live. New-phone users, travellers, and VPN users all report "no notification" at once, and the fastest fix someone reaches for is excluding them from the policy. Before you enforce, the free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=microsoft-authenticator-not-receiving-notifications

If you want a starting policy set and the exclusions pattern written down before MFA policies grow, the Entra ID Conditional Access Starter Pack has a starter policy library, a break-glass and exclusions playbook, and read-only Graph exports for policies and named locations: https://cashflow4375.gumroad.com/l/nhuyrc?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=microsoft-authenticator-not-receiving-notifications

Admin Pack Studio; not affiliated with Microsoft. Steps 1–8 favor read-only checks: sign-in log Authentication Details, Get-MgAuditLogSignIn, Get-MgUserAuthenticationMicrosoftAuthenticatorMethod, Get-MgReportAuthenticationMethodUserRegistrationDetail, a GET of the Microsoft Authenticator policy, the NPS registry value, and the phone's own settings. Removing an Authenticator registration, issuing a Temporary Access Pass, changing the Authentication methods policy, changing NPS registry values, and Require re-register MFA are deliberate changes. Change one layer at a time, retest with a fresh sign-in, and check current Microsoft Learn/Support for portal labels and app requirements.