ASD ISM 1401 Multi-factor authentication combines possession with knowledge or inherence
What it says
Multi-factor authentication uses either: something people have and something people know, or something people have that is unlocked by something people know or are.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSets the two combinations of factors that count as multi-factor authentication: a possessed item plus a secret, or a possessed item unlocked by a secret or a biometric.
This control defines what actually counts as multi-factor authentication. It is not enough to ask for two things at login; the two things must come from the right categories. The ISM accepts exactly two patterns: 1. **Something people have and something people know.** For example, a hardware security key or authenticator app (the "have") combined with a password or PIN (the "know"). 2. **Something people have that is unlocked by something people know or are.** For example, a phone or smart card (the "have") that only releases its credential after the user enters a PIN (the "know") or presents a fingerprint or face (the "are"). The common thread is that a **possession factor is always present**. A biometric or a PIN on its own is never a second factor; it can only serve to unlock a possessed item. Likewise, two secrets (a password plus security questions) or a password plus a one-time code sent to the same account are not multi-factor under this definition. Why it matters: the whole point of multi-factor authentication is that an attacker who steals one factor still cannot log in. Passwords are routinely phished, guessed, reused and leaked. A possession factor forces the attacker to also obtain a physical item or a bound device, which is far harder to do at scale. If an organisation deploys a scheme that looks like multi-factor but does not include a genuine possession factor, it gets the compliance tick without the protection, and remains just as exposed to credential theft as a password-only system.
Free. Save your status, tasks and notes.
Why it matters
If an organisation treats a weaker combination as multi-factor authentication (for example two knowledge factors, or a biometric with no possessed item behind it), a single stolen or phished secret can still grant full access. Attackers who harvest passwords through phishing, credential stuffing or breach dumps will be able to log in unimpeded, leading to account takeover, data theft and lateral movement. The organisation will also be non-compliant with the ISM despite believing it has implemented multi-factor authentication, which undermines every downstream control that depends on it.
How to implement
Identity and access administrators should inventory every authentication method currently offered by each identity provider and application, and label each factor as something people have, know or are, so the combination each system actually enforces is visible.
The security team should write a short authentication standard that states only two combinations are acceptable, possession plus knowledge, or possession unlocked by knowledge or a biometric, and should list the concrete methods (hardware keys, authenticator apps, smart cards, device-bound passkeys with PIN or biometric unlock) that meet it.
Identity administrators should configure the identity provider's authentication policies so that at least one possession-based method is mandatory in every multi-factor flow, and should disable combinations that pair a password with another knowledge factor such as security questions.
Where biometrics are used, device and endpoint administrators should enable them only as the unlock for a possessed credential (for example a passkey or certificate on the device) rather than as a standalone second factor, and should verify the biometric cannot be bypassed to release that credential.
Before enabling any new or vendor-changed authentication method, identity administrators should classify each factor it uses as something people have, know or are, and confirm the resulting combination matches one of the two accepted patterns before it is offered to users.
Keep it running
Day to day, this control shapes how identity and access teams evaluate and configure authentication methods. Whenever a new system, identity provider or authentication app is introduced, someone needs to classify each factor it offers as "have", "know" or "are" and confirm the resulting combination matches one of the two accepted patterns.
Practical points to keep in front of the team:
Keep a simple register of approved authentication methods with the factor categories noted against each one, and review it when vendors change how their products work.
- Passwords, PINs and passphrases are all "know". Adding a second one of these does not create multi-factor.
- Authenticator apps, hardware tokens, smart cards, passkeys bound to a device and phone-based push approvals are "have", provided the credential is actually bound to that item.
- Fingerprints and face recognition are "are", and under this control they only count when they unlock a possessed item (such as a phone or security key). A biometric that unlocks a server-side account directly with no bound device is not a valid combination.
- Watch for fallbacks. A method may be multi-factor on the primary path but drop to knowledge-only on a recovery or "trouble signing in" path. The fallback needs the same scrutiny.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the organisation's authentication standard or policy that defines multi-factor authentication.
Look at
Look for an explicit statement of which factor combinations are permitted and whether it matches the two patterns in the control.
Good evidence
The document names possession plus knowledge, or possession unlocked by knowledge or a biometric, as the only acceptable combinations, and rules out knowledge-plus-knowledge schemes.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the register or inventory of authentication methods in use across identity providers and key applications.
Look at
Check that each method is classified as have, know or are, and that every enforced combination includes a possession factor.
Good evidence
Every listed multi-factor method includes a possessed item, and any biometric is recorded as unlocking that item rather than acting as a second factor on its own.
- Check 3 of 5What an auditor asks for
Ask for
Ask for exported authentication policy configuration from the main identity provider.
Look at
Examine which methods are enabled and whether a password plus a second knowledge factor (for example security questions or a memorised code) could satisfy the policy.
Good evidence
The configuration requires a hardware token, authenticator app, smart card or device-bound credential in every multi-factor path, and knowledge-only combinations are disabled.
- Check 4 of 5What an auditor asks for
Ask for
Ask for a walkthrough or screen recording of a user logging in to a sensitive system, including the biometric path if one exists.
Look at
Observe what the user actually presents and whether the biometric is unlocking a device-held credential or being sent as a factor by itself.
Good evidence
The login clearly involves a possessed item, and any fingerprint or face scan only unlocks that item before its credential is used.
- Check 5 of 5What an auditor asks for
Ask for
Ask for change records for authentication methods added or altered in the review period.
Look at
Check whether each new or changed method was classified as have, know or are before it was enabled, and whether the resulting combination was assessed against the two accepted patterns.
Good evidence
Each record shows the factor classification and confirms the enforced combination includes a possessed item, either paired with a secret or unlocked by a secret or a biometric.
Mappings
Closest match in ASD Essential Eight: E8-MF-ML1.7, Multi-factor authentication combines two factors like a device and a PIN, which asks for the same thing.
ISO/IEC 27001: 1 mapping
This control depends on A.5.17.
ISM-1401 requires multi-factor authentication to be implemented using specific factors (possession with knowledge or inherence), which relies on proper handling of credentials and authenticators. Annex A 5.17 requires controlled allocation and management of authentication information, which is necessary to securely issue, protect, reset, and revoke the knowledge factors (e.g. PINs/passwords) and manage associated authenticators used in ISM-1401 MFA. ISM-1401 defines the factor model, while Annex A 5.17 provides the governance needed to operate those factors securely.
ASD Essential Eight: 13 mappings
This control is equivalent to E8-MF-ML1.7.
ISM-1401 defines what combinations of factors count as multi-factor authentication (possession + knowledge, or possession unlocked by knowledge or inherence). E8-MF-ML1.7 states the same acceptable MFA factor combinations using effectively identical language. Both controls are definitional and set the minimum criteria for MFA rather than prescribing where MFA must be applied.
This control partially overlaps E8-MF-ML2.3.
ISM-1401 defines multi-factor authentication in terms of factor combinations that must include possession with knowledge or inherence. E8-MF-ML2.3 requires MFA for online services to be phishing-resistant, and ISM-1401 underpins that by ensuring MFA uses true multiple factors rather than weaker single-factor lookalikes. E8-MF-ML2.3 adds a quality attribute (phishing-resistance) not required by ISM-1401.
- E8-MF-ML2.5Multi-factor authentication used for system access is phishing-resistantPartially overlaps
This control partially overlaps E8-MF-ML2.5.
ISM-1401 specifies that MFA must be based on possession with knowledge/inherence (or possession unlocked by those factors). E8-MF-ML2.5 requires that MFA for system access be phishing-resistant, and ISM-1401 supports this by ensuring the MFA design uses genuine factor separation including a possession element. E8-MF-ML2.5 goes further by constraining acceptable MFA methods to those resilient to phishing, which ISM-1401 does not address.
- E8-MF-ML3.2Phishing-resistant multi-factor authentication for online customer servicesPartially overlaps
This control partially overlaps E8-MF-ML3.2.
ISM-1401 defines MFA as possession with knowledge or inherence, including possession unlocked by those factors. E8-MF-ML3.2 requires customer MFA for online customer services to be phishing-resistant, and ISM-1401 supports that by ensuring the solution meets the baseline definition of MFA rather than single-factor or pseudo-MFA. E8-MF-ML3.2 adds phishing-resistance and a customer-service scope not covered by ISM-1401.
This control supports E8-MF-ML1.1.
ISM-1401 defines the required composition of multi-factor authentication factors (possession with knowledge/inherence, including possession unlocked by knowledge/inherence). E8-MF-ML1.1 requires MFA to be used for users accessing online services that handle the organisation's sensitive data, and ISM-1401 clarifies what implementations meet that MFA requirement. E8-MF-ML1.1 is about where MFA must be applied, while ISM-1401 is about what qualifies as MFA.
This control supports E8-MF-ML1.2.
ISM-1401 specifies acceptable MFA factor combinations (possession + knowledge, or possession unlocked by knowledge or inherence). E8-MF-ML1.2 mandates using MFA for third-party online services handling the organisation's sensitive data, and ISM-1401 provides the criteria to assess whether the chosen MFA method is valid. The candidate is scope-specific (third-party/sensitive data), whereas ISM-1401 is a general MFA definition.
This control supports E8-MF-ML1.3.
ISM-1401 defines MFA as specific factor combinations involving possession with knowledge or inherence (including unlocking a possessed item). E8-MF-ML1.3 requires MFA for third-party services processing non-sensitive organisational data, and ISM-1401 supports compliance by defining what constitutes MFA for that use case. E8-MF-ML1.3 sets an application requirement, while ISM-1401 sets the MFA construction requirement.
This control supports E8-MF-ML1.4.
ISM-1401 requires that MFA be implemented using specific factor combinations (possession with knowledge or inherence, including unlocked possession). E8-MF-ML1.4 requires MFA for users accessing online customer services handling sensitive customer data, and ISM-1401 clarifies what MFA mechanisms are acceptable to meet that mandate. The candidate focuses on service context and data sensitivity, whereas ISM-1401 is technology-criteria focused.
- E8-MF-ML1.5Multi-factor authentication for third-party services with sensitive customer dataSupports
This control supports E8-MF-ML1.5.
ISM-1401 defines the acceptable MFA factor combinations for authentication (possession with knowledge/inherence). E8-MF-ML1.5 mandates MFA for third-party online customer services handling sensitive customer data, and ISM-1401 supports implementation by defining what counts as MFA in that scenario. E8-MF-ML1.5 is about coverage (third-party customer services), while ISM-1401 is about MFA composition.
- E8-MF-ML1.6Multi-factor authentication for customer access to online services handling sensitive dataSupports
This control supports E8-MF-ML1.6.
ISM-1401 sets the minimum construction of MFA by requiring combinations of possession with knowledge or inherence (or possession unlocked by them). E8-MF-ML1.6 requires customers to use MFA when accessing online services that handle sensitive customer data, and ISM-1401 provides the definitional benchmark for acceptable MFA methods. The candidate is audience- and service-specific (customers), while ISM-1401 applies generally to MFA design.
This control supports E8-MF-ML2.1.
ISM-1401 defines what counts as MFA by specifying valid factor pairings involving possession and knowledge/inherence. E8-MF-ML2.1 requires MFA for privileged users of systems, and ISM-1401 supports that requirement by constraining acceptable MFA implementations. E8-MF-ML2.1 addresses who must use MFA (privileged users), whereas ISM-1401 addresses the MFA factor model.
This control supports E8-MF-ML2.2.
ISM-1401 requires MFA to combine possession with knowledge or inherence (including unlocking a token/device). E8-MF-ML2.2 mandates MFA for unprivileged users of systems, and ISM-1401 supports compliance by defining what qualifies as MFA for those users. The candidate is about coverage across user types, while ISM-1401 is about MFA construction.
This control supports E8-MF-ML3.1.
ISM-1401 defines the required factor combinations for MFA, ensuring implementations include possession plus knowledge/inherence. E8-MF-ML3.1 mandates MFA for users of data repositories, and ISM-1401 provides the criteria to validate that the repository authentication mechanism is truly MFA. The candidate is targeted at a particular asset class (data repositories), while ISM-1401 is broadly applicable to MFA composition.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.