ASD ISM 1682 Phishing-resistant multi-factor authentication for human users of systems
What it says
Multi-factor authentication used for authenticating human users of systems is phishing-resistant.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEvery MFA method that people use to sign in to systems must be one that a phishing site or fake login page cannot capture and replay.
Multi-factor authentication (MFA) asks for something more than a password before a person is let in. This control goes one step further: the second factor that human users rely on must be phishing-resistant. That means the authentication cannot be tricked out of the user by a fake login page, a convincing email or a scam phone call, and cannot be relayed by an attacker sitting between the user and the real system. Weaker MFA methods such as SMS codes, emailed codes, one-time codes typed from an app, or "approve this sign-in" push prompts can all be captured or manipulated. An attacker sets up a look-alike login page, the user enters their password and their six-digit code, and the attacker passes both to the real system in real time. Push prompts can be defeated by bombarding the user until they tap approve. Phishing-resistant methods, by contrast, bind the authentication to the genuine service so that a code or approval given to the wrong site is useless. In practice this means FIDO2/WebAuthn security keys, passkeys, smart cards (such as PIV cards) and platform authenticators such as Windows Hello for Business. This matters because most successful account takeovers begin with a phished credential. If the second factor can be phished as easily as the password, MFA gives a false sense of security. The control applies to human users of systems; it does not address authentication of services, devices or automated processes.
Free. Save your status, tasks and notes.
Why it matters
If human users authenticate with MFA that can be phished, an attacker who lures a user to a fake login page or floods them with approval prompts can capture or bypass the second factor and sign in as that user. The result is account takeover, access to the data and systems that user can reach, and the ability to move further into the environment while appearing to be a legitimate person. The organisation may believe it is protected by MFA when in practice the control fails at the exact moment it is needed.
How to implement
The identity and access owner inventories every system where human users sign in and records, for each one, which MFA methods are currently enabled so that non-phishing-resistant methods can be identified and scheduled for removal.
Identity administrators configure the identity provider and each in-scope system to accept only phishing-resistant MFA methods for people, and switch off SMS codes, emailed codes, typed one-time codes and simple push approvals as accepted second factors.
The security team issues phishing-resistant authenticators (FIDO2/WebAuthn security keys, passkeys, smart cards or Windows Hello for Business) to all human users, prioritising privileged and remote users first, and records who has been enrolled so that coverage can be tracked to completion.
The service desk lead rewrites enrolment, lost-authenticator and replacement procedures so that identity is verified and a new phishing-resistant credential is issued, without temporarily re-enabling a phishable method as a stopgap.
The change or onboarding process owner adds a mandatory check to new-system onboarding so that any system with human sign-in is connected to the organisation's phishing-resistant MFA before it goes live, rather than with a vendor default method.
Keep it running
Day to day, this control lives in the identity provider and in the authentication settings of each system that people sign in to. Someone needs to own the list of systems with human sign-in, know which MFA methods each system accepts, and make sure only phishing-resistant methods (FIDO2/WebAuthn security keys, passkeys, smart cards or Windows Hello for Business) are enabled for people.
Watch for drift. New systems are often connected with whatever MFA is easiest, legacy fallback methods (SMS, email codes, push approvals) get left switched on "just in case", and recovery or enrolment flows can quietly allow a weaker method. Service desk processes for lost authenticators and new-starter enrolment need to issue phishing-resistant credentials rather than temporarily falling back to a phishable one.
Users will need practical support: registering their authenticator, understanding what a genuine prompt looks like, and knowing what to do when they lose or replace a device. Expect a stock of replacement authenticators and a documented re-enrolment path so that convenience never becomes a reason to re-enable weaker methods.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the inventory of systems that human users sign in to, along with the MFA methods each system accepts.
Look at
Check that every system with human sign-in is listed and that the accepted methods column shows only phishing-resistant options (FIDO2/WebAuthn security keys, passkeys, smart cards or Windows Hello for Business), with no SMS, email, typed one-time code or push-approval methods remaining enabled.
Good evidence
The inventory is complete, current and shows only phishing-resistant MFA methods enabled for people on every listed system.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see the live authentication method settings in the identity provider and in a sample of systems that are not federated through it.
Look at
Compare the enabled methods on screen against the inventory, paying attention to legacy or fallback methods that are still switched on.
Good evidence
The live configuration matches the inventory and no phishable method can be selected by a human user at sign-in.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the enrolment and lost-authenticator procedures used by the service desk.
Look at
Read the steps that apply when a user starts, loses their authenticator or gets a new device, and check whether any step allows a temporary phishable method.
Good evidence
Procedures verify identity and issue a phishing-resistant authenticator in every case, with no temporary fallback to SMS, email or push approval.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a report of users and the MFA methods registered against each account.
Look at
Look for accounts that still have only a phishable method registered, and for accounts with a phishable method registered alongside a phishing-resistant one that could still be chosen at sign-in.
Good evidence
All human user accounts have a phishing-resistant method registered and no phishable method remains selectable.
- Check 5 of 5What an auditor asks for
Ask for
Ask for recent sign-in logs or authentication reports for a sample of users across different systems.
Look at
Check the authentication method recorded for each successful sign-in and confirm it was a phishing-resistant method rather than a code or push approval.
Good evidence
Sampled sign-ins across systems consistently show phishing-resistant methods in use, with no successful sign-ins using phishable methods.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML2.5, Multi-factor authentication used for system access is phishing-resistant, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.5.
ISM-1682 requires a specific secure authentication outcome: MFA used for system authentication is phishing-resistant. 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 (but is not limited to) phishing-resistant MFA. ISM-1682 is a specific, stronger implementation choice within the broader authentication control required by Annex A 8.5.
ASD Essential Eight: 7 mappings
This control is equivalent to E8-MF-ML2.5.
ISM-1682 requires that MFA used for authenticating human users of systems is phishing-resistant. E8-MF-ML2.5 states the same requirement for users of systems, using essentially the same scope and depth focused on phishing-resistant MFA methods. Implementing either control would largely satisfy the other for system sign-in by human users.
This control is broader than E8-MF-ML1.1.
E8-MF-ML1.1 requires MFA for access to online services that handle the organisation's sensitive data. ISM-1682 requires that MFA used for authenticating users of systems is phishing-resistant, which is a stronger and broader quality requirement that can apply beyond online services and beyond just sensitive-data contexts. Implementing ISM-1682 for relevant online services would satisfy and exceed E8-MF-ML1.1, but E8-MF-ML1.1 alone does not ensure phishing-resistant MFA.
- E8-MF-ML1.4Use multi-factor authentication for online services handling customer dataPartially meets
This control partially meets E8-MF-ML1.4.
ISM-1682 requires that any MFA used by human users to authenticate to systems is phishing-resistant. E8-MF-ML1.4 requires MFA for a particular use case (organisation online customer services handling sensitive customer data) but does not require that the MFA be phishing-resistant. ISM-1682 is therefore a stricter, more specific requirement that would strengthen and partially exceed what E8-MF-ML1.4 asks for.
This control partially overlaps E8-MF-ML2.2.
E8-MF-ML2.2 requires organisations to use MFA to authenticate unprivileged users of systems. ISM-1682 adds a quality requirement by mandating that MFA used for authenticating users of systems is phishing-resistant, which would apply to unprivileged users where MFA is deployed. The primary control does not specify phishing resistance, so ISM-1682 goes deeper on MFA strength while sharing the same authentication use-case.
This control partially overlaps E8-MF-ML2.3.
ISM-1682 requires that MFA used by human users to authenticate to systems is phishing-resistant. E8-MF-ML2.3 aligns by mandating phishing-resistant MFA specifically for users of online services, which is one important subset of system authentication. The ISM-1682 scope is broader because it is not limited to online services and applies to human authentication across systems more generally.
- E8-MF-ML3.2Phishing-resistant multi-factor authentication for online customer servicesPartially overlaps
This control partially overlaps E8-MF-ML3.2.
ISM-1682 requires phishing-resistant MFA for authenticating users of systems. E8-MF-ML3.2 requires phishing-resistant MFA for customers of online customer services, which may be outside typical 'user of systems' workforce authentication depending on interpretation. They align on the phishing-resistant MFA outcome, but E8-MF-ML3.2 is specifically customer-facing and service-specific while ISM-1682 is broader and more general.
This control partially overlaps E8-MF-ML3.3.
ISM-1682 requires phishing-resistant MFA for human users authenticating to systems. E8-MF-ML3.3 applies the same phishing-resistant requirement but narrows it to authentication for data repositories. This overlaps strongly on the phishing-resistance property, while ISM-1682 is broader because it applies to all relevant system sign-ins, not only repositories.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.