MFA maturity level 2 (Essential Eight): requirements and evidence

What Essential Eight MFA at Maturity Level 2 requires

If you are moving an organization from Maturity Level One toward Level Two, or an assessor has asked for MFA evidence, the short answer is this: at ML2 multi-factor authentication must cover privileged and unprivileged users of systems, not only users of online services. Staff signing in to online services and systems must use phishing-resistant MFA, customer-facing online services must offer customers a phishing-resistant option, and both successful and unsuccessful MFA events must be centrally logged. These requirements map to ISM-1173, ISM-0974, ISM-1872, ISM-1682, ISM-1873 and ISM-1683 in the ISM Essential Eight baselines, and the ML2 tags on those controls are the place to confirm the exact wording in your own copy.

The risk behind these requirements is credential theft and phishing against sign-in. A password plus a one-time code can be captured by a convincing fake login page and relayed to the real service within seconds, so ML2 pushes staff toward methods that bind the login to the genuine site. ML2 is harder than ML1 in practice for three reasons: the scope widens from online services to every administrative console, file server and internal application, legacy systems and service accounts often cannot take a modern second factor, and the logging requirement means someone must own the event pipeline. Start by inventorying which systems still accept password-only logins and which identity provider each one trusts.

Central logging is the requirement teams most often leave until last, and assessors notice. Confirm that your identity provider or MFA service can forward enrollment, success and failure events to a central log store, and that those logs are protected from unauthorized change and deletion under ISM-1815. Ask your identity platform vendor or implementation partner to show a sample of failed and successful MFA events from a test account, and confirm your retention settings with your own assessor before treating the logging as complete.

Which systems, users and services fall under MFA at ML2

At Maturity Level Two, MFA reaches well beyond online portals. The populations below, from privileged administrators to customers and third parties, each carry different factor requirements, so the scope decision drives most of the implementation effort. Confirm each population against the ISM Essential Eight ML2 profile before you size the work.

Privileged and unprivileged system users

ML2 extends MFA to human users of systems, not only users of online services. That covers administrators signing in to servers, domain controllers, network devices and management consoles, and it also covers ordinary staff logging on to workstations and internal applications. Build an inventory of every login path that reaches a system, including local console and remote desktop access, and check each one against the ISM ML2 profile. The gaps are usually in older management tools that authenticate against local accounts.

Staff of online services

Staff who sign in to online services, including the organization's own portals and third-party SaaS platforms that hold sensitive data, must use phishing-resistant MFA at ML2. Confirm which SaaS applications your staff use, whether each one accepts a central identity provider, and whether it supports phishing-resistant methods such as passkeys or security keys. Applications that only accept SMS or email codes will need a compensating path or a replacement decision.

Customers of online customer services

Online customer services must offer customers a phishing-resistant MFA option. The requirement is to offer the option, so customers may still choose a weaker factor, but the option must exist. Check your customer identity stack for WebAuthn or passkey support, the enrollment flow for customers who lose a device, and how recovery is handled, because recovery paths often bypass the strong factor. Document how the offer is presented to customers.

Legacy systems that cannot support strong factors

Some legacy systems cannot accept phishing-resistant factors at all. Record each one, its owner, and the reason it cannot be changed, then decide whether to replace it, place it behind a gateway that enforces MFA, or isolate it. Ask the assessor how they expect such exceptions to be documented, and confirm with the ISM ML2 profile whether any compensating treatment is acceptable. Do not assume an exception is accepted until it is written down and reviewed.

Service accounts and non-human identities

Service accounts, scheduled jobs and API integrations are not human users, so the MFA requirement for human users does not apply to them directly. They still need strict control, typically through credential vaulting, restricted permissions and monitoring. Inventory these identities separately from people, record which ones authenticate interactively, and flag any service account that a person signs in with. Those interactive cases move back into MFA scope.

Third-party access and external identity providers

Vendors, contractors and partners who reach your systems are in scope when they are human users. Identity providers that sit outside your organization, such as a parent company directory or a managed identity service, change who controls the factor. Confirm in writing which party enforces MFA, which party logs MFA events, and whether those events reach your central log store. Where the external provider cannot meet the requirement, the gap belongs in your risk register.

How an assessor tests MFA at ML2

