MFA maturity level 1: Essential Eight requirements and evidence

What Essential Eight MFA at maturity level 1 asks for

At Maturity Level One, the Essential Eight asks for multi-factor authentication in three places: staff logging in to the organisation's own online services and to third-party online services that hold sensitive data, customers logging in to online services that hold sensitive customer data, and login methods that combine two different kinds of factor. If you are preparing an assessment or a customer has asked for ML1 evidence, start by listing every online service your staff and customers use and marking which ones process, store or communicate sensitive data. That list determines the scope of the MFA evidence you will need.

The ISM controls behind this level are ISM-1504 and ISM-1679 for staff on own and third-party services holding sensitive data, ISM-1680 for third-party services holding non-sensitive data where MFA is available, ISM-1892 and ISM-1893 for staff accessing customer services holding sensitive customer data, and ISM-1681 for customers. ISM-1401 defines an accepted combination: something people have, such as a device or token, paired with something they know, or a factor that is unlocked by something they know or are. A password plus an SMS code qualifies, while two passwords do not. Confirm each control's exact wording against the ISM OSCAL catalog rather than relying on a summary, since assessors test the source text.

ML1 is a baseline because stolen passwords are the most common route to an account, and MFA stops a single leaked credential from granting access. The practical difficulty is coverage, not design. Legacy applications may not support a second factor at all, single sign-on may protect some applications while others still accept local passwords, and third-party accounts such as vendor portals, shared mailboxes or SaaS tools are often created outside central identity management. Build an inventory of login paths, then check each one against the scope above. Where an identity platform such as authentik or Keycloak fronts an application, confirm that the application cannot be reached without passing through it.

Which services and users fall inside ML1 MFA scope

Maturity Level One MFA scope turns on two questions: which online services handle sensitive data, and which users reach them. The cards below cover the decisions an assessor will expect you to have made and documented before you test a single login.

Own online services holding sensitive data

Start with the organisation's own online services that process, store or communicate sensitive data, including web portals, file sharing sites and internal web applications reachable over the internet. Staff must authenticate with MFA to each of them. Check the service inventory against the classification register, because a service that was never listed is usually the one that goes unchecked. Record the owner and the data class for each service.

Third-party services handling sensitive data

Cloud email, collaboration tools, payroll and customer relationship platforms that process, store or communicate sensitive data fall under the same requirement, even though the organisation does not operate them. Staff accounts on these services need MFA enabled by the organisation through configuration or contract. Ask each provider which MFA methods it supports and whether administrators can enforce them for all users.

Third-party services holding non-sensitive data

For third-party services that hold only non-sensitive data, the requirement applies where the service offers MFA. Where it does not, the gap should be recorded with a reason and a compensating measure, not silently accepted. This decision is easy to overlook because the data looks harmless. Review it whenever a service begins holding sensitive data, since the scope then changes.

Online customer services with sensitive data

Customer-facing services that hold sensitive customer data require customers to authenticate with MFA. Staff access to the administrative side of those same services is a separate requirement that also applies. Confirm which customer portals, mobile back ends and account management pages meet the sensitive data threshold, and document the customer populations each one serves.

The sensitive-data classification decision

The classification of what counts as sensitive data determines almost every scope boundary on this page, so the definition and its owner must be written down. An assessor will ask who approved the classification, which data types it covers and how a service is assigned to a class. Without a documented decision, the scope cannot be defended, and two teams can reach opposite conclusions about the same portal.

How an assessor tests ML1 MFA

This table shows how an assessor typically tests each ML1 MFA requirement, from sampling in-scope services to reviewing configuration exports. Read it as a checklist of what to prepare before an assessment, and note that the assessor's own procedures and sample sizes govern the actual test.

