Essential Eight MFA Requirements at a Glance

  • MFA is mandatory at every maturity level: Multi-factor authentication is one of the eight mitigation strategies, and no maturity level above zero permits password-only access to in-scope services.
  • Maturity Level One covers online services: MFA must protect your own online services and third-party online services that handle your organisation’s sensitive data, using something users have combined with something users know or are.
  • Maturity Level Two adds systems and phishing resistance: MFA must extend to privileged and unprivileged users of systems, must be phishing-resistant for online services and systems, and authentication events must be centrally logged.
  • Maturity Level Three adds data repositories: Phishing-resistant MFA must also protect access to data repositories, which in practice means FIDO2 security keys, smart cards, or hardware-backed certificates across the board.
  • Maturity Level Two is legally mandatory across government, defence, and critical infrastructure: It has applied to non-corporate Commonwealth entities under the Protective Security Policy Framework since 1 July 2022, to Defence Industry Security Program members since 15 November 2025, and to nine high-risk critical infrastructure asset classes under the enhanced CIRMP Rules registered on 9 June 2026.
  • Your score is set by your weakest strategy: Overall maturity is the level of the lowest-performing strategy, not an average, so a gap in MFA drags down the whole assessment.
  • The framework is being replaced, but not yet: ASD is transitioning the Essential Eight into a new Essentials series, with the Essential Eight remaining current guidance through the transition and existing controls expected to map across.

What is the Essential Eight?

The Essential Eight is a set of eight prioritised cyber security mitigation strategies published by the Australian Signals Directorate (ASD) through its Australian Cyber Security Centre (ACSC). The eight are application control, patch applications, configure Microsoft Office macro settings, user application hardening, restrict administrative privileges, patch operating systems, multi-factor authentication, and regular backups. They were drawn from ASD’s broader Strategies to Mitigate Cyber Security Incidents and represent the controls ASD judges most effective against the intrusion techniques it sees in real incident response work.

The Essential Eight Maturity Model was first published in June 2017 and has been revised regularly since, most significantly in November 2023. That revision is the one that matters for authentication. It set a minimum standard for what counts as a valid factor, removed weaker methods such as security questions and trusted signals, closed the loophole that let customers opt out of MFA on portals holding sensitive data, and moved the phishing-resistant MFA requirement down from Maturity Level Three to Maturity Level Two.

The model defines four maturity levels. Level Zero means the requirements for Level One are not met, Level One targets adversaries using widely available commodity tradecraft, Level Two targets adversaries willing to invest more effort against internet-facing infrastructure, and Level Three targets adaptive, well-resourced actors including state-sponsored adversaries. ASD expects organisations to reach the same level across all eight strategies before moving up, and overall maturity is set by the weakest strategy rather than by an average. In June 2026 ASD opened consultation on evolving the framework into a broader Essentials series, starting with a chapter called Essentials for enterprise IT. The Essential Eight remains the live, supported framework through that transition.

Who Does the Essential Eight Apply To?

The Essential Eight is written as guidance for all Australian organisations with internet-connected IT networks, but it becomes a hard obligation through several separate legal and contractual routes. In-scope organisations include:

  • Non-corporate Commonwealth entities: Federal departments and agencies subject to the Public Governance, Performance and Accountability Act must implement all eight strategies to at least Maturity Level Two, and consider Level Three where their threat environment warrants it. Maturity is reported annually.
  • Defence industry suppliers: Defence Industry Security Program (DISP) members must achieve and maintain the full Essential Eight at Maturity Level Two across the ICT systems used to correspond with Defence. Assessments against the older Top Four subset closed on 15 November 2025.
  • Critical infrastructure operators: Responsible entities under the Security of Critical Infrastructure Act 2018 can satisfy the cyber hazard element of a Critical Infrastructure Risk Management Program by adopting the Essential Eight at the prescribed maturity level, alongside options such as ISO/IEC 27001 and NIST CSF.
  • State and territory agencies: State frameworks commonly mandate the Essential Eight directly. The NSW Cyber Security Policy, for example, requires agencies to implement it to a minimum of Maturity Level One.
  • Private sector organisations and suppliers: There is no general legislative mandate for private business. In practice, Essential Eight maturity now appears routinely in government tenders, prime contractor flow-down clauses, vendor due diligence, and cyber insurance underwriting.

