When Microsoft Authenticator Says “Too Many Devices” and You Know That’s Not True

There is a very particular flavor of frustration that only appears in identity work. I used to work in the identity and network access division at Microsoft, so my joke was I needed to move faster over the course of my career, because I've landed smack dab in identity and by proxy security most of my career.

The moment I'm talking about is when Microsoft Authenticator calmly informs you that you have "too many devices registered." You know with absolute clarity that this is incorrect, because you just spent the last twenty minutes deleting half of them. Surprise! You were in Entra. You removed the devices. You then refreshed the blade, waited for replication, and tried again. Yet Authenticator continues to tell you that you've hoarded and registered too many devices.

This happened to me when I decided to get a new phone recently and I forgot about the lines of delineation. Hopefully my post helps you now or in the future when you need to remedy.

The instinctive response is to keep deleting (because know I did). The steps take you back into Entra, where you open the Devices blade, prune more aggressively, wait longer. But if that process loops without any change in behavior, it's usually the signal that you're not actually fighting a device problem at all. You're fighting an authentication method problem that happens to be wearing a disguise. The wording is misleading, the issue is subtle, and the fix requires understanding which object you're actually manipulating.

Devices Are Not What You Think They Are

When Microsoft Authenticator says you have too many devices, it is not referring to the objects under Entra's Devices blade. It has nothing to do with Intune records, hybrid join registrations, or the Mac you re-enrolled three times because JAMF kept fighting with you. It's referring to Microsoft Authenticator authentication method objects stored in Microsoft Graph, specifically microsoftAuthenticatorAuthenticationMethod entries that represent cryptographic bindings between your identity and a specific app instance on a specific device.

These objects are not visible in the device inventory blade. They live in the authentication methods collection for your user, and they accumulate quietly. Every time you reinstall the Authenticator app, reset your phone, scan a new QR code, or set up passwordless sign-in again, a new entry gets created. If you're someone who tests things, resets things, or switches phones with any regularity (basically me), you can build up a collection of stale Authenticator registrations without ever realizing it. Eventually you hit a backend limit, and the service responds with the wonderfully vague "too many devices" message, even though your Devices blade looks perfectly tidy.

You deleted the wrong thing because the error pointed you toward the wrong thing (thanks, Microsoft!).

The Moment It Clicked

The breakthrough came from recognizing that deleting devices was having absolutely no impact and then asking a better question. Instead of continuing to stare at the portal, I went directly to Microsoft Graph PowerShell to find out what authentication methods were actually registered for the user.

Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite","UserAuthenticationMethod.ReadWrite.All"

Get-MgUserAuthenticationMethod -UserId [email protected] | `
  ForEach-Object { "{0}  {1}" -f $_.Id, $_.AdditionalProperties.'@odata.type' }

What came back was illuminating. One password method. One phone method. Windows Hello. Email. And then five separate microsoft.graph.microsoftAuthenticatorAuthenticationMethod entries. Five of them, almost certainly created across multiple reinstallations and re-enrollments over time.

Now the error made sense. Authenticator was not lying. It was enforcing a limit on authentication method objects, not device objects. The device list was clean. The authentication method list was not.

Why Deleting Them Is More Complicated Than It Should Be

You might assume you can simply remove the extra Authenticator methods and move on. That assumption is reasonable, and it's also incomplete.

When you attempt to delete your own MFA methods via Microsoft Graph, the service requires a strong authentication claim issued within the last ten minutes, meaning you must have recently completed MFA. If you haven't, Graph will refuse the deletion and return an error like actionRequiresNgcMfaClaim. The platform is intentionally preventing someone from stripping MFA off an account without first proving they currently control it. From a security standpoint, this is exactly correct behavior. From a troubleshooting standpoint, it feels like the identity system is smirking at you.

The first time I tried to remove the stale registrations, I hit that exact error. The scopes were correct, the permissions were correct, and the only missing ingredient was a fresh MFA claim.

The Incognito Window That Solved It

The solution turned out to be surprisingly simple. Rather than continuing to fight the PowerShell session, I opened an incognito browser window and navigated to the security info page. A clean browser session forces a clean authentication flow. It doesn't reuse cached tokens or assume prior trust, so it challenges you properly.

I signed in, completed MFA, and that fresh sign-in issued the strong authentication claim the backend required. After that, the deletion process worked without complaint. The stale Authenticator registrations came out cleanly, and re-registering the app was straightforward.

Sometimes the most effective fix is not more scripting. It's forcing the identity system to re-evaluate you with fresh proof. Lesson learned for the future!

The Scripted Path Still Matters

For managed environments where automation or remote remediation is needed, the scripted approach is still the right one. Once the strong authentication requirement is satisfied, removing stale registrations is straightforward.

Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod `
  -UserId "[email protected]" `
  -MicrosoftAuthenticatorAuthenticationMethodId "<ID>"

Repeat that for each extra entry, wait a few minutes for backend propagation, and then re-register Authenticator as a clean setup. Avoid restoring from backup and treat it as a fresh cryptographic relationship rather than a continuation of a prior one. In managed environments, an Authentication Administrator can also remove these entries centrally, which bypasses the self-service strong authentication requirement entirely.

What Is Really Happening Under the Hood

Microsoft Authenticator registrations are not simply phone numbers in a list. They are cryptographic trust relationships, and each one represents key material bound to your identity. That's why deletion is guarded by strong authentication claims: the system is protecting against silent MFA removal, and it would rather inconvenience a legitimate user than allow a security boundary to be quietly dismantled.

The error message feels misleading because it uses the word "device," but the enforcement logic is entirely about authentication method objects. Once you understand that distinction, the entire troubleshooting process becomes far more rational. You stop working in the wrong layer and start working in the right one.

The Takeaway

If Microsoft Authenticator tells you that you have too many devices and deleting devices changes nothing, shift your focus to authentication methods rather than device inventory. Use Microsoft Graph to enumerate what actually exists. Understand that removing MFA methods requires fresh proof of control, and don't underestimate the value of an incognito browser window for resetting authentication context when cached tokens are getting in the way.

The cloud is often accused of being mysterious, but most of the time it is simply more precise than we expect. It enforces exactly what it was designed to enforce. The work is just making sure you're talking to the right object.

And sometimes that means realizing that devices are not always devices.