Table of contents
MFA requirements for cyber insurance often extend beyond email and VPN access. Depending on the insurer, the application may ask about administrative accounts, backups, critical applications, and systems containing sensitive information. A password-only customer portal or internal web app can leave a gap even when your workforce identity platform already enforces MFA.
You can close that web application gap without replacing how users sign in. Datawiza Access Proxy adds MFA on top of existing application credentials without application code changes. With Datawiza built-in MFA, Active Directory, LDAP, and an external identity provider are not required. You can also connect Microsoft Entra ID, Cisco Duo, Okta, or another supported provider if you prefer.
This guide explains what underwriters ask, how to protect web applications, and what evidence to prepare for an insurance application or renewal.
What are the MFA requirements for cyber insurance?
There is no single MFA standard shared by every cyber insurer. Your carrier’s application, quotation conditions, and policy determine the required systems, users, and authentication methods. Travelers’ MFA guidance, for example, identifies remote access, email, and administrative access as requirements for its Corvus by Travelers offering.
Review the wording carefully. A question about all remote access includes more than the corporate VPN if contractors or third parties use other routes into covered systems. Likewise, MFA at the identity provider only protects an application when the application’s access actually passes through that enforcement point.
Which systems need MFA for cyber insurance?
The following examples paraphrase the published Travelers MFA supplement and Corvus cyber insurance application. Use your own current questionnaire to confirm scope.
| Access area | Example underwriting question | Evidence to retain |
|---|---|---|
| Does MFA cover employee web or cloud email access? | Email policies and login records | |
| Remote access | Does MFA cover remote network access, including contractors and third parties? | Access-path inventory and enforcement tests |
| Administrative access | Does MFA protect internal and remote administrator access? | Privileged-account inventory and MFA policies |
| Backups | Is MFA required for backup access or administration? | Backup access settings and access logs |
| Critical applications | Does MFA protect all critical applications? | Per-application coverage and login test results |
| Sensitive information | Does MFA protect user access to systems or applications containing sensitive data? | Data-system inventory and authentication records |
Datawiza addresses the web application access portion of this inventory, including browser-based administrative interfaces. Native VPN, RDP, desktop login, and other non-web protocols need controls appropriate to those access paths.
Web application MFA gaps are not limited to legacy apps
A modern application can still rely on a username and password. Customer portals, partner and supplier sites, custom applications, internal tools, and commercial web applications may manage their own users without connecting to a corporate identity provider.
An application’s age does not determine its insurance relevance. What matters is who can access it, what it exposes, and whether it falls within the systems named in your questionnaire.
For example, employees may already use Entra ID MFA while customers sign in to a separate portal using application-local accounts. Protecting employee access does not automatically add a second factor to those customer accounts. The same issue can affect partners, vendors, or administrators using a separate web login.
Legacy application MFA remains one useful use case, but the broader requirement is consistent protection for the web applications in scope.
Add MFA to any web app while keeping existing credentials
Datawiza MFA for web applications places enforcement in the application’s HTTP or HTTPS traffic path. It can protect modern and legacy web apps, on premises or in the cloud, when their traffic is routed through Datawiza Access Proxy and their login and session flows are configured and tested.
You have two deployment options.
Option 1: Datawiza built-in MFA, with no AD, LDAP, or IdP
Your application keeps its existing user store and remains responsible for validating passwords. Datawiza adds the second factor before the user can access protected content.
- The user opens the web application through Datawiza Access Proxy.
- The application validates the user’s existing username and password.
- After successful primary authentication, Datawiza requires its built-in MFA challenge.
- The user completes the configured second-factor verification.
- Datawiza allows the verified session to reach protected application content.
Users keep their credentials. You do not need to migrate accounts to Active Directory, introduce LDAP, deploy an external IdP, or rewrite the application to support SAML or OpenID Connect just to add MFA.
Built-in methods include authenticator-app codes and email one-time codes. Choose methods that meet your security policy and insurer’s requirements; availability of a method does not mean every insurer accepts it for every use case. Confirm any phishing-resistance requirement with your insurer before selecting the method.
For implementation details, see MFA with existing application credentials, add MFA without Active Directory, and MFA for web applications without Entra ID.
Option 2: Connect your existing identity provider
If you prefer your existing identity and MFA platform, Datawiza also integrates with Microsoft Entra ID, Cisco Duo, and Okta. This option lets you extend the supported platform’s authentication policies to web applications through the access proxy.
Choose built-in MFA when you want to preserve application credentials without an external IdP. Choose an identity-provider integration when centralized SSO and identity-managed MFA are part of your access strategy. Review the authentication flow and available controls for the provider you select.
A cyber insurance MFA checklist for web applications
Before completing your cyber insurance application or renewal, map each relevant question to a verified control.
- Inventory applications and users. Include customer portals, partner sites, internal tools, admin interfaces, and accounts used by contractors or vendors.
- Map every access path. Check public and internal hostnames, alternate ports, direct-origin access, and bookmarked protected URLs.
- Choose the MFA architecture. Use Datawiza built-in MFA with existing credentials, or connect your chosen identity provider.
- Configure routing and enforcement. Route protected web traffic through the proxy and prevent direct access that bypasses MFA.
- Test the full session. Verify successful and failed login, enrollment, MFA denial, logout, session expiration, account recovery, and access to protected deep links.
- Pilot and document. Test representative employees and external users, then record results before expanding enforcement.
- Resolve or disclose exceptions. Give remaining gaps an owner and remediation date, and discuss them with the broker or carrier before answering the questionnaire.
No-code MFA for cyber insurance still requires deployment configuration and testing. The benefit is adding an access control without making an application rewrite or directory migration a prerequisite.
How to prove MFA to a cyber insurer
Prepare evidence that connects your answers to actual enforcement. A policy screenshot alone does not demonstrate that every relevant application and user is covered.
Keep a dated application inventory with the owner, user populations, URLs, chosen MFA method, enforcement point, and test status. Attach configuration records, representative authentication logs, and tests showing that users cannot reach protected content with only a password.
For Datawiza built-in MFA, document the existing application login, the additional challenge, and the protected access paths. For an IdP integration, include the relevant provider policies and show how the web application uses them.
Your cyber insurance MFA evidence should also identify exclusions, recovery procedures, and any approved exceptions. Ask the broker or carrier what format it needs. Accurate, current evidence is more useful than a generic claim that MFA is enabled everywhere.
Frequently asked questions
Is MFA required for cyber insurance?
Many insurers require MFA for specified access scenarios, but the exact scope varies. Check your current application and quotation conditions for required systems, users, and methods. MFA is one part of underwriting; implementing it alone does not guarantee coverage or a particular premium.
Can I get cyber insurance without MFA?
Availability and terms depend on the carrier and your risk profile. Some quotes require security controls before coverage can begin; Travelers describes MFA as a possible pre-binding condition. Disclose missing controls and ask your broker about the available options and remediation requirements.
What counts as MFA for cyber insurance?
MFA combines distinct authentication factors, such as a password and possession of an authenticator. Two passwords are not two factors. Confirm which methods your insurer accepts, whether phishing resistance is required, and whether the control covers every user and access path named in the question.
Can we meet web app MFA requirements without Active Directory or LDAP?
Yes. Datawiza built-in MFA can add a second factor while the web application continues validating its existing credentials. AD, LDAP, and an external IdP are not prerequisites. Confirm the deployed control and selected method satisfy your insurer’s specific requirements.
Can we use Entra ID, Cisco Duo, or Okta instead?
Yes. Datawiza supports those integrations for organizations that prefer their existing identity or MFA provider. Built-in MFA provides the alternative when you want to keep application credentials without adding an external identity platform.
Do cyber insurance renewal MFA requirements cover customer and partner portals?
They may, depending on the questionnaire’s scope. Review whether the portal is a critical application, contains sensitive information, or provides a covered access path. Include external users in your inventory and confirm ambiguous wording with the broker or carrier.
What if some applications still lack MFA?
Document the gaps and discuss them before submitting an answer that says all systems are protected. Identify the affected applications, users, temporary controls, and remediation dates. Do not assume an exception is accepted until the carrier confirms it.
Close your web application MFA gaps
Cyber insurance MFA requirements are easier to assess when each application has a clear enforcement point and evidence that it works. Datawiza helps you add MFA across web applications while keeping existing credentials, or connect the identity provider you already use.
Explore Datawiza Access Proxy or book a demo to review your web applications, authentication flow, and insurance MFA requirements.