Requirement	What the assessor checks	Evidence usually requested	Where it commonly fails
ISM-1504 (staff, own and third-party services with sensitive data)	Samples in-scope online services that process, store or communicate sensitive data and confirms a login prompt for a second factor is enforced	Service inventory marked by data sensitivity, login configuration exports, test login records	Service is listed as in scope but MFA is configured as optional or applies only to a subset of users
ISM-1679 (staff, third-party services with sensitive data)	Confirms third-party services used for sensitive data are covered, not only internally hosted applications	Third-party service list, identity provider settings or vendor admin screenshots, contract or access records	SaaS tools adopted by business units without central identity integration or MFA enforcement
ISM-1680 (third-party services with non-sensitive data)	Checks MFA is applied where the third-party service offers it, and that exceptions are recorded	Feature availability notes, enablement records, documented exceptions with reasons	MFA available in the vendor product but never switched on, with no record of why
ISM-1892 and ISM-1893 (staff, customer services with sensitive customer data)	Confirms staff MFA for online customer services holding sensitive customer data, and for the organisation's own services used to manage them	Customer service inventory, staff login configuration, admin console settings	Admin portals for customer services excluded from MFA because they sit outside the main identity provider
ISM-1681 (customers of online customer services)	Tests that customers are prompted for a second factor at login to services holding sensitive customer data, and that the option is not merely offered	Customer login flow configuration, test accounts showing the second-factor step, enrolment settings	MFA offered at enrolment but skipped at login, or enforced for some customer segments only
ISM-1401 (acceptable factor combinations)	Checks each enabled method combines something people have with something they know, or uses a device unlocked by a knowledge or biometric factor	Enabled factor list per service, enrolment policy, recovery code handling	SMS or email codes paired with a password reset path that bypasses the second factor
Enrolment and exception records	Reviews how users enrol, how exceptions are approved and whether they expire	Enrolment logs, exception register with approver and review date, offboarding records	Standing exceptions with no owner, or enrolled devices of leavers still accepted
Configuration exports	Compares exported policies against the claimed state for each in-scope service	Dated exports or screenshots from the identity platform and each in-scope service	Exports taken from a test tenant or an out-of-date version of the configuration

Testing the factor combination rule

The ML1 rule asks for two different kinds of proof combined: something a person has, such as a device or token, together with something they know, such as a password or PIN, or a factor that is unlocked by something they know or are. An assessor tests the combination, not the number of prompts. Two password screens, or a password followed by a security question, do not meet the rule, and a single prompt that asks for two things from the same category does not either. The practical test is to walk through a real sign-in for a staff member on a sensitive service and record which factor categories were presented, then confirm the same holds for every path to that service, including fallback and recovery routes.

SMS and email codes are the most common second factors and the most frequent source of disagreement. A code sent to a phone or inbox is generally treated as something the person has, and it can satisfy the rule when paired with a password. The weakness is shared channels. If the mailbox that receives the email code is the same one that resets the password, or the password and the code both arrive through the same identity provider session, the second factor adds little and an assessor may decide the factors are not independent. Confirm with your assessor, in writing, which channels and recovery paths they will accept for each service in scope, since acceptance depends on your architecture rather than on a fixed list.

The ML1 rule is the starting point for the phishing-resistant requirements at ML2 and ML3, which turn on whether a factor can be captured and replayed by a fake sign-in page. Codes typed into a form are the factors most exposed to that attack, so an ML1 design built on codes is a sound baseline but not the end state. Ask your identity platform team which second factors are enrolled today, whether hardware or platform-bound credentials are available for privileged users, and how recovery works, because those answers determine how much work the later levels will require. Check the current wording of the ISM controls with the assessor and the ASD maturity model before scoping.

Sequencing an ML1 MFA rollout

This sequence moves an organization from an unclear picture of which services hold sensitive data to a set of MFA configurations, enrolled users and evidence that an assessor can test against the Maturity Level One requirements. Each step produces a named artefact that the next step depends on.

Classify services by data sensitivity
Start by deciding which online services process, store or communicate sensitive data, and which customer services hold sensitive customer data. Involve the data owners, not only IT, because they know what the data is and which classification rules apply. The output is a classification register that records each service, the data it handles, and the sensitivity decision with a named owner. The step is done when every service has a sensitivity decision and someone can explain how that decision was reached.
Build the in-scope service inventory
Turn the classification register into an inventory of the staff-facing and customer-facing online services in scope, including third-party services that hold the organization's sensitive data. Record the login method, the identity source and whether each service supports MFA natively. Ask vendors to confirm MFA capability in writing where documentation is unclear. The output is the in-scope service inventory, and the step is complete when every in-scope service has an entry with an identified login path.
Choose the identity layer
Decide whether services will authenticate through a central identity provider or through individual application logins. Central single sign-on makes it easier to enforce MFA consistently, while direct logins require MFA settings in each application. Open-source options such as authentik, FreeIPA and Keycloak differ in how they handle second factors and federation, so confirm each candidate against the inventory from the previous step. The output is a configuration baseline that names the identity layer, the accepted second factor types and the services that will be brokered through it.
Enforce MFA per service
Configure MFA for each in-scope service against the baseline, starting with staff access to services holding sensitive data and then customer-facing services holding sensitive customer data. For each service, confirm that the combined factors meet the requirement that a factor the person has is combined with one they know, or is unlocked by something they know or are. Test a login from a clean session to show the second factor is actually challenged. The output is a per-service configuration record with a test result, and the step is complete when no in-scope service accepts a password alone.
Enrol users and handle recovery
Enrol staff and, where the customer model allows, customers into their chosen second factors, and define how lost devices and locked accounts are recovered. Recovery is where MFA is most often weakened, so the process should verify identity before issuing any reset and should not bypass the second factor by default. Record who was enrolled, when, and through which method. The output is an enrolment report with exceptions, and the step is complete when every in-scope user is either enrolled or listed as an exception with an owner.
Capture evidence and maintain the exception register
Gather the artefacts an assessor will ask for: the classification register, the in-scope service inventory, the configuration baseline, per-service test results, the enrolment report and the exception register. Each exception should record the service, the reason MFA is not yet enforced, the compensating control, the approver and a review date. Keep the evidence under change control so it reflects the current state. The output is an evidence pack that an internal reviewer can walk through from classification to enforcement, and the step is complete when the exception register has no entry without an owner.

