For years, many merchants and service providers treated PCI DSS multi factor authentication as a remote-access problem: put MFA on the VPN, put MFA on administrator logins, done. That reading has not been safe since 31 March 2025, when the future-dated requirements in PCI DSS v4.0 became mandatory. Every PCI DSS 4.0.1 assessment now tests them.
Two requirements do most of the work: 8.4.2, which widens who and what needs MFA, and 8.5.1, which sets rules for how the MFA system itself must behave.
The three MFA requirements in 8.4
- 8.4.1 requires MFA for all non-console access into the cardholder data environment (CDE) by personnel with administrative access. This one has been in place for a long time.
- 8.4.2 requires MFA for all non-console access into the CDE, for every user, not only administrators. This was the future-dated change that became mandatory after 31 March 2025.
- 8.4.3 requires MFA for all remote network access from outside the entity's network that could reach or affect the CDE, including access by employees, administrators and third parties.
The important word in 8.4.2 is "all". It applies whether the person connects from the internet or from a desk inside your own office. A segmented CDE reached from the corporate network still needs MFA at the point of entry.
What 8.4.2 does not cover
The requirement carries applicability notes. It does not apply to:
- application or system accounts that perform automated functions;
- user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction;
- user accounts that are only authenticated with phishing-resistant authentication factors.
The PCI Security Standards Council has also said in its FAQs that phishing-resistant factors can satisfy 8.4.2 in this way, while 8.4.1 and 8.4.3 still need an additional factor. Read the exact applicability notes in the standard before relying on any exception; your QSA will.
8.5.1: the MFA system itself has to be sound
Having MFA is no longer enough. Requirement 8.5.1 says the MFA system must be configured so that:
- it is not susceptible to replay attacks;
- it cannot be bypassed by any user, including administrative users, unless specifically documented and authorised by management on an exception basis, for a limited time;
- at least two different types of authentication factor are used;
- success of all authentication factors is required before access is granted.
The bypass rule is the one that catches teams out. Permanent "trusted IP" exceptions, service desks that can switch MFA off for a user indefinitely, and break-glass accounts nobody reviews all fail 8.5.1 unless each exception is documented, approved and time-limited.
Where MFA belongs in a CDE
MFA can be applied at the network level, when a user first enters the CDE, or at the system level on each system. Common entry points to cover:
- Windows servers reached over Remote Desktop. Put the second factor on the Windows login itself, not only on a gateway in front of it. See Windows Remote Desktop MFA.
- Linux hosts reached over SSH, plus privilege changes with sudo and su, covered through PAM.
- Jump hosts and bastions, which are the natural place for network-level MFA into a segmented CDE.
- Web consoles and payment application admin panels, through their own MFA or an authentication API.
Meeting the requirement without slowing the team
The practical risk of 8.4.2 is friction. Operations staff who move between CDE systems all day now face a second factor on every one of those logins, and friction is what produces the undocumented bypasses that 8.5.1 forbids.
Spriv's adaptive MFA is designed for exactly this. The second factor is verified out-of-band, over a separate channel from the login, by pairing a known workstation with the environmental identifier reported by the user's phone. On a trusted pair it clears in the background, often in about 175 milliseconds, with no tap. When anything changes, the user is challenged with Allow / Deny, two-way SMS or a TOTP code. Spriv transfers no personally identifiable information, which keeps the authentication service out of your cardholder data flows.
The result is MFA on every non-console login into the CDE that people do not try to switch off, which is the best evidence of a working control you can hand an assessor.
A quick 8.4.2 readiness check
- List every way a person reaches a CDE system: RDP, SSH, web consoles, database clients, jump hosts.
- Confirm each one demands MFA, including from inside the corporate network.
- Find every bypass: trusted IP ranges, service accounts used interactively, MFA-exempt groups. Document, approve and time-limit them, or remove them.
- Check that remote users authenticate twice where both 8.4.3 and 8.4.2 apply.
- Keep authentication logs your QSA can sample.
For the wider picture across PCI DSS, HIPAA, FFIEC and SOX, read the MFA compliance guide and the PCI DSS multi factor authentication page.