Most Microsoft 365 tenants have MFA switched on. Fewer actually enforce it. The distinction sounds pedantic until an attacker authenticates through a gap nobody knew existed, and the logs show a clean sign-in.
This article explains where that gap lives, why it persists quietly, and how to observe and evidence your enforcement coverage in Entra ID.
The Difference Between Enabled and Enforced
Microsoft offers more than one mechanism for MFA, and they do not all behave the same way.
Per-user MFA, the legacy approach found in the Microsoft 365 admin centre under Users > Active Users > Multi-factor authentication, marks an account as MFA-enabled or MFA-enforced. When set to enforced, the user is prompted to complete registration after their next sign-in. This sounds definitive. It is not. Per-user MFA has no awareness of network location, device state, or application context. More significantly, it can be bypassed by legacy authentication protocols such as IMAP, POP3, and older SMTP paths that do not support modern authentication challenges. A user marked as MFA-enforced in the per-user portal may still authenticate successfully against Exchange Online through a legacy mail client, completing no MFA step at all.
Security Defaults, introduced in 2019, apply a baseline MFA requirement across the tenant and block legacy authentication. For organisations that have not configured Conditional Access, they provide a meaningful floor. They are a blunt instrument, though. They cannot be scoped by group, application, or risk level, and they have to be turned off before you can enable your first Conditional Access policy. Many tenants assume Security Defaults remain active long after that first policy was created. They do not.
Conditional Access policies are where genuine, context-aware MFA enforcement lives. A policy can require MFA for all users, for privileged roles only, for specific applications, or when sign-in risk is elevated. Properly constructed, this is the right approach. The difficulty is that Conditional Access policies can fail silently, and several failure modes are common.
Where Enforcement Silently Fails
Admin Accounts That Predate the Policy
Conditional Access policies apply to users and groups. When a policy is created and scoped to "All users", break-glass accounts and older administrator accounts are frequently excluded, either through deliberate exclusion groups or because they sit in a directory role rather than a group covered by the policy. An administrator account created before your Conditional Access rollout, and never properly reviewed since, may have no effective MFA requirement against it.
Break-glass accounts are a legitimate exception. They need to operate when policy enforcement itself is broken. But they require compensating controls, strict credential management, and monitored sign-in alerts. In practice, many tenants have several accounts in a similar position with none of those controls in place.
Temporary Exclusions That Became Permanent
Conditional Access exclusions are added quickly and removed slowly. A user excluded because they were travelling without their registered MFA device, a contractor onboarded in a hurry, a shared account used by a third party: each exception feels justified at the time. Over months, exclusion groups accumulate members. No policy review removes them. The effective enforcement scope of your MFA policy quietly shrinks.
Legacy Authentication Paths
If your Conditional Access policies do not explicitly block legacy authentication, those protocols remain available. Legacy authentication cannot satisfy a modern MFA challenge. An attacker with a valid password and the knowledge that legacy auth is open can authenticate as that user without completing MFA, regardless of what your policy nominally requires.
Blocking legacy authentication is straightforward. A Conditional Access policy with a client app condition set to Exchange ActiveSync clients and Other clients, configured to block access, closes this path. Many tenants have either never created it or built it with exclusions that leave gaps.
Service Accounts and Non-Human Identities
Service accounts, application registrations, and managed identities each have different authentication behaviours. Service principals authenticating via client credentials (client ID and secret) do not go through an interactive sign-in flow and therefore cannot complete an MFA challenge. This is expected and by design. The risk arises when:
- A human account is used as a service account and is excluded from MFA policy to avoid breaking automation.
- An application registration holds a client secret with no expiry, no owner, and broad Microsoft Graph permissions, functioning as a privileged identity with no MFA and no oversight.
- Workload identities are not covered by your Conditional Access policies, which has historically required a separate licence tier.
Non-human identities are often the blind spot in MFA discussions because the conversation defaults to users. Privileged permissions held by an application or service principal represent real exposure if those credentials are compromised.
Report-Only Mode Policies
Conditional Access policies created in report-only mode log what would have happened without enforcing anything. This is valuable for testing. The risk is that a policy intended for enforcement is never moved out of report-only mode, and nobody notices. The Entra ID sign-in logs show the policy being evaluated against sign-ins, which gives the appearance of activity, but nothing is being blocked or required.
Observing and Evidencing Enforcement Coverage
Understanding your actual enforcement posture means looking at several things together, not simply confirming that policies exist.
Conditional Access policy inventory. Review every policy: its state (on, off, report-only), its assignment scope (users, groups, roles, guests), its exclusions, its grant controls, and its session controls. A policy set to "All users" with a large exclusion group may cover far fewer accounts than it appears to.
Sign-in logs. Entra ID sign-in logs record which Conditional Access policies applied to each sign-in and what the outcome was. Filtering for sign-ins where MFA was not performed, particularly for privileged accounts, shows where enforcement coverage is missing in practice rather than in theory. Retention varies by licence tier, so confirm how far back your data reaches before relying on it for evidence.
Authentication method registration. The Authentication Methods Activity report in Entra ID shows which users have registered a strong authentication method. A user covered by a Conditional Access policy requiring MFA but who has never registered an authenticator app is in a broken state. The policy will either block their sign-in or prompt them to register at sign-in time with no prior setup. Neither outcome is clean.
Per-user MFA state. If your organisation still holds legacy per-user MFA settings, verify whether they remain active alongside Conditional Access policies. Mixed state creates confusion and can produce unexpected behaviour.
Exclusion group membership. Pull the current membership of every group used in Conditional Access exclusions. Review whether each member still warrants exclusion and whether compensating controls are documented.
Legacy authentication sign-in data. Filter the Entra ID sign-in logs by client app to identify any successful authentications via legacy protocols. If these exist, your policy to block legacy auth is either absent, in report-only mode, or has gaps.
What ScanPosture Observes
ScanPosture reads your Entra ID configuration and sign-in metadata to surface exactly these gaps: policies in report-only mode, exclusion group sizes, the presence or absence of a legacy authentication block, per-user MFA states, service principal credential ages, and accounts with privileged roles that have no Conditional Access coverage.
The result is an Observable Readiness report mapped against the relevant technical controls. That includes NIST CSF PR.AA-01 (identity and credential management) and PR.AA-05 (access permissions and authorisation), NIST SP 800-53 IA-2 (identification and authentication) and AC-2 (account management), and the technical safeguard requirements under GDPR Article 32.
ScanPosture shows alignment and readiness against selected technical controls related to these models. It does not itself certify compliance or replace formal assessment, certification, or legal advice.
Because ScanPosture is read-only, it does not alter your configuration. What it provides is a structured, evidence-based picture of where your enforcement coverage holds and where it does not, which is a reasonable starting point for any remediation conversation.
Closing Thought
MFA being available in your tenant and MFA being enforced on every authentication path are materially different states. The distance between them is occupied by exclusions added for convenience, legacy protocols left open, policies stuck in report-only, and service accounts treated as edge cases. None of these gaps announces itself. Reviewing them takes deliberate, structured inspection of your Entra ID configuration rather than a quick check that MFA policies exist.
If you cannot say with confidence which accounts in your tenant are genuinely subject to an enforced MFA requirement on every sign-in, that is the gap worth addressing first.
