The MFA Question Takes 2 Seconds. Proving It Takes 2 Hours.

Every cyber insurance application asks the same question: Do you use multi-factor authentication (MFA) for all remote access?

Answering "yes" takes two seconds. Proving it — finding the right report, pulling the data in a format your underwriter accepts, documenting coverage scope and exception handling — takes two hours. Often longer if you're pulling from multiple platforms.

This article is the shortcut.

If you're renewing cyber insurance and use Entra ID, Duo, Okta, or a combination of these, this guide shows you exactly which reports to pull, where to find them in each admin console, what data carriers actually want to see, and the common traps that make reports unusable for underwriting.

Key Takeaways

  • Most carriers are not really asking whether MFA exists. They are asking whether it is enforced, who it covers, and where the gaps are.
  • Entra ID, Duo, and Okta each give you strong evidence surfaces, but none of them produces a perfect insurer-ready sentence by itself.
  • A defensible MFA packet usually combines policy proof, user coverage proof, recent activity, and documented exceptions.
  • The best time to export MFA evidence is before renewal week, not during it.

What a Defensible MFA Evidence Pack Should Include

Before we get platform-specific, define the target. A strong MFA evidence pack usually includes four layers:

1. Policy Evidence

Show the enforcement logic. What policies require MFA? Which users, groups, or applications do they apply to? Are there exclusions? This proves intent and configuration structure.

2. Coverage Evidence

Show who is actually enrolled or registered. This is where the carrier stops hearing "we turned it on" and starts seeing who is really inside the control.

3. Usage or Activity Evidence

Show that MFA is being used in reality, not just configured in theory. Recent sign-in or authentication activity is often the fastest way to support that claim.

4. Exception Context

Show the edge cases honestly. Break-glass accounts, incompatible systems, transition states, or platform gaps are not fatal by themselves. They become fatal when they are invisible.

For more context on why MFA reporting can be tricky in Microsoft environments, see The M365 MFA Reporting Gap.

Microsoft 365 / Entra ID: What to Export and Why

For many teams, Entra is the hardest MFA evidence source because the truth is spread across multiple surfaces. If you only export one thing, you will almost always miss something important.

Export 1: User Registration Details

This is the closest thing to user-level coverage proof. It helps show which identities are registered for MFA and gives the broker a denominator to work with.

Where to find it:

  1. Go to the Entra admin center (entra.microsoft.com).
  2. Navigate to Protection → Authentication methods → User registration details.
  3. This report shows which users have registered each authentication method. Look for the "Microsoft Authenticator," "Windows Hello," FIDO2, or other MFA methods. The report gives you a percentage of users registered for each.

What carriers want to see:

  • Registration percentage for at least one MFA method across your user base

Use the step-by-step guide here: Microsoft 365 / Entra ID evidence guide

Export 2: Conditional Access Policy Views

This is your policy-layer evidence. It answers the question "where is MFA required?" much better than a generic statement from memory.

Where to find it:

  1. Go to Protection → Conditional Access → Policies. Screenshot or export your active policies. Document which ones enforce MFA and which user groups they target.

What it proves:

  • whether MFA policies exist
  • what those policies target
  • what grant controls are used
  • and whether exclusions are built into the design

What it does not prove:

  • that every relevant identity is actually covered
  • that non-Microsoft remote access paths are protected
  • or that every excluded user has a defensible exception

Export 3: Security Defaults State

This is important because many smaller environments still rely on Security Defaults as the baseline MFA model.

What it proves:

  • whether Microsoft's baseline enforcement model is active

What it does not prove:

  • the full granularity a carrier may want
  • or whether the organization has a more nuanced policy model with exclusions and separate access paths

Check Protection → Security defaults and confirm the toggle is "Enabled."

Export 4: Sign-In Logs

This adds the runtime layer. It helps show recent MFA-related activity and supports the claim that the control is actually being exercised.

Where to find it:

  1. Go to Monitoring → Sign-in logs. Apply a filter for "Multifactor authentication" to see recent MFA authentication events. This is a smoke test showing MFA is actually being used.

What carriers want to see:

  • Evidence that MFA is being actively used (sign-in logs showing successful MFA events)
  • Any exceptions documented in your policies (e.g., "service accounts excluded due to legacy system integration")

The Key Entra Warning

Do not confuse registration with enforcement. That is the core problem described in The M365 MFA Reporting Gap. A user can be capable of MFA without being protected on every path the carrier actually cares about. That is why the Entra packet works best when policy, coverage, and activity are exported together.

Cisco Duo: What to Export and Why

Duo is often easier to explain to carriers because the evidence surfaces feel more direct. But it still helps to export the right combination.

Export 1: User Enrollment Report

This is the most useful starting point. It gives you a user list with enrollment context and helps answer the coverage question quickly.

Where to find it:

  1. Log in to the Duo Admin Panel (admin-[account-id].duosecurity.com).
  2. Go to Users → User Management to see total active users and which have MFA enrolled. You can export this list.

What it proves:

  • whether active users are enrolled
  • whether the deployment looks broad or partial
  • and whether there are obvious bypass or disabled states to explain

Export 2: Global Policy Screenshot or Policy Evidence

This is your configuration layer. It shows how the platform is intended to enforce MFA.

Where to find it:

  1. Go to Applications → Applications and document which integrations are protected by Duo policies.

Key point: In Duo, "enrolled" does not mean "enforced." A user can have MFA enrolled but a policy can mark it as optional. Carriers are asking for enforcement, not just enrollment. Show which policies are set to "Required" (not "Optional") for MFA. This is the enforcement proof carriers need.

Export 3: Authentication Log

This is the runtime layer. It helps prove that MFA is not just configured and forgotten. It is being used.

