By Ryan Windt | Head of Growth Marketing | Updated April 2026
Multi-factor authentication is the single control that appears on every cyber insurance application, every underwriting questionnaire, and every carrier declination letter when it is missing. It is also the control that generates the most confusion when businesses actually try to implement it. What counts as MFA? Where does it need to be deployed? What does “enforced everywhere” actually mean to an underwriter?
This guide answers those questions with enough specificity to be useful — whether you are deploying MFA for the first time, documenting existing coverage for a renewal, or preparing an evidence package for an underwriter who wants proof, not promises.
Why MFA Is the First Thing Underwriters Look At
The overwhelming majority of ransomware incidents and business email compromise events that generate cyber insurance claims share a common entry point: compromised credentials used to access systems that had no second factor of authentication.
Underwriters know this because they see the forensic reports. Stolen username and password, no MFA on the VPN or email, attacker inside the environment within hours. This pattern is so consistent that carriers have stopped treating MFA as a nice-to-have and started treating the absence of it as a material increase in risk that affects both eligibility and price.
What this means practically:
- No MFA on email or remote access will result in declination or heavy sublimits at most standard carriers
- Partial MFA deployment — covering some users but not all, or covering workstations but not servers — is scrutinized nearly as heavily as no MFA at all
- SMS-based MFA is increasingly viewed as insufficient for privileged and administrative accounts due to SIM-swapping risk
- The strongest applications document MFA enforcement through policy exports and configuration screenshots, not just attestation checkboxes
The good news is that for most SMBs and MSPs, the path to meeting underwriting standards is not technically complex. It requires coverage, enforcement, and documentation. Each of those is achievable with tools you almost certainly already have.
What Counts as MFA (and What Does Not)
Not all second factors are equal in the eyes of underwriters. Here is how the most common methods are evaluated:
Phishing-resistant MFA (strongest)
FIDO2 security keys (YubiKey, Google Titan), passkeys, and certificate-based authentication are the gold standard. They cannot be intercepted through phishing or real-time man-in-the-middle attacks because the credential is bound to the specific domain and device. Underwriters writing policies for high-risk categories — MSPs, financial services, healthcare — increasingly ask specifically whether phishing-resistant MFA is deployed for administrative accounts.
Authenticator app (TOTP/push) — widely accepted
Microsoft Authenticator, Google Authenticator, Duo, and similar apps generating time-based one-time passwords or push notifications are the current standard for most SMB and MSP applications. They are accepted by carriers for general user accounts and most remote access scenarios. For privileged accounts, expect to be asked whether number matching or additional context is enabled on push notifications to reduce push fatigue attack risk.
SMS / text message codes — acceptable with caveats
SMS-based MFA is still accepted by most carriers for standard user accounts, but is increasingly flagged as insufficient for administrator accounts, privileged access, and high-risk applications like financial platforms. If your MFA deployment relies entirely on SMS, flag it in your application and document compensating controls for privileged roles.
Email OTP — generally not accepted
One-time codes sent to email are not considered true MFA by most underwriters because the email account itself is a target. If your email is compromised, the one-time code sent to that same inbox is also compromised. This is not a qualifying second factor for cyber insurance purposes.
Security questions — not MFA
Questions like “what was your mother’s maiden name” are knowledge-based authentication, not a second factor. They do not satisfy MFA requirements.
Where MFA Must Be Deployed
“We have MFA” is not sufficient on a cyber insurance application. Underwriters want to know where it is deployed and whether it is enforced or merely available. These are the coverage areas that appear on virtually every supplemental questionnaire:
Email (Microsoft 365 / Google Workspace)
This is the highest-priority deployment. BEC attacks are the leading cause of cyber insurance claims by dollar value according to FBI IC3 data, and virtually all of them begin with email account compromise. MFA enforcement on all email accounts — not just admins, all users — is the minimum standard.
For Microsoft 365: enforce MFA through Conditional Access policies, not just per-user MFA settings. Per-user MFA can be bypassed using legacy authentication protocols. A Conditional Access policy that blocks legacy authentication and requires MFA for all cloud app access is the correct configuration.
For Google Workspace: enforce 2-Step Verification enrollment through the admin console and set it to required rather than optional.
Evidence to document: Screenshot of the Conditional Access policy (M365) or 2SV enforcement setting (Google Workspace) showing “enabled” and “enforced for all users.”
Remote Access (VPN, RDP, ZTNA)
Remote access is the second most common entry point for ransomware after email. RDP exposed directly to the internet without MFA is one of the most frequently cited underwriting red flags.
Every remote access method — VPN, Remote Desktop Gateway, Zero Trust Network Access tools, and remote support software — needs MFA enforced at the authentication layer. For MSPs, this includes your RMM platform.
No open RDP to the internet is a non-negotiable baseline. Remote desktop sessions should require VPN plus MFA before reaching the RDP layer. If RDP must be internet-accessible for any reason, a Remote Desktop Gateway with MFA enforcement is the minimum.
Evidence to document: VPN configuration showing MFA as required; external scan or firewall rule confirming RDP (port 3389) is not open to the internet; RMM console screenshot showing MFA enforced for all technician logins.
Administrative and Privileged Accounts
Privileged accounts — domain admins, global admins in M365, local admin accounts used across systems — are the most targeted credentials in any environment. Compromising a single privileged account can give an attacker the ability to push ransomware across every device the account has access to.
MFA requirements for admin accounts are distinct from general user requirements. Underwriters look for:
- Separate admin accounts for privileged tasks (no day-to-day browsing or email on admin credentials)
- MFA enforced on all admin account logins, including console access and management portals
- Phishing-resistant MFA specifically for the highest-privilege roles where feasible
- Just-in-Time elevation rather than standing privileged access where the tooling supports it
Evidence to document: Screenshot of admin role assignments showing MFA is enforced; Conditional Access policy showing admin accounts are in scope; PAM tool configuration if applicable.
Critical SaaS Applications
Underwriters increasingly ask about MFA coverage on the SaaS applications that matter most to your business operations: finance and accounting platforms, HR and payroll systems, CRM, and any platform that handles customer data or payment information.
For most SMBs, this means verifying that MFA is enabled in the application settings for each platform and that SSO through a identity provider (which inherits MFA requirements from your Conditional Access policy) is used wherever possible.
Evidence to document: Screenshot of MFA settings within the application (QuickBooks, Salesforce, ADP, etc.) or SSO integration showing the app routes through your identity provider with MFA enforced.
MSP-Specific: Client Environment Access
If you are an MSP, your access to client environments is a separate and critical coverage area. The credentials and access methods you use to manage client systems need the same MFA protection as your own internal systems — arguably stronger, given that a compromise of your management access affects every client simultaneously.
This means MFA enforcement on:
- Your RMM platform (N-able, ConnectWise, Datto, Kaseya, etc.)
- Any PSA tools with access to client credentials or systems
- Client-facing admin portals
- Documentation tools that contain client credentials or network diagrams
Underwriters writing MSP policies specifically ask about RMM MFA because the aggregation risk from a compromised RMM is so significant. See our post on MSP RMM Hardening for the full control set that carriers expect.
Enforcement vs. Availability: The Distinction That Matters Most
One of the most common MFA misrepresentation issues in cyber claims is the difference between making MFA available and actually enforcing it. These are not the same thing, and underwriters treat them differently.
Available but not enforced means MFA has been enabled as an option but users can choose not to use it, or certain accounts are exempted, or legacy authentication paths remain open that allow bypassing MFA entirely.
Enforced means there is no pathway into the system that does not require the second factor. Legacy authentication is blocked. There are no exempted accounts other than documented break-glass exceptions with compensating controls. New accounts are automatically enrolled.
An underwriter reviewing your application wants to see enforcement, not availability. The difference in a Microsoft 365 environment is the distinction between enabling per-user MFA (which still allows legacy auth bypass) and implementing Conditional Access with a block-legacy-authentication policy (which closes the bypass).
When you complete an insurance application and attest that MFA is “enforced for all remote access and email,” the carrier understands that to mean enforced — not enabled as an option. If a post-incident forensic investigation finds that an account was compromised via a legacy authentication protocol that bypassed MFA, that gap can be used to deny the claim.
Building Your MFA Evidence Package
Underwriters and their reviewers are not going to log into your systems to verify your controls. They rely on documentation you provide. The evidence package for MFA is relatively straightforward to assemble once the controls are in place, and having it ready before you apply or renew is one of the most direct ways to speed up the underwriting process and improve your terms.
Here is what a complete MFA evidence package looks like:
For M365 environments:
- Screenshot of the Conditional Access policy showing “require MFA” is enabled and the assignment covers all users
- Screenshot of the legacy authentication block policy showing it is enabled and set to “Block”
- MFA registration report showing enrollment percentage (aim for 100%; explain any gaps)
- Entra ID (Azure AD) sign-in logs showing MFA is triggering on logins (a 7-day sample is sufficient)
For Google Workspace environments:
- Screenshot of 2-Step Verification enforcement setting in Admin Console showing “On for everyone” or equivalent
- Enrollment report showing 2SV is active for all accounts
For VPN / remote access:
- Configuration screenshot showing MFA is required for VPN authentication
- For Remote Desktop: screenshot showing RDP is behind VPN or Remote Desktop Gateway with MFA required
For RMM (MSPs):
- Screenshot of MFA settings in the RMM console showing all technician accounts have MFA enabled and enforced
- Login policy screenshot showing MFA cannot be bypassed
For critical SaaS:
- One or two screenshots showing MFA or SSO with MFA is active on your most important platforms (finance, HR, CRM)
Organize these in a single folder — name it “MFA Evidence” or include it in a broader “Underwriting Evidence Pack.” When a carrier asks for documentation, you send the folder, not a rushed screenshot collection assembled under deadline.
Common MFA Gaps That Create Underwriting Problems
These are the gaps that show up most frequently in applications and renewal reviews:
Legacy authentication protocols still enabled. Exchange ActiveSync, IMAP, POP3, and basic authentication in M365 allow clients to authenticate without going through MFA. Leaving these enabled creates a bypass that makes MFA enforcement on the Conditional Access side largely irrelevant for accounts using legacy clients.
Break-glass accounts without compensating controls. Every environment needs break-glass accounts for emergency access when MFA systems are unavailable. But break-glass accounts that are simply excluded from MFA requirements, with no monitoring, no rotation policy, and no alerting on use, are an underwriting flag. Document break-glass accounts separately, show they have strong passwords, are monitored for use, and are rotated regularly.
Service accounts with interactive login enabled. Service accounts are often excluded from MFA requirements because they need to run automated tasks. That is acceptable when the service account has no interactive login capability and its credentials are managed through a vault. Service accounts that can be used for interactive logins without MFA are a significant gap.
Coverage gaps on servers. MFA on workstations and email is common. MFA on server console access, RDP to servers, and admin portals for server infrastructure is much less consistent. Underwriters ask specifically about servers.
New accounts not automatically enrolled. If your MFA policy requires individual setup for each new account, there will inevitably be recently created accounts that are not enrolled. Automate enrollment as part of account provisioning so that every new account is covered from day one.
Contractor and vendor access. Third-party access to your environment — vendors, consultants, outsourced IT — is often managed outside your normal identity infrastructure and therefore outside your MFA policies. Document how contractor access is managed and confirm MFA applies to external users the same way it applies to internal ones.
The Underwriting Self-Assessment
Before you submit an application or enter a renewal, run through this checklist and document your answer to each item. “Yes” with evidence is the goal for every line.
- MFA enforced on all email accounts (all users, not just admins)
- Legacy authentication protocols blocked in M365 or Google Workspace
- MFA required for all VPN and remote access
- RDP not open directly to the internet
- MFA enforced on all admin and privileged accounts
- Separate admin accounts used for privileged tasks
- RMM platform requires MFA for all technician access (MSPs)
- Critical SaaS applications use MFA or SSO with MFA enforced
- Break-glass accounts are documented, monitored, and rotated
- Service accounts with interactive login are disabled or vaulted
- Contractor and vendor access subject to the same MFA requirements as internal accounts
- New account provisioning automatically enrolls in MFA
- MFA enrollment is at or near 100% with documented exceptions
A score of 13/13 with documentation is the strongest possible application posture on this control. Anything below 10 should come with a remediation plan and timeline disclosed proactively to the carrier — undisclosed gaps found after a claim are far more damaging than disclosed gaps found before one.
How SeedPod Cyber Approaches MFA in Underwriting
Because SeedPod underwrites directly, we review MFA evidence at application rather than discovering gaps at claim time. When we see partial deployment or enforcement gaps, we tell you before binding — not after an incident. That means the coverage you receive reflects your actual posture, and the terms you receive reflect the controls you can actually document.
If you want to understand how your current MFA deployment looks through an underwriter’s eyes before your next renewal, contact us. We can walk through your evidence and tell you exactly where you stand.
Related resources:
- Cyber Insurance Requirements: The Minimum Controls Checklist for SMBs and MSPs
- MSP RMM Hardening: 5 Steps That Reduce Risk and Lower Your Premiums
- Cyber Insurance Renewal Checklist: How to Prepare, What Underwriters Want, and How to Get Better Terms
- Cyber Insurance Exclusions: What Most Policies Won’t Cover
This guide is for informational purposes only and does not constitute legal or insurance advice. Coverage terms, eligibility, and underwriting requirements vary by carrier and risk profile. Consult a licensed insurance professional for guidance specific to your situation.