IAM-008 Multi-Factor Authentication
Description
Multi-factor authentication is enforced at system or identity provider level for access to externally facing systems, administrative interfaces and systems holding sensitive or regulated data. The enforced mechanism combines at least two distinct authentication factors drawn from knowledge, possession and inherence, and one of those factors is provided by a device separate from the system being accessed. No access path in scope completes with a single factor. Enrolment is not left to the user to opt into. Supplemental authentication is required under defined higher-risk conditions, including first use of a device, sign-in from an unrecognised location and a change to authentication or recovery settings, and those conditions are documented.
Rationale
A password alone falls to phishing, credential stuffing and reuse. Multi-factor authentication closes most of those paths, which is why it is the first control an enterprise buyer asks about. What is under test here is enforcement and not availability: a tenant where the second factor is offered but optional fails this control. Factor strength varies. A phishing-resistant factor is materially better than a one-time code delivered over SMS, but the control sets the floor at two distinct factors. The separate-device requirement rules out approving a push on the same device that is signing in, which collapses two factors onto one compromised endpoint. Step-up authentication puts the extra challenge where the risk is instead of on every sign-in, so people stop looking for ways around it. Credential lifecycle and storage are IAM-009 and replay resistance of the mechanism itself is not required here.
Applicability (9 profiles)
Framework Mappings (16)
| IAM-13 | Strong Authentication | full |
| IAM-13 | Strong Authentication | full |
| HIPAA-164.308.a.5.ii.D | Password Management | informative |
| HIPAA-164.312.d | Person or Entity Authentication | full |
| 8.5 | Secure authentication | partial |
| NIS2-Art.21.2.j | Multi-Factor Authentication and Secured Communications | partial |
| NIS2-CIR-11.1 | Access Control Policy | informative |
| NIS2-CIR-11.3 | Privileged Accounts and System Administration Accounts | informative |
| NIS2-CIR-11.7 | Multi-Factor Authentication | full |
| IA-10 | Adaptive Authentication | full |
| IA-2 | Identification and Authentication (Organizational Users) | partial |
| IA-2(1) | Identification and Authentication (Organizational Users) | Multi-factor Authentication to Privileged Accounts | full |
| IA-2(2) | Identification and Authentication (Organizational Users) | Multi-factor Authentication to Non-privileged Accounts | partial |
| IA-2(6) | Identification and Authentication (Organizational Users) | Access to Accounts —separate Device | full |
| IA-2(8) | Identification and Authentication (Organizational Users) | Access to Accounts — Replay Resistant | partial |
| CC6.1 | Logical Access Security Software, Infrastructure, and Architectures | informative |
Evidence (3)
IdP or SSO provider settings showing MFA is enforced for all user accounts on externally-facing systems and administrative interfaces, with no active policy exclusions.
Example: Okta admin console export or Azure AD Conditional Access policy export showing an MFA enforcement policy applied to All Users with no user or group exclusions, set to Enabled/Enforced (not Audit or Disabled).
Test: Query the identity provider for the MFA policy configuration. Verify: (1) at least one policy requires MFA for all users accessing in-scope systems, (2) the policy is in enforcing mode rather than audit-only, (3) no exclusion group contains an active user account, (4) legacy authentication protocols that bypass MFA are blocked, (5) the permitted factor set requires one factor from a device separate from the system being accessed, and same-device approval is not an accepted combination.
Authentication event logs confirming that MFA challenges are consistently triggered and completed for user logins to in-scope systems.
Example: Okta System Log or Azure AD Sign-in Log export for the past 7 days showing authentication events with MFA step result (success/failure/bypass). Sample must include admin console logins and application logins.
Test: Query the IdP sign-in log for the past 7 days. Verify: (1) every successful login to in-scope systems includes a completed MFA event, (2) the count of logins with MFA_SKIPPED or MFA_BYPASS is zero, or each such entry has a matching documented exception, (3) no successful logins used password-only authentication to in-scope systems.
Adaptive authentication policy configuration listing the higher-risk conditions that require a supplemental challenge and the challenge applied to each.
Example: Conditional access risk policy export, 2026-08-20
Test: Export the adaptive authentication policy. Verify: (1) every higher-risk condition named in the documented condition set has a matching rule, (2) each rule is in enforcing mode rather than reporting, (3) a sign-in from an unrecognised device in a controlled test triggers the supplemental challenge, (4) the condition set was reviewed within the interval the policy states, (5) any condition disabled in the period carries a recorded approval and an end date.
Questions (3)
Is MFA enforced for all user access to externally-facing systems, administrative interfaces, and systems holding sensitive or regulated data?
MFA must be enforced at the system or IdP level, not left to user discretion. Enforcement means no in-scope access path can be completed with a password alone.
Which of the following are true of the multi-factor authentication enforced on in-scope systems?
The control constrains the properties of the mechanism, not the product. Phishing-resistant methods such as a hardware security key are stronger than a one-time code sent over a message channel. That choice belongs in the implementation note rather than here. The third item is the one that fails in practice: a legacy client or a recovery route that still accepts a password alone.
Which conditions trigger a supplemental authentication challenge on your systems?
Options run from the most commonly configured to the least. The conditions should be written down rather than left to a vendor default, because the default set is what an attacker can look up. Elevation and sensitive-operation triggers are the two most often absent.