Requirement 8.4.2 in PCI DSS v4.0 requires multi-factor authentication (MFA) for all access into the cardholder data environment (CDE), not just administrative access. It's a best practice until March 31, 2025, and mandatory after that. In plain terms, every person who reaches CDE systems needs MFA, including ordinary users on your internal network, with a few narrow exceptions. It sits alongside 8.4.1 (administrative access into the CDE) and 8.4.3 (remote access from outside your network), which are already in effect. A fourth requirement, 8.5.1, sets rules for how the MFA system itself must work and is also future-dated.
What does requirement 8.4.2 require?
The requirement is one line: "MFA is implemented for all access into the CDE."
Under v3.2.1, MFA into the CDE applied only to administrators, plus anyone connecting remotely. Requirement 8.4.2 extends it to every user. Think of customer service staff using a CDE application, finance staff looking up transactions, or developers with access to a CDE database. If they reach the CDE, they need MFA once the requirement takes effect.
With v3.2.1 retired at the end of March, v4.0 is now the only version assessments use. For many organizations, 8.4.2 is one of the larger projects on the 2025 list, and ten months isn't a generous runway.
How do 8.4.1, 8.4.2, 8.4.3 and 8.5.1 fit together?
| Requirement | What it covers | Status |
|---|---|---|
| 8.4.1 | MFA for all non-console access into the CDE for personnel with administrative access | In effect (carried over from v3.2.1) |
| 8.4.2 | MFA for all access into the CDE | Best practice until March 31, 2025 |
| 8.4.3 | MFA for all remote network access from outside the entity's network that could access or impact the CDE, for all personnel and for third parties and vendors | In effect (carried over from v3.2.1) |
| 8.5.1 | MFA systems are configured correctly | Best practice until March 31, 2025 |
Requirements 8.4.1 through 8.4.3 decide where MFA is needed. Requirement 8.5.1 decides whether what you've deployed counts as MFA at all.
What do the v4.0 applicability notes say?
The applicability notes carry much of the practical detail:
- Exclusions. Requirement 8.4.2 doesn't apply to application or system accounts performing automated functions. It also doesn't apply to user accounts on point-of-sale terminals that can access only one card number at a time to facilitate a single transaction, such as cashier IDs.
- MFA twice. MFA is required for both kinds of access in 8.4.2 and 8.4.3, and one doesn't replace the other. A person who connects remotely to your network and then connects from there into the CDE authenticates with MFA twice.
- All system types. The MFA requirements cover cloud and hosted systems, on-premises applications, network security devices, workstations, servers and endpoints. They cover direct access to networks and systems as well as web-based access to an application or function.
- One layer is enough. MFA into the CDE can be implemented at the network level or at the system or application level. It doesn't have to be both. If users hit MFA when they connect to the CDE network, they don't need it again at each system inside.
Two related notes are worth knowing. For 8.4.1, v4.0 treats MFA for non-console administrative access to in-scope systems outside the CDE as a best practice. For 8.4.3, remote access to part of your network that's properly segmented from the CDE doesn't need MFA under that requirement, although the standard recommends MFA for all remote access.
What does 8.5.1 require from the MFA system?
Requirement 8.5.1 has four conditions:
- The MFA system isn't susceptible to replay attacks. Captured authentication data mustn't work a second time. Time-limited one-time codes, challenge-response and cryptographic authenticators meet this. A static secret sent the same way at every login doesn't.
- It can't be bypassed by any users, including administrators, unless the bypass is specifically documented and authorized by management as a time-limited exception. Look for bypass groups, trusted-network exemptions, and settings that fall back to password-only login when the MFA service is unreachable.
- At least two different types of factor are used: something you know, something you have or something you are. Two passwords, or a password plus a security question, are both knowledge factors and don't qualify.
- Success of all factors is required before access is granted. A user shouldn't get into anything on the strength of the first factor alone.
Where does access into the CDE actually happen?
Before choosing an approach, map every human path into the CDE. The usual places to check:
- Jump hosts and bastion servers
- Remote access gateways that land users in CDE network segments
- Direct remote desktop or SSH connections from internal networks
- Web interfaces of CDE applications
- Database clients connecting to CDE databases
- Management consoles for virtualization and cloud platforms hosting CDE systems
- Management interfaces of network and security devices
- Third-party support connections and local or emergency accounts
Most organizations find at least one path they didn't know about. Fix the map before fixing the controls.
How can you implement MFA into the CDE?
Put an MFA gate in front of the CDE
Route all human access through a small number of controlled entry points, such as jump hosts, a remote access gateway or an identity-aware proxy, and enforce MFA there. Then use network security controls to block every other path. One enforcement point is easier to configure, monitor and evidence. The risk is a path around the gate, so confirm with firewall rule reviews and segmentation testing that there isn't one.
Enforce MFA at the application or system level
Where a network gate is impractical, put MFA on the systems themselves. Web applications can sit behind single sign-on with MFA enforced by your identity provider. Servers can require MFA at operating system login for SSH and remote desktop sessions. Watch for local accounts and older protocols that don't pass through the identity provider, because they're a quiet way around the control.
Cover cloud and management access
If CDE systems run in the cloud, enforce MFA for people signing in to the provider's console. Have command-line and API sessions used by people start with an MFA-backed sign-in that issues short-lived credentials. Workloads that call APIs on their own are performing automated functions, but any account a person can log in with is not.
Handle the edge cases
- Emergency accounts. Use MFA where the platform supports it. Where it doesn't, treat the account as a documented, management-approved, time-limited exception under 8.5.1, and monitor every use.
- Shared or service accounts used by people. Interactive use isn't an automated function. These accounts need MFA, plus the controls in 8.2.2 or 8.6.1.
- Third parties. Vendors already need MFA for remote access under 8.4.3. If they go on into the CDE, 8.4.2 applies too.
- Back-office and contact center staff. The point-of-sale exclusion is narrow. A user looking up many accounts in a CDE web application doesn't fit it.
Common gaps to check for
- MFA on the remote access gateway, but nothing between the internal network and the CDE
- Trusted-network rules that skip MFA for users already on the corporate network
- MFA that fails open when the authentication service is down
- Bypass groups created during rollout and never removed
- Local administrator accounts that sidestep the identity provider
Frequently asked questions
Do users on our internal network need MFA to reach the CDE?
Yes, from March 31, 2025. That's the main change 8.4.2 brings.
Does MFA on our remote access gateway cover 8.4.2?
Not by itself. It satisfies 8.4.3 for remote access into your network. The applicability notes say MFA on one type of access doesn't replace MFA on the other, so a remote user who then connects into the CDE authenticates twice.
Do we need MFA on every system inside the CDE?
No. MFA can be enforced at the network level or at the system or application level. It doesn't have to be both.
Do service accounts need MFA?
Accounts performing automated functions are excluded from 8.4.2. If people log in with those accounts interactively, that use isn't automated, and it needs MFA and management under 8.6.1, which is also future-dated to March 31, 2025.
Next steps
- Map every human path into the CDE, including third-party and emergency access.
- Choose your enforcement points: network gate, system level or a mix.
- Check your MFA configuration against the four conditions in 8.5.1.
- Remove bypasses and trusted-network exemptions, and document the few exceptions you keep.
- Roll out in phases and finish well before March 31, 2025, so you have evidence of it working when it counts.