MFA enabled and MFA registered are different numbers

01 / 11

The question on the renewal form

Consider a fictional 80-person manufacturer renewing its cyber insurance. The questionnaire has one line: is multi-factor authentication enforced for all users accessing email and business systems. The owner checks yes, because a contractor turned on a policy two years ago and nobody has revisited it since.

That yes answers a question the insurer did not quite ask. Enforced is carrying a lot of weight in that sentence, and Microsoft 365 keeps more than one number that could each honestly stand in for it. They are not the same number, and they do not move together.

This post is about which of those numbers you are actually looking at when you answer that question, and which one an attacker who has just stolen a password still has to get past.

02 / 11

Registered, capable, and challenged are three different claims

Start with the vocabulary, because everyday language hides the gap. Registered usually means a person has set up some extra step: an authenticator app, a text code, a security key. Enabled or enforced usually means some switch in the tenant is turned on. Neither statement says whether a specific sign-in, today, actually got stopped and asked for a second factor.

Microsoft's own reporting draws that line more precisely than ordinary language does, in two properties that sit one clause apart and mean genuinely different things: isMfaRegistered and isMfaCapable. Getting the difference right is the whole point of this post.

03 / 11

One clause is the entire difference

Both properties live on the same Microsoft Graph resource, userRegistrationDetails, and Microsoft's own definitions are worded closely enough that it is easy to read past the one clause that actually separates them.

isMfaRegistered: indicates whether the user has registered a strong authentication method for multifactor authentication. The method may not necessarily be allowed by the authentication methods policy.

isMfaCapable: indicates whether the user has registered a strong authentication method for multifactor authentication. The method must be allowed by the authentication methods policy.

Read those twice. The opening sentence is identical. The only difference is may not necessarily be allowed versus must be allowed. A user can be MFA registered and not MFA capable — they set up a method at some point, and your current authentication methods policy no longer accepts it, perhaps because an admin later restricted which methods count. Capable is the stricter, more current number, because it is scoped to what the tenant's live policy accepts today, not to whatever a user did once. If a form only has room for one number, our reading is that isMfaCapable is the one worth reporting, not isMfaRegistered.

04 / 11

Where the two numbers come from, and how stale they can be

Both surface in the Authentication Methods Activity dashboard, which has a Registration tab and a Usage tab. The Registration tab includes a per-user detail view listing the account, MFA capability, passwordless capability, self-service password reset status, methods registered, and when that row was last updated.

A Microsoft Entra ID P1 or P2 licence is required to access Usage and insights — the dashboards, not necessarily the raw report objects underneath them. Viewing rights are scoped to specific roles, including Reports Reader, Security Reader, Global Reader and Security Administrator among others.

The freshness caveat matters as much as the definitions: the data in the report is not updated in real-time and may reflect a latency of up to 36 hours, with most users' rows current within that window. Pull the number the same afternoon someone registers a method or a policy changes, and you may be reading yesterday's tenant, not today's.

05 / 11

Security defaults: free, blunt, and possibly what you are actually running

Some tenants answer enforced with a single free switch. Security defaults require users to do multifactor authentication when necessary, prompting based on factors such as location, device, role and task, and separately require administrators to do multifactor authentication every time they sign in, naming specific roles including Global Administrator, Application Administrator, Exchange Administrator, Helpdesk Administrator and a dozen others.

It costs nothing, because the required licence is none, against at least Microsoft Entra ID P1 for Conditional Access, and it offers no customization — it is on or off, full stop. Microsoft's own comparison is direct about who should have moved past it: if you are an organization with Microsoft Entra ID P1 or P2 licenses, security defaults are probably not right for you.

None of that makes security defaults a wrong answer for a small tenant with no premium licence. It does mean that if your only evidence of enforced is that this one switch is on, you have Microsoft's coarsest MFA control, applied uniformly, with no way to see which accounts it is actually catching.

06 / 11

The policy that actually challenges someone at sign-in

The layer built to intercept a real sign-in is Conditional Access, and Microsoft's own template for the broadest version is specific about its scope: require all users do multifactor authentication, using the authentication strength policy, without any app exclusions.

The same template page recommends carving out three groups before you turn it on: emergency access or break-glass accounts, to prevent lockout due to policy misconfiguration; service accounts and service principals, described as noninteractive accounts that aren't tied to any specific user; and, optionally, guest users if you are targeting them with a separate guest-specific policy.

