Compliance & Privacy · 2026-10-19

PCI DSS 4.0.1 Requirement 8.4.2: Phishing-Resistant MFA for Cardholder Data Environments

By J. W. Bouckaert

Three requirements, one exemption

PCI DSS version 4.0.1 was published on 11 June 2024 as a limited revision of 4.0, with no requirements added or removed. Version 4.0 was retired on 31 December 2024, and the future-dated requirements that 4.0 had introduced, 51 of its 64 new ones, became mandatory on 31 March 2025. Requirement 8.4.2 is one of those, and in the 4.0.1 text it reads: "MFA is implemented for all non-console access into the CDE." Its stated objective is that "access into the CDE cannot be obtained by the use of a single authentication factor".

Two neighbours frame it. Requirement 8.4.1 has required MFA for all non-console access into the CDE by personnel with administrative access since version 3.2, and 8.4.3 requires MFA for "all remote access originating from outside the entity's network that could access or impact the CDE". The applicability notes on 8.4.2 are explicit that these stack: "MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access." The worked example in the standard has a person authenticating twice, once to enter the network remotely and once to enter the CDE from it. The standard also allows the CDE control to sit "at the network or system/application level; it does not have to be applied at both levels".

Then the exemption, which 4.0.1 added and which the Summary of Changes describes as an applicability note "that this requirement does not apply to user accounts that are only authenticated with phishing-resistant authentication factors". The full note lists three exclusions: application or system accounts performing automated functions, user accounts on point-of-sale terminals that see one card number at a time for a single transaction, and "user accounts that are only authenticated with phishing-resistant authentication factors". The first two existed in 4.0. The third is new, and it is the subject of this post. Our earlier post on 4.0.1 covers Requirement 8 as a whole and a passkey ceremony that satisfies it; this one stays on the exemption's wording, because the wording is where assessments turn.

The Council's definition

The note points to Appendix G, where 4.0.1 added a definition. Phishing-resistant authentication is "authentication designed to prevent the disclosure and use of authentication secrets to any party that is not the legitimate system to which the user is attempting to authenticate (for example, through in-the-middle (ITM) or impersonation attacks)". Two sentences follow that do most of the work in practice. "Phishing-resistant systems often implement asymmetric cryptography as a core security control." And: "Systems that rely solely on knowledge-based or time-limited factors such as passwords or one-time-passwords (OTPs) are not considered phishing resistant, nor are SMS or magic links. Examples of phishing-resistant authentication includes FIDO2."

The definition is about the protocol rather than the user. NIST's Digital Identity Guidelines, finalised as SP 800-63B-4 in July 2025, say the same thing more precisely: phishing resistance is "the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier", and it must do so "without relying on the vigilance of the claimant". NIST recognises two ways to get it. Channel binding ties the authentication to the TLS session, as a PIV smart card with client-authenticated TLS does. Verifier name binding ties it to the verifier's authenticated domain name, which is how WebAuthn works: the authenticator chooses its secret "based on the authenticated domain name of the verifier", so a credential registered to the real domain produces nothing useful for a look-alike. A one-time code, by contrast, "SHALL NOT be considered phishing-resistant because the manual entry does not bind the authenticator output to the specific session being authenticated". CISA's 2022 guidance put the market position bluntly: "The only widely available phishing-resistant authentication is FIDO/WebAuthn authentication."

So the category is small and well defined. FIDO2 and WebAuthn credentials, including passkeys, and certificate-based smart cards qualify. Passwords, TOTP apps, push approvals with or without number matching, SMS codes and emailed magic links do not, whatever their other merits, because each of them can be relayed to the real site by an impostor sitting in the middle.

The May 2025 clarifications

The Council answered the two questions everyone asked in a pair of FAQs published in May 2025. FAQ 1595 asks whether synced passkeys count, and the answer is yes: "Passkeys synced across devices (also called synced passkeys), implemented according to the FIDO2 requirements, are considered phishing-resistant authentication, and may be used as a single authentication factor in place of multi-factor authentication (MFA) to meet PCI DSS Requirement 8.4.2." It adds the boundary: "Passkeys not implemented according to the FIDO2 requirements must include an additional factor to meet PCI DSS Requirements 8.4.1, 8.4.2, and 8.4.3 for MFA."

FAQ 1596 asks whether phishing-resistant authentication alone satisfies 8.4.1 or 8.4.3, and the answer is no: "phishing-resistant authentication cannot be used without an additional authentication factor to meet Requirements 8.4.1 or 8.4.3 because of the increased risk with these types of access." It must be combined with another factor, "for example, a password, PIN, or biometric".