This table sets out how an assessor typically tests each element of MFA at Maturity Level Two, what they sample, the evidence they request and the findings that most often delay a level decision. Read it as a checklist to run before the assessor arrives, since each row maps to a part of the MFA requirements that an assessor will test directly.

Test element	What the assessor does	Evidence requested	Common findings
Privileged and unprivileged user sampling	Selects samples from administrators and standard users across systems, not only from users of online services	User population lists per system, MFA enrolment status, sign-in records for sampled accounts	MFA enforced for standard users but exempted for some administrator accounts
Authentication flow configuration review	Reviews the identity provider and system login policies to confirm MFA is required on every sampled path	Exported policy or flow configuration, screenshots or config files showing required stages, change history	Legacy protocols or local logons skip the second factor
Phishing-resistant factor confirmation	Checks that enrolled and permitted factors for staff are phishing-resistant, such as WebAuthn or FIDO2 passkeys, and tests whether weaker factors can still be chosen	Factor configuration, list of allowed authenticator types, enrolment records by factor type	SMS or email codes counted as phishing-resistant, or still available as fallback without a documented reason
Recovery and fallback paths	Tests account recovery and help desk reset procedures to see whether they reopen a weaker route	Recovery procedure, reset logs, sample of recent resets and the factor used afterwards	Static recovery codes or helpdesk resets bypass the phishing-resistant requirement
Customer sign-in option review	Confirms online customer services offer a phishing-resistant MFA option and that the option works end to end	Customer sign-in flow walkthrough, configuration of customer authenticator choices, test account results	Option exists in documentation but is hidden, broken or not enabled for all customer services
Central log review of MFA events	Samples successful and unsuccessful MFA events and traces them from the authentication source to the central log store	Log source list, forwarding configuration, sample events for both outcomes with timestamps and user identifiers	Logs kept only on the identity server, failures not recorded, or gaps where some systems do not forward
Log integrity and retention	Checks that MFA logs are protected from unauthorised modification and deletion and retained for the period the organization sets	Access rights to the log store, retention settings, change or deletion audit records	Administrators can edit or delete MFA logs without an alert
Ownership and operating records	Asks who reviews MFA exceptions and how the organization knows its configuration matches what was tested	Exception register with approvals, periodic configuration review records, named control owner	Exceptions approved informally with no expiry or review date

How to implement MFA at ML2 in sequence

This sequence moves an organization from partial MFA coverage to Maturity Level Two by first mapping who signs in and how, then choosing phishing-resistant factors, extending MFA to system access, testing for bypass paths, centralizing MFA event logs, and recording the result as a control the organization can show an assessor.

Inventory human users and access paths
The organization's identity or security team lists every group of human users, including staff, privileged administrators, contractors, and customers, and every path they use to reach systems and online services. The inventory covers directory sources, single sign-on applications, VPN and remote access, administrative consoles, and data repositories. Each path is marked with its current factor, if any. The output is an inventory with named owners for each path. It is complete when the team can point to a path for every privileged and unprivileged account type and no path is unaccounted for.
Decide phishing-resistant factors and customer option
The security lead and the business owners record a policy decision for the staff factor and the customer option. The decision names which phishing-resistant methods are approved, such as FIDO2 security keys or passkeys, how recovery works without falling back to a weaker factor, and how customers will select the phishing-resistant option. The record also states which legacy factors are retired for each population. It is complete when the decision record is approved by the accountable executive and the assessor-facing wording matches what the systems will enforce.
Extend MFA to privileged and unprivileged system access
The platform team configures the identity provider and self-hosted identity components so that every human sign-in to systems, not only to online services, requires the approved factors. Privileged and unprivileged accounts both receive MFA. Open-source options such as authentik, FreeIPA, and Keycloak can enforce second factors at login, and their configuration is captured as a baseline stored under version control. The output is a configuration baseline with the exact policy settings and the list of enrolled factor types. It is complete when a test account in each population is challenged at every system path from the inventory.
Enforce policy and test for bypass paths
The team tests each access path from step one against the configuration baseline, looking for ways around the second factor. Typical checks include legacy protocols that skip MFA, service accounts with password-only logins, unmanaged recovery methods, weaker factors left enabled alongside phishing-resistant ones, and direct logins to applications that bypass single sign-on. The tester records each attempt, the result, and the remediation. The output is a test record covering every path in the inventory. It is complete when each bypass finding is closed or formally accepted by the accountable owner.
Centralize MFA event logging
The operations team forwards successful and unsuccessful MFA events from the identity platform to a central log store, so that every factor challenge can be reviewed in one place. The pipeline also protects logs from unauthorized modification and deletion, which the Essential Eight baselines require at ML2. The team confirms that events from every path in the inventory arrive and carry enough detail to identify the user, factor, result, and source. The output is a log pipeline check showing sample events from each source and proof of write protection. It is complete when a test failed sign-in and a test successful sign-in both appear in the central store within the team's agreed review process.
Document the control and record ownership
The compliance lead writes a control record that links the decision record, configuration baseline, test record, and log pipeline check to the ML2 MFA requirements, with named owners and a review cadence set by the organization. The record also states how incidents involving MFA events are reported to the CISO and handled under the incident response plan, consistent with the ML2 incident requirements. The output is a control record that an independent assessor can trace from requirement to evidence. It is complete when the record is approved and the owners confirm they know their recurring tasks.

