PCI DSS 8.5.1: The MFA system itself has to be sound: no replay, no bypass, two genuinely different factor types, and all factors required before access.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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. Four elements, and three need a closer look. 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 access follows only once every factor has succeeded. Not telling the user which factor failed goes beyond the wording, but it is sound practice, 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 sound practice, though the element itself only requires every factor to succeed before access.
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 does not meet this element.
Where this commonly fails
- A static code, or a one-time code that stays valid after use, 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
Terms
Glossary entries that name this control, each with its own example, limits and sources:
← 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.