Where to find it:

  1. Go to Reports → Authentication Log. This is your primary report. You can export this as CSV.
  2. From the Authentication Log, filter for successful MFA events and export. The report includes user, application, authentication method, and success/failure status.

What carriers want to see:

  • Recent authentication activity showing MFA is in active use
  • MFA method diversity (phone call, push notification, hardware token, etc.)
  • Any users without MFA enrolled, documented as exceptions (if any exist)

Extra Evidence When Duo Protects VPN or Remote Access

If Duo is specifically being used to secure VPN, RDP, or another remote access workflow, include the application or integration context as part of the packet. Carrier questions often care less about the identity brand and more about whether the risky access path is actually covered.

Use the click-by-click guide here: Cisco Duo evidence guide

Okta: What to Export and Why

Okta tends to create good evidence when the team pulls both policy and user-level material. It becomes weaker when the packet is only a screenshot of the admin console home page.

Export 1: MFA Enrollment Report

This gives you the user coverage view and helps answer the adoption question with real data.

Where to find it:

  1. Log in to the Okta Admin Console (your-org.okta.com/admin).
  2. Go to Security → Authenticators to see which MFA methods are available to users (Okta Verify, Google Authenticator, hardware tokens, etc.) and enrollment rates.

Export 2: Authentication Policy Screenshots

This is the policy layer. It shows what kinds of logins require MFA and under what conditions.

Where to find it:

  1. Go to Security → Authentication Policies. Screenshot or export your active policies. Document which ones require MFA and which user groups they apply to.

Key point: In Okta, you can add MFA as an "optional" factor to an authentication policy — users are offered MFA but not required to use it. Carriers want required. When you export your authentication policies, verify that MFA factors are set to "Required" in the policy, not just "Available." An optional MFA factor doesn't meet most carrier requirements.

Export 3: System Log Export

This is your activity layer. It supports the claim that authentication events are flowing through the platform and gives the packet more than a static configuration view.

Where to find it:

  1. Go to Reports → System Log. This is a real-time log of all authentication and administrative events in your Okta instance.
  2. Apply a filter: Event Type = "MFA" or use the search box to search "mfa_verify". Export the results as a CSV. This gives you recent evidence that MFA is being actively enforced.

What carriers want to see:

  • Factor enrollment rates (what percentage of users have at least one MFA method enrolled)
  • Active authentication policy assignments showing MFA is required (not optional)
  • Recent system log events showing MFA verification is happening
  • Exception groups documented in your policies (e.g., service accounts, contractors, vendors)

Extra Support: Enabled Authenticator Methods

If the carrier is likely to care about the quality of factors, not just the existence of MFA, include a view of the enabled authenticators as supporting context.

Use the step-by-step guide here: Okta evidence guide

The Common Mistakes That Make MFA Evidence Weaker Than It Should Be

The same avoidable mistakes show up over and over:

Mistake 1: Exporting Only the Policy and Not the Users

A policy screenshot can make the environment look stronger than it is. Without user coverage, the packet still leaves the main question open: who is actually protected?

Mistake 2: Exporting Only User Registration and Not the Policy Logic

This creates the opposite problem. It shows who is capable, not necessarily where enforcement is happening.

Mistake 3: Ignoring Non-Primary Access Paths

If the organization uses a separate VPN, remote support tool, privileged access workflow, or legacy application path, do not assume the main identity platform tells the whole story.

Mistake 4: Hiding Exceptions

Break-glass accounts, migration states, service-related exclusions, and one-off exceptions should be documented, not buried. Honest exception handling is stronger than a broad answer that falls apart later.

Mistake 5: Exporting the Evidence Too Late

Console exports created under deadline are messy, incomplete, and hard to explain. The best MFA packets are built before the renewal email becomes urgent.

How to Package the MFA Evidence So a Broker Can Use It

A broker should not have to decode raw CSVs in order to submit a clean answer.

Once you export the platform data, package it like this:

  1. One short summary statement — "We enforce MFA on all users through [method] with [X]% coverage. Exceptions are documented below."

  2. One page of policy context — The policy screenshots showing what policies are active and what they target.

  3. One page of user coverage context — The enrollment or registration data showing who is inside the control.

  4. One page of recent activity evidence — The activity logs or sign-in events showing MFA is being exercised.

  5. One short note on exceptions and next steps — Break-glass accounts, migration states, or known gaps with planned remediation.

If you need the policy artifact itself, the MFA policy template is the right companion document.

If you need the whole file packaged cleanly for underwriting, move the exports into the evidence packet workflow.

The Right Workflow for the Next Renewal

The simplest process is usually the best one:

  • Start with the platform guide
  • Export the evidence while the console is open
  • Add a short explanation of scope and exceptions
  • Then package it before the broker asks for it twice

That turns MFA from the control most likely to trigger back-and-forth into the control most likely to move the account forward quickly.

Next Steps

  1. Identify your platforms. Which of these three — Entra ID, Duo, Okta — do you use? Start with one.

  2. Get the step-by-step guides. For complete step-by-step screenshots and platform-specific nuances, see Collection Guides — we maintain detailed export guides for 30+ security platforms.

  3. Export the right evidence layers. Use the framework above: policy, coverage, activity, and exception context.

  4. Package it cleanly. Once exports are complete, use the five-point packaging approach above. If you need help, move the exports into the evidence packet workflow.

  5. Check what else you need. MFA is one control. Carriers typically ask about endpoint detection and response (EDR), backup and recovery, email security, and incident response. See 8 Controls Every Carrier Checks in 2026 for a complete list.

  6. Document policy and exceptions. If you don't have a written MFA policy, use the MFA policy template as a starting point.

Need the exact export steps? Open the evidence guides →

Ready to package those exports into something carrier-ready? Generate an evidence packet →