How central identity changes the MFA work

A central identity layer makes Maturity Level Two evidence easier to produce because one authentication path can enforce the required factors and emit the MFA events that ML2 requires to be centrally logged. When staff sign in through a single front door, the organization can show one set of phishing-resistant factor rules, one place where successful and unsuccessful MFA events are recorded, and one configuration to review at assessment time. Keycloak is the usual starting point for this pattern: applications redirect users to it for single sign-on over OpenID Connect, OAuth 2.0 or SAML 2.0, so the factor policy lives in the identity provider rather than in each application.

Identity brokering changes a different part of the picture. Zitadel can act as the broker that accepts sign-ins from external providers such as Microsoft Entra ID or Okta and presents them to applications through one trust relationship. This matters for ML2 when an upstream provider already enforces phishing-resistant MFA for staff, because the organization must confirm that the brokered login really carries that factor and that the broker logs the event. Enrollment and validation are the job of authentik, whose authenticator validation stage checks enrolled second factors such as TOTP apps, WebAuthn and FIDO2 passkeys during login. Confirm which factor types are permitted for staff and which are allowed for customers, because ML2 treats the two groups differently.

Central identity does not remove the work of checking each application. Any application that still offers a local username and password form, a legacy API login, or a break-glass account outside the central flow can skip the MFA path entirely, and the central logs will not show those sign-ins. Build an inventory of every login endpoint for each application, disable local authentication where the application allows it, and test with privileged and unprivileged accounts to confirm that each path produces a logged MFA event. Record the results, because an assessor will ask how the organization knows no sign-in bypasses the central flow.

Evidence that passes an MFA ML2 assessment

An assessor testing MFA at Maturity Level Two will want proof that the control works across every system in scope, not just a policy statement. The cards below cover the artifacts that prove enrollment, phishing-resistant factors, customer options, logging and response, and how to keep that evidence current between assessments.

MFA configuration exports per system

Export the MFA settings from each system in scope, including the identity provider, directory, VPN gateways, privileged access tools and key online services. Each export should show which users or groups must complete a second factor and which factor types are permitted. Compare exports against the system inventory so no in-scope system is missing. Ask whether any application still authenticates against a local password store that bypasses the central policy.

Phishing-resistant factor enrollment records

Keep enrollment records showing which staff have registered phishing-resistant factors, such as FIDO2 passkeys or hardware security keys, and when. Because ML2 requires phishing-resistant MFA for staff accessing online services and systems, a record of users still relying on SMS or email codes is a finding in its own right. Record exceptions, their owners and their expiry dates. Confirm with the vendor that each factor type you enrol meets the phishing-resistance expectation in the ISM.

Customer sign-in configuration evidence

ISM-1873 requires online customer services to offer a phishing-resistant MFA option. Capture screenshots or configuration exports of the customer sign-in flow showing that the option is presented and can be selected. Record the settings that govern it, including fallback methods and whether customers can downgrade to a weaker factor. Retain dated captures from before and after each change so the assessor can see the state at the assessment date.

