MFA registration gaps: the hole in most tenants
31 Jul 2026
MFA registration gaps: the hole in most tenants
Ask an admin whether their tenant has MFA and the answer is almost always yes. Ask them how many users are registered for a strong authentication method and the answer is a pause. Those are two different facts. A Conditional Access policy that requires MFA describes what happens when someone signs in through a covered path. Registration describes whether that person owns a second factor at all. The gap between the two — users the policy would challenge but who have nothing to answer with, and users the policy never touches — is the most common exploitable hole in a Microsoft 365 tenant, and it's invisible from the Conditional Access blade.
Enforced, capable, registered — three states people conflate
Entra ID tracks this per user in the authentication methods registration
report, exposed on the Graph API as
reports/authenticationMethods/userRegistrationDetails. Three
fields matter and they mean different things:
isMfaRegistered— the user has registered at least one method that can satisfy an MFA challenge. Includes SMS and voice call, which are registered but phishable.isMfaCapable— registered and the method is enabled by tenant policy. A user with only SMS in a tenant where SMS has been turned off is registered but not capable.isSsprRegistered— self-service password reset. Separate registration, separate gap, and the one that generates the helpdesk calls.
Where the gap actually hides
| Population | Why it's unregistered | Risk |
|---|---|---|
| Dormant licensed users | Never signed in, so never prompted to register. | Live password, open enrolment, nobody watching. |
| Policy exclusion groups | Added "temporarily" during a rollout in 2023. | Nobody audits the exclusion, it only grows. |
| Break-glass accounts | Deliberately excluded — that part is correct. | Fine if monitored and FIDO2-backed. Usually neither. |
| Guests | Authenticate in their home tenant, not yours. | You inherit their security posture, unseen. |
| Shared / service accounts | "MFA would break the scanner / the mailbox script." | Shared password, often over-privileged. |
| Admins with SMS only | Registered years ago, never upgraded. | Counts as MFA in every report. Phishable in practice. |
The first row is the one that connects to money as well as risk: the same accounts that show up in dormant accounts still holding licences are usually the ones with no registered method. One list, two reasons to act on it.
Closing it in four passes
Pull every user holding a privileged role and check the registered method, not the flag. Global Admins, Exchange Admins, User Admins and Helpdesk Admins on SMS are a password-reset chain away from the whole tenant. Target FIDO2 or passkeys here; there are few enough of them that "it's disruptive" isn't an argument.
For every licensed account with no sign-in in 90 days and no registered method, the answer is usually disable-and-reclaim rather than a registration campaign. If the account must stay, require registration from a trusted network or a Temporary Access Pass so the first enrolment can't come from an attacker's device.
List every group excluded from every MFA policy and expand the membership. The security posture of a tenant is defined by its exclusions, not its policies. Two break-glass accounts is a design; forty excluded users is an incident waiting for a date.
Move SMS and voice out of the authentication methods policy once the population registered on them has migrated. Then re-run the report: coverage that looked like 96% before will drop, and the new number is the true one. Track it monthly — registration drifts back down with every new hire and every phone replacement.
Why it isn't already on a dashboard
The registration report exists in the Entra portal, but it's per-tenant,
point-in-time, and it doesn't join to anything: not to sign-in recency, not to
assigned roles, not to licences. The joins are where the decisions live —
"privileged and SMS-only", "licensed, dormant and unregistered" — and they
require Entra ID P1 or P2 to read the underlying sign-in data, which is itself
a service plan most tenants already own without knowing it (see
service
plans you pay for but nobody uses). Doing it by hand means a
Get-MgReportAuthenticationMethodUserRegistrationDetail export, a
role assignment export, a sign-in activity export, and a VLOOKUP session that
happens once a year.
GraphPaaS collects the registration details alongside the role assignments, sign-in recency and licence assignments it already syncs per tenant, so the four passes above are filters rather than exports — and the monthly re-measure is a page you open, not a morning you spend.
See exactly who in your tenant is registered, with what method, and which admins are still one SMS away from a takeover.
Check your MFA coverage →