A note for Canadian and other non-Australian organisations: the Essential Eight has no extraterritorial force, but it reaches offshore suppliers through contracts. A Canadian vendor bidding for Australian government work, supplying a DISP member, or servicing an Australian critical infrastructure operator will typically be asked to demonstrate Essential Eight maturity for the systems used to deliver that service. Those with Australian subsidiaries or Australian government customers should expect to be assessed directly.

What Are the Essential Eight MFA Requirements?

The multi-factor authentication strategy is written as a set of discrete requirements that expand as you move up the maturity levels. Each maps to a numbered control in ASD’s Information Security Manual (ISM), which is what an assessor tests against. The table below shows how MFA scope changes by level.

Maturity Level What MFA Must Cover Factor Requirement Logging Requirement
Maturity Level One Your own online services and third-party online services handling your sensitive data, plus online customer services holding sensitive customer data Something users have plus something users know, or something users have unlocked by something users know or are Not required at this level
Maturity Level Two Everything at Level One, plus privileged and unprivileged users of systems, meaning workstations and servers Phishing-resistant for users of online services and users of systems, with a phishing-resistant option offered to customers Successful and unsuccessful MFA events centrally logged and protected from modification or deletion
Maturity Level Three Everything at Level Two, plus users of data repositories Phishing-resistant for online services, systems, data repositories, and customers of online customer services Central logging plus timely analysis of server and workstation event logs

The next table maps the specific ISM controls behind those requirements to their MFA relevance and to the LoginTC capability that addresses them.

Essential Eight / ISM Control Requirement MFA Relevance LoginTC Relevance
ISM-1504 (ML1, 2, 3) MFA for users of your own online services that handle sensitive data Mandatory MFA on VPNs, web portals, and remote access gateways via RADIUS and SAML
ISM-1679, ISM-1680 (ML1, 2, 3) MFA for third-party online services handling sensitive data, and where available for non-sensitive data Mandatory / where available Federated MFA for SaaS applications through a single policy set
ISM-1401 (ML1, 2, 3) MFA must use something users have with something users know or are Defines valid factors Push, hardware token, OTP, and FIDO2 factor options with policy enforcement
ISM-1173, ISM-0974 (ML2, 3) MFA for privileged and unprivileged users of systems Mandatory at ML2 MFA at Windows and Linux logon, RD Gateway, and privileged administrative access
ISM-1682, ISM-1872 (ML2, 3) MFA for users of systems and online services must be phishing-resistant Mandatory at ML2 FIDO2 security keys and hardware-backed certificates as enforced factors
ISM-1505, ISM-1894 (ML3) Phishing-resistant MFA for users of data repositories Mandatory at ML3 MFA in front of file servers, databases, and jump hosts at the access layer
ISM-1683, ISM-1815 (ML2, 3) Successful and unsuccessful MFA events centrally logged and protected from tampering Audit evidence Detailed authentication logs with syslog and SIEM forwarding

What Counts as Phishing-Resistant MFA

Phishing-resistant, in ASD’s terms, means verifier impersonation resistant. The authenticator has to cryptographically bind its response to the specific session being authenticated, using a private key the user controls, so a fake login page cannot relay the response to the real service. Anything that requires a person to read a code and type it in fails that test, because the code is not bound to the session. That rules out SMS codes, voice calls, email one-time passwords, and app-generated codes at Maturity Level Two and above. What qualifies is a shorter list: FIDO2 security keys, smart cards, hardware-protected certificates, device-bound passkeys, and Windows Hello for Business backed by a hardware Trusted Platform Module.

