Skip to content
PRO-13 Identity, credential and access management
ASD EssentialsIT.PRO-13.4

ASD Essentials IT.PRO-13.4 Enforce Phishing-Resistant MFA for All User Authentication, Including from Untrusted Locations

What it says

Use phishing-resistant MFA for users authenticating to systems, including from untrusted, external or high-risk locations.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Requires users to sign in to systems with multi-factor authentication that fake sites cannot trick, including from untrusted, external or high-risk locations.

Some kinds of multi-factor authentication (MFA), such as text codes or phone prompts, can still be tricked by fake sign-in pages. Phishing-resistant MFA, such as a security key or passkey, works only with the real system and a device the person holds. To meet this, it is needed for every routine sign-in, including from home, while travelling or on public wi-fi. Services for customers offer it too, and emergency access is tested and reviewed.

Where this action applies

What's in each domain?

ASD orders the work by domain: apply this action to each ticked domain, phase by phase.

Phase 1
Phase 2
Phase 3

Why it matters

Attackers can sign in with stolen or guessed passwords, capture codes on fake sign-in pages, or flood users with prompts until one is approved. Once in, they move between systems and add their own sign-in method to keep access.

How to implement

  1. The identity lead should list every in-scope system and sign-in path by ASD domain, with the sign-in methods each accepts.

    Connect each one to the central sign-in service, or switch on phishing-resistant MFA in the system itself.

  2. Identity administrators should allow only phishing-resistant methods, switching off text, voice, simple phone prompts and typed codes, even for backup or recovery.

    Issue spare security keys, and require an existing phishing-resistant method or identity check to add or replace one.

  3. The identity lead should define which locations are trusted and which are untrusted, external or high-risk, for the head of security to approve.

    Then set sign-in rules requiring phishing-resistant MFA for every routine sign-in from every location, trusted ones included.

  4. The head of security should give each exception or backup path an approver and end date, closing any used routinely.

    The identity lead should lock away emergency sign-in devices, alert on every use, and test and review them regularly.

  5. Owners of customer-facing services should offer customers a phishing-resistant option, such as passkeys, at sign-up or later.

    Staff who run those services use phishing-resistant MFA themselves.

Keep it running

The identity team enforces this through central sign-in rules. It reviews sign-in logs for sign-ins without a phishing-resistant method or from unknown locations. A common gap is covering remote access only, not every system. Send new systems, location types and exception requests through change control, so the rules stay complete. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Request the list of in-scope systems and sign-in paths, and the latest MFA coverage report.

    Look at

    Whether some systems or ASD domains lack phishing-resistant MFA, or coverage stops at remote access.

    Good evidence

    Every routine sign-in to in-scope systems uses phishing-resistant MFA, matching the list.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Request the sign-in method settings and a summary of methods used recently.

    Look at

    Whether text, voice, simple phone prompts or typed codes are still switched on, even as backup or recovery.

    Good evidence

    Only phishing-resistant methods are switched on, and recent sign-ins used nothing weaker.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the defined location types, the sign-in rules using them and sample sign-ins.

    Look at

    Whether rules treat all locations alike, miss defined high-risk types, or let weaker sign-ins through.

    Good evidence

    Untrusted, external and high-risk locations all require phishing-resistant MFA, as sampled sign-ins show.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the exceptions list, accounts excluded from the rules and recent emergency access tests.

    Look at

    Whether exceptions allow routine weaker sign-in, or emergency accounts are untested or used for routine work.

    Good evidence

    No exception allows routine weaker sign-in, and emergency access is tested, protected and kept for emergencies.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Request the list of customer-facing services and the MFA options each offers.

    Look at

    Whether any service offers no MFA, or only text, email or app codes.

    Good evidence

    Every customer-facing service lets customers sign up for and use a phishing-resistant method.

ASD indicators of good practice (11)

The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".

Not effective(4)

  • NE-1Phishing-resistant MFA is not enforced for interactive user authentication to systems.
  • NE-2MFA is deployed but uses non-phishing-resistant methods, such as SMS, voice, or push-only authentication instead of phishing-resistant MFA.
  • NE-3No access policies differentiate between trusted and untrusted, external or high-risk locations.
  • NE-4Access from untrusted, external or high-risk locations is permitted without MFA, or with non-phishing-resistant MFA.

Partially effective(3)

  • PE-1Phishing-resistant MFA is deployed for some but not all systems within scope.
  • PE-2Access policies exist but do not cover all organisationally defined high-risk location categories.
  • PE-3Exceptions or alternative authentication pathways allow routine or recurring authentication without phishing-resistant MFA, or emergency access arrangements are not adequately restricted, monitored, tested or reviewed.

Fully effective(4)

  • FE-1Phishing-resistant MFA is enforced for all routine interactive user authentication to systems within scope.
  • FE-2Phishing-resistant MFA is enforced for routine authentication attempts from untrusted, external or high-risk locations.
  • FE-3Customer-facing services provide a phishing-resistant MFA option for authentication.
  • FE-4Emergency access arrangements are periodically tested and reviewed to confirm that they remain operational, appropriately protected and limited to their intended purpose. Credentials or authentication factors used for emergency access are securely managed and are not used for routine administration.

Mappings

Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.8.5Secure authentication technologies and proceduresPartially meets
  • A.6.7Remote Working Security MeasuresPartially overlaps
Essential Eight

ASD Essential Eight: 15 mappings

  • E8-MF-ML1.1Require multi-factor authentication for sensitive online servicesPartially overlaps
  • E8-MF-ML1.2Multi-factor authentication for third-party services handling sensitive dataPartially overlaps
  • E8-MF-ML1.3Use multi-factor authentication for non-sensitive third-party servicesPartially overlaps
  • E8-MF-ML1.4Use multi-factor authentication for online services handling customer dataPartially overlaps
  • E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataPartially overlaps
  • E8-MF-ML1.6Multi-factor authentication for customer access to online services handling sensitive dataPartially overlaps
  • E8-MF-ML1.7Multi-factor authentication combines two factors like a device and a PINPartially overlaps
  • E8-MF-ML2.1Multi-factor authentication for privileged users of systemsPartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.