Skip to content
arrow_back
policyASD Information Security Manual (ISM)

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.
policyASD Information Security Manual (ISM)ISM-1682

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.

ML2ML3NCOSPASD Information Security ManualGuidelines for system access
Control Stack classificationPreventativeMulti-factor authentication
record_voice_over

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

Topic

Multi-factor authentication

priority_high

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.

settings

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.

build

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.
fact_check

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.
link

Cross-framework mappings

How ISM-1682 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.

ISO 27001

ControlNotesDetails
layersPartially meets(1)expand_less
Annex A 8.5ISM-1682 requires a specific secure authentication outcome: MFA used for system authentication is phishing-resistant

E8

ControlNotesDetails
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.

See all Guidelines for system access controls, or browse the full ASD ISM library.

Mapping detail

Mapping

Direction

Controls