Workforce Access Versus Customer Access

The Essential Eight treats staff and customers separately, and both are in scope. Requirements for users cover employees, contractors, and partner guests. A parallel set covers customers of your online customer services where those services hold sensitive customer data such as personal, health, or identity information. Since November 2023, customers must be enrolled in MFA rather than allowed to opt out into password-only access, a phishing-resistant option must be offered to them at Maturity Level Two, and phishing-resistant MFA becomes the requirement at Level Three.

Where Compensating Controls Fit

ASD accepts compensating controls where a requirement cannot be implemented, but they must provide equivalent protection to the requirement they replace and must be documented. Legacy technology is the usual reason organisations reach for them: in ASD’s 2025 reporting, 59 per cent of Commonwealth entities said legacy technology had affected their ability to implement the Essential Eight. ASD’s position is that legacy systems should be upgraded as a priority rather than permanently exempted.

Is MFA Required by the Essential Eight?

Yes. Multi-factor authentication is one of the eight mitigation strategies, and every maturity level above zero requires it. There is no discretion about whether to deploy MFA at all, only about which maturity level your organisation needs to reach and therefore how far MFA has to extend.

Whether that requirement is legally binding depends on who you are. For non-corporate Commonwealth entities, the Protective Security Policy Framework has required all eight strategies at Maturity Level Two since 1 July 2022, which makes phishing-resistant MFA on workstations, servers, and online services a mandatory control rather than a recommendation. For DISP members, the same standard has applied across the full Essential Eight since 15 November 2025. For critical infrastructure responsible entities, the enhanced CIRMP Rules registered on 9 June 2026 raise the prescribed level to Maturity Level Two for nine high-risk asset classes, with staged grace periods running into 2027 and 2028. For everyone else, the Essential Eight arrives through procurement and insurance rather than legislation.

The November 2023 revision raised the technical bar, and many organisations have not caught up. A deployment built around an authenticator app pushing codes no longer meets Maturity Level Two, even though it was compliant under the earlier model. ASD’s figures show the effect: 22 per cent of Commonwealth entities reached overall Maturity Level Two in 2025, up from 15 per cent in 2024 but still below the 25 per cent recorded in 2023 before the controls were hardened.

The bottom line is that MFA itself is not the hard part of the Essential Eight. Coverage and factor strength are. An organisation that has MFA on Microsoft 365 and nothing else is at Maturity Level Zero for this strategy, and because overall maturity is set by the weakest strategy, that single gap defines the whole assessment result.

Consequences of Essential Eight Non-Compliance

The Essential Eight carries no fines of its own. ASD is not a regulator with penalty powers and there is no certificate to lose, so the consequences arrive through other channels that are often more expensive than a fine would be.

For federal entities, non-compliance surfaces as a reporting failure. Maturity is self-assessed and reported through the PSPF and ASD’s annual survey, results are aggregated into the Commonwealth Cyber Security Posture report tabled in Parliament, and shortfalls attract scrutiny from ministers, the Australian National Audit Office, and parliamentary committees. ASD also runs targeted assessment and remediation programs, so a poor result tends to convert into an externally supervised uplift program. For suppliers, the consequence is commercial: DISP membership depends on demonstrating Maturity Level Two and is frequently a precondition of Defence contracts, primes cascade the requirement to subcontractors, and insurers now use Essential Eight maturity in eligibility and pricing decisions.

The most serious exposure is what happens after a breach an Essential Eight control would have prevented. Since December 2022, a serious interference with privacy can attract a civil penalty of up to the greater of A$50 million, three times the benefit obtained, or 30 per cent of adjusted turnover, with a mid-tier penalty of up to A$3.3 million added in 2024 for conduct below that threshold. In October 2025 the Federal Court imposed the first civil penalty under the Privacy Act, ordering Australian Clinical Labs to pay A$5.8 million over a 2022 breach affecting more than 223,000 people.

