PCI DSS 8.4.2: Multi-factor authentication for every non-console way into the cardholder data environment, for everyone.
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.
PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1
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. 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. Three kinds of account are outside it: application and system accounts performing automated functions, user accounts on point-of-sale terminals that can reach only one card number at a time for a single transaction, and user accounts authenticated only with phishing-resistant factors. MFA can sit at the network level or at the system or application level; it does not have to be applied at both.
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. Control the bypasses before claiming coverage. A break-glass account or an IP allowlist that skips MFA is a bypass. 8.5.1 allows one only when it is documented, authorised by management as an exception, and limited in time; anything else means MFA is not implemented for all access.
4. Do not stop at remote access. MFA on the VPN and none on the internal path 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, such as 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… |
Terms
Glossary entries that name this control, each with its own example, limits and sources:
- Authentication
- Multi-factor Authentication (MFA)
- Non-console Access
- Phishing-Resistant Authentication
← 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.