Essential Eight multi-factor authentication is the strategy teams are most confident they have already finished, and the one most often rated below what they expected. The strategy is assessed on two things: how much of your access it actually covers, and how well the factors hold up against the ways MFA is defeated in practice. Owning a licence for an authenticator app answers neither question.
The Essential Eight maturity model already names the usual cause — MFA available but not required is not implemented. That is the headline. What follows is the rest of the gap, because enforcement is only the first of three places a confident claim comes apart.
What Essential Eight Multi-Factor Authentication Asks at Higher Maturity
Essential Eight multi-factor authentication asks for two things at higher maturity, and they move independently. The first is breadth: more of what MFA protects. The second is strength: more resistance to the ways an attacker gets past it.
On breadth, the direction of travel runs outward from the obvious perimeter. Remote access and privileged operations come first, because that is where an attacker arrives and what they want. From there the expectation extends to the systems holding your important data, to the services and portals holding your data on someone else's infrastructure, and to users who are not employees.
On strength, the expectation moves toward phishing-resistant methods as the target level rises. Lower levels accept that a second factor exists at all. Higher levels care which kind, because the adversary the level is written against will not be stopped by a code a user can be talked into reading aloud.
Essential Eight MFA maturity therefore cannot be read off a product name. Two organisations running the same identity provider land on different levels depending on which populations are enrolled, which systems sit behind the provider, and whether the enrolled factors can be relayed.
Why Phishing Resistance Is the Distinction That Matters
Phishing resistance is the distinction that makes the maturity progression coherent rather than arbitrary. It separates methods an attacker can borrow from methods an attacker cannot.
Consider how a modern credential attack works. The victim is sent to a page that looks like the real login and is in fact a proxy. They type their password; the proxy forwards it to the genuine service. The genuine service asks for a second factor; the proxy relays that request to the victim. The victim reads a one-time code off their phone and types it in, or taps approve on a push notification. The proxy passes the response along, receives a valid session, and keeps it. Every step the user took was correct. The second factor worked exactly as designed, for the attacker.
That is the failure mode of any method whose response is a piece of information the user can hand over: codes sent by SMS, codes from an authenticator app, numbers read out to a help desk, and push approvals, which ask only for a tap and carry no binding to where the login is happening.
Phishing-resistant MFA closes this by binding the authentication to the origin requesting it. The authenticator performs a cryptographic operation tied to the domain and to the device holding the private key, and the result is meaningless to anything else. A proxy on a lookalike domain cannot obtain a usable response, because what it asks for is not what the authenticator will sign. There is nothing for the user to read out and nothing for the attacker to replay. Hardware security keys and platform authenticators built on origin-bound public-key credentials work this way, as do certificate-based schemes where the credential is non-exportable.
For planning, that means enrolling everyone in an authenticator app is a real improvement over passwords alone and will not by itself satisfy a target level written against a capable adversary. Treat method quality as a separate workstream from coverage, with its own timeline.
Think your MFA is finished?
Share your work email and we'll walk your enrolment and enforcement data against your user and system inventory, and mark the populations and legacy paths that would lower your MFA rating.
The Coverage Questions That Decide the Rating
The coverage questions that decide the rating are mechanical, and you can answer them in an afternoon. Each one is a population or a surface that a claim of full MFA quietly excludes.
- Which users? Employees are enrolled. What about shared and departmental accounts, accounts created for integrations, and the accounts of people who joined through an acquisition and still authenticate against a second directory.
- Which systems? MFA on the corporate identity provider says nothing about systems that never federated with it — the legacy line-of-business application, the database admin console, the network device with local accounts, the hypervisor.
- Remote access? Not just the VPN. Remote desktop gateways, jump hosts, cloud console access from outside the office, and any management interface reachable from the internet.
- Privileged access? Privileged operations are the point of the strategy, and they overlap heavily with restricting administrative privileges. An admin account that holds standing rights and authenticates with a single factor is two findings, not one.
- Third parties and contractors? This is the omission that surprises people most. Managed service providers, offshore development teams, contract finance staff and auditors hold real access, often through accounts your identity provider does not govern and your enrolment report does not count.
Write the answers against an inventory rather than from memory. MFA for Essential Eight compliance is rated against what exists, and the systems nobody listed are exactly the ones nobody protected.
Available Is Not Enforced
MFA enforcement is the difference between a capability and a control, and the gap shows up in five recognisable places.
Legacy authentication paths left open. Older mail and sync protocols, basic authentication endpoints and API paths that accept a password alone will be found and used. A conditional access policy that requires MFA for browser sign-in while a legacy protocol remains enabled has not required anything.
Exception registers with no expiry. An exception that never expires is not an exception; it is the configuration. One executive who found the prompts inconvenient in 2024 is a permanent hole in a control you believe is universal.
Break-glass accounts. Every environment needs a way in when the identity provider is unavailable, and those accounts are routinely excluded from MFA for exactly that reason. The exclusion is defensible; leaving it undocumented, unmonitored and unrotated is not. An assessor will ask how many there are, who holds the credentials, and what alerts when one is used.
Service accounts. Non-interactive accounts cannot be prompted, so they are enforced with something other than a second factor — credential storage, certificates, managed identities, restricted source addresses. Teams either forget they exist or assume they are out of scope. Neither position survives an assessment that asks what prevents a stolen service credential from being used.
Application-level authentication that bypasses the identity provider. The quietest failure. An application supports single sign-on but retains its own local login page, which still works, or an administrative back door remains for support purposes. The policy is enforced at the identity provider while the application accepts a username and password directly, so the control is present on paper and absent in the request path.
Each of these is findable by testing rather than asking. Attempt a sign-in on every path you believe is closed, from outside your network, and record what happens.
Push Fatigue in a Deployment That Looks Complete
Push fatigue is the failure mode of a deployment that looks complete on every dashboard. Coverage is universal, enrolment is one hundred per cent, enforcement is on, and the control is still defeated — by an attacker who has the password and simply asks.
Prompt bombing is the crude version: repeated approval requests, dozens in a row, late at night, until the user taps approve to make it stop. The refined version pairs one or two requests with a help desk call from someone impersonating IT, explaining that the prompts are a system migration and asking the user to approve. Both exploit the same property. A bare approval prompt gives the user no information about what they are approving, so there is nothing for them to evaluate.
Partial mitigations are worth deploying while the longer migration runs: number matching, so approval requires reading a value off the login screen rather than tapping a button; context in the prompt showing the application, location and requesting device; rate limiting and alerting on repeated denials, treated as an incident signal rather than noise. User awareness helps at the margin and is not a control.
The structural fix is the one maturity pushes you toward anyway. A method bound to the origin cannot be prompted into approving a login the user did not initiate, because the attacker never reaches a state where a prompt is useful.
The Evidence an Assessor Wants
The evidence an assessor wants is an enforcement report measured against your user and system inventory. Not a screenshot of a policy toggle, which proves a setting exists and nothing about who it reaches.
In practice that means four artefacts. A policy export showing what is required, for which populations, on which applications. An enforcement report from the identity provider showing actual sign-in outcomes — how many authentications in the period completed with which method, including the ones that completed without MFA. The denominator: the user and system inventory the report is measured against, so an unenrolled remainder is a visible number rather than an implied one. And the exception register, with an owner and an expiry date on every entry, break-glass accounts included.
An enrolment figure of ninety-eight per cent is a real achievement and is not the same as enforcement, because enrolment counts who could use MFA and sign-in data counts who did. Where the two disagree, the sign-in data is the control. The same discipline applies across the other strategies, which is why the Essential Eight assessment process asks for configuration and logs rather than attestations.
Essential Eight MFA Questions Teams Ask
These are the Essential Eight MFA questions teams ask most often after a rating comes back lower than the one they expected to claim.
No. An authenticator app generating one-time codes produces a value the user can read out and type into an attacker's proxy, which replays it to the real service within the validity window. Push approvals have the same weakness: the user is asked to approve, not to prove where the login is happening. Phishing resistance requires the authentication to be cryptographically bound to the origin requesting it, so a lookalike domain cannot obtain a usable response.
Yes, and they are the most commonly excluded population. If a managed service provider, an offshore development team or a contract administrator can reach your systems, that access is in scope regardless of who employs them. The practical problem is visibility: third-party access often sits outside the identity provider your enrolment report draws from, so it never appears in the denominator. Enumerate external access separately and contract for the method you require rather than assuming the provider's standard matches yours.
Treat them as a distinct control problem rather than an exemption. Non-interactive accounts cannot present a second factor, so compensating measures are the answer: managed or workload identities instead of static secrets where the platform supports them, certificate-based authentication, secrets held in a vault with access logged, source address restrictions, and rotation on a defined cycle. Document each account, its owner, and what prevents a stolen credential from being used.
No. A policy screenshot shows that a setting exists; it does not show coverage. What answers the question is sign-in or authentication data for a defined period, broken down by method and by application, measured against the inventory of users and systems in scope. That pairing makes the gap visible — the accounts still completing sign-in without MFA, the applications never federated, the legacy protocols still accepting a password. Provide the exception register alongside it, because an assessor who finds an undisclosed exclusion discounts the whole submission.
Only if you can state a maturity level per strategy with evidence behind it, and MFA is rarely the strategy that holds you back. Buyers ask for a level across all eight, and ASD's guidance is to reach the same level on every strategy before advancing any of them, so a strong authentication posture next to an unenforced application control deployment is assessed on the weaker one. See Essential Eight in government tenders for what the submission itself needs to contain.
Evidence your MFA coverage instead of asserting it
Book a demo and we'll show how Konfirmity tracks enrolment, enforcement and exceptions against your user and system inventory, so the MFA level you claim is the one the data supports.
Book a demo
Rate MFA on Enforcement, Not Intent
Rate this strategy on enforcement rather than intent, and the self-assessment stops disagreeing with the assessor. Three things produce an honest number: an inventory that includes third parties and the systems that never federated, sign-in data rather than enrolment data, and an exception register where every entry has an owner and a date it dies.
Then plan the method migration separately. Coverage can be closed in weeks because it is mostly configuration and enumeration. Moving a workforce to phishing-resistant authentication involves hardware, enrolment logistics, and applications that do not support it yet, and it is the work that takes a quarter rather than a sprint. Starting both at once is the difference between reaching your target level this year and discovering in a procurement cycle that you cannot.
The place to begin is a current rating you believe. Measure MFA against the maturity model honestly, then move it in step with the rest of the eight rather than ahead of them — ASD publishes the maturity model and its assessment guidance at cyber.gov.au, and the levels are defined by the adversary the implementation would withstand, which is the standard your enforcement report has to meet.
