PCI DSS 8.5.1: MFA systems
PCI DSS v4.0.1 control 8.5.1: the requirement in full, the 5 testing procedures an assessor uses to verify it, and the related controls in section 8.5.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.5
MFA systems are implemented as follows:
- The MFA system is not susceptible to replay attacks.
- MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
- At least two different types of authentication factors are used.
- Success of all authentication factors is required before access is granted.
Summary
The MFA system itself has to be sound: no replay, no bypass, two genuinely different factor types, and all factors required before access.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 8.5.1.a | Examine vendor system documentation to verify that the MFA system is not susceptible to replay attacks. |
| 8.5.1.b | Examine system configurations for the MFA implementation to verify it is configured in accordance with all elements specified in this requirement. |
| 8.5.1.c | Interview responsible personnel and observe processes to verify that any requests to bypass MFA are specifically documented and authorized by management on an exception basis, for a limited time period. |
| 8.5.1.d | Observe personnel logging into system components in the CDE to verify that access is granted only after all authentication factors are successful. |
| 8.5.1.e | Observe personnel connecting remotely from outside the entity’s network to verify that access is granted only after all authentication factors are successful. |
The control that decides whether the MFA in 8.4.1, 8.4.2 and 8.4.3 counts. Five elements, and three are commonly missed. Not susceptible to replay rules out a static code and is what pushes toward time-based or challenge-based factors. Cannot be bypassed by any user admits exactly one exception: documented, authorised by management, for a limited period, so a standing exemption fails. And all factors required before access is granted means the system must not tell an attacker which factor failed, since revealing that a password was correct turns MFA into a sequential test of one factor at a time.
What to prepare
- The MFA configuration for each system, showing the factor types.
- The list of any bypasses, with documented authorisation and an end date.
- Evidence that failure messages do not distinguish which factor was wrong.
How to implement it
1. Prefer phishing-resistant factors. A push notification or a code read aloud can be relayed by an attacker in real time; a hardware key or a passkey bound to the origin cannot, and it answers the replay element cleanly.
2. Make failure indistinguishable. "Password incorrect" followed by "code incorrect" is a two-stage oracle. One message for both is what the element asks for.
3. Give every bypass an expiry. The requirement permits exceptions only for a limited time. A break-glass account with no end date is a permanent bypass with paperwork.
4. Check the factors are different categories. A password and a knowledge-based question are both something you know, which is the single most common failure of this element.
Where this commonly fails
- SMS or a static code accepted where replay resistance is required.
- A standing administrative bypass, rather than a documented and time-limited one.
- Error messages that reveal which factor failed.
- Two factors from one category presented as multi-factor.
Related controls
← 8.4.3 · All controls · 8.6.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.