Microsoft 365 and Entra ID are where most underwriters expect to see proof of MFA, access control, and tenant security. This guide is for IT admins, MSPs, and brokers who need evidence that MFA is enforced — not just enabled. That distinction matters because Microsoft separates registration status, sign-in activity, and policy enforcement into different reporting surfaces.
Underwriters want evidence that users are registered for MFA, that MFA prompts actually occur during sign-in, and that enforcement is controlled by policy rather than informal admin intent. In Microsoft's ecosystem, that usually means sign-in logs showing authentication behavior, registration detail reports showing who is enrolled, Conditional Access policy evidence showing how MFA is required, and documentation of any exclusions or named locations. More than 99% of password spray attacks use legacy authentication protocols, so carriers increasingly ask whether legacy auth is blocked.
You need at least the Reports Reader role. For Conditional Access policy evidence, you need Entra ID P1 or P2 licensing. Key retention limits: sign-in logs are retained for 7 days on free tier, 30 days with P1/P2. If you do not have P1/P2, the fallback is Security Defaults, which is weaker evidence. Legacy authentication blocking requires a Conditional Access policy — navigate to Conditional Access > Policies and create a policy that blocks "Exchange ActiveSync clients" and "Other clients" under Conditions > Client apps.
In the Entra admin center, go to Monitoring and health > Sign-in logs. Filter to the renewal period and relevant applications. Export as CSV. This is your strongest direct evidence that MFA is invoked during authentication events.
Pro tip: Include the MFA result column — it shows whether MFA was required, satisfied, or bypassed per sign-in.
Suggested filename: entra-signin-logs-mfa-renewal-2026-03.csv
Export user registration details from Protection > Authentication methods > Activity. This proves how many users are registered for MFA-capable methods. Registration alone is weak — pair it with sign-in or Conditional Access evidence.
Pro tip: Registration evidence shows coverage; sign-in evidence shows enforcement. You need both.
Export or capture Conditional Access policies showing which users or groups are targeted, which applications are covered, the grant control requiring MFA, and any named location or trusted-IP exceptions. Requires Entra ID P1 or P2.
If the tenant uses Security Defaults because it lacks P1/P2, state that plainly. Security Defaults enables baseline MFA but lacks per-app policy granularity and exception controls. Honesty here is better than implying fine-grained enforcement you cannot prove.
Show that legacy auth protocols (IMAP, POP3, SMTP, ActiveSync) are blocked. Navigate to Conditional Access > Policies and capture the policy blocking legacy client apps. Over 99% of password spray attacks use legacy protocols — carriers care about this.
Sometimes, but it is weaker evidence than Conditional Access because it lacks per-app policy granularity and exception controls. Present it accurately rather than overselling it.
Conditional Access requires Microsoft Entra ID P1 or P2. Without it, you are limited to Security Defaults.
7 days on the free tier, 30 days with P1/P2. If you need longer retention, you must archive to Azure Storage or a SIEM.
Because registration, usage, and enforcement are split across different reporting surfaces. A tenant can have users registered for MFA without proving MFA is enforced for all access paths.
Legacy auth refers to older protocols (IMAP, POP3, SMTP, ActiveSync) that bypass MFA entirely. Over 99% of password spray attacks use these protocols. Blocking them is increasingly a carrier requirement.
Automate Microsoft 365 evidence collection instead of rebuilding it from screenshots every renewal. Run a free readiness check.
Run Free Readiness Check →