Passkeys, MFA, and PCI DSS Compliance: A Guide to Requirements 8.3.3, 8.3.11, and 8.5.1

For organizations that process payment card data, strong authentication controls are imperative. Stolen or compromised credentials remain one of the most common ways attackers gain access to systems—and once inside, attackers can quickly move laterally to access sensitive data.

That’s why PCI DSS places such a strong emphasis on authentication controls—particularly multi-factor authentication (MFA).

At the same time, authentication technology is evolving quickly. Over the past few years, passkeys—a passwordless authentication method built on cryptographic key pairs—have gained significant traction. Recently, guidance from the National Institute of Standards and Technology (NIST) confirmed that properly implemented passkeys can meet Authentication Assurance Level 2 (AAL2) requirements.

This development has important implications for organizations that must comply with PCI DSS, particularly requirements 8.3.3, 8.3.11, and 8.5.1.

Here’s what you need to know:

PCI DSS requirement 8.3.3 focuses on securing authenticator recovery processes so attackers cannot bypass MFA through account recovery workflows.
Requirement 8.3.11 mandates that MFA factors be unique and not shared by multiple accounts.
Requirement 8.5.1 addresses MFA session security, ensuring authenticated sessions cannot be hijacked after login.
Passkeys can satisfy PCI DSS MFA requirements when implemented correctly because they combine device possession with biometrics or a device PIN.

Passkeys and Modern MFA Implementations

Many organizations are already leveraging passkey-based authentication through platform tools such as Windows Hello, Google Passkeys, and Apple iCloud Keychain. These technologies are built directly into modern operating systems and browsers, allowing organizations to deploy phishing-resistant authentication without requiring separate hardware tokens or authentication applications.

Passkeys rely on cryptographic key pairs rather than traditional credentials like passwords. A public key is stored by the service provider, while the corresponding private key remains securely stored on the user’s device.

During authentication, the device proves possession of the private key—typically unlocked using biometrics or a device PIN—without transmitting the key itself. Because the authentication event requires both device possession and biometric or PIN verification, passkeys effectively provide two authentication factors within a single user interaction.

Recent guidance from NIST allows properly implemented passkeys to meet AAL2 requirements. This level of assurance aligns with the strength expected by standards like PCI DSS.

PCI DSS Requirement 8.3.3: Verifying Identity Before Modifying Authentication Factors

One of the most common weaknesses in authentication systems isn’t the login process itself—it’s what happens when authentication factors need to be reset or replaced.

PCI DSS requirement 8.3.3 requires that a user’s identity be verified before any authentication factor is modified, reset, or replaced. This control helps prevent attackers from bypassing MFA by exploiting account recovery workflows such as password resets, help desk requests, or device re-enrollment.

Without strong identity verification during these processes, attackers may be able to social engineer support personnel or abuse automated recovery mechanisms to gain control of an account. For example, if a password alone can be used to reset a second authentication factor, the MFA control effectively collapses back into single-factor authentication.

Organizations should carefully evaluate how authentication factors are recovered or replaced, particularly when manual processes such as help desk verification are involved. Identity verification procedures should provide assurance equivalent to the original authentication process.

Passkey-based authentication can strengthen this area because authentication keys remain stored on user devices rather than being stored on centralized systems. However, organizations still need to review device recovery and account restoration workflows to ensure they do not introduce unintended bypass mechanisms.

PCI DSS Requirement 8.3.11: MFA Factors Must Be Assigned to Individual Users

PCI DSS requirement 8.3.11 mandates that MFA factors be uniquely assigned to an individual user and cannot be shared between multiple accounts. This ensures authentication activity can always be attributed to a specific identity and prevents organizations from relying on shared authentication mechanisms.

Passkeys align well with this requirement because cryptographic credentials are generated uniquely for each account and stored securely on the user’s device. The private key never leaves the device and typically requires biometric verification or a device PIN that is unique to each user.

PCI DSS Requirement 8.5.1: MFA Session Security

Strong authentication is only part of the equation. Even when MFA is used—including modern methods such as passkey-based authentication—attackers may attempt to compromise an authenticated session after the login process has completed.

PCI DSS requirement 8.5.1 addresses this risk by requiring controls that protect MFA sessions from interception or reuse. These protections are designed to prevent attacks such as session token theft, replay attacks, and man-in-the-middle or relay attacks that could allow a bad actor to take over an authenticated session.

For example, if an attacker is able to intercept a session token after authentication has occurred, they may be able to reuse that session without completing the MFA challenge themselves. Similarly, replay attacks attempt to proxy authentication requests between a legitimate user and a target system in real time in order to bypass authentication protections.

Using passkeys can help organizations meet this requirement. “Passkeys generate unique challenge tokens for each authentication attempt. In turn, any intercepted authentication data cannot be used in separate login attempts,” said Kyle Kofsky, senior consultant and Lead QSA at BARR Advisory. “In short, your credentials cannot be stolen since they are unique for each login (i.e., each use of the passkey), and the private key used to respond to the challenge token is stored locally on your device’s authenticator app.”

The Bottom Line

Credential theft remains one of the most common ways attackers gain access to sensitive systems, making strong authentication controls essential for protecting the cardholder data environment.

Recent guidance from NIST allowing passkeys to meet AAL2 requirements opens the door for organizations to use passwordless authentication models while still meeting regulatory MFA expectations.

For organizations working toward PCI DSS compliance, passkeys can play an important role in modern authentication strategies, provided they are implemented with secure recovery workflows and strong session protections.