Evidence that passes an ML1 MFA assessment

An assessor testing MFA at Maturity Level One wants proof on two fronts: that the right services are covered and that the controls are enforced in practice. The cards below cover the artifacts that connect the service inventory to enforcement settings, enrolment records, exceptions and third-party contracts. Each one needs a named owner and a recurring refresh so the evidence still matches the environment when the assessor arrives.

Sensitive-data service inventory

This is the scoping document everything else depends on. It lists every staff-facing and customer-facing online service, the third-party services that process, store or communicate the organisation's sensitive data, and the data classification that puts each one in scope. Record the owner and the data type for each row. Refresh it on a schedule and whenever a new SaaS tool is approved, because an unlisted service is the most common reason MFA coverage fails review.

MFA enforcement configuration export

For each in-scope service, keep an export or screenshot of the setting that forces MFA on for every account, not only for administrators. Identity platforms such as authentik can be checked through their configured authenticator validation stage in a flow. Export the configuration on a scheduled basis and store it with a timestamp so you can show what was enforced on a given date. Check that conditional or bypass rules do not silently remove the requirement for some user groups.

Enrolment and factor-type reports

Enforcement shows the policy exists, while enrolment reports show it works. Produce a report listing each user, the factor types enrolled, and the date of enrolment, then reconcile it against the active directory. Accounts without any second factor are the gaps an assessor will sample. Record which factor combinations are in use, such as a TOTP app plus a password, so you can show they meet the requirement to combine something people have with something they know.

Documented exceptions with approvals

Some services cannot enforce MFA today, such as legacy applications or devices without second-factor support. Each exception needs a written justification, a named risk owner's approval, a compensating control, and an expiry date. Store exceptions in the same register as the inventory so they stay visible. An undocumented exception reads as a control failure, while a dated, approved one shows the organisation is managing the gap.

Third-party service contracts and configuration evidence

For SaaS providers that hold sensitive data, MFA is still required, but the organisation may not control the settings. Keep the contract clauses or security documentation that show the provider supports and requires MFA, plus a configuration screenshot taken from the tenant admin console. Request updated documentation at each contract renewal. Where a provider cannot enforce MFA for all users, the exception process above applies.

Self-hosted identity options for ML1 MFA

authentik is best considered as a central authenticator that sits in the login flow and checks the second factor an enrolled user presents. Its authenticator validation stage supports the factor types most organizations need at ML1, so one place can govern how staff and customers prove who they are.

Factor coverage: The validation stage checks TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes.
Enrollment control: Administrators decide which factors a user may enroll and which fallbacks, such as recovery codes, remain available.
Migration case: An organization moving off a legacy login form can place authentik in front of existing applications and enforce a second factor before access is granted.
Evidence: Login events and enrollment records give an assessor a single trail to test against the MFA controls.

Confirm with your own environment whether authentik's chosen factors meet your ML1 combination requirement, how recovery codes are issued and stored, and whether SMS or email codes are acceptable for your sensitive data services.

What ML1 MFA costs in money and effort