MFA event logs with successes and failures

ISM-1683 requires successful and unsuccessful MFA events to be centrally logged. Provide samples from the central log store showing both outcomes for a defined period, with user, system, factor type and timestamp fields populated. Failed attempts matter as much as successful ones, so show that repeated failures are captured rather than dropped by a filter. Confirm that the log sources feeding the central store cover every system in the MFA configuration exports.

Log protection settings

ISM-1815 requires event logs to be protected from unauthorised modification and deletion. Evidence includes access control lists on the log store, write-once or immutable retention settings where available, and a list of accounts able to alter or delete logs with the reason each needs that right. Show that administrators cannot silently purge MFA logs. Ask your logging vendor to confirm exactly which protection features the product provides before you describe them in an assessment.

Incident response records tied to MFA alerts

Assessors will look for evidence that MFA alerts, such as bursts of failed factor challenges or unexpected enrollment of a new device, lead to action. Keep tickets showing triage, escalation to the CISO where an incident is confirmed, and actions taken under the incident response plan (ISM-0123, ISM-0140, ISM-1819). Link each MFA-related ticket to the alert that raised it so the chain from detection to response is visible.

What meeting MFA at ML2 costs

This table breaks the cost of meeting the ML2 multi-factor authentication requirements into components, showing who is paid, whether each item is one-time or recurring, and what moves it up or down. Use it to build a quote request, because no prices or durations are supplied here and each figure depends on your estimate of users, systems and internal capacity.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it, and what to request in a quote
Phishing-resistant factor hardware	Hardware vendor, procured by the organization	One-time per user, plus replacement cycle	Number of staff, privileged users and spares. Request unit counts, warranty terms and replacement assumptions.
Identity platform licensing	Vendor, or no license fee for self-hosted open source	Recurring for commercial IdP, none for the software itself	User count and feature tier. For open source, confirm which costs remain for hosting and support.
Engineering to extend MFA to systems	Internal staff or implementation partner	One-time, with ongoing change work	Number of privileged and unprivileged system types to bring behind the second factor. Request a system-by-system breakdown.
Central logging of MFA events	Log platform vendor or internal team	Recurring storage and operation	Event volume and retention period. Confirm that successful and unsuccessful MFA events both reach the central store.
Evidence upkeep	Internal compliance or security staff	Recurring	Frequency of access reviews, config exports and sampling evidence. Ask the partner which artifacts they hand over and in what format.
External testing or review	Independent testers or reviewers, engaged by the organization	Recurring, usually per assessment cycle	Scope of MFA bypass and phishing-resistance testing. Request a written scope before any work starts.
Auditor sampling	Independent auditor or assessor	Recurring, per assessment	Number of systems and users sampled. Confirm the sampling approach and the evidence the auditor expects before fieldwork.

Self-hosted open-source tools for MFA ML2 evidence

authentik is an identity provider released under the MIT license. Its authenticator validation stage checks the second factors a user has enrolled during login, so it is the component that decides whether a password alone is enough. The stage supports TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. The factor types are not equal for phishing resistance, and an assessor will expect the organization to say which ones it permits for staff.

Enrollment and policy records: Configuration exports show which authenticator types each flow requires, which supports the claim that MFA applies to privileged and unprivileged users.
Phishing-resistant factors: WebAuthn and FIDO2 passkeys are the factors the organization can point to as phishing-resistant, subject to its own criteria.
SMS and email factors: These are supported by the stage but are generally not phishing-resistant, so they should be excluded from staff flows if the ML2 requirement applies.
Recovery codes: Static recovery codes need a documented issuance and storage process, since they are a weak point an assessor will ask about.
Authentication events: Successful and unsuccessful events should be exported to the central log store, which is the ML2 logging requirement.

Confirm with your own configuration which factors are enabled in each flow and whether your deployment matches the phishing-resistance criteria you have adopted.

Where MFA at ML2 usually fails review

Most MFA programs that look complete on paper fail at the edges: the second factor that is not phishing-resistant, the console that skips the login flow, and the logs that exist but cannot be trusted. Each card below names one gap an assessor is likely to test, what to check, and the action that closes it before evidence is gathered.

SMS and email codes counted as phishing-resistant

