What this check looks at
Checks that Microsoft Authenticator shows which app is asking, and where the sign-in comes from, on every approval request.
When Microsoft Authenticator asks someone to approve a sign-in, it can show extra context: the name of the application asking (for example Office 365 Exchange Online) and a map of where the sign-in is coming from, based on its IP address. Both are controlled in the Microsoft Authenticator settings of the authentication methods policy. Microsoft made them part of the default (Microsoft managed) behaviour in 2023, but either can be set to Disabled, for everyone or for a group.
This check applies when Microsoft Authenticator is enabled as a method. The check fails when the application name or the geographic location has been set to Disabled; it passes when both are enabled or left to Microsoft, which shows both.
MFA fatigue attacks rely on people approving prompts they did not start: an attacker who already has the password keeps triggering sign-ins until someone approves to make them stop, or calls pretending to be IT. Number matching makes this harder; the app name and map make it obvious, because a prompt from another country for an app the person is not using is easy to recognise and deny.
Why it matters
MFA-fatigue attacks send approval prompts until someone taps Approve. When the prompt names the app and shows a map, a person can see at a glance that the sign-in is not theirs. Turning these details off removes the last check between a stolen password and the account.
An employee of a 60-person firm gets an Authenticator prompt at seven in the morning for a sign-in she did not make. With the map showing a city abroad and the app shown as Azure portal, she denies it and reports it. Without them she sees only a number to type, which the attacker has already sent her by text, pretending to be the IT helpdesk.
The setting costs nothing and changes nothing for genuine sign-ins beyond showing more detail. It is one of the cheapest defences against push-approval attacks.
CIS Microsoft 365 Foundations Benchmark 5.2.3.1 asks for Microsoft Authenticator to be configured to protect against MFA fatigue, and CISA SCuBA MS.AAD.3.3 asks for Authenticator to show login context. CIS Controls v8 safeguard 6.3, ISO 27001 A.8.5, the NCSC CAF identity verification and authentication outcome and NIST CSF PR.AA-03 support it.
How to fix it
Where: Entra admin centre → Protection → Authentication methods → Microsoft Authenticator
Before you start
- Nothing to prepare: the change only adds details to approval requests people already get.
Step by step
- Open the Microsoft Authenticator settings. In the Microsoft Entra admin centre, go to Entra ID > Authentication methods > Policies, select Microsoft Authenticator and open the Configure tab.
- Turn on the application name. Under Show application name in push and passwordless notifications, set Status to Enabled (or Microsoft managed) and Target to All users, and remove any group listed under Exclude unless there is a documented reason for it.
- Turn on the geographic location. Under Show geographic location in push and passwordless notifications, set Status to Enabled (or Microsoft managed) and Target to All users, clear any exclusions in the same way, and select Save.
- Tell users what to check. Send a short note: approve a prompt only if you have just started a sign-in and the app and location look right; deny and report anything else to the helpdesk.
- Confirm the prompt shows the details. Sign in to a test account from a browser and check the Authenticator prompt shows the application name and a location map. Reopen the Configure tab to check both settings saved. The finding clears at the next assessment.
What users will notice
Approval requests in Microsoft Authenticator name the app asking and show a map of where the sign-in comes from.
How to confirm it worked
Sign in to a test account from a browser and check the Authenticator prompt shows the application name and a location map.
Frameworks and controls
This check maps to controls in 13 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B2.a Identity verification, authentication and authorisation |
| NIS2 | Art. 21(2)(j) Multi-factor authentication and secured communications |
| Microsoft Cloud Security Benchmark | IM-6 Use strong authentication controls |
| Zero Trust | Identities |
| SOC 2 | CC6.1 Logical access security software, infrastructure and architectures |
| NIST SP 800-171 | 3.5.3 Use multi-factor authentication |
| CMMC Level 2 | IA.L2-3.5.3 Multifactor Authentication |
| ISO 27001:2022 | A.8.5 Secure authentication |
| CISA SCuBA | MS.AAD.3.3v2 Microsoft Authenticator shows login context |
| CIS M365 | 5.2.3.1 Ensure Microsoft Authenticator is configured to protect against MFA fatigue |
| CIS Controls v8.1 | 6.3 Require MFA for externally-exposed applications (IG1) |
| NIST CSF 2.0 | PR.AA-03: Users, services, and hardware are authenticated |
| NCSC 10 Steps | Identity and access management |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Use additional context in Authenticator notifications (Microsoft Learn)