ASD ISM 1919 Disable authentication protocols that cannot support multi-factor authentication
What it says
When multi-factor authentication is used to authenticate human users or customers to online services or online customer services, all other authentication protocols that do not support multi-factor authentication are disabled.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishWhere MFA protects logins to online services, every legacy or alternative sign-in protocol that cannot carry MFA is switched off so attackers cannot sidestep it.
Turning on multi-factor authentication (MFA) for an online service is only half the job. Many services still accept older or alternative ways of signing in that only take a username and password, such as legacy mail protocols, basic authentication on APIs, or older client sign-in methods. If any of those remain enabled, an attacker with a stolen password simply uses the path that does not ask for a second factor, and the MFA you rolled out never comes into play. This control closes that gap. When MFA is used to authenticate human users or customers to online services, or to online customer services, all other authentication protocols that do not support MFA must be disabled. In practice that means finding every way a person can log in to the service and either making sure it enforces MFA or turning it off entirely. The aim is that there is no "back door" login that accepts a password alone, so the second factor is genuinely required for everyone, every time.
Free. Save your status, tasks and notes.
Why it matters
If non-MFA authentication protocols are left enabled, MFA becomes a formality that attackers route around. Phished, reused or breached passwords can be used against the legacy protocol to gain full access to user or customer accounts, leading to data theft, fraud against customers, business email compromise and the loss of any assurance the organisation believed MFA was providing. It also creates a false sense of security in risk assessments and audits, because the control is reported as implemented while the real exposure remains.
How to implement
Service owners compile a list of every online service and online customer service where human users or customers authenticate with MFA, and for each one document all supported authentication protocols and sign-in methods (for example legacy mail protocols, basic authentication, older client sign-in flows and API password logins).
Identity or platform administrators use the service's admin console or tenant policy settings to disable each protocol that cannot support MFA, applying the setting at the organisation or tenant level so it covers all existing and future accounts rather than individual users.
Before switching a protocol off, the IT team reviews sign-in logs to identify any applications, devices or integrations still using it, then migrates those to an MFA-capable modern authentication method or replaces them, so disabling the protocol does not break legitimate services.
Security administrators configure conditional access or equivalent policies to block any authentication that does not present MFA, providing a second layer of enforcement in case a legacy protocol is inadvertently re-enabled.
The service owner adds a check to the change and release process for each online service so that any new sign-in method, platform upgrade or vendor feature is assessed for MFA support before it is enabled, and any protocol lacking MFA support stays disabled.
Keep it running
Keep a current inventory of every online service and online customer service where MFA is used for human users or customers, and for each one list the authentication protocols and client sign-in methods the platform supports. Mark each protocol as MFA-capable (and enforced) or not, and confirm those that are not are disabled at the service or tenant level rather than just discouraged.
Watch for regressions. Vendors add new sign-in methods, administrators re-enable legacy protocols to fix a broken integration, and new mailboxes or accounts can inherit default settings that allow basic authentication. Build the check into change management for the service, review the settings after platform upgrades, and periodically confirm from sign-in logs that no successful authentications are arriving over protocols that should be off. Where a legacy protocol is temporarily needed for migration, treat it as a time-boxed exception with an owner and a removal date.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the inventory of online services and online customer services where MFA is used to authenticate human users or customers, including the authentication protocols each service supports.
Look at
Check that every supported protocol or sign-in method is listed for each service and is marked as either MFA-capable or disabled.
Good evidence
A complete, dated inventory with a named owner where no protocol lacking MFA support is shown as enabled.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the tenant or service configuration settings that disable legacy or non-MFA authentication protocols.
Look at
Look at the actual configuration export or console screenshots, confirming the settings apply organisation-wide rather than to selected users only.
Good evidence
Configuration evidence showing each non-MFA protocol set to disabled or blocked at the tenant level, with a recent capture date.
- Check 3 of 5What an auditor asks for
Ask for
Ask for recent sign-in or authentication logs for a sample of the in-scope services.
Look at
Search for any successful authentications over protocols that are meant to be disabled, and for logins that completed without an MFA claim.
Good evidence
Logs show no successful authentications over disabled protocols, and any attempts on those protocols are rejected.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the exceptions register or change records covering any protocol that was re-enabled or is still in use.
Look at
Check whether each exception has a justification, an owner, a compensating control and an expiry date, and whether closed exceptions were actually removed.
Good evidence
Few or no exceptions, each time-boxed and tracked, with evidence the protocol was disabled again when the exception expired.
- Check 5 of 5What an auditor asks for
Ask for
Ask how new services, platform upgrades and vendor sign-in features are assessed for MFA support before being enabled.
Look at
Look for a documented step in change management or service onboarding that requires confirming a protocol supports MFA, and evidence it has been followed.
Good evidence
Change records or onboarding checklists showing the MFA-support check was performed, with any non-MFA protocol left disabled.
Mappings
Closest match in ISO/IEC 27001: A.8.5, Secure authentication technologies and procedures, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.5.
ISM-1919 mandates disabling non-MFA-capable protocols for online services when MFA is implemented, specifically preventing legacy access routes. Annex A 8.5 requires implementing secure authentication technologies, which includes encouraging MFA-capable protocol use, hence broader in scope.
ASD Essential Eight: 10 mappings
This control supports E8-MF-ML1.1.
ISM-1919 disables all non-MFA-capable protocols to prevent circumvention when MFA is used. E8-MF-ML1.1 requires MFA for accessing sensitive online services, aligning with ISM-1919 in securing entry points by eliminating weaker authentication methods.
This control supports E8-MF-ML1.2.
E8-MF-ML1.2 requires MFA for authentication to third-party services handling sensitive data. ISM-1919 supports this by disabling non-MFA authentication protocols for online services, reducing bypass paths. E8-MF-ML1.2 sets the MFA requirement, while ISM-1919 ensures its enforcement.
This control supports E8-MF-ML1.4.
ISM-1919 mandates turning off protocols that cannot support MFA if MFA is used for service access, preventing legacy bypass. E8-MF-ML1.4 requires MFA where sensitive data is involved, aligning with ISM-1919 in enhancing security by ensuring MFA is both adopted and not bypassed.
- E8-MF-ML1.6Multi-factor authentication for customer access to online services handling sensitive dataSupports
This control supports E8-MF-ML1.6.
ISM-1919 ensures that when MFA is implemented, alternatives not supporting MFA are disabled, preventing circumvention. E8-MF-ML1.6 mandates MFA usage for protected access to sensitive data, which ISM-1919 hardens by removing weaker options.
This control supports E8-MF-ML1.7.
E8-MF-ML1.7 requires MFA to use two factors to strengthen authentication. ISM-1919 supports that outcome by requiring organisations to disable alternative authentication protocols that do not support MFA when MFA is in use for online services/customer services. ISM-1919 is about eliminating downgrade paths and ensuring MFA is consistently enforced, which is complementary to (but not defined by) E8-MF-ML1.7's factor-combination requirement.
This control supports E8-MF-ML2.3.
ISM-1919 requires disabling any authentication protocols that cannot support MFA when MFA is used, to prevent bypass via legacy paths. E8-MF-ML2.3 requires phishing-resistant MFA for online services to ensure that remaining paths after non-MFA-capable protocol disablement are robust. Together, they reinforce MFA implementation by removing bypass routes and strengthening MFA.
This control supports E8-MF-ML3.1.
E8-MF-ML3.1 requires MFA for authenticating users of data repositories. ISM-1919 requires disabling authentication protocols that do not support MFA once MFA is used, preventing bypass paths that would undermine repository MFA. E8-MF-ML3.1 does not explicitly cover protocol hardening, so ISM-1919 supports secure enforcement of the primary control.
This control depends on E8-MF-ML1.3.
E8-MF-ML1.3 requires multi-factor authentication (where available) for user access to third-party online services handling an organisation's non-sensitive data. ISM-1919 strengthens that outcome by requiring that, once MFA is in use for an online service, any non-MFA-capable authentication protocols are disabled to prevent MFA bypass. ISM-1919 is more about hardening the authentication implementation, whereas E8-MF-ML1.3 is about ensuring MFA is used for the specified third-party service scope.
- E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataDepends on
This control depends on E8-MF-ML1.5.
E8-MF-ML1.5 requires MFA for authentication to third-party online customer services. ISM-1919 mandates disabling non-MFA-capable protocols in such contexts, ensuring MFA cannot be bypassed, thus supporting the integrity of E8-MF-ML1.5's MFA requirement and preventing protocol-based downgrades.
This control depends on E8-MF-ML2.1.
ISM-1919 requires disabling authentication protocols that do not support MFA whenever MFA is used, reducing the risk privileged users can authenticate without MFA via legacy methods. This supports E8-MF-ML2.1 by ensuring MFA for privileged system access is enforced and not undermined by alternative protocols that permit single-factor authentication. E8-MF-ML2.1 focuses on requiring MFA for privileged users, while ISM-1919 focuses on disabling non‑MFA protocol options.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.