Compliance & Privacy · 2026-05-22

PCI DSS 4.0.1 and Identity Verification: Stronger Authentication Without Storing Cardholder Data

By J. W. Bouckaert

The quiet tightening of Requirement 8

PCI DSS 4.0 was published in March 2022. The transition window for the future-dated requirements closed on 31 March 2025, at which point a long list of authentication controls became mandatory rather than aspirational. Version 4.0.1, published in June 2024, is a clarifications-only release: no new requirements, but several sharpened definitions around multi-factor authentication, replay resistance, and account independence.

The combined effect is that as of 2026, identity verification systems serving the payment ecosystem are operating under a regime that explicitly contemplates phishing-resistant authentication, requires MFA for all non-console CDE access, and treats SMS one-time passwords as deprecated in everything but name.

The standard did not ban SMS OTPs. It did define MFA in a way that makes SMS OTPs structurally non-compliant for any new deployment that takes the independence and replay-resistance language seriously.

This is the context in which carrier-signal-augmented passkey authentication becomes interesting. Not because it is novel, but because it is the only widely deployable architecture that satisfies the future-dated requirements without dragging additional cardholder data into scope.

Requirement 8 in 2026

The relevant requirements, all effective:

8.3.6—Password composition

Minimum 12 characters (or the maximum supported by the system if less than 12). This is a backstop rather than a strategy: an environment that still depends on password complexity for primary authentication has already lost.

8.4.2—MFA for non-console access into the CDE

All non-console access into the CDE, for all personnel, must use multi-factor authentication. The previous carve-outs for administrative-only or remote-only access are gone.

8.4.3—MFA for all remote access

Remote network access from outside the entity's network—including remote access by vendors and third parties—must use MFA. This catches the long tail of contractor and managed-service-provider access that historically relied on a VPN password and a phone call.

8.5.1—MFA implementation requirements

MFA systems must be implemented to prevent misuse. The standard enumerates five conditions: factors are not known to be compromised, at least two different factor types are used, success requires all factors, factors are independent (compromise of one does not affect the others), and the system is resistant to replay attacks.

8.6.3—Application and system account credentials

Passwords or passphrases for accounts used by applications and systems must be changed periodically and have appropriate complexity for the level of risk to the system.

The architectural implication is plain: the era of "password plus SMS code" as a default MFA pattern for the CDE is over.

The phishing-resistance pivot

The PCI SSC's Information Supplement on Multi-Factor Authentication (v1.0, February 2017) and the council's updated 2024 MFA guidance treat phishing-resistant authenticators as the preferred path. Both align directly with the NIST SP 800-63-4 Digital Identity Guidelines, finalised in July 2025, which treat device-bound FIDO2 hardware authenticators as AAL3-capable when correctly bound to the relying party, and synced platform passkeys as AAL2.

The deprecation pattern across federal and payment standards is now coherent:

The last row is the one PCI DSS 4.0.1 does not explicitly anticipate, because the standard predates the maturity of programmable carrier APIs. But every individual requirement it imposes is satisfied—often more cleanly than by older patterns.

A carrier-signal-augmented passkey ceremony

The ceremony has five stages. None of them touch cardholder data.

                       PasskeyBridge / Relying Party
                                   |
[ User device ] --(1) Begin authentication---->|
                                               |
       <---(2) WebAuthn challenge + RP ID -----|
                                               |