Those exclusions are correct policy, not a loophole — a control that can lock out the account meant to recover from lockouts defeats itself. But they are also exactly where a registered, even capable, user can still go unchallenged: added to an exclusion group for a legitimate reason once, and never removed once the reason passed; or simply never in scope of any Conditional Access policy at all, because nobody assigned them to one. We are not re-covering the P1 licensing gate itself here — that is one line, and this blog has covered it elsewhere.

07 / 11

Per-user MFA: the setting an owner might still be pointing to

Some tenants still carry the original per-user MFA switch — a per-account Enabled or Enforced flag from before Conditional Access existed for their licence tier. Microsoft's guidance on it is blunt: don't enable or enforce per-user Microsoft Entra multifactor authentication if you use Conditional Access policies, because the best way to protect users with Microsoft Entra MFA is to create a Conditional Access policy instead.

Microsoft goes further with a standing recommendation to turn per-user MFA off entirely, arguing that Conditional Access and MFA used together let your most sensitive resources carry the tightest controls while less sensitive resources stay more freely accessible, with fewer prompts overall.

We looked specifically for a Microsoft notice retiring per-user MFA outright, or setting an end date for the legacy portal that manages it, and did not find one. What exists is a standing recommendation to move off it, not a published retirement date. If your tenant's enforced number still traces back to this per-user switch, that is worth knowing on its own — whichever way Microsoft eventually settles the timeline.

08 / 11

A different mandate: MFA for admins signing into Microsoft's own portals

A separate Microsoft requirement sometimes gets folded into the same yes, and it is answering a narrower question. Starting in October 2024, MFA is required for accounts that sign in to the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center to perform any create, read, update, or delete operation, with enforcement rolling out gradually worldwide, and starting in February 2025 the same gradual enforcement began for the Microsoft 365 admin center.

A second phase extends the requirement further out: starting October 1, 2025, MFA enforcement began gradually for accounts that sign in to Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, and REST API endpoints to perform any create, update, or delete operation — read operations are excluded.

This is Microsoft requiring MFA for accounts doing administrative sign-ins into its own management surfaces, not a statement about whether your regular staff signing into email or SharePoint face a challenge. Microsoft's own wording commits to a gradual rollout, not a completion date, so treat this as in force for admin sign-ins to those specific surfaces, and as a separate claim entirely from tenant-wide enforcement.

09 / 11

Four numbers, one question

Line these up before you answer anyone's questionnaire, because each one can look fine while the others are not.

10 / 11

What to check this week

None of this needs a purchase. It needs someone to pull four things and write down what each one actually says.

• Pull isMfaCapable, not just isMfaRegistered, from the Authentication Methods Activity report, and note the report's own 36-hour latency before treating either as today's exact number.
• Confirm which mechanism is actually switched on in your tenant — security defaults, per-user MFA, or a named Conditional Access policy — since more than one can be left behind by a prior admin.
• If you have an all-users Conditional Access MFA policy, open its exclusions list and read the names on it, not just the count, so you know exactly who it does and does not cover.
• If per-user MFA is still doing the work, treat it as a legacy setting Microsoft steers you away from, not a deadline — no retirement date has been published for it.
• Answer any outside questionnaire with more than one word: the registered count, the capable count, and which policy actually challenges sign-ins, each labelled as what it is.

11 / 11

Where to start

Open the Authentication Methods Activity report this week if your licence reaches it, and if it does not, open Conditional Access and security defaults and read, by name, which one is actually on and who it excludes. That single check answers the insurer's question more honestly than the checkbox does.

Disclosure: this is a category we sell into. Avalon CloudSec reports Microsoft 365 MFA registration coverage and calls out administrators without MFA specifically, alongside Conditional Access policy analysis that flags gaps such as missing admin MFA coverage or lingering legacy authentication. It reads these same Microsoft numbers rather than replacing them, and it inherits their limits: it cannot turn a policy on, close an exclusion, or resolve which single number your insurer actually wants — it can only surface all of them, labelled, for your team to act on in the Microsoft admin center. To see that view against your own tenant, email support@awservices.org.

Microsoft, Microsoft 365, Azure, Entra, Intune and Defender are trademarks of the Microsoft group of companies. Avalon CloudSec is an independent service and is not endorsed by Microsoft.