Cyber insurance MFA questions: how to answer them

Key facts

• Multi-factor authentication is the first control on every Australian cyber insurance proposal form and the one most likely to be treated as a hard requirement rather than a rating factor.
• Insurers split the question into four scopes: remote access, web-based email, admin and privileged service accounts, and cloud resources including backups.
• Proposal forms define multi-factor authentication as knowledge, something only the user knows, plus possession, something only the user has, so that compromise of a single device compromises only one factor.
• SMS codes satisfy that definition and are accepted, but they are the weakest available factor, and some insurers ask separately whether an authenticator app, hardware token or push with number matching is used.
• Legacy authentication protocols bypass multi-factor authentication entirely, so a mailbox can have it enforced and still be reachable without it.
• Multi-factor authentication on the backup console is asked twice on longer forms, once under identity and again under the backup environment, because ransomware operators target the backup platform first.

Why insurers ask about this in so much detail

Underwriters moved from a single yes or no question to four or more because the single question stopped predicting anything. Almost every business answered yes, and a large share of those businesses were then compromised through the one system that had been excluded: a legacy application that could not support it, a shared mailbox nobody thought of, a service account running an integration, or a remote access tool installed for a specific supplier.

The questions below are compiled from Australian cyber insurance proposal forms current as at September 2026. No insurer is named. Where forms differ, the stricter wording is used, because a control built to the stricter version answers both. For the full set of 45 technical questions across all 12 control areas, see the cyber insurance questionnaire guide.

The multi-factor authentication questions insurers ask

Is multi-factor authentication required for all remote access to your systems?

Australian cyber insurance proposal forms ask this as the first identity question, and some word it as “is MFA required for all users to access all remote access to the network” or “is multi factor authentication required for any and all remote access to your systems, including webmail, Citrix desktop, cloud based applications, or Remote Desktop Protocol”. The answer an underwriter accepts is yes, enforced on every remote entry point, with no per-user and no per-application exclusions.

To answer that honestly you need conditional access or an equivalent policy applying to all users and all remote applications, and you need Remote Desktop Protocol not published to the internet at all. Every exception has to be closed rather than documented, because the words “any and all” leave no room for one.

The evidence an underwriter or a claims assessor will ask for is a conditional access policy export, a sign-in log filtered to remote sessions showing the policy applying, and an external port scan showing no exposed Remote Desktop Protocol. The common trap is the honest answer being “yes except one legacy application”. That exception is the entire question, and a single excluded entry point is treated as no multi-factor authentication.

Is multi-factor authentication required for web-based email?

Insurers ask about email separately from remote access, because mailbox compromise is the entry point for business email compromise and invoice fraud rather than for network intrusion. The answer required is yes, on every mailbox without exception, including shared mailboxes, service mailboxes and executive accounts.

What has to be in place is enforcement across all mailboxes plus legacy authentication protocols disabled. This is the silent failure in this whole area: protocols such as POP, IMAP and SMTP AUTH predate multi-factor authentication and cannot present a second factor, so where they remain enabled an attacker with a valid password reaches the mailbox without ever meeting the prompt. Multi-factor authentication can be fully deployed and completely bypassable at the same time.

Hold a per-user registration report showing every mailbox covered, and the policy that blocks legacy authentication. Shared mailboxes are worth checking specifically, because they are frequently excluded during rollout and then never revisited.

Is multi-factor authentication required for admin and privileged service accounts?

Proposal forms ask about privileged accounts as their own question, and the glossary on longer forms defines privileged accounts to include accounts used by automated processes or by applications that need elevated rights. Service accounts are therefore inside the scope of this question, which is where most small and medium businesses fail it.

The control needed is administrative identities separated from daily-use accounts, with multi-factor authentication on all of them, plus a documented position on any service account that cannot support it at all. That position is usually conditional access restricting the account to a known source address, or a move to a workload identity with certificate authentication. What is not acceptable is an undocumented exclusion.

