What Essential Eight MFA at maturity level 3 asks for
At Maturity Level Three, the Essential Eight multi-factor authentication strategy asks for two things that ML2 does not. First, users of data repositories must authenticate with phishing-resistant MFA (ISM-1505 and ISM-1894 in the Information Security Manual's Essential Eight baseline). Second, customers of online customer services must be required to use phishing-resistant MFA, not merely offered it. That second obligation comes from ISM-1874, which replaces the ML2 requirement to offer a phishing-resistant option (ISM-1873). Everything from ML1 and ML2 carries forward, including phishing-resistant MFA for staff on online services and systems and central logging of MFA events. ML3 adds to that baseline; it does not swap any of it out.
The risk behind these controls is credential phishing and session theft. A password plus a one-time code can be captured by a fake login page and replayed within minutes, and a stolen session token can bypass MFA entirely after login. Phishing-resistant methods, such as FIDO2 passkeys or WebAuthn hardware keys, bind the credential to the genuine site, which is why the assessor will look for them rather than for the mere presence of a second factor. The hard part is usually not the strategy itself but the legacy estate: customer flows that still depend on SMS or email codes, applications that authenticate outside the central identity provider, and data repositories reachable through many paths, including service accounts, APIs, sync clients and older protocols. Confirm each path to every repository, and record which ones can be forced through phishing-resistant MFA and which need a compensating design.
Start by building an inventory of customer-facing online services and of data repositories, then mark each login path. For customers, decide whether the identity layer can enforce a phishing-resistant factor for every account, or whether a migration period, with a clear end date owned by the organization, is needed. For repositories, check whether non-human access can be separated from human access so the ML3 requirement applies cleanly to people. Open-source identity platforms such as authentik, FreeIPA and Keycloak can enforce second factors centrally, and their documentation shows which factor types they support, so confirm each factor against the ISM text with your assessor. Ask any implementation partner to name the evidence they will produce for each login path, and remember that the organization owns the control while only an independent assessor can give an assessment opinion.
Which data repositories, customer services and identities fall in scope
Maturity Level Three turns on two scope questions: which repositories and services the phishing-resistant requirement reaches, and which identities must meet it. The cards below cover the decisions that most often move the work, and each one changes which accounts, systems and evidence an assessor will sample.
Data repositories holding human users' data
ISM-1505 and ISM-1894 require phishing-resistant MFA for human users authenticating to data repositories. The first decision is which stores count as repositories: file shares, document management, databases with direct user access, data warehouses and collaboration sites that hold sensitive records. Build an inventory from the data classification register, not from the list of applications IT already manages. Each repository reached by staff needs its login path confirmed, including legacy protocols that bypass the identity provider.
Customer services requiring phishing-resistant MFA
At ML3, ISM-1874 requires customers of online customer services to use phishing-resistant MFA, replacing the ML2 option to offer it. Scope starts with services that hold customer data and let customers sign in with a second factor. Confirm whether mobile apps, partner portals and API-driven front ends count as separate services. Where customers can still reach a service with SMS or email codes only, that path sits outside the ML3 position and needs either removal or a documented decision.
Service accounts and non-interactive identities
Service accounts, scheduled jobs and API clients do not complete a human login, so the human-user requirements in ISM-1505 and ISM-1894 generally do not apply to them. The work lies in proving that classification. List every non-interactive identity, confirm it cannot be used for an interactive login, and check that it has no path to a repository where a person could authenticate with it. An assessor will test a sample of these accounts, so an undocumented exception will usually be questioned.
Third-party and contractor users
Vendors, contractors and managed service staff who reach your repositories or customer services are human users, so the staff requirements apply to them. Where a third party authenticates through its own identity provider, the organization still needs evidence that the provider enforces phishing-resistant methods. Check contracts for MFA obligations, confirm guest accounts are included in the identity inventory, and decide how external accounts are removed when an engagement ends.
Federated logins and identity brokers
When users sign in through a central identity provider, the phishing-resistant check may happen in the broker rather than in each application. Keycloak, authentik, FreeIPA and Zitadel can each sit in this role, and each can also broker logins to external providers. Map every application to the provider that enforces its second factor. A federated sign-in that bypasses the broker's MFA stage leaves a gap that the repository-level scope will not reveal, so test each path directly.
Legacy and direct-access paths
Scoping often stops at the main sign-in page, while the repository is still reachable through an older protocol, a local account or a service that authenticates directly against a directory. Inventory SMB, database native logins, remote desktop gateways, and API keys that let a person reach data without the identity provider. Each path either joins the identity provider with phishing-resistant MFA or is removed from the environment. Record the decision for each path, since an assessor will look for it.
How an assessor tests ML3 MFA
This table sets out how an assessor samples and tests each Maturity Level Three MFA requirement, the evidence they ask for, and where implementations commonly fail. Read each row as a test step: the left column names the requirement, and the other columns show what the assessor checks and what proof they expect. The main takeaway is that a phishing-resistant method being available is not enough; assessors look for fallbacks and defaults that let users avoid it.
| Requirement | What the assessor tests | Evidence requested | Common finding |
|---|---|---|---|
| Phishing-resistant MFA for repository users (ISM-1505, ISM-1894) | Sample user accounts with access to data repositories and confirm each one authenticates with a phishing-resistant second factor | Account listing for repository access, authenticator enrolment records, and sign-in logs showing the method used | Some repository accounts still sign in with TOTP or SMS because enrolment was never enforced |
| Customer phishing-resistant MFA (ISM-1874) | Walk through customer login flows and confirm phishing-resistant MFA is required, not just offered | Authentication policy or flow configuration, and test sign-ins from each customer journey | A phishing-resistant option exists, but the default enrolment path still lets customers choose SMS or email codes |
| Second-factor method configuration | Review which second-factor types the identity platform accepts, including TOTP, SMS, email codes, Duo and static recovery codes | Exported authenticator stage or policy settings, with a dated change history | Legacy factors remain enabled in a stage that also serves privileged or repository access |
| Fallback and bypass testing | Attempt sign-in using SMS, OTP or recovery codes in place of the phishing-resistant factor, and check whether the platform allows it | Test scripts, screenshots or recordings of each attempt, and the platform's responses | Recovery codes or a help-desk reset path give a weaker factor a route around the required method |
| Central logging of MFA events | Confirm MFA events from repositories and customer services reach a central log store and cannot be edited by administrators | Log source inventory, sample events for successful and failed MFA, and retention settings | MFA events are logged locally on the identity server only, or failed attempts are not captured |
| Event log analysis scope at ML3 | Check that timely analysis covers non-internet-facing servers and workstations as well as internet-facing servers (ISM-1907, ISM-0109) | Analysis schedules, alert rules and records of reviewed alerts for each device class | Review covers internet-facing servers only, which leaves MFA-related events on internal hosts unexamined |
| Exceptions and compensating controls | Review every documented exception to phishing-resistant MFA and test whether the compensating control works | Signed exception register with owner, expiry date and the compensating control tested | Exceptions have no expiry, so temporary accounts keep weaker factors indefinitely |
Sequence for moving MFA to ML3
This sequence takes an organization from Maturity Level Two multi-factor authentication to Maturity Level Three by scoping the systems that hold data repositories and customer services, choosing phishing-resistant methods, closing weaker fallbacks, and producing evidence an assessor can test. The organization owns each control; an implementation partner can prepare configurations and records for review.
Inventory data repositories and customer services
Start by listing every data repository that human users can reach and every online customer service your organization operates. For each entry, record the owner, the login path, the identity provider or local account store it uses, and whether it is internet-facing. This scoped inventory is the boundary for ML3 MFA, so it should be reviewed by the system owners and the compliance lead before any configuration changes. Confirm the scope against the current ISM Essential Eight baseline profile, since the controls apply to specific populations rather than to the whole estate.
Confirm ML2 MFA is already in place
Before adding anything, verify that every ML1 and ML2 MFA requirement is met across the inventory. ML3 keeps all of those controls, including phishing-resistant MFA for staff using online services and systems and central logging of MFA events, so a gap at ML2 becomes a gap at ML3. Produce a gap register that lists each system, the MFA factor type it uses today, and any exceptions with an owner and a closure record. The register shows whether the uplift is a targeted change or a broader program.
Select phishing-resistant authentication methods
Choose the methods that will serve as the phishing-resistant factor for repository users and customers. Options named in common practice include WebAuthn and FIDO2 passkeys and hardware security keys. Check each candidate against the applications it must cover, the devices your users hold, and the recovery process you will run. Your identity platform must support the chosen method, so confirm this with the vendor or in a test environment rather than assuming it. Record the decision and its rationale as a configuration baseline that names the approved methods for each population.
Remove or restrict weaker fallback methods
Identify where SMS codes, email codes, static recovery codes or other non-phishing-resistant factors can still complete a login for in-scope users. Disable them where the approved method is available, or restrict them to a documented recovery procedure with named approvers and logging. Recovery paths are a common gap, because a weak fallback can defeat a strong primary factor. Test that a phishing attempt cannot step down to a weaker factor. The output is a change record for each system and a test record showing the fallback was blocked or tightly controlled.
Enforce phishing-resistant MFA for customers
For customer-facing online services, move from offering a phishing-resistant option to requiring it at ML3. Plan the customer impact before enforcement: how existing customers enroll, how they recover access, how support staff verify identity, and what happens to customers who cannot use a supported device. Communicate the change, stage the rollout, and track enrollment so you can show the requirement is applied to the whole in-scope customer base. The output is an enforcement configuration, a rollout record and a customer support procedure.
Extend central logging and verify the result
Confirm that MFA events from every in-scope repository and customer service reach central logging, and that logs are reviewed in line with ML3 expectations for non-internet-facing servers and workstations. Then test the whole design: attempt logins with a phishing-style replay, confirm weaker factors are refused, and check that the logs record each attempt. Gather the configuration baseline, the test record, the log samples and the gap register into one evidence pack. An independent assessor, not the implementation partner, decides whether the evidence supports the maturity claim.
How ISM-1505, ISM-1894 and ISM-1874 change the baseline
At Maturity Level Three, the MFA baseline gets stricter in two places: data repository users and customers of online customer services. In the ISM OSCAL catalog, ISM-1505 and ISM-1894 are tagged to the ML3 Essential Eight profile. ISM-1505 requires MFA for human users of data repositories, and ISM-1894 requires that this MFA be phishing-resistant. The ML3 profile also replaces three ML2 controls with stricter versions: ISM-1691 and ISM-1695 (staff MFA on online services and systems) and ISM-1873 (customer MFA). Confirm the exact replacement wording against the current ISM_catalog.json in the ISM OSCAL release, because the replacement is a change in the control text, not just a new tag.
ISM-1874 is the customer change. At ML2, an online customer service only has to offer a phishing-resistant option. At ML3, phishing-resistant MFA must be required for customers, so a customer who chooses a weaker factor is no longer permitted to sign in with it. For a customer identity layer, the practical decision is which second factors to remove from the enrolment and step-up flows, and how to handle customers who cannot use a passkey or hardware token. Document that decision and the fallback path, because an assessor will test whether the weaker factor is still reachable, not just whether a stronger one exists.
The ML3 profile also extends timely event log analysis from internet-facing servers to non-internet-facing servers and workstations (ISM-1907 and ISM-0109). For MFA, this means authentication events from identity providers, directory services and internal workstations need to be collected and reviewed on the same timescale as internet-facing logs. Check whether your identity platform writes MFA enrolment, challenge, failure and recovery-code events to your central log store, and whether anyone is assigned to review them. Treat this as a recurring task with an owner, not a one-off configuration.
Choosing a self-hosted identity pattern for ML3 MFA
Choose this pattern when one identity store will hold the people who sign in to your online services and systems, and you want WebAuthn and FIDO2 passkeys as the second factor. authentik's authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. The license is MIT. For ML3, the evidence question is not whether the stage exists but whether every path into your services is forced through it with phishing-resistant factors only.
- Enrollment policy: Confirm that passkeys are enrolled and that TOTP, SMS, email and static recovery codes are not accepted as the sole factor for staff.
- Recovery paths: Static recovery codes are not phishing-resistant. Confirm how recovery is issued, who approves it and how it is logged.
- Application coverage: Confirm that every application you assess is actually routed through the identity store rather than retaining local passwords.
- Central event records: Confirm that authentication events can be exported to your central log store, since ML3 requires MFA events to be logged centrally.
- Customer flows: Confirm whether customer sign-in uses the same stage and whether a phishing-resistant method is required, not merely offered.
Confirm these points in your own environment with the vendor documentation before you rely on them in an assessment.
Choose this pattern when your users, groups and Linux hosts already sit in a directory and you need OTP tokens managed alongside them. FreeIPA (GPL-3.0-or-later) supports two-factor authentication with HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration. The important limit for ML3 is that HOTP and TOTP are OTP methods, so FreeIPA alone does not establish phishing-resistant MFA for staff unless you confirm how hardware-bound credentials are used.
- Token type: Confirm which token types your staff use. A YubiKey used in OTP mode is not the same as a FIDO2 credential, so check the configuration on every key.
- RADIUS migration: If OTP checks are proxied to an existing RADIUS server, document the interim state and the date you plan to retire it.
- Host login paths: Confirm that SSH, sudo and console logins all require the same factor policy, since gaps usually sit in secondary access paths.
- Central logging: Confirm that directory authentication and OTP events reach your central log store.
- Customer data repositories: Confirm whether repository access for customers or third parties goes through this directory at all.
If your phishing-resistance requirement cannot be met with OTP tokens, plan a separate phishing-resistant method and confirm it with your assessor.
Choose this pattern when many applications exist and you want users to authenticate once with a central hub rather than in each application. Keycloak (Apache-2.0) provides single sign-on, supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to existing OpenID Connect or SAML 2.0 identity providers. For evidence, the hub becomes the point where MFA policy is set once and checked across applications, which simplifies consistent enforcement, but only if applications do not keep their own login paths.
- Brokered providers: Confirm whether a brokered upstream provider enforces phishing-resistant MFA. Keycloak cannot make an upstream provider stronger than the provider's own policy.
- Authentication flows: Confirm that the browser flow requires a phishing-resistant credential for staff and that the policy cannot be bypassed by a fallback flow.
- Legacy applications: Confirm which applications still authenticate directly, since those sit outside the hub's MFA enforcement.
- Admin console access: Confirm that administrative access to the hub itself requires phishing-resistant MFA.
- Event export: Confirm that login and MFA events are exported to a central log store with timestamps you can present to an assessor.
Write down each application's login path before the assessment, because the hub only evidences what it actually controls.
Choose this pattern when your users already sign in through external providers such as Google, Microsoft Entra ID or Okta, and you want one broker that applications trust instead of trusting each provider separately. Zitadel (AGPL-3.0-only) acts as a central identity broker so users can sign in through external identity providers over OpenID Connect, SAML 2.0 or LDAP. The license is AGPL-3.0-only, so confirm with counsel what that means for your deployment and any modifications you make before you choose it.
- Phishing resistance sits upstream: The broker inherits the strength of each external provider's MFA. Confirm which methods each provider enforces for your staff and customers.
- Provider inventory: List every provider the broker trusts, since each one becomes part of your ML3 scope.
- Customer requirement: ML3 requires phishing-resistant MFA for customers, so confirm that each customer path through an external provider offers and enforces that method.
- Logging across providers: Confirm that you can obtain MFA events from the external providers as well as the broker, because the broker alone may not show the factor used.
- Fallback accounts: Confirm whether local accounts exist and how they are protected.
Ask each external provider for written confirmation of its phishing-resistant options before assuming the broker meets the requirement.
Evidence that passes an ML3 MFA assessment
An assessor testing MFA at Maturity Level Three will want proof that phishing-resistant methods are enforced, not just configured, across data repositories and customer services. The five artifacts below connect configuration, enrolment, policy, logging and review, and each one needs a refresh rhythm so it reflects the environment on the day of assessment.
MFA configuration exports
Export the enabled second-factor methods for each data repository and each customer-facing online service, with the date and the identity provider or policy that enforces them. At ML3 the export should show that phishing-resistant methods such as WebAuthn or FIDO2 passkeys are the only accepted factor for repository users, and that customer services require one rather than merely offering it. Check that the export matches what users actually encounter, because a policy that allows a weaker fallback will fail the test. Re-export after every change to login flows and at least once per quarter.
Phishing-resistant enrolment records
Keep a register of who enrolled which phishing-resistant authenticator, when, and under which identity verification step. For repository users and customers, the register should separate hardware keys, platform passkeys and any remaining software factors so an assessor can see that the required method is in use. Reconcile the register against the directory every month to catch accounts enrolled with a method that no longer meets the requirement. Ask your identity platform vendor which enrolment events it records natively and which need an export job.
Fallback and recovery policy
Write down how a user recovers access when a phishing-resistant authenticator is lost, damaged or replaced. The policy should say who approves recovery, how identity is verified, how long a recovery code or temporary factor remains valid, and whether SMS or email codes are permitted as a fallback. Assessors frequently test whether the fallback quietly defeats the primary control, so the document must state the fallback path explicitly. Review it annually and whenever the identity platform changes.
Central MFA event logs
Retain authentication events from every repository and customer service in one central store, including successes, failures, factor type used and any enrolment or recovery change. Central logging is an ML2 expectation that continues at ML3, and assessors will check that events from non-internet-facing systems are included, not only public services. Confirm the retention period with your own risk and legal owners, then test a sample query for one account across a full day. Verify log integrity on a schedule so the record can be relied upon.
Dated access review sample
Keep dated access reviews covering who holds repository access and who can change customer-service authentication settings. Each review should record the reviewer, the population sampled, the accounts removed or changed, and the factor each remaining user is enrolled with. A sample from several past cycles shows the review is operating, not drafted for the audit. Schedule the reviews on a fixed calendar and store the signed output with the exports they relied on.
What meeting ML3 MFA costs in money and effort
This table breaks down the cost components of moving to phishing-resistant MFA at Maturity Level Three, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. No figures are given because none were supplied, so use the drivers as questions to put to any quote.
| Cost component | One-time or recurring | What drives it up or down |
|---|---|---|
| Identity platform licenses or self-hosting effort | Recurring licenses or support; one-time build effort | Commercial licenses scale with users and features. Self-hosted open source such as authentik, Keycloak or Zitadel removes license spend but moves cost to hosting, upgrades, patching and staff time. Confirm each product's license terms with the vendor or project. |
| Hardware security keys or passkey rollout | One-time procurement and enrolment; recurring replacement | Headcount, number of shared or remote staff, and whether passkeys on managed devices can replace physical keys. Ask for the replacement and lost-key process in the quote. |
| Engineering time for repository and customer flow changes | One-time | Number of data repositories, how many use single sign-on already, and whether legacy applications need proxies or code changes. Ask which repositories are in scope and how each login path is tested. |
| Customer communication and support | One-time rollout; recurring help desk demand | Size of the customer base, the channels customers use, and how many will need help enrolling a phishing-resistant method. Plan for a support queue during the cutover period. |
| Evidence upkeep | Recurring | How often configurations change, how many repositories and customer services must be shown, and whether MFA events are collected centrally. Automated exports reduce manual collection each cycle. |
| Auditor sampling | Recurring per assessment cycle | Assessor sample sizes, the number of users and systems sampled, and how well records are kept. Ask the independent assessor how it will select samples before work starts. |
Who does what: your team, a partner and the auditor
Maturity Level Three for multi-factor authentication touches identity, applications, customer journeys and logging, so no single party can close it alone. The Essential Eight is a set of mitigations, not a certification scheme, so the organization owns the controls, a partner prepares the systems and evidence, and an independent assessor forms the view on whether the level has been met.
Your controls and policy decisions
Your organization owns the control environment. Leadership must decide which data repositories fall under ML3 scope, which customer services are in scope for phishing-resistant MFA, and what happens to customers who cannot enroll a phishing-resistant factor. Those decisions set the target and should be written down before any configuration starts. Check that a named owner signs off on the scope statement and on every exception.
Identity configuration and integration
A partner can configure the identity provider, enroll phishing-resistant authenticators such as WebAuthn and FIDO2 passkeys, and connect applications and data repositories so they accept the central login. This work covers the authenticator stages, recovery paths and integration with existing directories. Ask the partner to show how each repository enforces the factor, not only how the identity platform is set up.
Customer journey and recovery design
Requiring phishing-resistant MFA for customers changes sign-up, account recovery and support processes. Your product and customer teams decide how customers register a passkey, what fallback is acceptable, and how support staff verify identity without weakening the factor. The partner can build and test these flows, but your team must approve them. Confirm that recovery methods do not offer a route around the required factor.
Logging and monitoring evidence
ML3 keeps all ML1 and ML2 MFA controls in force, including central logging of MFA events. A partner can route authentication logs to a central store, set retention and alert on failed or bypassed challenges. Your security operations team must review these logs on a defined cadence and retain proof of that review. Check that the log sources cover every repository and online service in scope.
Evidence packs and testing
The partner assembles evidence for each in-scope system: configuration exports, enrollment records, test results showing a password-only login is refused, and log extracts. Testing should include attempts to phish or replay credentials against the in-scope services. The organization retains and reviews these packs. Ask for a list of evidence items mapped to the relevant ISM controls before work begins.
Independent assessment and reporting
An independent assessor tests whether the implementation and its effectiveness meet ML3, using the maturity model and the ISM baseline. Only that assessor issues a finding or report. DeployOpen prepares systems and evidence and does not issue assessments or certificates, and the Essential Eight has no ASD certificate. Confirm the assessor's independence and agree the assessment scope in writing before evidence collection starts.
Questions buyers ask about ML3 MFA
How much more effort is ML3 MFA than ML2 MFA?
ML3 adds a narrower set of changes on top of ML2, so the effort depends on how far your current MFA already reaches. Every ML1 and ML2 MFA control remains at ML3, so the work is not a replacement of your existing setup. The new demands are phishing-resistant MFA for human users of data repositories (ISM-1505 and ISM-1894) and phishing-resistant MFA for customers of online customer services, replacing the ML2 requirement to only offer a phishing-resistant option (ISM-1874). The main drivers are how many customer-facing and repository-access paths exist, how many of them already accept a phishing-resistant factor, and how many users would need a new credential. Ask any partner to size the work from an inventory of these paths, not from a generic estimate.
Can our own team implement ML3 MFA in-house?
Often yes, if your team already runs identity infrastructure and can test changes safely. The work splits into identity platform configuration, application integration, user enrollment, recovery design and evidence collection. Internal teams usually own policy decisions, such as which repositories are in scope and how recovery works, and they should keep that ownership. Outside help is most useful where the team lacks capacity, has many legacy applications to reconfigure, or needs an independent check before an assessment. Whatever the split, the organization owns its controls and evidence, and only an independent assessor can issue a conclusion about them.
What does ML3 MFA ask from staff and customers?
Staff must enroll and use phishing-resistant factors for the systems and repositories in scope, and customers must be able to complete login with a phishing-resistant method once it is required. The practical burden falls on help desks, account recovery, device replacement and communications. Staff who lose a hardware key or change phones need a documented, verified recovery path that does not weaken the control. Customers may need clear instructions, support channels and time to adopt passkeys or security keys. Plan the enrollment waves, the fallback rules and the messaging before the enforcement date, and measure how many accounts can still log in through a weaker method.
Can customers be forced onto passkeys at ML3?
ML3 requires that MFA for customers of online customer services be phishing-resistant, so an organization can make a phishing-resistant method the only accepted second factor for those accounts. Whether that is a passkey, a FIDO2 security key or another phishing-resistant option depends on the method your identity platform supports and on your customers' devices. Forcing adoption carries customer support and abandonment risk, so decide the cut-over approach, the exceptions process and the recovery options before enforcement. Confirm the exact requirement wording in the ISM profile with your assessor, and confirm each platform's supported methods with its vendor.
How long does an ML3 MFA rollout take?
No supplied figure fixes the duration, so treat any number you hear as unverified until a scoped plan confirms it. The timeline is driven by the number of applications and repositories in scope, the state of your identity provider, how many users must re-enroll, how many legacy systems need changes, and how long recovery and help desk procedures take to prove out. A reasonable step is a written scope that lists each in-scope path with its current factor and target factor, then a phased schedule agreed before work starts. Ask any implementation partner for a fixed-scope plan with milestones.
What will an assessor ask to see for ML3 MFA?
An assessor will typically ask for a list of in-scope systems, repositories and customer services, the MFA method configured for each, and proof that phishing-resistant factors are enforced rather than merely available. Expect requests for central logging of MFA events, configuration exports from the identity platform, enrollment records, recovery procedure records and samples of authentication logs. For customers, expect evidence that the phishing-resistant requirement applies to all relevant accounts, not just new ones. Preparation partners can build and organize this evidence, but only the independent assessor reaches a conclusion. Ask your assessor early which evidence formats they accept.
Which open-source identity platforms can support ML3 MFA?
authentik, Keycloak, FreeIPA and Zitadel each address parts of the requirement, but none should be chosen on the strength of this page alone. authentik's authenticator validation stage checks enrolled second factors, including WebAuthn and FIDO2 passkeys. Keycloak provides single sign-on so applications authenticate centrally. FreeIPA supports TOTP and HOTP tokens and hardware tokens such as YubiKeys. Zitadel can broker logins to external identity providers. Confirm, in a proof of concept, that the chosen platform enforces phishing-resistant factors for every in-scope path, that it logs MFA events centrally, and that its recovery design meets your policy.
Where to read the ML3 MFA controls
Start with the ASD Essential Eight Maturity Model, which defines what Maturity Level Three means for multi-factor authentication and the other seven strategies. For the control-level detail, use the Information Security Manual (ISM) published in OSCAL, which includes Essential Eight ML1, ML2 and ML3 baseline profiles. Within the ML3 profile, the controls that matter most for this topic are ISM-1505 and ISM-1894, which require phishing-resistant MFA for human users of data repositories, and ISM-1874, which requires phishing-resistant MFA for customers of online customer services. Read them in the catalog's own wording, not in summaries, and map each one to a named owner in your environment. Remember that the ML3 profile also carries every ML1 and ML2 MFA control forward, so the ML3 scope is cumulative rather than a replacement list.
Before you scope anything, confirm which release you are working from. The ISM OSCAL material is versioned, and the release referenced here is v2026.09.4, dated September 2026. Check the ASD site and the ASD mirror in the ISM OSCAL repository for any newer release, and record the version you assessed against in your scoping document and evidence register. An assessor will ask which version your control mapping reflects, and a mismatch between the catalog you designed against and the one they test can cost time late in the engagement. Also confirm with your assessor or internal audit function how they intend to read the maturity model, since the model describes what must be demonstrated, not a certification that ASD issues.
