MFA registered, but not enforced

One hundred per cent MFA registration says nothing about whether MFA is actually enforced. Registration sits with an account. Enforcement happens at the moment of the sign-in. In Entra ID the two drift apart as soon as Conditional Access stops asking for the second factor on part of the sign-ins, while every user does have a method registered. That difference shows up in the sign-in logs, not in the registration report that some dashboards display.

This applies to any organisation reporting MFA coverage to its board, an auditor or an insurer. Start by measuring: how many successful sign-ins over the past thirty days met an MFA requirement, broken down by application and account type.

Where the gap between registration and enforcement sits

Registration and enforcement are two separate mechanisms. At registration a user records a method, using for example an Authenticator app or a FIDO2 key. At enforcement a policy then decides whether that method is actually requested during a sign-in. Authentication strength adds a third element, determining which methods may satisfy that requirement. A push notification and a phishing-resistant passkey are both MFA, but they do not offer the same level of protection. Between registration on one side and enforcement on the other, the room for error appears.

Policies are often left in report-only because few administrators want to tighten them, whether for reasons of usability or because of exclusions covering trusted locations or that one application that would not work otherwise. Accounts were added as an exception during a migration and are still there. Legacy authentication cannot request a second factor at all and therefore bypasses everything else you have put in place.

Security Defaults is intended as baseline protection for tenants without their own Conditional Access policies. It requires users to register a method, requires MFA for administrators, can require MFA for users where Microsoft considers it necessary, and blocks legacy authentication protocols. For new tenants, device code flow has also been blocked since 1 July 2026. That reduces exposure to common attacks, but offers no control by application, user group, location, device state or method. Organisations that want to determine in advance where MFA applies, manage exceptions demonstrably or enforce phishing-resistant authentication for critical roles will generally need Conditional Access. The two do not operate as separate policy layers running side by side.

So this is not a shortcoming of MFA, nor a configuration error you resolve at the press of a button. The figure most CISOs look at measures something that does not tell the whole story, which leaves a gap in coverage invisible. Including in environments where everything needed to get this right is technically available.

What the sign-in logs do and do not show

The sign-in logs hold what you need to reconstruct an authentication event: the user, application, resource, client, IP address and device state, the sequence of methods used, and which policies were evaluated, applied, not applied or active only in report-only mode. This is where the enforcement rate comes from.

The Authentication requirement field is not sufficient on its own. A resource can accept a previously issued MFA claim, so the user receives no new prompt even though the session rests on earlier strong authentication. Conversely, a sign-in can appear as single factor while a valid claim existed in the broader context. The original method, the session state and the token chain therefore have to be assessed together. Shortly after an event the Authentication details can also still be incomplete, because Microsoft is processing the log data. Where the picture is unclear, use the final log record and link related events through the Request ID and Correlation ID.

How this comes about in practice

Anyone using Entra ID stands a chance of having this difference in their own environment. It is not a fault that arrives with a particular version or configuration, but a result of how organisations work with Conditional Access over time. Checking is therefore worthwhile, even without a direct reason to suspect it.

During a forensic investigation, DeepBlue Security & Intelligence examined a Microsoft 365 account for which Authenticator was registered. The tenant used Security Defaults. Access with valid primary credentials nevertheless proved possible. That does not automatically mean Authenticator or Security Defaults was technically bypassed. The same picture can arise from an existing session, a previously issued claim, the application being accessed or the protocol used. The question is not whether MFA is switched on, but which requirement applied to that specific access and how it was satisfied.

The cause is rarely one large mistake. Usually it comes down to exclusions that were meant to be temporary. An application that would not work with modern authentication during a migration. A supplier that had to be able to work from a fixed IP address. A group of users skipped during a rollout to keep to the schedule. Each of them a defensible decision at the time. What tends to be missing is an end date and an owner, so nobody looks at it again for as long as everything keeps working.

The problem usually surfaces when something changes that the policy was never adjusted for: a migration, a merger, a new SaaS application, or an administrator who leaves. If something like that has happened recently and no new measurement followed, the dashboard is likely to show a different picture than the sign-in logs.

What you can do now

Measure the enforcement rate in the sign-in logs over the past thirty days, broken down by application, account type and location, and place it alongside the registration figure currently in circulation. The difference between the two is your actual finding.
Review every exclusion in Conditional Access, including the policies still set to report-only, and record for each exclusion who requested it, why, and until when it is valid. Anything you cannot justify goes.
Block legacy authentication and measure again afterwards. Take stock first of what still relies on it, because this is where you cause a production issue if you move too quickly.
Bring service accounts, break-glass accounts and guest accounts under explicit policy, each with a documented compensating control and monitoring on use. This group often falls outside the scope and generally holds the heaviest privileges.
Deploy phishing-resistant methods for admin accounts. Enforced MFA based on push resolves your coverage, but not token theft or an AiTM attack where the attacker sits between the user and the service.

Conclusion

The number of registered users says nothing here about the MFA coverage rate. The enforcement rate per sign-in does answer the question that should be asked. What remains: even a high enforcement rate does not rule out token theft and session hijacking, and says nothing about the resilience of the methods in use. So start with a clear overview, and address the methods after that.

Sources

Further reading: penetration testing, managed SOC and leaked credentials.

Last reviewed for technical accuracy: 29 July 2026.