MFA Requirements for Cyber Insurance: The Legacy App That Can Void Your Coverage

On a cyber insurance application, the riskiest word is often all. Do you enforce MFA for all remote access? All privileged accounts? All business-critical applications? All cloud and external access paths?

MFA requirements for cyber insurance are no longer a soft recommendation or a renewal checkbox. Carriers increasingly expect applicants to show that multi-factor authentication is actually deployed across the systems named in the questionnaire. The gap is rarely Microsoft 365 or VPN anymore. The gap is the older customer portal, partner portal, admin console, vendor-managed web app, or on-premises application that was never connected to the identity provider.

This guide explains what underwriters usually ask, why legacy applications create coverage risk, what evidence teams should prepare, and how to close legacy app MFA gaps without rewriting applications before renewal.

What Underwriters Actually Ask

For legacy dashboards and management consoles outside your identity provider, review the pattern for MFA for privileged and admin accounts so questionnaire answers match actual enforcement.

Cyber insurance is not a regulation, so there is no single universal MFA standard. Each carrier sets its own underwriting questions and policy terms. But broker and carrier questionnaires have converged around a familiar set of MFA requirements.

Most applications ask some version of:

• Do you enforce MFA for all remote access to your network, including VPN, RDP, and virtual desktop?
• Do you enforce MFA for all email access, including webmail and mobile access?
• Do you enforce MFA for all privileged and administrative accounts, including domain, cloud, and network administrators?
• Do you enforce MFA for access to backup systems and backup management consoles?
• Do you enforce MFA for remote, external, or internet-facing access to business-critical applications?

The important word is all. These are usually yes/no questions. There is no clean checkbox for "yes, except the older partner portal that still uses local passwords."

That is where coverage risk starts.

The Attestation Trap

The failure pattern is common. An IT or security lead completes the renewal application. Microsoft 365 has MFA. The VPN has MFA. The identity provider enforces MFA for the applications connected to it. So the answer to "do you enforce MFA for all remote access and business-critical applications" feels like yes.

But one internet-facing partner portal still uses local usernames and passwords. A vendor-managed admin console sits outside the identity provider. A ten-year-old web application was excluded from the SSO rollout because it does not support SAML, OIDC, or OAuth.

The application says yes. The environment says mostly.

If a breach investigation finds that attackers used the exception, the discussion can shift from security improvement to underwriting accuracy. The issue is not only whether the missing MFA was a technical weakness. It is whether the insurance application, renewal form, or warranty accurately described the environment.

That is why MFA requirements for cyber insurance should be treated as evidence questions, not policy questions. Before answering yes, teams need an inventory, enforcement proof, and a clear exception register.

Regulators See the Same MFA Gap

This is not only an insurance-industry concern. The New York Department of Financial Services published MFA guidance after reviewing hundreds of reported cybersecurity events at regulated financial services companies. DFS found that approximately 64% of covered entities that reported cybersecurity events from January 2020 to July 2021 had some MFA gap: absent MFA, incomplete implementation, misconfiguration, or partial rollout.

DFS also identified recurring sources of MFA failure that sound familiar to cyber insurance teams: legacy systems that do not support MFA, applications accessible outside VPN, third-party portals, incomplete rollouts, and poor exception management.

The security math behind insurer interest in MFA is also straightforward. Microsoft has reported that MFA can block over 99.9% of account compromise attacks. For a carrier, a control that materially reduces credential-based compromise is a natural underwriting question.

Why Legacy Applications Become the Gap

Legacy applications are usually excluded from MFA rollouts for practical reasons, not because security teams ignore them.

• The application uses local accounts and custom session handling, with no support for SAML, OIDC, OAuth, or modern MFA.
• The app is vendor-managed, and the vendor roadmap does not include modern authentication before the renewal deadline.
• Changing the login flow would require a full release cycle, regression testing, and business risk.
• The application predates the current identity provider and was never included in the SSO project.
• The app is on premises, but still reachable by remote users, partners, vendors, or administrators.

The result is a coverage inventory that looks good at the top and fragile at the edge: email, VPN, and cloud apps protected by MFA, while two or three business-critical web applications remain password-only.

Those two or three applications are the difference between an honest all and a risky mostly on the next insurance application.

How Datawiza Closes the Gap Before Renewal

Datawiza Access Proxy puts an MFA enforcement layer in front of existing web applications, including applications with their own local login that cannot be rewritten. The application can keep running as it does today while Datawiza protects the route to it.

Two deployment patterns cover most insurance-driven MFA projects.

Built-in MFA at the proxy layer.

For an application with a local username-and-password login and no practical path to native MFA, Datawiza can add MFA using its built-in MFA capability. In this model, the user signs in with the application's existing login first, then Datawiza enforces the MFA challenge before granting access to the protected application. The app keeps its own login. Datawiza adds the second factor at the access layer.

Identity provider integration.

If your organisation standardises on Microsoft Entra ID, Okta, Ping, Auth0, Duo, Google Workspace, or another identity provider, Datawiza can integrate with that provider. The IdP applies SSO, MFA, and conditional access policy. Datawiza protects the route to the legacy application and passes approved identity context to the app.

For a renewal packet, the enforcement flow documents cleanly:

1. The user requests the protected application URL.
2. With identity provider integration, Datawiza intercepts the request before the application's login page is exposed and redirects the user to the IdP for SSO, MFA, and conditional access.
3. With Datawiza built-in MFA, the user completes the application's existing username-and-password login first, then Datawiza enforces MFA before granting access.
4. In either mode, only authenticated and approved traffic is forwarded to the application.
5. Authentication events and access decisions can be logged as evidence for underwriting, audit, and incident response.

