ASD ISM 1920 Blocking MFA self-enrolment from untrustworthy devices
What it says
When multi-factor authentication is used to authenticate human users to online services, online customer services, systems or data repositories - that process, store or communicate their organisation's sensitive data or sensitive customer data - human users are prevented from self-enrolling into multi-factor authentication from untrustworthy devices.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishUsers of sensitive-data systems cannot register their own MFA method from a device the organisation has no reason to trust, closing a common account-takeover route.
Multi-factor authentication (MFA) only protects an account if the second factor belongs to the right person. Most MFA platforms let a user enrol a new factor themselves, for example scanning a QR code into an authenticator app or registering a security key. If that self-enrolment can be done from any device at all, an attacker who has obtained a user's password can enrol their own phone or token as the second factor, and from that point MFA works for the attacker rather than against them. This control applies wherever MFA is used to authenticate human users to online services, online customer services, systems or data repositories that process, store or communicate the organisation's sensitive data or sensitive customer data. For those systems, the organisation must make sure that a human user cannot self-enrol into MFA from an untrustworthy device. In practice this means enrolment is only possible from devices the organisation has some basis to trust (for example, a managed corporate device, or a device that meets a defined trust condition), or the enrolment is not left to the user alone. Why it matters: MFA registration attacks are one of the most common ways attackers turn a stolen password into persistent access. Blocking self-enrolment from untrusted devices removes that opportunity for the systems that hold the most sensitive information.
Free. Save your status, tasks and notes.
Why it matters
If a user (or an attacker holding that user's credentials) can enrol an MFA factor from any device, the second factor no longer proves anything about who is signing in. An attacker can register their own authenticator or token, satisfy MFA on every later login, and gain persistent access to systems holding sensitive organisational or customer data. Because the login then looks fully legitimate, the compromise is harder to detect and may only surface after data has been accessed or exfiltrated, exposing the organisation to a serious breach, customer harm, and regulatory consequences.
How to implement
Have the identity and access team inventory every online service, online customer service, system and data repository that processes, stores or communicates sensitive organisational or customer data and uses MFA for human users, so the enrolment restriction is applied to the full in-scope set.
Have the security team define, in writing, what makes a device trustworthy for MFA enrolment purposes (for example, an organisation-managed device meeting a stated configuration state) and what is therefore untrustworthy, and get that definition approved so platform configuration has a clear basis.
Have identity platform administrators configure the MFA registration policy so that self-enrolment of a new factor is only permitted when the request comes from a device that satisfies the trust definition, and is denied from any other device, applying this policy to all in-scope services.
Have the service desk and customer support teams establish and document an assisted enrolment path for staff and customers who have no trustworthy device available, so that legitimate users can still be enrolled without reopening open self-service registration from untrusted devices.
Have the change management process require that any new sensitive-data system, portal or repository placed behind MFA is checked for the enrolment restriction before go-live, with the check recorded in the change record.
Keep it running
Day to day, this control lives in the configuration of the identity provider or MFA platform rather than in a manual process. Someone needs to own the definition of what counts as a trustworthy device for enrolment purposes and keep the enrolment policy aligned with it as device fleets, management tooling and identity platforms change.
New starters, staff who replace a phone, and customers who lose access to their authenticator are the common friction points. Each of these scenarios needs a supported path that still satisfies the control, such as enrolling from a managed device, or completing enrolment through an assisted process rather than an open self-service page. Help desk and customer support staff should know these paths so they do not improvise workarounds that reopen self-enrolment from untrusted devices.
Whenever a new online service, customer portal, system or data repository handling sensitive data is onboarded to MFA, confirm that the enrolment restriction is applied to it as well, not only to the initial set of systems.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the list of online services, online customer services, systems and data repositories that hold sensitive organisational or customer data and use MFA for human users.
Look at
Check that the list is complete and that each entry is marked with whether the MFA enrolment restriction is applied to it.
Good evidence
A maintained inventory where every in-scope system is covered by the restriction, with no unexplained gaps.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the organisation's written definition of a trustworthy device for MFA enrolment.
Look at
Look at whether the definition is specific enough to be enforced by technology and whether it has been approved by an appropriate owner.
Good evidence
A clear, approved definition that the identity platform configuration can be traced back to.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the MFA registration or enrolment policy configuration from the identity provider or MFA platform.
Look at
Look at the conditions attached to registering a new factor and whether they deny self-enrolment when the device does not meet the trust definition.
Good evidence
Configuration that blocks self-enrolment from untrustworthy devices for all in-scope services, matching the written definition.
- Check 4 of 5What an auditor asks for
Ask for
Ask to observe or see evidence of an attempted MFA self-enrolment from a device that does not meet the trust definition.
Look at
Look at whether the attempt is refused and what the user sees when it is.
Good evidence
The enrolment is blocked and the user is directed to a supported path rather than being allowed to proceed.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the service desk or customer support procedure used when a user needs to enrol MFA but has no trustworthy device.
Look at
Look at whether the procedure keeps enrolment off untrusted devices rather than granting a temporary exception that reopens self-service.
Good evidence
An assisted enrolment procedure that staff follow consistently, with no standing exceptions that bypass the restriction.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-1920 requires that users are prevented from self-enrolling MFA from untrustworthy devices when accessing services handling sensitive data. ISO/IEC 27001:2022 Annex A 5.15 requires establishing and implementing logical access control rules and procedures based on security requirements, which can include policies restricting MFA enrolment to trusted devices. Annex A 5.15 is broader (overall access control governance), while ISM-1920 is a specific access-control rule focused on MFA enrolment context and device trust.
This control partially meets A.5.16.
ISM-1920 requires controlling how users enrol MFA by blocking self-enrolment from untrustworthy devices for sensitive-data services. ISO/IEC 27001:2022 Annex A 5.16 requires managing the full identity life cycle, which commonly includes onboarding steps such as registering authentication factors and enforcing conditions for that registration. Annex A 5.16 covers many identity processes beyond authentication-factor enrolment, whereas ISM-1920 targets a specific anti-takeover safeguard during MFA enrolment.
This control partially meets A.5.17.
ISM-1920 requires preventing MFA self-enrolment from untrustworthy devices to reduce account takeover risk for sensitive systems. ISO/IEC 27001:2022 Annex A 5.17 requires allocation and management of authentication information to be controlled by a management process, which can include controlled issuance/registration of MFA credentials and prohibiting unmanaged devices from performing enrolment. Annex A 5.17 is broader (all authentication information management), while ISM-1920 is a specific control on the enrolment pathway and device trust decision.
This control partially meets A.8.5.
ISM-1920 requires that users are prevented from self-enrolling MFA from untrustworthy devices when authenticating to online services, systems or data repositories handling sensitive organisational or customer data. Annex A 8.5 requires organisations to implement secure authentication technologies and procedures based on access restrictions and access control policy, which can include controlling MFA enrolment workflows and enforcing device-based conditions. ISM-1920 is a specific procedural/technical restriction (blocking self-enrolment on untrusted devices), while Annex A 8.5 is broader and does not explicitly mandate this particular enrolment constraint.
ASD Essential Eight: 3 mappings
- E8-MF-ML1.6Multi-factor authentication for customer access to online services handling sensitive dataPartially overlaps
This control partially overlaps E8-MF-ML1.6.
E8-MF-ML1.6 requires customers to use MFA when authenticating to online customer services handling sensitive customer data. ISM-1920 adds an implementation safeguard for MFA enrolment by preventing self-enrolment from untrustworthy devices in the same kinds of services and data sensitivity contexts. E8-MF-ML1.6 is about requiring MFA at login, whereas ISM-1920 governs the security of the MFA enrolment process and device trust conditions.
This control depends on E8-MF-ML2.3.
E8-MF-ML2.3 requires organisations to use phishing-resistant MFA for users of online services to prevent credential interception and replay via phishing. ISM-1920 strengthens that outcome by restricting MFA self-enrolment from untrustworthy devices for online services (and other contexts), reducing the likelihood an attacker can register their own factor after phishing or device compromise. ISM-1920 does not itself define phishing-resistance, but it supports the integrity of MFA deployments that E8-MF-ML2.3 relies on.
This control depends on E8-MF-ML3.1.
E8-MF-ML3.1 requires MFA to authenticate users of data repositories. ISM-1920 adds an enrolment hardening requirement by preventing users from self-enrolling into MFA from untrustworthy devices when accessing systems or data repositories. This supports E8-MF-ML3.1 by reducing the risk that MFA on repositories is undermined through insecure enrolment, but it is about MFA lifecycle controls rather than the base requirement to use MFA.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.