Teams often report any second factor as MFA. At ML2, the factors used by staff for online services and systems must be phishing-resistant, and codes delivered by SMS or email can be relayed by a convincing fake login page. Check the enrolled factor list for each user group, not the policy document. Authentik's authenticator validation stage can check TOTP, WebAuthn, FIDO2 passkeys, Duo, SMS, email and static recovery codes, so the configured stage order determines what a user can actually fall back to. Action: restrict staff enrollment to phishing-resistant authenticators and remove SMS and email as staff options.

Admin consoles and legacy protocols that skip MFA

MFA often applies to the web portal while administrative consoles, command line tools, VPN gateways, or legacy protocols accept a password alone. ML2 requires MFA for both privileged and unprivileged human users of systems, not only online services, so each of these entry points is in scope. Build an inventory of authentication paths from the identity provider logs and the firewall rules, then confirm each one either enforces the second factor or is disabled. Action: map every login path to an identity source and block password-only access on each.

Customer MFA offered but not configured

A customer policy may promise a phishing-resistant option while the application still defaults to SMS or never presents the option at all. ML2 requires online customer services to provide a phishing-resistant MFA option, so an assessor will sign up a test customer account and walk the enrollment flow. Confirm that the option appears in the real journey, works on each supported browser and device class, and is recorded in the account. Action: run a scripted enrollment test for a customer account and keep the screenshots and results as evidence.

MFA events logged on the device only

Many systems write authentication results to a local file that rotates within days or disappears when a host is rebuilt. ML2 requires successful and unsuccessful MFA events to be centrally logged, so the identity provider's events must reach a store outside the systems that generate them. Check that failed challenges, not just successful sign-ins, arrive at the central store, and that the timestamps and user identifiers match across sources. Action: forward identity provider MFA events to a central log platform and test with a deliberate failed challenge.

No protection against log tampering

Central logging loses value if administrators can edit or delete the records of their own sign-ins. ML2 baselines require event logs to be protected from unauthorized modification and deletion, which means write-once storage, restricted delete rights, and integrity checks. Review who holds administrative rights on the log store and whether those rights are logged in a place they cannot change. Action: separate log administration from identity administration and restrict deletion rights on the MFA log store.

MFA alerts not tied to incident handling

Logs that no one reviews provide little assurance. ML2 expects event logs from internet-facing servers and detected cyber security events to be analyzed in a timely manner, and incidents to be reported to the CISO and to ASD with the incident response plan enacted. A burst of failed MFA challenges for one account should open a case with a named owner, not sit in a dashboard. Confirm the alert thresholds, the on-call rota, and the reporting path are written down and have been exercised. Action: create an MFA alert rule that opens an incident ticket and document the escalation path to the CISO.

Questions buyers ask about MFA at Essential Eight ML2

Can an in-house team meet MFA at Essential Eight ML2 without outside help?

Yes, in principle. The organization owns its controls, and an in-house team can implement them if it has the skills and time. ML2 MFA asks for three things: MFA that covers privileged and unprivileged human users of systems, phishing-resistant methods for staff, and central logging of successful and unsuccessful MFA events. Teams that already run a central identity provider usually find the extension easier than teams that manage authentication app by app. The harder part is usually inventory and coordination: finding every system that needs MFA, and getting identity, network and application owners to change login flows in the same window. An outside partner can prepare systems and evidence, but it does not decide compliance or issue an assessment result. Only an independent assessor can do that.

What drives the cost and effort of ML2 MFA?

Cost depends mostly on how many systems and identity sources exist and how many already support phishing-resistant factors. The main cost components are internal staff time, licensing for any identity or hardware token products, hardware keys if the organization issues them, and the work to connect each application to a central identity provider. Recurring costs include token replacement, enrollment support for new staff, and the time spent reviewing MFA logs. Costs fall when applications already support single sign-on and rise when legacy systems need proxies or custom integration. When requesting a quote, ask the partner to list each system in scope, the identity sources involved, the phishing-resistant methods proposed, the logging destination, and which items are one-time and which recur.

How long does ML2 MFA implementation usually take?

