The owner of a small accounting firm I support called me earlier this year, frustrated. Their staff had started seeing “Approve sign in request” every time they logged in to Microsoft 365, and two of them didn’t want the Authenticator app on their personal phones. They asked me to “just turn Authenticator off.”
What they really needed was to understand why the prompt appeared and which of the settings behind it they could change. That’s what this guide covers. I’ll explain where the requirement comes from, what an admin can safely change, and what Microsoft no longer allows anyone to turn off.
Quick answer: The Authenticator prompt appears because multifactor authentication (MFA) is required, usually by security defaults, Conditional Access or per-user MFA. As an admin, you can let people use another method, such as a passkey or a hardware key, under Microsoft Entra admin center > Entra ID > Authentication methods, and stop the “set up Authenticator” nudges in the Registration campaign. You can’t turn off MFA for the Azure, Entra, Intune or Microsoft 365 admin centers; Microsoft requires it.
Why Microsoft 365 asks for the Authenticator app
The message looks like this. The user has to open the Authenticator app and type the number shown on the screen:

This isn’t the Authenticator app switching itself on. It’s MFA, and Authenticator is simply the method that meets it. Something in your tenant requires a second step, and these are the usual sources:
| Source | What it does | Where it’s managed |
|---|---|---|
| Security defaults | Free baseline: everyone registers for MFA, admins use it at every sign-in, legacy sign-in is blocked | Entra ID > Overview > Properties |
| Conditional Access | Policies that decide when MFA is required (needs Microsoft Entra ID P1, included in Microsoft 365 Business Premium and E3) | Entra ID > Conditional Access |
| Per-user MFA | The legacy per-person switch; Microsoft doesn’t recommend it anymore | Entra ID > Users > All users > Per-user MFA |
| Mandatory MFA | Required by Microsoft for admin portals; can’t be turned off | Not configurable |
The number you type is called number matching. It’s always on for Authenticator notifications and can’t be disabled, because it stops people from approving sign-ins they didn’t start.
If the phone isn’t handy, the user can select I can’t use my Microsoft Authenticator app right now and pick any other method they’ve registered, such as a code or a text message. If sign-in fails earlier, at the password step, that’s a different problem; see the sign-in name or password does not match error:

What you can’t turn off
Before changing anything, know the one thing that’s fixed. Since October 2024, Microsoft requires MFA to sign in to the Azure portal, the Microsoft Entra admin center and the Intune admin center, and since February 2025, the Microsoft 365 admin center.
Starting October 1, 2025, the same rule began rolling out to Azure CLI, Azure PowerShell, the Azure mobile app and other tools whenever they create, change or delete resources.
Tenants could postpone each phase for a while, but those extensions have run out, and Microsoft states there’s no way to opt out.
Admin accounts, including break-glass accounts, will always need a second step. The same goes for admin scripts that sign in as a person, such as Connect-SPOService in the SharePoint Online Management Shell, whenever your policies require MFA for admins.
You also can’t use these settings to make sign-in password-only and expect it to be safe. Microsoft reports that MFA stops more than 99 percent of account-compromise attacks, and a password on its own is exactly what attackers guess, phish and reuse.
Option 1: Let people use a different sign-in method
This is usually the real answer when people don’t want the app. You keep MFA and give them another method.
Sign in to the Microsoft Entra admin center (you need at least the Authentication Policy Administrator role), go to Entra ID > Authentication methods, and open Policies:

Enable another method first, such as Passkey (FIDO2) for security keys and passkeys, or Hardware OATH tokens. Then open Microsoft Authenticator. On the Enable and Target tab, keep it enabled, open Exclude and add the group of people who’ll use the other method:

Users who already rely on Authenticator will need to register the new method first, so plan the change with them.
Since September 30, 2025, methods are managed only in this Authentication methods policy, not in the old MFA and self-service password reset settings.
There’s one catch, though.
If your tenant relies on security defaults, users can meet MFA only with the Authenticator app or another authenticator app that shows six-digit codes.
Security keys and other passkeys count when MFA comes from Conditional Access, which needs Microsoft Entra ID P1 (included in Microsoft 365 Business Premium and E3). If you want to try it first, a Microsoft 365 E5 trial includes it.
Option 2: Stop the “set up Authenticator” prompts
If people keep seeing a screen asking them to set up Authenticator or a passkey, that’s the registration campaign. By default it’s Microsoft managed.
Microsoft nudges users toward a passkey when they’re enabled for passkeys, and otherwise toward Authenticator. The Authenticator nudge goes only to people who sign in with a text message or phone call, and after three skips, setup becomes required.
Open Entra ID > Authentication methods > Registration campaign (you need at least the Authentication Policy Administrator role). The settings sit right on the page, with no Edit button. Set State to Disabled, or keep it and use Select group under Exclude, then select Save:

