ASD ISM 1872 Phishing-resistant multi-factor authentication for human users of online services
What it says
Multi-factor authentication used for authenticating human users of online services is phishing-resistant.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhen people sign in to online services, the second factor must be one a fake login page cannot capture or replay, so a tricked user still cannot be impersonated.
This control says that where an organisation uses multi-factor authentication (MFA) for people signing in to online services, the MFA method itself must be resistant to phishing. It applies to human users (not service accounts or machine-to-machine connections) and to online services, meaning things people reach over a network such as web portals, cloud applications and remote access. Not all MFA is equal. A one-time code typed into a web page, an SMS code, or a push prompt can all be defeated by a convincing fake login page: the attacker captures the password and the code, or nudges the user into approving a push, and then logs in as that person. Phishing-resistant MFA closes that gap. The authentication is cryptographically bound to the genuine service, so a look-alike site cannot obtain anything useful, and there is no code for the user to be talked into handing over. Passkeys and FIDO2 security keys, and smart-card or certificate-based logins, are common examples of methods that meet this bar. It matters because phishing remains one of the most common ways attackers get their first foothold. Users will always be tricked sometimes, and awareness training only lowers the rate. Phishing-resistant MFA is designed so that even a user who is fooled does not hand the attacker a working session.
Free. Save your status, tasks and notes.
Why it matters
If MFA for people signing in to online services is not phishing-resistant, an attacker who lures a user to a convincing fake login page can capture the password and the code, or trigger a push approval, and take over the account in real time. That gives them the user's email, files, cloud applications and remote access, from which they can steal data, move to other systems, commit payment fraud or launch further phishing from a trusted account. The organisation may believe it is protected because "MFA is on" while its most-targeted accounts remain exposed to a routine attack technique.
How to implement
The identity or security lead builds an inventory of online services that human users sign in to (identity provider, email and collaboration suites, cloud applications, remote access, admin portals) and records for each whether phishing-resistant MFA is supported and enforced.
Identity administrators configure the identity provider's authentication policies so that human accounts must use a phishing-resistant method (for example passkeys, FIDO2 security keys or certificate-based authentication) and disable SMS, voice, emailed codes, one-time-password apps and plain push as accepted factors for those services.
The IT service desk issues each user a phishing-resistant credential during onboarding and runs a staged migration for existing users, starting with privileged and high-value accounts, with a cut-off date after which the older methods are removed from their accounts.
Service owners route online services through the central identity provider using federation or single sign-on so the phishing-resistant requirement is enforced consistently, and raise a remediation or replacement plan for any service whose local login cannot support it.
The service desk lead defines and documents a recovery and re-enrolment process for lost or broken authenticators that verifies the person's identity through a controlled method and issues a new phishing-resistant credential rather than a temporary phishable code.
Keep it running
Day to day this control lives in the identity provider and in the sign-in policies of each online service. Someone needs to own the list of online services used by staff and know, for each one, which MFA methods are permitted for human accounts and whether any weaker methods (SMS, voice, emailed codes, one-time-password apps, plain push) are still allowed as a fallback, because a fallback that phishing can defeat undermines the control even if a strong method is also registered.
Joiners need a phishing-resistant credential issued at onboarding, and leavers or lost-device cases need a secure recovery and re-enrolment path that does not quietly drop back to a phishable method. New online services should be checked before go-live for whether they support phishing-resistant authentication, ideally through the organisation's central identity provider rather than local logins. Sign-in and configuration logs should be reviewed periodically for accounts authenticating with non-compliant methods and for policy changes that loosen the requirement.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the authentication policy or standard that states which MFA methods human users may use for online services.
Look at
Check whether it explicitly requires phishing-resistant methods and names the weaker methods that are not permitted, and whether it covers all online services rather than just the main identity provider.
Good evidence
A current, approved document that requires phishing-resistant MFA for human users of online services, lists acceptable and prohibited methods, and applies to every in-scope service.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export or screenshots of the identity provider's authentication method and conditional access settings.
Look at
Look at which methods are enabled for human accounts and whether any policy still accepts SMS, voice, emailed codes, one-time-password apps or plain push, including as a fallback or exception.
Good evidence
Only phishing-resistant methods are enabled for human users, with fallback options disabled and any exceptions time-limited, documented and approved.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a report of registered authentication methods per user, and recent sign-in logs showing the method used.
Look at
Compare how many human users have a phishing-resistant method registered against how many actually authenticated with one, and look for successful sign-ins using weaker methods.
Good evidence
All or nearly all human users hold and use a phishing-resistant method, and any sign-ins with weaker methods are explained by an approved exception with a closure date.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the inventory of online services that people sign in to and how each one authenticates users.
Look at
Check whether every service is federated to the identity provider enforcing phishing-resistant MFA, and for any with a separate local login, what MFA method is used there.
Good evidence
Each online service either inherits the enforced policy through single sign-on or enforces phishing-resistant MFA locally, with any gaps tracked in a remediation plan.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the onboarding, lost-authenticator and recovery procedures, plus a sample of recent recovery tickets.
Look at
Look at how a user proves who they are when they lose their authenticator and what credential they are issued afterwards, and whether the tickets show a temporary phishable method was granted.
Good evidence
Recovery verifies identity through a controlled process and re-issues a phishing-resistant credential; tickets show no lasting fallback to codes or push.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML2.3, Multi-factor authentication online services must be phishing-resistant, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.5.
ISM-1872 requires a specific authentication outcome: MFA for online services must be phishing-resistant for human users. ISO/IEC 27001:2022 Annex A 8.5 requires secure authentication technologies and procedures based on access restrictions and access control policy, which can include phishing-resistant MFA as an implementation choice. ISM-1872 is a specific, prescriptive subset of the broader secure-authentication requirement in Annex A 8.5.
ASD Essential Eight: 7 mappings
This control is equivalent to E8-MF-ML2.3.
ISM-1872 requires that multi-factor authentication (MFA) for human users of online services is phishing-resistant so credentials or factors cannot be captured and replayed by fake login pages. E8-MF-ML2.3 states the same requirement for MFA used to authenticate users of online services to be phishing-resistant. Both controls align in scope (online services, human users) and depth (explicit phishing-resistance property).
This control is broader than E8-MF-ML3.2.
ISM-1872 requires that multi-factor authentication (MFA) used to authenticate users of online services is phishing-resistant. E8-MF-ML3.2 applies the same phishing-resistant MFA requirement but only for customers of online customer services. E8-MF-ML3.2 is therefore a subset of ISM-1872 because it narrows the user population to customers and the service type to customer services.
- E8-MF-ML1.7Multi-factor authentication combines two factors like a device and a PINPartially overlaps
This control partially overlaps E8-MF-ML1.7.
ISM-1872 requires the use of phishing-resistant multi-factor authentication for online services. E8-MF-ML1.7 defines acceptable factor combinations for MFA (e.g. something users have plus something users know/are), which supports consistent MFA design and deployment. However, E8-MF-ML1.7 does not ensure phishing resistance (e.g. it does not distinguish between phishable OTP and phishing-resistant methods), so it is supportive rather than equivalent.
- E8-MF-ML2.5Multi-factor authentication used for system access is phishing-resistantPartially overlaps
This control partially overlaps E8-MF-ML2.5.
ISM-1872 requires phishing-resistant MFA for human users of online services to prevent capture/replay via phishing. E8-MF-ML2.5 requires phishing-resistant MFA for authenticating users of systems, which can include but is not limited to online services. The overlap is the phishing-resistance requirement, but E8-MF-ML2.5 is broader in target environments (systems generally), while ISM-1872 is narrower to online services.
This control partially overlaps E8-MF-ML3.3.
ISM-1872 requires phishing-resistant MFA for human users authenticating to online services. E8-MF-ML3.3 also mandates phishing-resistant MFA, but it is scoped specifically to data repositories rather than all online services. They overlap where data repositories are accessed via online services, but each control has different primary scope boundaries (online services broadly vs data repositories specifically).
This control depends on E8-MF-ML1.1.
E8-MF-ML1.1 requires MFA for users accessing the organisation's online services that handle sensitive organisational data. ISM-1872 strengthens this by requiring the MFA used for authenticating users of online services to be phishing-resistant, reducing the likelihood of credential theft bypassing MFA. ISM-1872 is a quality/strength requirement for MFA rather than a baseline requirement to deploy MFA everywhere in scope.
This control depends on E8-MF-ML3.1.
E8-MF-ML3.1 requires MFA for users of data repositories. ISM-1872 requires that MFA used for authenticating users of online services is phishing-resistant, strengthening the assurance of MFA where repositories are accessed via online service interfaces. ISM-1872 adds a quality/strength requirement (phishing resistance) that is not explicit in E8-MF-ML3.1, so it supports rather than duplicates it.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.