ASD ISM 0974 Multi-factor authentication for unprivileged human users of systems
What it says
Multi-factor authentication is used to authenticate unprivileged human users of systems.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery ordinary (non-admin) staff account must prove identity with two or more factors, not just a password, whenever a person signs in to a system.
This control requires that ordinary human users, meaning staff and other people who use systems without administrative or other privileged rights, sign in using multi-factor authentication (MFA). MFA means a person must present more than one type of proof of identity, for example something they know (a password or PIN) together with something they have (a security key, smart card or authenticator app) or something they are (a biometric). The scope is deliberately specific. It covers unprivileged accounts, which are the bulk of an organisation's users, and it covers human users rather than service or machine accounts. Privileged users are addressed by other controls, so this control is about making sure the everyday workforce is not the weak point. It matters because passwords on their own are routinely defeated. They are phished, guessed, reused across sites, exposed in breaches and captured by malware. An attacker who obtains a single staff password can log in as that person, read their email and files, and use that foothold to move further into the environment. Requiring a second factor means a stolen password by itself is not enough, which removes the most common way that adversaries first get in.
Free. Save your status, tasks and notes.
Why it matters
If unprivileged human users can sign in with only a password, any phished, guessed, reused or leaked password gives an attacker direct access to that person's mailbox, files, applications and internal systems. That initial access is then used for business email compromise, data theft, ransomware staging and lateral movement towards privileged accounts. Because these accounts make up most of the user base, the likelihood of at least one being compromised is high, and the organisation would also be unable to demonstrate this ISM control is met.
How to implement
The identity or IT lead should inventory every system that unprivileged human users sign in to (email, file sharing, line-of-business applications, VPN, HR and finance tools) and record for each whether it federates to the central identity provider or manages its own logins.
The identity administrator should configure the identity provider (for example Microsoft Entra ID, Okta or Google Workspace) with a policy that requires multi-factor authentication for all unprivileged human user accounts, applying it to the group or role that contains those users rather than to individuals.
The IT team should connect standalone systems that cannot federate to the identity provider by enabling that system's native MFA option, or by placing it behind an MFA-enforcing gateway or single sign-on portal, so that no system used by unprivileged staff accepts a password alone.
The service desk should build MFA enrolment into the user onboarding procedure, issuing or registering the second factor (authenticator app, hardware security key or smart card) before the person receives their credentials, and document a verified-identity process for re-enrolment after a lost or replaced device.
The identity administrator should exclude non-human accounts (service accounts, automation identities) from the human-user MFA policy only where they are properly classified as such, and run a periodic report of unprivileged human accounts with no registered factor or with a policy exclusion so they can be fixed.
Keep it running
Day to day, this control lives in the identity platform and the onboarding process. Every new unprivileged user account should have MFA enrolled before or at first sign-in, and any account that somehow lacks a registered factor should be treated as an exception to fix, not a convenience to leave alone.
Expect a steady trickle of operational work: replacing lost or broken tokens and phones, re-enrolling users who change devices, handling temporary access codes for people locked out, and removing factors when someone leaves. Keep the enrolment and recovery paths controlled so that the MFA reset process does not become the easy way around MFA.
Systems that are integrated with the central identity provider inherit the policy automatically. Standalone or legacy systems with their own logins are where gaps usually appear, so maintain a list of systems used by unprivileged staff and confirm each one either federates to the MFA-enforcing identity provider or enforces MFA itself. Watch conditional access or policy reports for accounts that are excluded from MFA requirements and review why.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the identity provider's authentication policy or conditional access configuration that applies to unprivileged human users.
Look at
Check which users or groups the policy targets, that MFA is set to required rather than optional, and whether any exclusions exist.
Good evidence
A policy requiring MFA covers all unprivileged human user accounts, and any exclusions are limited to documented non-human accounts.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export of user accounts showing MFA registration status for each unprivileged human user.
Look at
Compare the list of active unprivileged human accounts against those with at least one registered factor and identify any without.
Good evidence
Every active unprivileged human user has a registered second factor, and any account without one is a known exception with a remediation date.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the list of systems used by unprivileged staff and how each one enforces MFA.
Look at
Check that every system either federates to the MFA-enforcing identity provider or has native MFA enabled, and probe any legacy or standalone applications.
Good evidence
No system in scope accepts a password alone for unprivileged human sign-in, and the list is current.
- Check 4 of 5What an auditor asks for
Ask for
Ask for sign-in logs for a sample of unprivileged users over a recent period.
Look at
Confirm that successful sign-ins record a second factor being satisfied, and look for single-factor successes.
Good evidence
Sampled successful sign-ins consistently show MFA was completed, with any single-factor successes explained and remediated.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the onboarding and MFA re-enrolment procedures used by the service desk.
Look at
Check that MFA enrolment happens at onboarding and that re-enrolment after a lost device requires identity verification rather than a simple reset on request.
Good evidence
Procedures are documented, followed in sampled tickets, and do not allow MFA to be bypassed through the reset process.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML2.2, Use multi-factor authentication for unprivileged user access, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control partially meets A.8.5.
ISM-0974 requires a specific secure authentication mechanism (MFA) for unprivileged human users of systems. ISO/IEC 27001:2022 Annex A 8.5 requires implementing secure authentication technologies and procedures based on access restrictions and access control policy, which can include MFA among other measures. ISM-0974 is a concrete, prescriptive instance within the broader authentication control set described by Annex A 8.5.
This control supports A.5.17.
ISM-0974 requires MFA for unprivileged human users of systems, which relies on managing authenticators such as tokens, device-bound keys, or OTP seeds. ISO/IEC 27001:2022 Annex A 5.17 addresses the controlled allocation and management of authentication information and user handling guidance, supporting the secure operation of MFA required by ISM-0974. ISM-0974 mandates using MFA, while Annex A 5.17 governs how the underlying authentication information is issued, protected, and managed.
ASD Essential Eight: 5 mappings
This control is equivalent to E8-MF-ML2.2.
ISM-0974 requires multi-factor authentication (MFA) to be used to authenticate unprivileged human users of systems. E8-MF-ML2.2 requires MFA for unprivileged users of systems, matching the same user type (unprivileged) and the same authentication objective (system access). Neither control, as stated, adds additional conditions such as phishing-resistance or logging, so the scope and depth are substantially aligned.
This control is broader than E8-MF-ML1.7.
E8-MF-ML1.7 specifies the acceptable construction of MFA using two distinct factors or a device unlocked by knowledge/biometrics. ISM-0974 mandates MFA for unprivileged users of systems, which would typically be implemented using the factor combinations described in E8-MF-ML1.7. ISM-0974 is narrower because it focuses on applying MFA to a particular user group, not on defining factor combinations.
This control partially meets E8-MF-ML2.5.
ISM-0974 requires MFA for unprivileged human users when authenticating to systems. E8-MF-ML2.5 also addresses MFA for authenticating users of systems, but further constrains the required MFA to be phishing-resistant. As a result, ISM-0974 is a subset of E8-MF-ML2.5 because it does not, by itself, require phishing-resistant MFA.
- E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataPartially overlaps
This control partially overlaps E8-MF-ML1.5.
E8-MF-ML1.5 mandates MFA for access to third-party online customer services with sensitive data. ISM-0974 requires MFA for unprivileged users, possibly including third-party service accounts. They overlap on MFA application to limit credential compromise impacts, yet differ in user privilege scope versus service/data context.
- E8-MF-ML3.1Multi-factor authentication is used to authenticate users of data repositoriesPartially overlaps
This control partially overlaps E8-MF-ML3.1.
E8-MF-ML3.1 requires MFA for users accessing data repositories. ISM-0974 requires MFA for unprivileged users of systems, which may include unprivileged access paths to repository platforms or supporting systems. The overlap is that both drive MFA for user authentication, but E8-MF-ML3.1 is asset-specific (repositories) while ISM-0974 is user-class/system-wide and not repository-specific.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.