The evidence is a privileged role assignment list, an inventory of administrative accounts, and an exclusion register naming the compensating control for each entry. An exclusion register with the compensating controls filled in reads far better to an underwriter than a blanket yes that does not survive a claim investigation.

Is multi-factor authentication required for cloud resources, including backups?

The words “including backups” are the point of this question. Insurers ask it because ransomware operators go for the backup console before they encrypt anything, and a backup platform reachable with a compromised production administrator credential offers no protection at all.

What you need is multi-factor authentication on the backup console specifically, and backup administrator credentials that are separate from production domain or tenant administrator credentials. Shared credentials fail the intent of the question even where the technical answer is yes.

Hold the backup platform’s administrator list showing the authentication state for each account, plus something demonstrating the credential separation. Note that longer forms ask this twice, once here and again as part of the backup environment questions, and the two answers need to match.

What counts as multi-factor authentication, and does SMS qualify?

Proposal forms define it explicitly. The mechanism must combine knowledge, something the user and only the user knows, with possession, something the user and only the user has, so that the compromise of any single device compromises only one authentication factor. An SMS code satisfies that definition, and answering yes where SMS is the method in use is accurate rather than misleading.

That said, SMS is the weakest factor available. SIM swap attacks and interception mean the possession factor can be captured without touching the device, and several insurers now ask separately whether the method is an authenticator app, a hardware token, or a push notification with number matching. An authenticator app, a passkey or a hardware key is the stronger answer and the better control.

The evidence is the authentication methods policy showing which methods are permitted in your environment. This question is worth answering before the other four, because it determines whether those four answers are true: a deployment that relies on a factor the insurer discounts changes what the rest of the section really claims.

Do you have controls on access to online banking and financial platforms?

Some Australian proposal forms ask this as a separate question with three acceptable answers, worded as whether procedures require, for all online financial accounts and banking platforms, either two-factor authentication, or passwords changed at least every 45 days, or long passwords of 12 characters or more with at least three special characters.

Only one of those three is a good control. Forced 45 day password rotation and mandatory special-character complexity both push people toward predictable patterns and written-down credentials, and current Australian Cyber Security Centre guidance moved away from both years ago. The fact that a proposal form still accepts them is not an endorsement. Choose the two-factor authentication option and implement it on every banking and financial platform login.

The evidence is a named list of every financial platform the business uses with the authentication method recorded against each. Building that list usually surfaces two or three platforms nobody had accounted for, which is useful well beyond the insurance form.

The evidence to assemble before the form arrives

Five artefacts cover every question above, and assembling them once makes the next renewal and any competing quote a much shorter exercise:

• Conditional access or equivalent policy exports, showing scope and any exclusions.
• A per-user multi-factor authentication registration report covering all mailboxes.
• The policy blocking legacy authentication protocols.
• An administrative and service account inventory, with an exclusion register naming the compensating control for each excluded account.
• A list of financial platforms with the authentication method recorded for each.

Most of these questions map onto the multi-factor authentication strategy in the Australian Signals Directorate Essential Eight, so a business working toward Maturity Level 1 is building the same controls the underwriter is asking about. The Essential Eight guide for Australian SMEs covers how the eight controls fit together, and the cyber insurance guide for Australian SMEs covers what underwriting looks like more broadly. The Essential Eight itself is published by the Australian Cyber Security Centre at cyber.gov.au.

One thing not to do

Do not soften an answer to get a better outcome on the form. Australian cyber insurance proposal forms carry a duty of disclosure, and the consequence of an inaccurate answer is not a slightly higher premium. It is an insurer entitled to reduce a claim, refuse it, or treat the policy as though it never existed, discovered at the exact moment the cover was needed. Where the answer is no, the gap is real whether or not the form asks about it, and fixing the control is both the cheaper and the safer path.

If a cyber insurance questionnaire is sitting in your inbox and the identity section is the part holding it up, 4iT works through the whole form against your actual environment, closes the exclusions that turn a yes into a no, and produces the evidence pack the underwriter will ask for. Request a callback and we will work through it with you.