Multi-factor authentication

Multi-factor authentication requires valid, independent factor types and becomes phishing-resistant at Maturity Level Two. It had the lowest result of the eight strategies across Commonwealth entities in 2024–25.

What is required, and where

MFA scope widens at each level, and the quality of the factor changes at Level Two.

Maturity Level One requires MFA for:

• users of your own and third-party online services that handle your organisation's sensitive data
• users of third-party online services handling non-sensitive data, where the service offers it
• users of your online customer services
• customers of online customer services that handle sensitive customer data

Maturity Level Two extends the scope to all privileged and unprivileged users of your systems, and the methods must be phishing-resistant. Customers are offered a phishing-resistant option. Level Two also adds logging: successful and unsuccessful MFA events are centrally logged, the logs are protected from modification, and internet-facing server logs are analysed. Incidents are reported to the chief information security officer (CISO) and to ASD.

Maturity Level Three extends the scope to users of data repositories. Customer MFA becomes phishing-resistant outright rather than optional, and log analysis widens to workstations and non-internet-facing servers.

See the requirements matrix for every control at each maturity level.

The factor rules

The requirement in the Essential Eight Maturity Model is precise about the combination, not just the count:

…something users have and something users know, or something users have that is unlocked by something users know or are.

The three factor types are:

• something the claimant knows, such as a PIN, password or passphrase
• something the claimant has, such as a security key, smart card, software certificate, one-time password token or smartphone
• something the claimant is, such as a fingerprint or facial geometry

What ASD explicitly excludes:

• Security questions. "The use of knowledge-based authentication techniques (i.e. security questions) is not recognised as a valid form of memorised secret."
• Biometrics as a primary factor. They may only unlock something you have.
• "Trusted Signals" as a primary factor.
• "Remember this computer" tokens, because they authenticate the browser, not the person.
• Multi-step authentication as a substitute for multi-factor.

ASD's stated reason for tightening this, in the November 2023 changes, explains the whole update:

Previously, Maturity Level One did not specify the types of authentication factors… This led to the adoption of weaker forms of MFA that used biometrics, security questions or 'Trusted Signals', none of which are recognised as valid authentication factors within standards.

Commonwealth implementation

Multi-factor authentication is the lowest-performing of the eight across Commonwealth entities. Before the update, 54% sat at Maturity Level Two or above. That fell to 23% in 2023–24, once the phishing-resistance requirement was pulled forward. It has since recovered to 34% in 2024–25, according to ASD's Commonwealth Cyber Security Posture in 2025.

ASD attributes the fall to the higher technical standard introduced in November 2023. The previous model had led to weaker implementations using biometrics, security questions or Trusted Signals. The 2024–25 increase reflects entities adopting the new requirements.

If you build software, this is a product requirement

For online customer services, MFA capability must be built into the product.

If an application is an online customer service handling sensitive customer data for a client bound by the Essential Eight, it must support:

• customer MFA at Level One
• a phishing-resistant option at Level Two
• phishing-resistant customer MFA at Level Three

Moving a product from SMS one-time codes to passkeys may affect authentication flows, account recovery and device enrolment. Account for that work during product design rather than treating MFA as a deployment setting. See the software vendors page for the wider product implications.

An exception applies to consumer-facing systems where customers genuinely cannot use MFA. ASD's Implementing multi-factor authentication suggests compensating controls "subject to acceptance of risk by an appropriate authority". These may include security questions in addition to a passphrase, together with enhanced monitoring. This is a compensating control for the affected customer cohort, not a general alternative to MFA.