This removes the nudge without changing who needs MFA. Keep in mind that Microsoft recommends moving away from text messages and phone calls because they’re easier to intercept, so a passkey is a better long-term replacement.
Option 3: Change per-user MFA for one person
Per-user MFA is the older, person-by-person switch. It’s worth checking when one user is prompted and others aren’t. To see who’s actually active before you change anything, you can pull Microsoft 365 usage reports with Microsoft Graph.
In the Microsoft Entra admin center, go to Entra ID > Users > All users, select the … menu on the toolbar, and choose Per-user MFA (you need at least the Authentication Policy Administrator role).
The page lists every user with a Status of disabled, enabled or enforced. Select a user to use Enable MFA, Disable MFA or Enforce MFA. If you already read users from Microsoft Entra ID with Microsoft Graph, the beta Graph API can also report each user’s per-user MFA state:

Setting a user to disabled here only helps if per-user MFA was the only thing requiring MFA. Microsoft recommends Disabled as the per-user status for everyone who’s covered by security defaults or Conditional Access, because those policies do the job better. If either applies, the user is still prompted.
Option 4: Security defaults (and why to replace, not remove them)
Security defaults turn on MFA for the whole tenant, and guests, such as the external users you share SharePoint sites with, are treated the same way. In the Microsoft Entra admin center, go to Entra ID > Overview, open the Properties tab, and scroll to Security defaults (you need at least the Conditional Access Administrator role):

Select Manage security defaults to open the pane. In my tenant they’re off because Conditional Access policies do the job:

As the warning on that screen says, disabling security defaults leaves your organization exposed.
Microsoft’s guidance is to turn them off only when you’re replacing them with Conditional Access policies, which let you require MFA in the situations that matter, such as for admins or sign-ins from outside the office, instead of all the time.
Microsoft also offers Microsoft-managed Conditional Access policies that keep the same protections. If you disable security defaults with nothing in their place, Microsoft may notify you and turn them back on.
A note on system-preferred authentication
Some older guides tell you to disable System-preferred authentication under Authentication methods > Settings. That setting only decides which of a user’s registered methods is offered first.
In its default Microsoft managed state, it now does this for the first sign-in step too, so someone with a passkey sees the passkey before the password. Turning it off doesn’t remove MFA or the Authenticator prompt.
What I recommended for the accounting firm
The firm already had Microsoft 365 Business Premium, so we replaced security defaults with Conditional Access policies that require MFA.
Then we bought two inexpensive security keys for the staff who didn’t want the app on their phones, enabled passkeys as a method, and excluded that group from the registration campaign.
Everyone else kept Authenticator, which is still the easiest option for most people. The complaints stopped, and the firm’s sign-ins stayed protected. The same approach works for other features people ask me to switch off, like when admins want to turn off Copilot in Windows 11: find the policy behind it before you flip anything.
If you look after sign-in and sharing in Microsoft 365, these guides pick up where this one stops:
Frequently Asked Questions
Can I turn off Microsoft Authenticator for all users in Microsoft 365?
You can disable the Authenticator method or exclude groups in the Authentication methods policy, but people will still need another MFA method if MFA is required. The better move is to offer another method, such as a passkey.
Why does Microsoft 365 keep asking me to set up the Authenticator app?
That’s the registration campaign. An admin can disable it or exclude users under Entra ID > Authentication methods > Registration campaign.
Can admins turn off MFA for the Microsoft 365 admin center?
No. Microsoft requires MFA for the Azure, Microsoft Entra, Intune and Microsoft 365 admin centers, and there’s no way to opt out.
How do I turn off security defaults in Microsoft Entra?
Go to Entra ID > Overview > Properties > Manage security defaults and set it to Disabled. Microsoft recommends doing this only when you replace them with Conditional Access, as explained in its security defaults documentation.

I have worked with Microsoft technologies for more than 18 years, including SharePoint, Microsoft 365 and the Power Platform (Power Apps, Power Automate and Power BI), at companies like HP, TCS and KPIT. I started EnjoySharePoint in 2011 to share the solutions I build in real projects with readers in the United States, Canada, the United Kingdom, Australia, New Zealand and beyond. Microsoft has recognized this work with the Microsoft MVP award 13 times since 2014.