ASD ISM 2011 Disabling weaker MFA options when phishing-resistant MFA is used
What it says
When phishing-resistant multi-factor authentication is used by human users, other non-phishing-resistant multi-factor authentication options are disabled for their user accounts.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnce a person signs in with phishing-resistant MFA, their account must not keep any weaker MFA method switched on as a fallback that an attacker could target instead.
Phishing-resistant multi-factor authentication (such as a hardware security key or a platform authenticator bound to the device) is designed so that a fake login page cannot capture and replay the second factor. That protection only holds if the strong method is the *only* method the account accepts. If a user has been given phishing-resistant MFA but their account still allows an SMS code, a voice call, a one-time code from an app, or a push notification as an alternative, an attacker does not need to beat the security key at all. They simply steer the victim (or the login flow) towards the weaker option and phish that instead. In practice the account is only as strong as its weakest enabled method. This control closes that gap. Whenever a human user authenticates with phishing-resistant MFA, every other, non-phishing-resistant MFA option must be disabled on that person's account, not merely discouraged or left as a backup. This is about the account configuration itself, not just what the user normally chooses at sign-in.
Free. Save your status, tasks and notes.
Why it matters
Leaving weaker MFA options enabled alongside phishing-resistant MFA gives attackers a downgrade path. A convincing phishing page, a real-time proxy attack, or an MFA-fatigue push campaign can capture or coerce the weaker factor, and the organisation gains almost none of the protection it invested in when it rolled out security keys or passkeys. The likely outcome is account takeover of staff who believed they were strongly protected, followed by access to email, systems and data at that person's level of privilege.
How to implement
The identity and access team documents which MFA methods the organisation treats as phishing-resistant (for example FIDO2 security keys, passkeys and certificate-based smart cards) and which are not (SMS, voice, email codes, app-generated one-time codes and simple push approvals), and records this in the authentication standard.
The identity administrator configures an authentication methods policy in the identity provider so that users in the phishing-resistant MFA group can only satisfy MFA with the approved strong methods, and removes the weaker methods from that group's allowed list.
The identity administrator runs a script or report against the identity provider to list every user who has a phishing-resistant method registered and still has SMS, voice, app code or push registered, then removes the weaker registrations from those accounts.
The service desk updates the onboarding and device-issue procedure so that once a user's security key or passkey is registered and tested, the interim MFA method they enrolled with is deleted from their account as the final step of the ticket.
The security team builds an alert or scheduled check on identity provider audit logs that fires when a non-phishing-resistant method is added to an account that holds phishing-resistant MFA, and assigns the service desk to remove it and confirm with the user.
Keep it running
Day to day, this control lives in the identity provider's authentication method and policy settings. The identity or access team maintains a list of which MFA methods count as phishing-resistant for the organisation and configures policies so that accounts enrolled in those methods cannot also use the weaker ones.
The main operational friction points are onboarding and recovery. New users often enrol in a weaker method first (for example an authenticator app) before a security key is issued, so the weaker method must be removed once the strong one is registered. Lost or broken security keys create pressure to "temporarily" re-enable SMS or app codes; the recovery process should instead issue a replacement key or use a controlled, time-limited recovery path that does not silently leave a weaker method registered afterwards.
Periodic reviews should reconcile the list of users who hold phishing-resistant MFA against their currently registered methods, and identity provider change logs should be watched for anyone re-enabling a weaker method on their own account.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the authentication methods policy or MFA configuration that applies to users who have phishing-resistant MFA.
Look at
Look at which methods are enabled for that group or policy scope, and whether SMS, voice, email codes, app one-time codes or push approvals are still listed as permitted.
Good evidence
Only the organisation's defined phishing-resistant methods are enabled for those users, and the weaker methods are explicitly disabled rather than just not preferred.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an export from the identity provider of registered authentication methods for all users who hold a security key, passkey or smart card.
Look at
Look for any of those accounts that also have a phone number, authenticator app or push method registered.
Good evidence
No user with phishing-resistant MFA has a weaker method registered.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the onboarding or device-issue procedure used when a user receives a security key or registers a passkey.
Look at
Look for the step that removes the interim or previous MFA method once the strong method is working.
Good evidence
The procedure has an explicit removal step, and sampled onboarding tickets show it was completed.
- Check 4 of 5What an auditor asks for
Ask for
Ask how a lost or broken security key is handled and what the user is given in the meantime.
Look at
Look at whether the recovery process re-enables a weaker MFA method and, if so, whether it is removed again afterwards.
Good evidence
Recovery issues a replacement strong authenticator or uses a controlled temporary access path, and any weaker method is removed once the user is back on phishing-resistant MFA.
- Check 5 of 5What an auditor asks for
Ask for
Ask what monitoring exists for users adding a weaker MFA method to an account that already has phishing-resistant MFA.
Look at
Look at audit log queries, alerts or review reports and any resulting tickets.
Good evidence
Additions of weaker methods are detected within a reasonable time and there is evidence they were removed and the user was contacted.
Mappings
Closest match in ISO/IEC 27001: A.5.17, Management of authentication information, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.5.17.
ISM-2011 requires a specific rule: if phishing-resistant MFA is used by human users, other non-phishing-resistant MFA options must be disabled for their user accounts. ISO/IEC 27001:2022 Annex A 5.17 requires that allocation and management of authentication information is controlled by a management process, under which permitted MFA methods and the disabling of weak factors would be governed. Annex A 5.17 is broader governance over authentication information generally, while ISM-2011 is a prescriptive hardening requirement targeting MFA downgrade paths.
This control partially meets A.8.5.
ISM-2011 requires disabling non-phishing-resistant MFA options when phishing-resistant MFA is used, specifically to prevent fallback authentication being exploited. ISO/IEC 27001:2022 Annex A 8.5 requires secure authentication technologies and procedures to be implemented based on access restrictions and access control policy, which would include selecting phishing-resistant MFA and preventing insecure fallback mechanisms. Annex A 8.5 is broader across authentication technologies and procedures, whereas ISM-2011 is a narrowly defined configuration requirement about disabling weaker MFA options on an account.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-MF-ML2.3.
ISM-2011 requires that when a human user uses phishing-resistant MFA, all other non-phishing-resistant MFA options are disabled on that user account to remove downgrade or fallback sign-in paths. E8-MF-ML2.3 requires MFA for authenticating users of online services to be phishing-resistant, which aligns with the intent of preventing credential phishing and MFA interception. However, E8-MF-ML2.3 is primarily a strength requirement for the MFA method used, while ISM-2011 is specifically about account configuration to prevent weaker alternative MFA methods being left enabled.
This control partially overlaps E8-MF-ML3.3.
ISM-2011 requires disabling any non-phishing-resistant MFA options for a user account once phishing-resistant MFA is used, preventing attackers from selecting a weaker MFA pathway. E8-MF-ML3.3 requires MFA used to authenticate users of data repositories to be phishing-resistant, which supports the same goal of resisting phishing-based account compromise for a specific asset class. The key difference is that E8-MF-ML3.3 does not explicitly require disabling other (weaker) MFA methods on the account, whereas ISM-2011 is explicitly about removing those fallback options regardless of service type.
This control supports E8-MF-ML2.5.
ISM-2011 requires that when phishing-resistant MFA is used by user accounts, any non-phishing-resistant MFA options are disabled for those accounts to prevent fallback. This supports E8-MF-ML2.5 because disabling weaker MFA options is a direct control to ensure MFA for system access remains phishing-resistant under real-world conditions. E8-MF-ML2.5 defines the strength requirement for MFA used for system access, while ISM-2011 focuses on configuration hardening to stop weaker MFA paths being used.
This control supports E8-MF-ML3.2.
ISM-2011 requires that when phishing-resistant MFA is enabled for a user account, other non-phishing-resistant MFA options are disabled for that account. This supports E8-MF-ML3.2 by helping ensure customer authentication cannot be downgraded to weaker MFA methods, preserving phishing resistance for online customer services. E8-MF-ML3.2 sets the phishing-resistant requirement for customer services broadly, whereas ISM-2011 is a specific enforcement requirement about disabling alternative MFA methods once phishing-resistant MFA is in use.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.