Before PCI DSS 4.0, multi-factor authentication (MFA) was required for remote access and for administrators. Version 4.0 extended it to everyone who accesses the cardholder data environment (CDE), and added requirements for how the MFA system itself behaves. Those additions were future-dated until March 31, 2025, and they are now tested like any other requirement.
Most teams already enforce MFA at the identity provider. The gaps an assessor finds are elsewhere: a path into the CDE that skips the identity provider, an exemption nobody documented, a break-glass account with a password and nothing else, or a factor that is not really a second factor.
This article covers where Requirement 8 requires MFA, what the exemptions are, what the MFA system must do, the password and service account rules that sit beside it, and the evidence to prepare. For MFA rollout in general, see enforcing MFA for every user.
The three places MFA is required
Requirement 8.4 has three parts. Each covers a different kind of access.
| Requirement | Who it covers | Which access |
|---|---|---|
| 8.4.1 | Personnel with administrative access | All non-console access into the CDE |
| 8.4.2 | All personnel, not only administrators | All access into the CDE, subject to the applicability notes |
| 8.4.3 | All personnel and third parties, including vendors with support or maintenance access | All remote network access from outside your network that could access or affect the CDE |
Non-console access means logical access over a network interface, rather than a direct physical connection to the system. In cloud and remote-first environments, almost all administrative access is non-console.
Requirement 8.4.3 is broader than it looks. It is not limited to access into the CDE. Remote access to your network that could reach or affect the CDE counts, which in a flat or loosely segmented network means almost all remote access.
MFA twice: once for the network, once for the CDE
The applicability notes make a point that surprises people. MFA for remote access and MFA for access into the CDE are separate requirements, and one does not satisfy the other.
If an engineer connects to your network remotely, they authenticate with MFA under 8.4.3. If they then connect from your network into the CDE, they authenticate with MFA again under 8.4.2. A VPN with MFA, followed by a password-only login to a CDE server, meets the first requirement and fails the second.
Designs that put the CDE behind a single access gateway with MFA, and allow no other path in, make this easier to reason about. The gateway becomes the place both requirements are met and the place an assessor tests.
What 8.4.2 does not cover
The applicability notes for 8.4.2 exclude:
Application or system accounts performing 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, an exemption added in version 4.0.1
The third exemption is worth understanding. It recognizes that a phishing-resistant method, such as a FIDO2 security key or platform authenticator used as the only factor, addresses the risk 8.4.2 targets. It applies to 8.4.2 only. The administrative and remote access requirements in 8.4.1 and 8.4.3 still require MFA. Read the guidance in the standard before relying on it, and agree the design with your assessor.
How the MFA system itself must work
Requirement 8.5.1 sets four conditions on the MFA system:
It is not susceptible to replay attacks. A captured authentication exchange cannot be reused.
It cannot be bypassed by any user, including administrators, unless the bypass is specifically documented and authorized by management, on an exception basis, for a limited time.
It uses at least two different types of factor. The types are something you know, something you have and something you are. Two passwords, or a password and a security question, are one type twice.
Every factor must succeed before access is granted. Passing the first factor alone grants nothing.
The second condition is where most findings come from. Break-glass accounts, emergency access procedures and service desk resets can all become bypasses. Each needs a documented exception with an approver and an end date, or it needs MFA.
Factor independence deserves thought too. If one device both holds the password and receives the one-time code, compromising that device yields both factors. The Council has published supplementary guidance on MFA that discusses independence. Read it, decide your position on shared devices, and agree it with your assessor before fieldwork.
The password rules beside MFA
MFA does not remove the password requirements. Where passwords are used as an authentication factor, Requirement 8.3 still applies:
At least 12 characters, or eight where a system does not support 12, with both numbers and letters (8.3.6)
No reuse of any of the last four passwords (8.3.7)
Lockout after no more than 10 invalid attempts, for at least 30 minutes or until identity is confirmed (8.3.4)
Where a password is the only factor for user access, either change it at least once every 90 days or analyze the account's security posture dynamically to decide access in real time (8.3.9)
Requirement 8.2.8 adds that a session idle for more than 15 minutes requires the user to authenticate again. Requirement 8.2.6 asks that inactive user accounts are removed or disabled within 90 days.
System and application accounts
Requirement 8.6 covers accounts used by systems and applications, and it is where much of the remaining risk sits.
Interactive login (8.6.1). If a system account can be used to log in interactively, that use must be prevented unless needed for an exceptional circumstance, limited in time, justified, approved by management, tied to a confirmed individual identity, and attributable to that person.
No hard-coded passwords (8.6.2). Passwords and passphrases for these accounts must not appear in scripts, configuration files or source code.
Protection and rotation (8.6.3). Passwords for these accounts are protected against misuse and changed on a schedule your targeted risk analysis sets, with complexity suited to how often they change.
A secrets manager that issues credentials at runtime addresses 8.6.2 and makes 8.6.3 a configuration setting rather than a manual task.
MFA evidence to prepare
Prepare these before fieldwork:
A list of every access path into the CDE and the point where MFA is enforced on each
Identity provider and gateway configuration showing MFA policies, including any exclusions
An exception register for MFA bypasses, with approver, reason and expiry
Sample authentication logs showing MFA on real logins
Vendor and third-party remote access configuration, showing MFA under 8.4.3
An inventory of system and application accounts, with how their credentials are stored and rotated
Privileged access deserves its own review, and the approach in managing privileged access fits the administrative accounts 8.4.1 covers. If your identity provider is the main enforcement point, SSO as a compliance control covers the evidence that makes it credible.
How TrustLynce helps
TrustLynce runs user access reviews for CDE systems on the six-month cycle Requirement 7.2.4 sets, with decisions and remediation recorded where they are made. Evidence from your identity provider is collected on a schedule, and continuous monitoring routes a failing MFA control to its owner.