Cyber insurance renewal in Australia has changed. Two years ago, a questionnaire tick-box next to "MFA deployed" was enough. In 2026, most Australian insurers require documented attestation — evidence that MFA is deployed, that the scope matches what they require, and that there are no material exceptions they were not told about.
This guide explains exactly what Australian cyber insurers look for in MFA attestation, how to produce evidence from Microsoft 365 in under 30 minutes, and how to fix the most common gaps before your next renewal date.
What Australian Insurers Are Actually Asking
The MFA section of Australian cyber insurance questionnaires has grown substantially. The standard question set now typically includes:
- Is MFA deployed for email access? — yes/no, plus scope
- Is MFA deployed for remote access (VPN, RDP, cloud access)? — yes/no, plus scope
- Is MFA deployed for privileged/administrator accounts? — yes/no, plus MFA method
- Are there any accounts exempted from MFA? — yes/no, if yes describe
- What MFA method is used? — options typically include SMS, authenticator app, hardware token, biometric
The exemptions question is where most Australian SMBs create problems for themselves. If you have three IT staff accounts, two shared mailboxes, and a handful of service accounts excluded from MFA — and you tick "no exemptions" — you have created a coverage dispute risk that goes beyond just the insurance premium.
The Four MFA Controls Insurers Prioritise
1. Email — Non-Negotiable
Every Australian cyber insurer that underwrites business email compromise (BEC) coverage — which is most of them — requires MFA on email access. In Microsoft 365 terms, this means Conditional Access requiring MFA for Exchange Online for all users. An "on-premises only" MFA deployment that does not cover cloud-delivered Exchange is insufficient.
2. Remote Access — VPN, RDP, Cloud Applications
MFA on email alone does not satisfy most insurers. Remote access — any pathway into your systems from outside the office network — requires MFA. For Microsoft 365 shops, this means MFA on all cloud applications via Conditional Access, not just Exchange. If you also have VPN or RDP access, those must be separately covered by MFA at the gateway level.
3. Privileged Accounts — Elevated Standard
Insurers that previously accepted SMS for all accounts now frequently distinguish between standard users and privileged administrators. Common insurer language: "Administrator accounts must be protected by phishing-resistant MFA." In Microsoft 365, phishing-resistant MFA means FIDO2 security keys or Windows Hello for Business — not Authenticator app push notifications, and certainly not SMS.
The ACSC Essential Eight Maturity Level 2 requirements align with this elevated standard for privileged accounts, so if your organisation has already reached ML2 for MFA, you are likely to satisfy insurer requirements.
4. No Meaningful Exemptions
The cleanest MFA posture for insurance purposes is a Conditional Access policy that covers all users, all cloud applications, with no network location exclusions and no device-state exemptions. If you have trusted location exclusions (for example, office IP addresses bypass MFA), document the rationale in writing. Insurers increasingly scrutinise these exclusions as a mechanism by which attackers who have compromised an office IP address or VPN can bypass MFA entirely.
Producing MFA Attestation Evidence from Microsoft 365
This takes less than 30 minutes in a standard Microsoft 365 Business Premium or E3/E5 environment.
Step 1: Export your Conditional Access policies
In the Microsoft Entra ID portal at entra.microsoft.com, navigate to Protection → Conditional Access → Policies. For each policy that enforces MFA:
- Click the policy name to open it
- Take a screenshot showing the policy name, assignment (users and groups), cloud apps scope, and grant control (Require multi-factor authentication)
- Alternatively, export the policy as JSON via the ... menu for a more formal record
Your attestation evidence package should include the policy name, the user scope (All Users, or the groups included), the cloud app scope (All Cloud Apps, or named apps), and the MFA grant control. If any group exclusions or named location exclusions exist, these should be visible in the export.
Step 2: Pull a sign-in report showing MFA completion
In the Microsoft Entra ID portal, navigate to Monitoring → Sign-in logs. Filter for the last 30 days and add a column for MFA result. Export this to CSV.
This report shows which users completed MFA challenges and which were excluded. If you see a material number of sign-ins without MFA being required — for example, for service accounts or legacy authentication protocols — these represent the gaps an underwriter will probe.
Step 3: Run a user licence and MFA registration report
In the Microsoft 365 Admin Centre, navigate to Reports → Microsoft 365 reports → Microsoft 365 Apps usage. The Authentication methods report shows which users have registered for MFA and which methods they have registered.
Export this report and identify:
- Users who have not registered any MFA method (highest risk)
- Users registered for SMS only (potentially insufficient for privileged accounts)
- Users registered for the Authenticator app (acceptable for standard users)
- Users registered for FIDO2 or Windows Hello (satisfies phishing-resistant MFA requirements)
Step 4: Compile your attestation package
Most Australian insurers will accept:
- Conditional Access policy screenshots or JSON exports
- A sign-in report excerpt showing MFA is being enforced
- A user MFA registration report
- A brief written statement covering: date of implementation, scope, any exceptions and their rationale
If your insurer requires a third-party attestation, a completed SMB Cyber Security Assessment generates a structured report you can provide as supporting evidence.
The Most Common MFA Gaps — and How to Fix Them
Gap 1: Accounts excluded from Conditional Access
The problem: Shared mailboxes, service accounts, break-glass accounts, or individual users are excluded from the MFA Conditional Access policy, either by group exclusion or by being explicitly listed.
The fix: Review every exclusion. For shared mailboxes, MFA enforcement is handled differently — use Exchange Online authentication policies rather than Conditional Access exclusions. For service accounts that use legacy authentication protocols, investigate whether the protocol can be updated to modern authentication; if not, document the compensating controls. For break-glass accounts, these should be excluded from MFA with monitoring alerts in place — document this explicitly with the alert configuration as evidence.
Gap 2: SMS-only MFA for administrators
The problem: Global Administrators, billing administrators, and security administrators are using SMS-based MFA, which most insurers now consider insufficient for privileged roles.
The fix: Register FIDO2 security keys or Windows Hello for Business for all administrator accounts. Microsoft Entra ID Authentication Strengths (in Conditional Access) let you enforce phishing-resistant MFA for specific user groups without affecting standard users. A hardware security key costs approximately AUD 50-80 per administrator — a small cost compared to the premium impact of inadequate privileged account protection.
Gap 3: Legacy authentication not blocked
The problem: Legacy authentication protocols (SMTP AUTH, IMAP, POP3, ActiveSync without modern auth) allow email access without MFA even when Conditional Access is in place, because these protocols do not support MFA challenges.
The fix: In Microsoft Entra ID, under Protection → Authentication methods → Authentication strengths, create a Conditional Access policy that blocks legacy authentication for all users. This is a non-negotiable control for most Australian cyber insurers and is required for ACSC Essential Eight Maturity Level 1. Run the sign-in logs filtered by Client app: Legacy authentication clients to identify users who will break before enabling the block.
Gap 4: MFA registered but Conditional Access not enforced
The problem: Users have registered for MFA in the Microsoft 365 Admin Centre using per-user MFA (the legacy method) but there is no Conditional Access policy enforcing it. Per-user MFA can be bypassed by applications that do not trigger the challenge.
The fix: Migrate from per-user MFA to Conditional Access-enforced MFA. Disable the legacy per-user MFA settings after Conditional Access policies are in place. This is a two-step migration that requires careful sequencing to avoid locking out users — document the migration steps and run a pilot before a full rollout.
Before Your Next Renewal
Run through this checklist 60 days before your cyber insurance renewal date:
- Conditional Access policy covering All Users, All Cloud Apps, with MFA required
- Legacy authentication blocked via Conditional Access
- Privileged accounts using phishing-resistant MFA (FIDO2 or Windows Hello)
- All exclusions documented with written rationale
- Sign-in logs showing MFA enforcement for the last 30 days
- User MFA registration report exported
- Break-glass accounts have monitoring alerts configured and documented
If you are not sure where your MFA posture stands, the free SMB Cyber Security Assessment takes 10 minutes and gives you a structured report on your current security controls — including MFA coverage — that you can use as supporting evidence for your insurer.
The evidence requirement is not going away. Insurers have learned from claim patterns that organisations with documented MFA controls have materially lower BEC and ransomware claim rates than those without. The attestation requirement is the commercial mechanism by which this knowledge gets translated into underwriting — and the organisations that can produce clean evidence quickly will continue to get the best renewal terms.
