ASD ISM 1401Multi-Factor Authentication Combines Possession With Knowledge or Inherence
Official control statement
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.
In plain English
Sets 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.
What this means in practice
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.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
ML1, ML2, ML3
Guideline
Guidelines for system accessTopic
Multi-factor authentication
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the organisation's authentication standard or policy that defines multi-factor authentication.Look atLook for an explicit statement of which factor combinations are permitted and whether it matches the two patterns in the control.GoodThe 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.
- AskAsk for the register or inventory of authentication methods in use across identity providers and key applications.Look atCheck that each method is classified as have, know or are, and that every enforced combination includes a possession factor.GoodEvery 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.
- AskAsk for exported authentication policy configuration from the main identity provider.Look atExamine 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.GoodThe configuration requires a hardware token, authenticator app, smart card or device-bound credential in every multi-factor path, and knowledge-only combinations are disabled.
- AskAsk for a walkthrough or screen recording of a user logging in to a sensitive system, including the biometric path if one exists.Look atObserve what the user actually presents and whether the biometric is unlocking a device-held credential or being sent as a factor by itself.GoodThe login clearly involves a possessed item, and any fingerprint or face scan only unlocks that item before its credential is used.
- AskAsk for change records for authentication methods added or altered in the review period.Look atCheck 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.GoodEach 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.
Cross-framework mappings
How ISM-1401 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
extensionDepends on(1)expand_less | ||
| Annex A 5.17 | ISM-1401 requires multi-factor authentication to be implemented using specific factors (possession with knowledge or inherence), which re... | |
E8
| Control | Notes | Details |
|---|---|---|
equalEquivalent(1)expand_less | ||
sync_altPartially overlaps(3)expand_less | ||
handshakeSupports(9)expand_less | ||
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.