The authentication-specific case to know is Medibank. The Australian Information Commissioner filed civil penalty proceedings in June 2024 over the October 2022 breach affecting 9.7 million people. According to the Commissioner’s concise statement, an attacker obtained the credentials of an administrator account belonging to a third-party IT contractor and used them to log into Medibank’s Global Protect VPN, which at the time accepted a device certificate or a username and password without requiring two or more proofs of identity. Roughly 520 gigabytes of data was exfiltrated. The proceedings remain before the Court, so the allegations are not yet findings, but the pattern is the one this mitigation strategy exists to prevent: stolen credentials, a remote access path without MFA, and unrestricted movement behind it.

How to Implement MFA for Essential Eight Compliance

1. Set Your Target Maturity Level and Scope Your Environment

Establish which maturity level you are obliged to reach, because everything else follows from it. Non-corporate Commonwealth entities and DISP members are targeting Maturity Level Two, and critical infrastructure responsible entities should check the level prescribed for their asset class and the applicable grace period. Then inventory what falls in scope: internet-facing services, third-party SaaS handling sensitive data, online customer services, workstations, servers, and at Level Three, data repositories. Document it, because an assessor will ask how you defined scope before asking how you covered it.

2. Map Every Authentication Path, Including the Awkward Ones

List every way a user can reach your environment and note which factor each path requires today. The gaps that fail assessments are rarely the obvious ones: the vendor support account that bypasses the VPN, the legacy application with local credentials, the break-glass administrator account excluded from conditional access, the exemption granted to users on the corporate network. ASD is explicit that users should be prompted for MFA regardless of sign-in location, so location-based exclusions are a finding rather than a design choice.

3. Choose a Solution That Reaches Systems, Not Just Cloud Apps

Maturity Level One can often be met inside a cloud identity platform. Maturity Level Two cannot, because it extends MFA to privileged and unprivileged users of systems, which means workstation and server logon. Choose a solution supporting RADIUS, LDAP, and Active Directory alongside modern federation, so one policy set covers VPN concentrators, Remote Desktop Gateway, Windows and Linux logon, and network devices. Decide early between cloud, on-premises, and hybrid deployment, since Australian government and defence environments often have data residency or air-gap requirements that rule out a cloud-only model.

4. Deploy Phishing-Resistant Factors Before You Deploy Broadly

If your target is Maturity Level Two or above, plan for phishing-resistant factors from the start rather than rolling out an app-based method and replacing it later. Issue FIDO2 security keys, smart cards, or hardware-backed certificates to privileged users first, then extend to the wider workforce. Keep a documented enrolment and identity verification process, because a phishing-resistant credential issued to the wrong person is worse than a weaker credential issued correctly. Retire SMS, voice, and email one-time passwords rather than leaving them as fallbacks, since an available weak fallback undermines the control.

5. Extend Coverage to Workstations, Servers, and Legacy Systems

Roll MFA out to workstation and server logon, including administrative access to jump hosts and management consoles. Where a system cannot accept MFA directly, enforce it at the access layer through RADIUS, an authentication proxy, or a privileged access path, so authentication happens before the user reaches the system. Where a genuine gap remains, document a compensating control providing equivalent protection, with the rationale, the approval, and the remediation plan.

6. Turn On Central Logging and Protect the Logs

Maturity Level Two requires successful and unsuccessful MFA events to be centrally logged and protected from unauthorised modification and deletion. Forward authentication logs to your SIEM or central log store, restrict who can alter or delete them, and confirm retention meets your obligations. Level Two also expects event logs from internet-facing servers to be analysed in a timely manner, and Level Three extends that to non-internet-facing servers and workstations, so logging has to feed a monitoring process rather than a passive archive.

7. Assess, Evidence, and Reassess

