ASD ISM 1682Phishing-resistant multi-factor authentication for human users of systems
Official control statement
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.
In plain English
Every 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.
What this means in practice
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.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
ML2, ML3
Guideline
Guidelines for system accessTopic
Multi-factor authentication
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the inventory of systems that human users sign in to, along with the MFA methods each system accepts.Look atCheck 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.GoodThe inventory is complete, current and shows only phishing-resistant MFA methods enabled for people on every listed system.
- AskAsk to see the live authentication method settings in the identity provider and in a sample of systems that are not federated through it.Look atCompare the enabled methods on screen against the inventory, paying attention to legacy or fallback methods that are still switched on.GoodThe live configuration matches the inventory and no phishable method can be selected by a human user at sign-in.
- AskAsk for the enrolment and lost-authenticator procedures used by the service desk.Look atRead 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.GoodProcedures verify identity and issue a phishing-resistant authenticator in every case, with no temporary fallback to SMS, email or push approval.
- AskAsk for a report of users and the MFA methods registered against each account.Look atLook 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.GoodAll human user accounts have a phishing-resistant method registered and no phishable method remains selectable.
- AskAsk for recent sign-in logs or authentication reports for a sample of users across different systems.Look atCheck the authentication method recorded for each successful sign-in and confirm it was a phishing-resistant method rather than a code or push approval.GoodSampled sign-ins across systems consistently show phishing-resistant methods in use, with no successful sign-ins using phishable methods.
Cross-framework mappings
How ISM-1682 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.5 | ISM-1682 requires a specific secure authentication outcome: MFA used for system authentication is phishing-resistant | |
E8
| Control | Notes | Details |
|---|---|---|
equalEquivalent(1)expand_less | ||
open_in_fullBroader than(1)expand_less | ||
layersPartially meets(1)expand_less | ||
sync_altPartially overlaps(4)expand_less | ||
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.