PCI DSS 8.4.2: MFA is implemented for all non-console access into the CDE
PCI DSS v4.0.1 control 8.4.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 8.4.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.4
MFA is implemented for all non-console access into the CDE.
Summary
Multi-factor authentication for every non-console way into the cardholder data environment, for everyone.
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.4.2.a | Examine network and/or system configurations to verify MFA is implemented for all non-console access into the CDE. |
| 8.4.2.b | Observe personnel logging in to the CDE and examine evidence to verify that MFA is required. |
The broadest of the MFA controls and the one merchants ask about most. Note what it does not say: it is not limited to administrators, not limited to remote access, and not limited to access from outside. 8.4.1 covers administrative access, 8.4.3 covers remote access from outside the network, and this one covers all non-console access into the CDE regardless of who or from where. An internal user reaching a CDE system over the network from a trusted office subnet is in scope. Where the three overlap, this is usually the widest, and 8.5.1 then governs how the MFA itself must behave.
What to prepare
- The list of access paths into the CDE, and the MFA in place on each.
- Evidence MFA cannot be bypassed, which 8.5.1 requires.
- The factors in use, showing they are two of the three categories rather than two passwords.
- Coverage evidence for every user type: staff, contractors, vendors and administrators.
How to implement it
1. Enumerate the paths, not the applications. SSH, VPN, the management console, the database client, the jump host and the cloud provider API are each a way in, and coverage is usually complete on the obvious one and absent on a bastion.
2. Check the categories. A password plus a security question is two things you know, which is not multi-factor. The factors must come from different categories.
3. Remove the bypasses before claiming coverage. A break-glass account or an IP allowlist that skips MFA means it is not implemented for all access, which is what 8.5.1 tests.
4. Do not stop at remote access. The commonest gap is MFA on the VPN and none on the internal path, which satisfies 8.4.3 and fails this control.
Where this commonly fails
- MFA on remote access only, leaving internal access to the CDE single-factor.
- Administrator coverage complete and ordinary user coverage absent, reading 8.4.1 as the whole obligation.
- Two factors from the same category, most often a password and a knowledge-based question.
- Service and vendor accounts exempted without the conditions that would permit it.
Related controls
Others in section 8.4:
| Control | What it requires |
|---|---|
| 8.4.1 | MFA is implemented for all non-console access into the CDE for personnel with administrative… |
| 8.4.3 | MFA is implemented for all remote access originating from outside the entity’s network… |
← 8.4.1 · All controls · 8.4.3 →
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.