This table separates the cost components of meeting Maturity Level One MFA into one-time work and recurring work, and names who is paid for each. Read it to see where license spend can be removed by self-hosting and where operating effort remains. No prices are stated because none are supplied for this topic; ask for them in a written quote.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it up or down
Identity platform licenses or hosting	Vendor for commercial identity products; cloud or data center provider for self-hosted infrastructure	Recurring for licenses and hosting; one-time for initial build	Number of users and applications; self-hosting removes per-user license fees but keeps hosting and patching costs
Integration of applications and third-party services	Internal engineers or an implementation partner	One-time, with ongoing work when new services are added	Number of applications and third-party online services holding sensitive data; legacy systems that cannot delegate login
Migration of existing accounts and second factors	Internal identity team, often with a partner	One-time	Size of the directory, number of enrolled authenticators, and whether a RADIUS or legacy OTP server must be proxied during cutover
User enrolment and help-desk support	Internal service desk staff	Enrolment is one-time per user; lost-device and reset requests recur	Staff count, number of factor types offered, and clarity of self-service recovery steps
Customer-facing MFA support	Internal product and support teams	Recurring	Number of customer services holding sensitive customer data and volume of account recovery requests
Evidence upkeep	Internal compliance or security staff	Recurring	Frequency of configuration reviews, how many services must be shown, and whether logs and screenshots are collected automatically
External review and auditor sampling	Independent assessor or auditor, fees set by their engagement terms	Recurring at each assessment cycle	Number of in-scope systems, sample sizes the assessor selects, and how cleanly evidence is organized beforehand
Operating effort for self-hosted platforms	Internal platform or security engineers, or a retained support provider	Recurring	Upgrade frequency, certificate and key management, availability requirements, and staff familiarity with the platform

Where ML1 MFA programs usually fall short

Most ML1 MFA gaps are not missing technology. They are scope decisions that were never written down, enforced or evidenced. The cards below cover the six gaps assessors most often find, paired with the step that closes each one.

MFA enforced only for administrators

Many organisations turn on MFA for domain and cloud administrators and assume the rest of staff are covered. ML1 asks for MFA on staff access to the organisation's own and third-party online services that hold sensitive data, so administrator-only enforcement leaves most of the population outside the requirement. Check the identity provider's conditional access or policy export against the list of services that process sensitive data, and confirm that standard user accounts are in the enforced group.

Unmanaged SaaS with password-only logins

Staff often sign up to third-party SaaS tools with a work email and a local password, outside the single sign-on catalogue. Those services can hold sensitive data while sitting entirely outside the MFA policy. Build an inventory from identity provider logs, expense records and browser management data, then either route each service through single sign-on with MFA enforced or record it as in scope for a documented exception.

MFA offered but not enforced for customers

Customer portals frequently offer MFA as an optional setting that few customers enable. ML1 requires customer authentication to online services holding sensitive customer data, so an opt-in setting does not meet the requirement on its own. Review the authentication flow in the customer service itself, not the marketing description, and confirm that the sign-in path cannot complete with a password alone for sensitive accounts.

SMS-only factors without justification

SMS codes are the easiest second factor to deploy, so they often become the only factor in the environment. The ML1 requirement is a combination of factors, and an SMS code alone is a single possession-based factor that also depends on the carrier. Where SMS remains, record why it was chosen and what stronger option was considered, and check that the authenticator setup offers TOTP or a hardware token as an alternative for the same users.

Undocumented MFA exceptions

Service accounts, legacy protocols, kiosks and executives often get exempted during rollout and the exemption is never recorded. Each exception quietly becomes a sign-in path that bypasses the control. Keep a register that names the account or service, the owner, the reason, the compensating control, and the review date. Ask the team to produce the register on request, and reconcile it against the identity provider's exclusion groups.

No evidence of sensitive data classification

The MFA scope depends on which services hold sensitive data, yet many organisations cannot show how that decision was made. Without a classification record, an assessor cannot confirm that the right services were included, and the team cannot defend exclusions. Maintain a short classification register that maps each online service to its data category and owner, and tie each MFA policy decision back to a register entry so the scope is traceable.

Who does what for ML1 MFA

The organisation owns its Essential Eight posture. That means deciding which online services hold sensitive data, which customer services hold sensitive customer data, and which factor combinations are acceptable for each group. These classification and enforcement decisions sit with management and the security function, and they cannot be delegated to a partner or a tool. The organisation also writes the user-facing MFA policy, including enrolment rules, recovery handling and what happens when a user loses a second factor.

Data classification: Decide which systems and third-party services process, store or communicate sensitive data, and record the reasoning.
Enforcement decisions: Choose where MFA is enforced for staff and customers, and whether any exception is approved in writing with an owner and an expiry.
User policy: Set rules for enrolment, approved authenticator types, lost-device handling and help-desk identity checks.
Third-party contracts: Confirm that vendor agreements allow MFA configuration and provide access to logs or attestations.
Ongoing ownership: Keep the register of in-scope services current as applications are added or retired.

Confirm with your own assessor which decisions they expect to see documented and signed by a named role.

Questions buyers ask about ML1 MFA

How much effort does Maturity Level One MFA take?

