Understand the M365 MFA reporting gap for cyber insurance. Learn the difference between Entra ID conditional access, security defaults, and true MFA enforcement.
Many organizations believe they have MFA enforced in Microsoft 365 because they've enabled Entra ID security defaults or set up conditional access policies, but underwriters often reject these as insufficient proof of MFA enforcement. The issue is that different M365 features provide different levels of protection and reporting: (1) Security defaults require MFA for all users but don't provide granular policy control or enrollment reports, (2) Conditional Access policies can enforce MFA for cloud apps but may have exclusions and don't prevent legacy authentication from bypassing MFA entirely, (3) Per-user MFA (legacy) allows admins to enable MFA per user but doesn't prevent users from registering weak authentication methods. Underwriters typically require evidence showing: (a) MFA is required for all users and cannot be disabled, (b) Legacy authentication is blocked (users cannot use basic auth), (c) Enrollment reports showing 100% user adoption, (d) Conditional access policies configured with no broad exclusions. A common gap is that Entra ID reports may show conditional access policies are configured but lack visibility into whether legacy authentication is actually blocked—an attacker can still use basic auth to bypass MFA. Another gap: conditional access policies may exclude specific users (service accounts, guest users) who then become vulnerable to compromise. Brokers should request: screenshot of conditional access policy showing MFA required for all cloud apps with no broad exclusions, report from Entra ID sign-in logs showing that legacy authentication attempts are blocked (zero basic auth logins), and enrollment report showing all expected users have MFA registered.
IT team says 'We have security defaults enabled' or 'We use conditional access for MFA.' Broker checks yes for MFA on application. Underwriter asks for enrollment report and policy screenshots; IT discovers no enrollment report available and conditional access policies don't show actual legacy auth block status.
M365 administrators don't understand policy differences. Conditional access policies configured but not verified to block legacy auth. No enrollment report showing MFA adoption percentage. Underwriter requirements for legacy auth blocking not communicated to IT. No distinction made between security defaults, conditional access, and legacy MFA.
MFA documentation showing: conditional access policy screenshot with MFA required, sign-in logs verifying legacy auth is blocked, enrollment reports showing MFA user adoption percentage, and confirmation that users cannot disable MFA.
BindLedger M365 MFA checker queries Entra ID to verify conditional access policies, checks sign-in logs for legacy auth activity, and generates enrollment reports.
View M365 MFA guide
View M365 MFA guide →“Conditional access policies provide granular control over MFA enforcement, but must block legacy authentication to be fully effective.”
“Threat actors consistently use legacy authentication to bypass MFA, leveraging mail protocols like IMAP4, POP3, or SMTP, and older Outlook clients that don't support MFA.”
“The sign-in logs provide information about the usage of managed applications and user sign-in activities, which includes information about multifactor authentication usage.”
“Sign-in logs provide details on user authentication activity including MFA status, conditional access policy evaluation, and legacy authentication attempts.”
“Enrollment reports show MFA adoption rate and help verify user compliance with policies.”