The application itself does not need to be rewritten. What changes is your ability to answer the all questions with evidence.

What Evidence to Prepare for Underwriting

A defensible cyber insurance response is built on evidence, not a broad policy statement. Before renewal, assemble proof that matches each MFA answer.

• A complete inventory of internet-facing, remotely accessible, privileged, backup, cloud, and business-critical applications
• Per-application MFA enforcement status, including legacy and vendor-managed applications
• Identity provider policy exports showing MFA by user, group, application, and condition
• Access proxy configuration showing which applications sit behind the MFA enforcement point
• Authentication logs showing successful MFA challenges, denied attempts, and administrative access
• Privileged access controls for administrator, support, service, and break-glass accounts
• A written exception register with owner, business reason, compensating control, and remediation date

The exception register matters. A broker or carrier may be able to work with a documented, time-bound exception. What creates risk is a silent gap hidden behind a yes answer.

Cyber Insurance MFA Is Not the Same as Compliance MFA

Compliance frameworks define MFA scope around regulated environments. PCI DSS focuses on the cardholder data environment. NYDFS focuses on covered entities and their information systems. Cyber Essentials focuses on internet-facing and cloud services. Cyber insurance questions are often broader and blunter.

A carrier asks about every path a credential can be used because every path can become a claim. That is why an insurance-driven MFA project should look beyond email and VPN.

Include these systems in the inventory:

• Customer portals
• Partner, dealer, supplier, and member portals
• Admin dashboards and support tools
• Backup consoles and backup management systems
• Vendor-managed web applications
• On-premises web applications reachable by remote users or third parties
• Applications with local accounts outside the identity provider

Implementation Checklist

1. Pull the current carrier application or renewal questionnaire and highlight every MFA question containing all.
2. Inventory every place a user can sign in: remote access, email, cloud services, privileged tools, backups, and web applications.
3. Mark which systems enforce MFA through the identity provider today.
4. Identify exceptions: local-login applications, vendor-managed consoles, older portals, and anything outside SSO.
5. Prioritise internet-facing, privileged, business-critical, and remotely accessible applications.
6. Place an access proxy in front of applications that cannot be rewritten before renewal.
7. Choose Datawiza built-in MFA or IdP-integrated MFA for each protected app.
8. Assemble policy exports, proxy configuration, authentication logs, and screenshots as evidence.
9. Document remaining exceptions with owners and dates. Do not let a gap ride silently under a yes.

Frequently Asked Questions

What are MFA requirements for cyber insurance?

There is no single cyber insurance MFA standard. Each carrier sets its own questions. In practice, applications commonly ask for MFA on remote access, email, privileged and administrative accounts, backup systems, cloud applications, and business-critical or internet-facing applications. The questions often use all, so teams need to verify actual coverage before answering.

Can an insurer deny a claim or challenge coverage over MFA?

Yes. If an insurance application, warranty, or renewal form says MFA is enforced and a breach investigation finds that it was not enforced for the relevant system, the carrier may challenge coverage, narrow payment, deny the claim, or raise misrepresentation issues depending on the policy language and facts. Review the exact policy and questionnaire with your broker or counsel.

Does cyber insurance require MFA for legacy applications?

If a legacy application is internet-facing, remotely accessible, business-critical, privileged, or used by third parties, it may fall under the all language in the carrier questionnaire. That is especially true when the app contains sensitive data or can be used as a path into the environment.

Can a reverse proxy satisfy cyber insurance MFA requirements for legacy apps?

An access proxy can help when it enforces MFA before users can access the protected application and produces evidence of that enforcement. Datawiza can use built-in MFA at the proxy layer or integrate with an identity provider such as Microsoft Entra ID, Okta, Ping, Auth0, Duo, or Google Workspace.

What should we show the insurer or broker?

Show an application inventory with per-app MFA status, identity provider policy, access proxy configuration, authentication logs, privileged access controls, and a dated exception register for anything not yet covered. The goal is to make the evidence match the attestation.

Should we answer yes if most systems have MFA?

Be careful. If the question says all, most is not the same as all. A better path is to document the exception, apply a compensating control such as access-layer MFA where possible, and confirm the wording with the broker or carrier before submission.

For business-critical ERP coverage, see how to add MFA to JD Edwards without OAM, IDCS, or JDE code changes.

The Bottom Line

MFA requirements for cyber insurance come down to one risky word: all. Email and VPN are usually the easy part. Legacy web applications outside the identity provider are where all quietly becomes mostly.

An access-layer approach can close that gap before renewal. Datawiza Access Proxy can add built-in MFA on top of an existing local-login app, or integrate the app with your preferred identity provider for SSO, MFA, and conditional access. Either way, the goal is the same: enforce MFA before access and produce evidence that supports the insurance attestation.

To see the access-layer pattern in action, explore no-code MFA for existing applications, MFA for web applications, and adding MFA to legacy apps without code changes.

If your renewal questionnaire has a yes you are not sure about, book a demo to see how Datawiza can help close the gap without rewriting the application.

Sources

NYDFS Guidance on Multi-Factor Authentication: https://www.dfs.ny.gov/industry_guidance/industry_letters/il20211207_mfa_guidance

Microsoft Security: One simple action you can take to prevent 99.9 percent of attacks on your accounts: https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/

Related remote access guidance

• secure remote access to internal web applications without a VPN for remote-user and third-party access scenarios that show up in insurance questionnaires.