[ User performs UV (biometric/PIN) ]           |
                                               |
       ---(3) Signed assertion ---------------->|
                                               |
                                               |--(4)--> [ Carrier API ]
                                               |          (HMAC of MSISDN,
                                               |           returns: swap?,
                                               |           tenure, port-out)
                                               |
                                               |<--(4') boolean signal -----
                                               |
       <---(5) Auth decision (accept/step-up)--|

Stage 1 starts the ceremony. Stage 2 sends a WebAuthn challenge bound to the relying-party identifier; this is the anti-phishing primitive. Stage 3 returns a signed assertion from the user's platform or roaming authenticator with UV='required' enforced. Stage 4 runs in parallel on the relying party: the user's enrolled MSISDN is HMAC'd with a tenant-held key and queried against a carrier API for a real-time SIM-status boolean. Stage 5 combines the assertion verification with the carrier signal to make a final decision—accept, step-up, or deny.

Three properties of this design matter for PCI scope:

1. No cardholder data is processed in any stage. The ceremony authenticates a user; it does not transmit a PAN, expiry, CVV, or any SAD.
2. The MSISDN is never stored or transmitted in plaintext to the carrier signal layer. It is hashed at the edge using HMAC-SHA-256 under a server-held pepper, and only the hash is correlated against the carrier's matching hash. This is the architectural pattern detailed in our piece on hashed-signal architecture for cross-border carrier lookups.
3. The carrier signal is a boolean derived from a hash. The relying party receives { swap_within_24h: false, line_tenure_days: 1247, last_port_out: null }—no subscriber identifier, no PII, no payment context.

Mapping the ceremony to each requirement

This is the audit-facing table that matters. Every requirement that applies to the authentication flow, and how the architecture satisfies it.

The independence row is the one most likely to come up in an audit. The PCI SSC's MFA supplement is explicit: independence is about compromise propagation, not physical separation. A passkey unlocked by a biometric on a device the attacker controls is not independent of an SMS OTP delivered to that same device—malware reads both. A passkey on the device, paired with a SIM-status signal queried from the carrier over a separate authenticated API channel, satisfies independence because the carrier's view of the SIM is not derivable from device compromise.

For deeper context on the freshness TTL question—and why a SIM-swap check from twelve hours ago is a historical fact rather than a security signal—see carrier signal freshness: TTL matters more than signal strength.

Signals the carrier check detects

The independence story is only as strong as the signals being queried. The four most useful for PCI-scoped flows:

A high-value transaction or admin escalation can require a stricter combination: SIM-swap-free for 72 hours, tenure greater than 90 days, and not roaming. A low-friction sign-in can require only that no swap occurred in the last hour. This is the policy surface that PCI does not specify—it requires only that the authentication be resistant to replay and compromise—and where most of the engineering judgement actually lives.

For the underlying detection mechanics, see how to detect a SIM swap in the next 50 milliseconds.

The cardholder data environment

This is the conversation that decides whether an identity provider becomes part of your CDE or stays adjacent to it. The relevant text is in PCI DSS 4.0.1's Scope of PCI DSS Requirements section:

The CDE comprises systems and networks that store, process, or transmit account data (cardholder data and/or sensitive authentication data), and system components that are not isolated from such systems.

An identity provider that authenticates users for access to a merchant's payment systems is not, by virtue of the authentication, storing or transmitting account data. It is connected-to-CDE infrastructure under the PCI SSC's scoping guidance—which means it must be hardened, network-segmented, monitored, and subject to change control—but it does not inherit the full set of CDE controls.

Three architectural choices preserve this distinction:

1. The authentication assertion contains no payment context. A FIDO2 assertion is a signed challenge response. It does not, and must not, carry a PAN or a token derived from one.
2. The carrier signal layer operates on HMACs. It never receives a phone number in plaintext, and it never receives any payment data at all.
3. Session issuance and account data lookup are separated. The identity provider returns an authenticated subject identifier; the merchant's CDE systems use that identifier to retrieve account data from their own stores. The identity provider never reads or writes account data.

The boundary is preserved by the architecture. This is the distinction between zero-PII identity verification and zero-PII-by-promise.

Replay resistance in two layers

Requirement 8.5.1's replay-resistance clause is satisfied at two layers in this architecture:

WebAuthn ceremony layer. The relying party generates a fresh challenge for every authentication. The challenge is bound to the relying-party identifier and is single-use. The authenticator signs the challenge along with the origin and a counter; replay of a captured assertion fails because the challenge does not match.

Token binding layer. The session token issued after authentication is bound to a client-held key using DPoP (RFC 9449). A stolen bearer token cannot be replayed from a different client because the DPoP proof requires the original key. This is the DPoP shadow telemetry pattern that detects token replay attempts in production traffic.

Together, these two layers exceed the standard's text. The standard requires resistance; the architecture provides detection as well.

SMS OTPs

SMS OTPs are not banned by PCI DSS 4.0.1. They are also not, in any practical reading, defensible as a primary second factor for a new deployment. The reasons are documented across multiple authoritative sources:

• NIST SP 800-63B has classified out-of-band SMS as a "restricted authenticator" since 2017
• The FBI Internet Crime Complaint Center reports SIM swap losses of over $48 million in 2023
• The FCC's 2023 SIM swap and port-out order requires carriers to implement enhanced authentication for SIM changes and port-outs, an acknowledgement that the historical control set was inadequate

The PCI SSC's MFA supplement does not say "do not use SMS". It says SMS may be used as an out-of-band authenticator if the implementation addresses the known weaknesses. In practice, the known weaknesses cannot be addressed by an SMS implementation alone. They can be addressed by querying the carrier—which is the architectural inversion at the heart of this design. Instead of receiving a code over SMS and trusting that it reached the right phone, the relying party queries the carrier directly to verify that the phone has not been moved, ported, or swapped.

That change is a different model of trust, well beyond a small refactor: from "the carrier delivered a secret to a number" to "the carrier confirmed the line's authoritative state at the moment of authentication". The latter is what Requirement 8.5.1.e calls replay-resistant.

The 3PAO test plan

A 3PAO performing a Report on Compliance assessment against this architecture will test, at minimum:

1. Ceremony completeness. Can the auditor trigger a CDE-access authentication and observe both the WebAuthn assertion and the carrier signal in the audit log?
2. Factor independence. Is the carrier signal derived from infrastructure that is not on the authenticating device or under the user's direct control?
3. Replay protection. Does a captured assertion fail when replayed? Does a captured DPoP-bound token fail when used by a different client?
4. Logging and monitoring. Are authentication events logged in a tamper-evident chain (Requirement 10), and do they include enough metadata to detect anomalies without exposing PII?
5. Carrier API trust boundary. Is the external carrier service documented under SA-9 equivalents in the System Security Plan, with the data exchanged characterised as non-attributable hashes?
6. No expansion of CDE. Can the auditor confirm that no cardholder data, no PAN, and no sensitive authentication data passes through the identity provider's infrastructure?

Items 5 and 6 are where most of the documentation work concentrates. They are also where a zero-PII architecture pays for itself in audit hours, because the answers are short and the evidence is small.

Horizon

PCI DSS 4.0.1 will be in force for years. Version 5.0 is not on the published roadmap. The realistic horizon is that the requirements discussed here are the standing requirements for the rest of the decade, with clarifications rather than new mandates from the PCI SSC.

The architectural conclusion follows: organisations that built their payment authentication around passwords and SMS OTPs are migrating. Organisations that built around passkeys without a real-time carrier signal are partially compliant—they satisfy 8.4.2 but struggle with 8.5.1.d when the authenticator and the workstation are the same device. Organisations that combine phishing-resistant passkeys with an in-request carrier attestation, operated against hashed identifiers, are the only group that meets every clause of Requirement 8 without expanding the cardholder data environment.

That is the architectural posture PasskeyBridge was designed to enable. Not compliance by checklist. Compliance by ceremony.

Start free · Test the API