MFA Under PCI DSS v4.0.1: Requirements 8.4.1, 8.4.2, 8.4.3 and 8.5.1 Explained

Multi-factor authentication is where PCI DSS v4.x quietly raised the bar the most. Under v3.2.1, MFA was largely an administrator and remote-access control. Since 31 March 2025, it is required for everyone accessing the cardholder data environment, and the standard now also cares about how well your MFA is implemented, not just whether it exists.

We still meet environments that believe their VPN token satisfies PCI DSS. It often does not, on its own. This deep-dive walks through the three access scenarios in Requirement 8.4, the implementation rules in 8.5.1 that trip up real deployments, and the questions your assessor will ask under PCI DSS v4.0.1.

The three MFA scenarios in Requirement 8.4

Requirement 8.4 breaks MFA into three distinct situations, and a compliant programme has to handle all that apply.

• 8.4.1: administrators, all non-console access into the CDE. Anyone with administrative capability authenticating over the network to CDE systems uses MFA. This was already the rule under v3.2.1 and carries forward unchanged.
• 8.4.2: everyone, all access into the CDE. The big v4 change, mandatory since 31 March 2025. Every user, administrator or not, authenticating over the network into the cardholder data environment goes through MFA. The application accounts and machine identities are handled elsewhere (Requirement 8.6); 8.4.2 is about people.
• 8.4.3: all remote access from outside the network. Anyone connecting in from outside, staff, contractors, vendors, third-party support, authenticates with MFA before reaching the internal network at all.

The scenario people miss is the combination: a remote administrator can quite legitimately face MFA twice, once at the network boundary under 8.4.3, and again at the CDE boundary under 8.4.1/8.4.2. The Council has been explicit that these are separate control points; one factor ceremony at the VPN does not automatically satisfy the CDE requirement. Whether your architecture can justify a single strong implementation covering both is exactly the kind of question to settle with your assessor before assessment week.

Requirement 8.5.1: the rules your MFA system itself must meet

New in v4.x, and in force since March 2025, Requirement 8.5.1 stops treating MFA as a checkbox and starts testing its quality. Your MFA implementation must:

• Resist replay attacks. Codes and approvals must not be reusable. Time-based one-time passwords, FIDO2 keys and challenge-response mechanisms qualify; static secrets pretending to be a second factor do not.
• Not be bypassable. No standing exemptions for convenience, no “trusted network skips MFA” carve-outs, no help-desk override that quietly disables it. Any exception must be individually authorised by management, for a limited time, and documented.
• Use at least two different factor types. Something you know, something you have, something you are, and they must be from different categories. A password plus a security question is one factor twice, not two factors.
• Grant access only after all factors succeed. The system must not reveal which factor failed, and no session should be established on partial success.

This is where real-world deployments stumble. SMS one-time codes remain technically permissible as a possession factor, but between SIM-swap attacks and interception they are the weakest qualifying option, and the industry direction, reinforced by the Council’s own guidance glossary work on phishing-resistant authentication, is firmly toward authenticator apps with number matching, hardware tokens, or FIDO2/passkeys. If you are investing in MFA in 2026, deploy phishing-resistant factors and skip the intermediate step.

Push fatigue: the attack your MFA rollout invited

A word on push-notification MFA, because it features in a growing share of the breaches we read about. Attackers who have phished a password simply send login pushes until a tired user taps approve. High-profile intrusions have started exactly this way. Push approval without context is barely MFA under 8.5.1’s spirit: it is bypassable by persistence. Number matching, where the user must type a code displayed on the login screen into the authenticator, closes most of the gap at essentially zero cost, and every major identity platform now supports it. If your MFA sends bare approve/deny pushes, changing that setting is the highest-value five minutes available in your identity console.

Common failure patterns at assessment

1. MFA at the VPN only. The remote factor satisfies 8.4.3, then flat internal access lets anyone who is inside reach CDE systems with a password. Since March 2025, that fails 8.4.2. Pairing MFA with proper segmentation is what makes the CDE boundary enforceable.
2. Administrator exemptions. The break-glass account that skips MFA “for emergencies” and is used every week. Break-glass is legitimate; routine use of it is a bypass, and assessors look at its logs.
3. Shared factors. A team hardware token in a drawer, or an authenticator seeded on a shared tablet. Factors must tie to individual identities, and Requirement 8 is built on individual accountability.
4. Cloud consoles forgotten. The management plane of your cloud environment is non-console administrative access to the CDE, as we cover in our cloud guide. Root and owner accounts without enforced MFA are an automatic finding.
5. Self-service enrolment as the weak link. If an attacker with a stolen password can enrol their own authenticator unchallenged, the second factor protects nothing. Enrolment and factor-reset processes need identity verification, and your help desk needs a script that resists social engineering.

Making it work operationally

The successful pattern we see: put MFA at a small number of well-chosen boundaries (identity provider, VPN, CDE access gateway, cloud console) rather than bolting it onto every application separately; use phishing-resistant factors for administrators immediately and roll them to all CDE users over a defined window; align session lifetimes so re-authentication is frequent enough to matter without breeding workarounds; and monitor the MFA system itself, because failed-push storms and unusual enrolment activity are among the earliest signals of an account-takeover attempt. Requirements 10.4.1.1’s automated log review expectations apply to authentication logs as much as anything else.

Frequently asked questions

Does PCI DSS require MFA for all users now?

For all users accessing the cardholder data environment over the network, yes. Requirement 8.4.2 became mandatory on 31 March 2025 and extends MFA beyond administrators to every person accessing the CDE, with 8.4.3 separately covering all remote access into the network from outside.

Is SMS-based MFA allowed under PCI DSS v4.0.1?

Yes, an SMS one-time code is a possession factor and can satisfy the requirement today. It is also the weakest qualifying option given SIM-swap and interception attacks, and the practical direction of travel is toward authenticator apps with number matching, hardware tokens or FIDO2 passkeys. New deployments should start phishing-resistant rather than plan a second migration.

Do users need MFA twice, at the VPN and again at the CDE?

They are two separate control points: Requirement 8.4.3 covers remote access into the network, and 8.4.1/8.4.2 cover access into the CDE. Depending on architecture, one strong implementation can sometimes serve both boundaries, but that is a design conversation to have with your QSA, not an assumption to make. A VPN factor plus flat internal network does not satisfy 8.4.2.

What makes an MFA implementation fail Requirement 8.5.1?

The usual culprits: replayable factors, bypass paths (trusted-network exemptions, routine break-glass use, help-desk overrides), two factors of the same type such as password plus security question, or systems that grant partial access before all factors succeed. Assessors now test the implementation, not just its existence.

Check your MFA before your assessor does

Cianaa’s QSAs review MFA architectures against Requirements 8.4 and 8.5.1 as part of readiness assessments across New Zealand and Australia, including the boundary questions that generate the most assessment-week friction. If you are unsure whether your implementation would hold up, talk to our assessors or start with our PCI DSS services overview.