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-MgUserAuthenticationMicrosoftAuthenticatorMethodlists 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 | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Symptom captured | Which user, which app, which phone, what the screen said | "Authenticator is broken" with no detail |
| 2. Sign-in log read | MFA was required, a push was attempted, result detail known | Guessing at the phone when the log already names the cause |
| 3. Registered devices | One current Authenticator registration on the phone in hand | Push goes to the old phone; new phone shows nothing |
| 4. Methods policy | Authenticator enabled, user in scope, mode allows push | Can't add Authenticator, or never offered a push |
| 5. Method selection | Push is what the sign-in actually asks for | User is prompted for a passkey, TAP, or code instead |
| 6. Phone and app | Notifications allowed, clock automatic, supported app version | No banner, "expired," or "Enable push notifications" |
| 7. By-design no-push cases | Anomalous/unfamiliar sign-in, NPS extension, wearables understood | "No notification" that is working as designed |
| 8. Risk and blocks | User not flagged High risk or blocked by policy | MFA "denied" after the user reported a prompt |
Step 1: Capture the exact symptom (read-only)
Write these facts on the ticket before anyone deletes a method:
| Fact | Why it matters |
|---|---|
| User and time of the failed sign-in | You need the exact sign-in event in the log (Step 2) |
| App or resource | Browser, Outlook, Teams, VPN (NPS extension), RD Gateway, or a federated app |
| Phone in hand | iOS or Android, new or old, work profile or personal, recently restored from backup |
| What the sign-in screen showed | "Approve sign-in request" with a number, a code box, a passkey prompt, or an error |
| What the phone showed | Nothing, a banner with no sound, a request that says it expired, or an error message in the app |
| Location | Travelling, new country, VPN on the phone |
| What changed | New phone, app reinstall, OS update, a policy change, an NPS extension upgrade |
| Pattern | Likely layer |
|---|---|
| Sign-in page says it sent a request; new phone shows nothing | Old phone is still registered (Step 3) |
| Sign-in page asks for a code or passkey, not a push | Method selection or policy mode (Steps 4–5) |
| Request appears only after opening the app and refreshing | Anomalous / unfamiliar sign-in, by design (Step 7) |
| Every request says it expired | Phone clock (Step 6) |
| No banner, but requests are in the app | Phone notification settings or Do Not Disturb (Step 6) |
| Android, user in mainland China | Google Play push channel blocked (Step 6) |
| VPN shows a code prompt or plain Approve/Deny, no number | NPS extension behavior (Step 7) |
| "Sign-in denied" in the app | Authenticator denies GPS location discrepancies (Step 6) |
| MFA denied right after the user tapped "report" on a prompt | Report suspicious activity → High user risk (Step 8) |
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:
-
Basic info: the error code.
50074means strong authentication was required and the user didn't pass the MFA challenge.50076means a configuration change (such as Conditional Access or per-user enforcement) or a new location requires MFA.50079means the user must register for MFA. - Conditional Access: which policy required MFA. If the result is a block (53003), this isn't an Authenticator ticket.
- 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:
| Result detail | Read it as |
|---|---|
| unable to send the mobile app notification to the device | Service couldn't deliver to that registration: stale device, app removed, OS push channel (Steps 3, 6) |
| unable to send the mobile app notification | Delivery failed; check the registration and the phone (Steps 3, 6) |
| user didn't respond to mobile app notification | Sent, not answered: wrong phone, no banner, or the user didn't open the app (Steps 3, 6, 7) |
| user declined the authentication | The user tapped Deny (or reported it). Ask before you assume a fault |
| user is blocked | Account or risk block (Step 8) |
| user doesn't have any verification methods registered | No usable method: registration problem, not push (Steps 3–4) |
| authentication in-progress / duplicate authentication attempt | Overlapping requests; one pending request can hide the next |
| misconfiguration / service error | Check policy (Step 4) and Microsoft service health before touching the user |
| satisfied by claim in the token / skipped due to remembered device / skipped due to location | No push was needed. "I never got a prompt" can be correct |
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:
| What you see | What it means |
|---|---|
| Two or more rows | More than one phone can receive pushes. DisplayName is the device name. Ask which one is in hand |
| Old device name only | The new phone never completed registration |
Old PhoneAppVersion
|
Possibly below what Microsoft supports (Step 6) |
CreatedDateTime empty |
Normal if the device isn't registered for passwordless phone sign-in (documented) |
| No rows | No Authenticator registered; the push can't be the method |
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:
| Setting | What to check |
|---|---|
| Enable | On |
| Include | A group the user is actually in (Microsoft removed targeting individual users; old user targets remain but should move to a group) |
| Exclude | The user isn't in an excluded group |
| Authentication mode | Any (push or passwordless), Push, or Passwordless. Combined registration of Authenticator works only with Any or Push |
| Allow use of Microsoft Authenticator OTP | Whether the code option is allowed as a fallback |
| Configure tab | Show application name / geographic location in notifications (context only, not delivery) |
# 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:
| Check | Documented detail |
|---|---|
| App version | Microsoft doesn't support Authenticator versions more than 12 months old. Versions without number matching won't work for push. Microsoft also retires old versions; users on devices that can't run modern versions should use an OATH code |
| Notifications | Authenticator Settings → Notification Settings → Show notifications on; OS notifications allowed for the app; sound/vibrate on |
| Do Not Disturb / Focus | Can prevent notifications |
| Battery | Authenticator Settings → Turn off battery optimization |
| Clock | "Always expired" → set the device clock to automatic, then restart |
| Network | Switch Wi-Fi ↔ mobile data; Airplane mode off; try without VPN on the phone. Push responses need internet (codes don't) |
| Other apps' notifications | If no app gets notifications, it's the phone's network or the Apple/Google notification channel |
| Some accounts work, one doesn't | Remove that account from the app and add it again, allowing notifications |
| Android | Push requires Google Play Services and the Google Play Store. In mainland China, Android push doesn't work because Google Play services are blocked (iOS notifications do work). Plan another method |
| Work profile | Add the PIN/biometric in the work profile; biometrics don't always carry over |
| Jailbroken / rooted | Since February 2026, Authenticator blocks work/school Entra credentials on jailbroken or rooted devices |
| "Sign-in denied" | Authenticator denies authentications when GPS-reported locations don't agree |
| Logs | In the app, Send feedback sends diagnostic logs. Capture them before escalating |
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)
| Case | What Microsoft documents | What the user does |
|---|---|---|
| Anomalous sign-in or unfamiliar location | Since August 2023, these don't generate notifications | Open Authenticator (or Authenticator Lite in Outlook), pull down to refresh or tap Refresh, then approve |
| Pending passwordless request | An unanswered phone sign-in request can make the next sign-in show only the password option | Open Authenticator and respond to the pending prompt |
| Same device as the app | In Microsoft apps like Outlook and Teams, users can reply Yes/No instead of typing the number. Browsers still require the number | Expected; not a missing prompt |
| NPS extension (VPN, RADIUS) | NPS doesn't support number matching. Extension 1.2.2216.1 or later prompts for a TOTP code if the user has one registered; without one, users see Approve/Deny | Use the Authenticator code. Check the server uses PAP (MSCHAPv2 doesn't support TOTP) |
| RD Gateway with NPS extension | Users with both TOTP and push registered can fail the challenge | Microsoft's documented fix: OVERRIDE_NUMBER_MATCHING_WITH_OTP = FALSE (Approve/Deny) |
| AD FS adapter | Number matching needs the documented Windows Server updates; unpatched servers show Approve/Deny | Patch the AD FS servers |
# 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:
- 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>'
- 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.
- 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.
- Phone-side finding: fix the one setting (clock, notifications, app update, Company Portal update, work-profile biometric).
- NPS / RD Gateway: change the one registry value Microsoft documents and restart the NPS service.
- 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
| Finding | Prefer | Avoid |
|---|---|---|
| Two Authenticator registrations; push goes to the old phone | Remove the one stale registration | Require re-register MFA for the user |
| Lost phone, no other method | Temporary Access Pass, then register | Disabling MFA or excluding the user from CA "for now" |
| User not in the Authenticator include group | Add their group | Enabling Authenticator for all users mid-incident without review |
| User offered a passkey/CBA/TAP instead of push | Explain Sign in another way / check system-preferred | Deleting the higher-ranked method to "force" push |
| Requests appear only after refresh, while travelling | Explain the documented anomalous/unfamiliar sign-in behavior | Re-registering the app |
| Every request "expired" | Automatic clock + restart | Resetting the account |
| Old app version / old Company Portal | Update the app | Re-registering on the same outdated app |
| Android in mainland China | An alternate method for that user | Repeated re-registration |
| NPS shows code / Approve-Deny | Documented extension behavior; PAP; registry value | Turning off MFA for the RADIUS client |
| MFA denied after a suspicious-activity report | Investigate and remediate the risk | Deleting methods to clear the block |
| Everything suspect | Require re-register MFA + Revoke sessions, deliberately | Doing it first, for every ticket |
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:
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.
Top comments (0)