TL;DR: Essential 8 MFA requirements get stricter as you move up the maturity levels. At Maturity Level 1 (ML1), a range of multi-factor methods (including a password plus an authenticator app, or even SMS) can be acceptable for users of your online services, though SMS is discouraged. At Maturity Level 2 (ML2) and Maturity Level 3 (ML3), the MFA used for online services and systems must be phishing-resistant, which rules out SMS, voice, email OTP and authenticator push. This guide explains what counts at each level, where MFA must be enforced, and how to deploy it in Microsoft 365 without locking your admins out.
What are the Essential 8 MFA requirements?
The Essential 8 MFA requirements are a set of multi-factor authentication controls defined by the Australian Signals Directorate (ASD) in the Essential Eight Maturity Model, published at cyber.gov.au. Multi-factor authentication is one of the eight mitigation strategies, and its requirements tighten across three maturity levels. The model dictates two things at each level: which accounts and services must use MFA, and how strong that MFA has to be.
The single biggest shift, introduced by the ASD in its November 2023 update, is the move toward phishing-resistant MFA at ML2 and above. Earlier versions of the model did not specify which authentication factors were acceptable, which led many organisations to adopt weaker forms of MFA that were vulnerable to real-time phishing and social engineering. The current model closes that gap.
If you want the broader context on how MFA fits alongside the other seven strategies, our Essential 8 compliance overview walks through the full framework.
Which MFA methods satisfy ML1, ML2 and ML3?
The methods that satisfy each level differ sharply: ML1 accepts standard two-factor methods, while ML2 and ML3 require phishing-resistant MFA. The simplest way to read the model is that ML1 is about having MFA at all, and ML2 and ML3 are about making that MFA resistant to phishing.
Maturity Level 1
At ML1, MFA must use either something users have and something users know, or something users have that is unlocked by something users know or are. In a Microsoft 365 or Microsoft Entra tenant, that means a password plus an authenticator app, a password plus an OATH token, or stronger passwordless methods all qualify. Microsoft notes that any ISM-permitted multi-factor authenticator can achieve ML1. Even a password plus an SMS code can satisfy ML1 in Entra, though it is not recommended. The two methods Microsoft flags as not permitted even at ML1 are SMS sign-in (as a sole passwordless method) and email OTP.
Maturity Level 2 and Maturity Level 3
At ML2 and ML3, the MFA used to authenticate users of online services and of systems must be phishing-resistant. Microsoft's guidance for both levels lists only one category of permitted authenticator: multi-factor crypto hardware. In practice that means FIDO2 security keys, device-bound passkeys, Windows Hello for Business backed by a hardware Trusted Platform Module, smart cards, and a hardware-protected certificate. ML3 adds one more scope item on top of ML2: MFA for users of data repositories must also be phishing-resistant.
Why SMS and weaker methods are being phased down
SMS, voice calls, email one-time passwords and authenticator push notifications are being phased down because they are not phishing-resistant. The ASD strengthened the model in response to a rise in attacks against weaker MFA implementations, specifically those susceptible to real-time phishing or social engineering. An attacker running a proxy phishing page can relay a one-time code or trigger a push prompt and capture the resulting session, so the second factor adds little protection against a determined adversary.
For Microsoft 365 tenants, the practical effect is a clear exclusion list at ML2 and ML3. Microsoft documents the following methods as not permitted at those levels: SMS sign-in, email OTP, Authenticator phone sign-in, password plus SMS, password plus voice call, password plus email OTP, password plus Authenticator OTP, and password plus Authenticator push notification. If your organisation is targeting ML2 or higher, none of these will pass an assessment for the in-scope users. Phishing-resistant methods such as passkeys and Windows Hello for Business are the path forward.
Where must MFA be enforced under the Essential 8?
MFA enforcement scope widens as you climb the maturity levels, starting with users of online services and ending with nearly every user on every system. Getting the scope right matters as much as getting the method right, because an assessor checks both.
ML1 scope
At ML1, MFA is required for users authenticating to your organisation's online services that handle your sensitive data, and to third-party online services that handle your sensitive data. Where available, it is also required for third-party services that handle your non-sensitive data. Microsoft adds an important enforcement detail: users should be prompted for MFA regardless of where they sign in from, and Conditional Access policies should not exclude MFA based on location, such as the corporate network.
ML2 scope
At ML2, the scope expands to cover privileged users of systems and unprivileged users of systems, in addition to the online-service users covered at ML1. ML2 also brings in two new control requirements that are easy to miss: successful and unsuccessful MFA events must be centrally logged, and those event logs must be protected from unauthorised modification and deletion.
ML3 scope
At ML3, MFA must additionally cover users of data repositories, and all of the in-scope MFA must be phishing-resistant. This is the level expected for systems handling the most sensitive information. The central logging and log-protection requirements carry over from ML2.
The break-glass (emergency access) account rule
Every organisation enforcing MFA in Microsoft 365 should keep at least one emergency access, or break-glass, account excluded from the MFA enforcement policy so administrators are never locked out. Microsoft recommends creating a dedicated security group, for example named EmergencyAccess, and excluding it from any Conditional Access policy that could block sign-in. If your only privileged accounts are caught by a misconfigured MFA policy, a single bad policy change or an identity provider outage can leave you with no way back into the tenant.
This is not a loophole in the Essential 8: it is a recognised operational safeguard. The practical balance is to exclude a small number of tightly monitored break-glass accounts from the enforcement policy, then protect those accounts another way. Microsoft recommends configuring them with a passkey (FIDO2) or certificate-based authentication and monitoring all of their sign-in activity with alerts, validating that they still work at least every 90 days. Note that report-only Conditional Access policies do not block access, so they do not need the break-glass exclusion.
This is exactly the kind of step that is easy to forget under deadline pressure. CYBERWHITE's one-click AutoFix can deploy a Conditional Access MFA policy through the Microsoft Graph API with a break-glass exclusion built in, so you enforce MFA across your tenant without risking an admin lockout. Our automated Essential 8 assessment also flags report-only policies that are not yet enforcing, so a policy that looks active but is not actually protecting anyone does not get scored as compliant.
How CYBERWHITE helps with Essential 8 MFA
CYBERWHITE assesses your Microsoft 365 tenant against the Essential 8 MFA requirements and shows exactly where you sit against ML1, ML2 and ML3. The platform reads your Entra Conditional Access configuration, identifies which users and services are covered, and checks whether the methods in use are phishing-resistant where the target maturity level demands it. CARS adaptive risk scoring then prioritises the gaps that carry the most risk, rather than presenting a flat checklist.
CYBERWHITE is Australian owned and operated (ABN 31 598 198 475) and a DSI Licensed Commercial Holder of SMB1001, so the assessment is built for the Australian frameworks your contracts reference. For a deeper look at how the full assessment works across all eight strategies, see our Essential 8 compliance page.
Frequently asked questions
Does SMS count for Essential 8 MFA?
SMS can satisfy MFA at Maturity Level 1 when combined with a password, but it is discouraged, and it does not count at ML2 or ML3. At those levels the MFA must be phishing-resistant, and Microsoft lists SMS sign-in and password-plus-SMS as not permitted.
What is phishing-resistant MFA?
Phishing-resistant MFA is multi-factor authentication that cannot be intercepted or relayed by a proxy phishing page or social engineering. In Microsoft 365 this means FIDO2 security keys, device-bound passkeys, Windows Hello for Business with a hardware TPM, smart cards, and hardware-protected certificates.
Does Microsoft Authenticator satisfy Essential 8?
Authenticator push notifications and OTP codes can satisfy ML1 but not ML2 or ML3, because they are not phishing-resistant. A passkey in Microsoft Authenticator (device-bound) does count as phishing-resistant and is acceptable at the higher levels.
Which maturity level requires phishing-resistant MFA?
Maturity Level 2 and Maturity Level 3 require phishing-resistant MFA for users of online services and systems. Maturity Level 3 additionally requires it for users of data repositories. Maturity Level 1 does not mandate phishing-resistant MFA.
Where does the Essential 8 require MFA to be applied?
At ML1, MFA applies to users of online services that handle sensitive data. At ML2 it extends to privileged and unprivileged users of systems. At ML3 it also covers users of data repositories. Higher levels also require central logging of all MFA events.
Do break-glass accounts break Essential 8 compliance?
No. Excluding a small number of monitored emergency access accounts from your MFA enforcement policy is a recognised safeguard to prevent admin lockout, not a compliance failure. Those accounts should still be protected with a strong method such as a FIDO2 passkey and closely monitored.
Does Essential 8 MFA need to be logged?
Yes, at ML2 and above. The model requires successful and unsuccessful MFA events to be centrally logged, with those logs protected from unauthorised modification and deletion.
Can I enforce MFA based on location only?
No. Microsoft's Essential 8 guidance states that users should be prompted for MFA regardless of sign-in location, and Conditional Access policies should not exclude MFA for users signing in from the corporate network.
What MFA methods are acceptable at ML2 in Microsoft 365?
At ML2, Microsoft permits only multi-factor crypto hardware: FIDO2 security keys, device-bound passkeys, Windows Hello for Business with a hardware TPM, smart cards, and hardware-protected certificates. Password-plus-OTP and push-based methods are not permitted.
How do I check which Essential 8 MFA level my tenant meets?
Run an automated assessment that reads your Microsoft 365 Conditional Access configuration and compares the in-scope users and methods against ML1, ML2 and ML3. CYBERWHITE does this and highlights the specific gaps to close for your target level.