The duration depends on scope and change control rather than on any fixed figure. Timing is driven by the number of systems that must change, whether applications can be moved to single sign-on, how many user groups need enrollment, and how long change windows and testing take in production. Privileged accounts and internet-facing services often need the most careful sequencing. Organizations with a clear system inventory and an existing identity provider generally move faster than those discovering their estate during the project. Ask any partner to show the phases, the systems in each phase, the testing approach, and the points where the organization must approve changes. Treat any duration given without that breakdown as an estimate to test, not a commitment.

What does the organization need to provide for ML2 MFA work?

The organization needs named owners and a working inventory before implementation begins. Typical inputs include an identity owner who can approve login changes, application owners for each in-scope system, and a list of systems that accept human logins, including privileged interfaces and internet-facing services. Network and security teams must agree on change windows, rollback plans and testing access. Helpdesk staff need enrollment and recovery procedures before users are asked to change factors. Records of approvals, configuration changes and test results become part of the evidence, so the organization should decide early where those records are kept and who can read them.

Does SMS count as a phishing-resistant MFA method?

No. SMS codes can be intercepted, redirected or entered into a fake login page, so they do not meet the phishing-resistant requirement that ML2 places on MFA for staff. The Essential Eight ML2 baseline is about the method, so an organization can keep SMS as a fallback only if the phishing-resistant method is required for the relevant users and the fallback is governed by its own controls. Phishing-resistant options typically involve hardware or platform authenticators that bind login to the legitimate site. Confirm with your assessor how fallback methods, recovery codes and exceptions will be treated before you finalize the design.

Does ASD issue an Essential Eight certificate after ML2 is reached?

No. The Essential Eight is a set of mitigation strategies, not a certification scheme, so ASD does not issue a certificate. Maturity is shown through an assessment of how each strategy is implemented and how well it works against the maturity model. The organization owns its controls and its maturity claims. Independent assessors can test the evidence and report on it, but a partner that prepares systems and records does not issue any assessment result. Buyers should be cautious of any offer that promises a certificate for ML2, because the evidence and the assessment conclusion are what matter.

What should a scope document say about ML2 MFA work?

A scope document should state which systems, user groups and identity sources are in scope, and which are excluded with reasons. It should name the phishing-resistant methods to be deployed, how fallback and recovery will work, and how customer-facing services are handled, since the ML2 requirement for customers is an option rather than a mandate. It should specify the central logging destination, the log fields collected, retention and protection of those logs, and how logs are reviewed. It should list deliverables such as configuration records, test results and a runbook, identify which tasks the organization performs, and state how changes will be approved and rolled back. Finally, it should say the partner prepares evidence but does not issue assessment conclusions.

How DeployOpen prepares MFA ML2 evidence

DeployOpen starts with a written scope that names the systems, user populations and identity flows the Maturity Level Two work covers. For MFA, that means listing every privileged and unprivileged human account path to systems, every online service that holds customer data, and every point where a login is currently allowed without a phishing-resistant second factor. The scope also records which logging destination receives MFA events, since successful and unsuccessful events must be centrally logged. Agreeing these boundaries in writing before work starts lets the organization and its assessor see exactly what was tested and what was out of bounds.

DeployOpen then implements and hardens the self-hosted identity components inside the client's own environment, such as an authentik authenticator validation stage configured to accept WebAuthn and FIDO2 passkeys, or a Keycloak realm that brokers logins to existing identity providers. Where directory services already exist, FreeIPA can enroll TOTP and hardware tokens and proxy OTP checks to an existing RADIUS server during migration. The team configures each product's settings, documents them as code or configuration exports, and records which methods remain enabled. Confirm with each vendor which features your chosen version supports, particularly around phishing-resistant enrollment for customers, before committing to a design.

DeployOpen documents configurations, produces the evidence set the client's assessor will request, and hands over a record of how each MFA control was met. That evidence typically includes configuration exports, enrollment policies, central log samples showing MFA events, and the logging protection and incident reporting arrangements that the ML2 baseline also requires. DeployOpen does not issue audit reports, attestations or certifications, and Essential Eight is a set of mitigations rather than a certification scheme, so maturity is judged by an independent assessor against the maturity model. Organizations that want to prepare their MFA controls for that assessment can review the ASD Essential Eight maturity model and then request a written scope conversation with DeployOpen.

Multi-factor authentication maturity level 2