The effort depends mostly on how many systems and online services are in scope, how many user populations need MFA, and how much of the identity landscape already supports a second factor. ML1 asks for MFA for staff on the organisation's own and third-party online services that hold sensitive data, for staff on online customer services holding sensitive customer data, and for customers of sensitive customer services. Each of these adds configuration work, user enrolment, help desk procedures and testing. An organisation with a single identity provider and modern single sign-on will spend far less time than one with separate logins for each application. Ask your team to inventory every online service that touches sensitive data before estimating effort, because that inventory usually sets the scope.

Can our own team implement ML1 MFA without a partner?

Often yes, if the team has identity administration skills and enough capacity to finish the work and gather evidence. Many organisations configure second factors on their identity platform and enforce them for applications in-house. The work becomes harder when the team must document scope, roll out enrolment to users, cover third-party services that do not accept central sign-on, and assemble evidence that an independent assessor can test. A partner can help with those tasks, but the organisation still owns its controls, its risk decisions and its sign-off. Be realistic about your bandwidth during the rollout period, since user support tickets rise sharply when enrolment starts.

What does an implementation partner typically do for ML1 MFA?

A partner typically prepares the systems and the evidence, while the organisation keeps ownership of the control. Common work includes:

Confirming the scope of online services and user populations against the ML1 requirements
Deploying or configuring an identity provider that supports second factors such as TOTP, WebAuthn or passkeys, and SMS or email codes where they are accepted
Connecting applications to single sign-on and testing that MFA cannot be bypassed
Writing enrolment and recovery procedures, and training help desk staff
Producing configuration exports, test records and an evidence map for the assessor

DeployOpen plans, implements and documents self-hosted open-source platforms in the client's own infrastructure, and prepares evidence for compliance assessments. It does not issue assessment reports or certifications. An independent assessor performs that role.

How long does ML1 MFA take to implement?

Duration depends on scope drivers rather than a standard period. The main drivers are the number of applications that need central sign-on, whether third-party services support federation, how many user populations must enrol, and how much existing identity infrastructure you can reuse. Integrations with legacy applications that cannot use modern protocols often take the longest, and staged user rollouts add time because enrolment has to be managed. Ask any provider to break the timeline into identity platform setup, application onboarding, user enrolment and evidence preparation, so you can see which driver dominates. No duration in this page is a guaranteed figure. Confirm the timeline against your own environment before committing budget.

Do SMS codes satisfy ML1 MFA requirements?

SMS codes can form one factor, but the requirement is about combining factors, not about any single method. ML1 accepts MFA that combines something people have with something they know, or something people have that is unlocked by something they know or are. A code sent by SMS relies on a phone the user possesses, and it is typically paired with a password, which the user knows. Whether a specific SMS implementation is acceptable should be confirmed with your assessor and against the ISM controls for MFA, because SMS delivery carries known weaknesses such as SIM swapping and interception. Authenticator apps, security keys and passkeys are generally stronger choices, and open-source platforms such as authentik can validate TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Choosing which factors to enable is an organisational decision.

What should we ask for in a written quote for ML1 MFA?

Ask for a quote that lists scope in writing, so cost follows from what is included. Request the list of in-scope services and user populations, the identity platform and factors to be configured, and the number of applications to onboard. Ask which items are one-time work, such as design, configuration and migration, and which recur, such as licences, hosting, support and periodic review. Confirm who prepares the evidence, who reviews it, and which deliverables you receive at the end. Ask what is excluded, including third-party services you manage yourself, hardware tokens and user support after go-live. Check whether the quote states a timeline and the assumptions behind it. A fixed-scope agreement, which is the usual model for DeployOpen engagements, makes these terms easier to compare across providers.

How DeployOpen prepares ML1 MFA evidence

DeployOpen plans and implements self-hosted open-source identity platforms inside your own infrastructure, so MFA for staff and customers is configured and documented on systems you control. We prepare the systems and evidence for your assessment, while your organization owns its controls and an independent assessor reaches the conclusions.

How we scope

Engagements are fixed-scope, with the list of ML1 MFA services and user groups agreed in writing first.
The written scope names which staff and customer services hold sensitive data and need MFA.
Scope also records third-party online services and whether each is in scope for MFA enrollment.

How we build

We configure second-factor enrollment and validation for staff and customer logins in your environment.
Login flows combine a knowledge factor with a possession factor, such as an authenticator app or security key.
We test enrollment, recovery and failed-login paths against the agreed scope before handover.

How we hand over

You receive configuration records, the scope register and test results mapped to each ML1 MFA control.
Documentation explains how enrollment, recovery and account lockout work, so your staff can operate them.
You confirm with your assessor which evidence formats they accept before the assessment begins.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover re-testing when new online services or third-party providers join the MFA scope.
Ask any provider to confirm in writing who maintains the evidence between assessment cycles.