Use ASD’s Essential Eight assessment process guide to test your implementation the way an assessor would, and keep the artefacts: policy documents, conditional access and RADIUS policy exports, enrolment records, exception registers, and log samples. Maturity drifts as environments change, so schedule reassessment rather than treating the level as a standing credential. PSPF entities report annually and DISP members face point-in-time assessments, both of which reward evidence of controls running continuously.

Where Essential Eight MFA Deployments Get Difficult

Two things account for most of the distance between Maturity Level One and Maturity Level Two on this strategy.

The first is workstation and server logon. Enforcing MFA on internet-facing services is well-trodden ground and most organisations have done it. Requiring phishing-resistant MFA for privileged and unprivileged users of systems is a different scale of project, because it touches every endpoint and every server, including domain controllers, jump hosts, and machines that are not domain-joined. Organisations that treat this as an extension of a cloud identity project often discover partway through that the cloud platform does not reach the systems in question.

The second is legacy technology. Australian government and critical infrastructure environments carry a significant volume of systems that predate modern identity protocols and cannot be modified. ASD’s position is to upgrade them, but funding and viable replacements are the reported constraint, and in the meantime those systems still hold data and still accept logins. Enforcing MFA at the access layer, so authentication happens in front of the legacy system rather than inside it, is usually the only practical route to coverage without a replacement program. Getting this right early is what separates an assessment that confirms Level Two from one that reports Level One with a remediation plan attached.

Essential Eight MFA Best Practices

  • Design for your target level, not your current one: If Maturity Level Two is the obligation, deploy phishing-resistant factors and system-level coverage in the first pass. Rolling out an app-based method and replacing it later costs two change programs instead of one.
  • Remove location-based exemptions: ASD expects MFA regardless of sign-in location, so policies that skip MFA on the corporate network or from a trusted IP range are a compliance gap rather than a convenience.
  • Bring third-party and vendor access into scope: Contractor and support accounts are a recurring root cause in Australian breaches. Every third-party path into your environment needs the same factor strength as internal access, and the requirement should be written into the contract.
  • Treat customer-facing portals as in scope: If a portal holds sensitive customer data, MFA is required and customers cannot be allowed to opt out into password-only access. A phishing-resistant option is expected at Maturity Level Two.
  • Balance maturity across all eight strategies: Because overall maturity is set by the weakest strategy, pushing MFA to Level Three while application control sits at Level One buys no improvement in your assessed result. Move the eight together.
  • Keep evidence continuously, not at assessment time: Maintain policy exports, enrolment records, exception registers, and log samples as an ongoing practice. Maturity slips between assessments, and evidence gathered retrospectively rarely covers the intervening period.

How LoginTC Helps with Essential Eight MFA Compliance

LoginTC is built for the kind of mixed environment Essential Eight assessments actually encounter, where MFA has to reach cloud applications, VPN concentrators, Windows and Linux servers, network infrastructure, and legacy applications that cannot be changed. LoginTC integrates through RADIUS, LDAP, Active Directory, AD FS, and SAML, so a single policy set can cover the access paths ISM-1504, ISM-1679, ISM-1173, and ISM-0974 require without replacing existing infrastructure.

For the Maturity Level Two requirement that MFA for users of systems be phishing-resistant under ISM-1682, LoginTC supports FIDO2 security keys and hardware tokens as enforced factors and applies them to Windows logon, Remote Desktop Gateway, and privileged administrative access as well as to remote access. Prebuilt connectors cover the equipment common in Australian government and critical infrastructure environments, including Cisco, Fortinet, and Palo Alto VPNs, RADIUS-based network devices, and RD Gateway. For the data repository requirement at Maturity Level Three under ISM-1505 and ISM-1894, enforcing MFA at the access layer protects file servers, databases, and jump hosts without modifying the systems themselves, which is often the only viable route for legacy technology.

