PCI DSS 8.4.3: MFA is implemented for all remote access originating from outside the entity’s network
PCI DSS v4.0.1 control 8.4.3: 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 remote access originating from outside the entity’s network that could access or impact the CDE.
Summary
Anyone reaching in from outside your network uses multi-factor authentication.
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.3.a | Examine network and/or system configurations for remote access servers and systems to verify MFA is required in accordance with all elements specified in this requirement. |
| 8.4.3.b | Observe personnel (for example, users and administrators) and third parties connecting remotely to the network and verify that multi-factor authentication is required. |
The perimeter half of MFA, and its scope is wider than "the VPN": it covers all remote access from outside the network that could access or impact the CDE, which includes an administrator connecting to a management plane that can change CDE systems even if the connection never touches them. Distinguish it from 8.4.2, which is about access into the CDE from anywhere including inside. The two overlap heavily, and the gap between them: internal access to the CDE: is where entities that implemented only this one fail.
What to prepare
- The list of remote access paths: VPN, remote desktop, cloud consoles, SaaS management planes, vendor tunnels.
- Evidence of MFA on each, for every user type including contractors and vendors.
- Evidence there is no unenforced path, which is what 8.5.1 examines.
How to implement it
1. Count the cloud console as remote access. It is reached from outside the network and can impact CDE systems directly, and it is frequently protected only by a password and an IP allowlist.
2. Cover vendor tunnels. A support connection set up years ago for a supplier is remote access from outside, and it is rarely in the same enforcement path as staff access.
3. Do not stop at the VPN. Anything reachable from the internet that can affect the CDE is in scope; SaaS admin panels for in-scope tooling are the usual omission.
4. Remember the overlap. Satisfying this leaves internal CDE access untouched, which is 8.4.2, so plan them together rather than sequentially.
Where this commonly fails
- MFA on the VPN with a cloud management console protected by a password alone.
- Vendor and support access outside the enforcement point.
- "Could impact the CDE" read narrowly as "touches cardholder data".
- Implemented in place of 8.4.2 rather than alongside 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.2 | MFA is implemented for all non-console access into the CDE |
← 8.4.2 · All controls · 8.5.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.