Read together, the position is this. For an ordinary user entering the CDE from inside the network, a FIDO2 credential on its own meets 8.4.2. For an administrator, and for anyone coming in from outside, the same credential must be paired with a second factor type. Synced passkeys are in, which matters because platform passkeys on phones and laptops sync by default and the Council could have drawn the line at device-bound credentials; NIST draws exactly that line at AAL3, where "syncing violates the non-exportability requirements", while accepting syncable authenticators at AAL2. The Council also replaced its 2017 MFA information supplement in August 2025 with a broader Authentication Guidance that covers phishing-resistant methods; that document sits behind the Council's library and is the next thing an assessor will cite.

The word that decides the assessment

The exemption applies to accounts "only authenticated with phishing-resistant authentication factors". The plain reading of "only" is the one that catches deployments. An account that authenticates with a passkey on Monday and with a password plus a one-time code when the passkey is unavailable on Tuesday is not only authenticated with phishing-resistant factors; it has a phishable path, and an attacker who can phish will use it. On that reading the exemption is a property of the account's configuration, not of its usual login, and an account with a password fallback still needs MFA under 8.4.2 in the ordinary way.

That reading is ours, from the text; the Council has not published a FAQ on fallback paths. It is also the reading an assessor can test, because the testing procedures for 8.4.2 are concrete. 8.4.2.a: "Examine network and/or system configurations to verify MFA is implemented for all non-console access into the CDE." 8.4.2.b: "Observe personnel logging in to the CDE and examine evidence to verify that MFA is required." An assessor relying on the exemption for a population of accounts will want the identity provider's policy showing that, for those accounts, no other authentication method is enabled, the enrolment records showing a FIDO2 credential per account, and a demonstration that a login with any other method is refused. The exemption is easier to claim for a fresh population than to retrofit onto one that grew up with passwords.

Three further conditions from 8.5.1 apply wherever MFA is used, and two of them apply to phishing-resistant deployments as well. The MFA system must not be susceptible to replay; 4.0.1 added a definition, an attacker intercepting a valid transmission and resending or redirecting it, and WebAuthn's per-ceremony challenge satisfies it by construction. It "cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period", which is the clause a recovery flow has to be designed against. Where two factors are used they must be of different types, and "using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication"; a passkey with a device PIN is one factor from the standard's point of view, the possession of the key, which is why the FAQ 1596 pairing for administrators calls for a password, PIN or biometric as the second.

A carrier check beside the definition

A carrier check does not make anything phishing-resistant. The Appendix G definition is about whether an authentication secret can be captured and used by an impostor, and a check of a SIM's state at the network says nothing about that. What it does is speak to the factor the phishable methods depend on. An SMS code is "something you have" only if the phone number is still in the customer's hands, and a SIM swap or port-out is the event that moves it. A fresh carrier check beside an SMS code turns a factor the Council excludes into one whose weakness is at least observed; it does not turn it into one the Council includes, and a deployment should not claim otherwise.

The stronger use is beside the credential the Council does include. A FIDO2 credential answers the question of who is presenting it; it does not answer whether the person's account has been targeted this hour. For the second-factor pairings that 8.4.1 and 8.4.3 require, and for the step-up decisions that 8.5.1's exception process should be gating, a carrier signal is an independent channel that the attacker who phished nothing still has to defeat. The freshness argument is the one that matters there: a check from this minute is evidence, a check from this morning is history.

An assessor's view of the three requirements

One consequence of the layout is worth stating for planning. Because 8.4.3 and 8.4.2 are separate instances, a remote worker on a phishing-resistant credential authenticates with two factors at the perimeter and may then enter the CDE on the credential alone, if their account is configured with nothing else. That is the deployment the exemption was written for, and it is the one that removes the daily one-time code from the people who handle card data most.

Left open

The Council's June 2026 request for comments was on version 4.0.1 itself rather than on a successor, so the text above is the text for the foreseeable assessment cycle. Two questions have no published answer. Whether an account with a disabled but re-enableable password still counts as "only" phishing-resistant is a matter for the assessor and the Authentication Guidance, and we have given our reading. And whether the Council will follow NIST in distinguishing synced from device-bound credentials for the higher-risk requirements is a question FAQ 1596 answers only by requiring a second factor either way. Our passkey and carrier ceremony is built for the second-factor case, which is the one every administrator is in.

Start free · Test the API