MFA Registration Is Not Enforcement in Microsoft 365

Seeing an authentication method next to every user does not prove that Microsoft 365 requires MFA at sign-in. Registration shows that a user has set up a method. Enforcement comes from access policy.

An MFA registration report can therefore look reassuring while ordinary sign-ins still succeed with a password alone. The useful question is not “Who has registered for MFA?” It is “Which sign-ins can still get through without it?”

What the registration report actually tells you

Microsoft Entra’s Authentication Methods Activity report shows which methods users have registered and whether they are considered MFA-capable. Its usage view shows successful interactive sign-ins that required single-factor or multifactor authentication.

The report is worth checking, but it does not describe the enforcement policy. A registered phone, authenticator app, or security key is available when a sign-in asks for it. Registration does not make the sign-in ask.

Microsoft says the report can lag by up to 36 hours. Usage and insights requires Microsoft Entra ID P1 or P2, and its authentication-requirement figures do not include third-party MFA providers. See Microsoft’s Authentication Methods Activity documentation.

Registration tells you what users can do. Access policy tells you what they must do.

Where enforcement comes from

For a small organization without Microsoft Entra ID P1, Security Defaults provides a baseline at no extra licence cost. It requires MFA registration, enforces MFA for administrators and when Microsoft considers it necessary for other users, and blocks legacy authentication.

Security Defaults is intentionally simple: it is on or off, without custom exclusions or targeting. Microsoft’s Security Defaults guidance positions it for organizations that need a baseline without complex access requirements.

Organizations with Microsoft Entra ID P1, including Microsoft 365 Business Premium customers, can use Conditional Access for more control. It also creates more ways to leave an unintended gap.

A policy can require MFA and still leave a gap because it:

• covers one group rather than all intended users;
• applies only to selected resources;
• excludes users, groups, roles, guests, or locations;
• protects administrators but not ordinary accounts; or
• remains in report-only mode.

Check the policy state before trusting the name. Report-only policies record what would have happened but do not prompt users or enforce MFA.

What credible evidence looks like

First identify the mechanism: Security Defaults, Conditional Access, or another documented MFA provider. Then verify effective scope rather than relying on a policy name.

For Conditional Access, Microsoft recommends a baseline covering all users and all resources, with MFA required. Emergency access accounts are a legitimate exception because they must remain usable if normal administrators are locked out. Every exclusion still needs a current reason, an owner, and monitoring.

A policy called “Require MFA” may be disabled or report-only. A group-based rollout may omit new employees, an app-specific policy may leave other resources outside its scope, and guests may need separate coverage.

Then compare the policy with actual sign-ins. Microsoft recommends testing changes in report-only mode, reviewing the results in sign-in logs, and moving the policy to On once its impact is understood. Its Conditional Access MFA guidance and report-only documentation describe that workflow.

The result should be explainable: who and what is covered, which exceptions remain, and what recent sign-ins show.

Enforced MFA is not the end of the identity review. Device code phishing can succeed even when MFA is enforced because the user authenticates a session initiated by an attacker. That flow needs its own access decision.

Avoid the quick fix that creates a lockout

Do not switch on a broad Conditional Access policy without preparing for it. Confirm licensing, inform users, protect emergency access, and test the policy before enforcement.

Check for older clients or protocols that cannot complete MFA. Security Defaults blocks legacy authentication; a Conditional Access rollout normally needs equivalent protection so an older path does not bypass the new requirement.

The point is not to delay MFA. It is to verify a working access decision instead of declaring success from a registration count.

Make it a recurring check

Coverage changes as people join groups, applications are added, exceptions outlive support cases, and policies change state. A correct result today is not permanent.

PosturIQ assesses MFA coverage and highlights exclusions or scope gaps for review. An intentional exception, such as an emergency access account, can be recorded with its reason and owner. If another exclusion appears later, the next assessment flags the new gap instead of treating it as part of the approved exception.

The assessment is read-only: the administrator or MSP applies any policy change, then runs another assessment to verify the result.

This is one part of a wider small business security posture audit, where identity, email, and device evidence need to agree with the security outcome the business expects.