For the central logging obligations under ISM-1683 and ISM-1815, LoginTC produces detailed records of successful and unsuccessful authentication events and forwards them to a SIEM or central log store, which is the operational evidence an assessor expects rather than a policy statement. Entities with data residency, sovereignty, or air-gap requirements can run LoginTC on-premises, keeping authentication infrastructure and logs inside their own controlled environment, which matters for classified and isolated networks where a cloud-only identity platform is not an option.

Explore LoginTC for Government | View All Connectors

Frequently asked questions

Does the Essential Eight require MFA?

Yes. Multi-factor authentication is one of the eight mitigation strategies and is required at every maturity level above zero. Maturity Level One requires MFA for your own and third-party online services that handle sensitive data. Maturity Level Two extends it to privileged and unprivileged users of systems and requires it to be phishing-resistant. Maturity Level Three adds data repositories. No maturity level permits password-only access to in-scope services.

Who does the Essential Eight apply to?

All Australian organisations with internet-connected IT networks are encouraged to implement it, but it becomes binding through specific routes. Non-corporate Commonwealth entities and Defence Industry Security Program members must reach Maturity Level Two, the former under the Protective Security Policy Framework and the latter under DISP membership conditions. Critical infrastructure responsible entities can use the Essential Eight to satisfy the cyber hazard element of a Critical Infrastructure Risk Management Program. Private organisations face no general legislative mandate but are commonly required to demonstrate maturity through tenders, contracts, and insurance.

What types of MFA are acceptable under the Essential Eight?

At Maturity Level One, MFA must combine something users have with something users know, or something users have that is unlocked by something users know or are. Security questions, biometrics used alone, and trusted signals are not valid factors. From Maturity Level Two, MFA for online services and systems must be phishing-resistant, which rules out SMS codes, voice calls, email one-time passwords, and app-generated codes. Acceptable methods include FIDO2 security keys, smart cards, hardware-protected certificates, device-bound passkeys, and Windows Hello for Business backed by a hardware TPM.

Does the Essential Eight apply to Canadian or other non-Australian organisations?

Not directly, because it has no extraterritorial force. It reaches offshore organisations contractually. A Canadian vendor bidding for Australian government work, supplying a DISP member, or servicing an Australian critical infrastructure operator will usually be asked to demonstrate Essential Eight maturity for the systems used to deliver that service, and primes routinely flow the requirement down to subcontractors. Organisations with Australian subsidiaries or Australian government customers should expect direct assessment.

Is the Essential Eight being replaced?

It is being transitioned rather than withdrawn. In June 2026 ASD opened consultation on evolving the framework into a broader Essentials series, starting with a chapter called Essentials for enterprise IT, with further chapters signalled for cloud and operational technology. ASD has said the Essential Eight remains a live, supported document through the transition and that existing controls and investments are expected to map across. Current obligations, including the PSPF and DISP Maturity Level Two requirements, continue to apply.

Does LoginTC need to be deployed a certain way to support Essential Eight compliance?

No. The Essential Eight does not prescribe a hosting model, and both cloud and on-premises LoginTC deployments can support compliance. On-premises deployment is often the better fit for Australian government, defence, and critical infrastructure environments with data residency, sovereignty, or air-gap requirements, or that need to enforce MFA on isolated and legacy systems. What matters for the assessment is coverage, factor strength, and logging, not where the service runs.

Get a Free Essential Eight MFA Strategy Session

Reaching Maturity Level Two for multi-factor authentication means more than switching MFA on. It means covering workstations and servers as well as internet-facing services, deploying phishing-resistant factors instead of app-based codes, closing vendor and legacy access gaps, and producing central authentication logs an assessor can test.

Our team helps Australian government entities, defence industry suppliers, and critical infrastructure operators deploy MFA that meets the Essential Eight across modern and legacy systems, on-premises or in the cloud. If you are preparing for an ASD assessment, a DISP cyber assessment, or a CIRMP uplift, we can help you scope the work and close the gaps.




Start your free trial today. No credit card required.

Sign up and Go