The renewal paperwork arrives, and halfway down page three is a block of yes-or-no questions. Is multi-factor authentication enforced for all email access? For remote access? For privileged accounts? Someone ticks yes because MFA was turned on a couple of years ago. Cyber insurance MFA requirements are rarely as simple as that tick box makes them look.
This isn't legal or insurance advice. Policies and application wording differ, and your broker is the person to confirm what your insurer means by each question. What we can tell you is what these questions usually cover on the technical side, and where the honest answer tends to be less tidy than the form.
What the application usually asks
The wording varies by insurer, but the same areas come up again and again:
- MFA on email, including webmail and phone access, for every user
- MFA on remote access: VPN, remote desktop, and any cloud app staff log into from outside the office
- MFA on admin and privileged accounts: anyone who can change settings, reset passwords or read other people's mail
- Backups kept separate from the main systems, ideally offline or immutable, and tested by actually restoring something
- Endpoint protection on laptops and servers, often specifically endpoint detection and response rather than basic antivirus
- Phishing training for staff, sometimes with simulated phishing emails
- Offboarding: how fast accounts are disabled when someone leaves
Some applications now ask what kind of MFA you use as well, not just whether you have it. A code sent by text message and a hardware security key are not treated as equivalent everywhere.
Why a partly true yes is a problem
The application is part of what the insurer relied on when it agreed to cover you. If there's a claim and the investigation finds the attacker got in through an account the form said was protected, you may have a difficult conversation about whether the policy responds. How that plays out depends on your policy and your jurisdiction, which is exactly why it's a question for your broker and not for us.
What we can say is where the gaps usually are. MFA was turned on for most people, but:
- The shared info@ account was left out because several people use the password
- A few users were given an exemption during rollout and it was never removed
- New starters get a grace period to enroll, and some never did
- The super admin account belongs to a former IT contractor and has no second factor
- Old mail protocols or app passwords let someone sign in without MFA at all
- A scanner, a line-of-business app or a service account signs in with a plain password
Any one of these makes "MFA is enforced for all users" untrue. Attackers look for exactly these accounts, because they're the ones without the second lock.
Closing the gaps in Google Workspace and Microsoft 365
Google Workspace
In the Admin console, 2-Step Verification has two separate settings: allowing users to turn it on, and enforcing it. Allowing it is not the same as enforcing it. Enforce it for the whole organization, or for every organizational unit, and keep the new-user enrollment period short. For super admins, require security keys.
Then check the reports. The Admin console shows each user's 2-Step Verification enrollment status, and that list is the honest answer to the insurer's question. Look at which third-party apps have access to your accounts while you're there.
Microsoft 365
Smaller tenants can start with Security defaults, which require MFA registration for everyone and block legacy authentication. If you have Entra ID P1, which comes with Business Premium, use Conditional Access policies instead: require MFA for all users, require it for every admin role, and block legacy authentication. Keep one or two emergency access accounts excluded from those policies, with long passwords stored safely and sign-ins monitored, so a misconfigured policy can't lock everyone out.
Prefer the Microsoft Authenticator app over text-message codes where you can, and check the authentication methods registration report in Entra to see who has actually set up MFA. That report, not the policy screen, is what tells you whether the answer is yes.
Admin accounts on either platform
Give admins a separate admin account and use their normal account for everyday work. Cut the number of super admins or global admins to the few people who need it, and give everyone else a narrower role. If nobody at your company currently holds the top admin login, fix that first.
The rest of the form
Remote access is often a VPN or a remote desktop setup that predates your cloud email and was never tied to it. It needs its own MFA. Endpoint protection should be on every laptop, including the ones people bought themselves and use for work. Offboarding needs a written checklist and a named owner, so accounts are disabled the day someone leaves, not when the next license bill arrives.
Keep evidence as you go: screenshots of enforcement settings, the enrollment report, the date of your last test restore. Your broker may want it, and you'll want it at the next renewal.
If you're planning a platform move anyway, it's a good time to start clean; our email migration checklist covers what to settle first. If you need a full picture of every system, account and backup before you answer, that's what our Systems Audit is for.
If you'd rather not do this yourself
We can go through your admin console with you, find the accounts that would make the answer untrue, and fix them, usually in less time than people expect. The first 30-minute call is free. More on our Google Workspace and Microsoft 365 security work.