PCI DSS 4.0 shifts customer authentication toward passkeys

At a glance

What this is: This article argues that PCI DSS 4.0 pushes payment authentication away from passwords and OTPs toward passkeys built on FIDO2.

Why it matters: It matters because payment IAM programmes must now balance stronger phishing resistance, third-party access controls, and smoother user authentication without leaving recovery or fallback paths exposed.

👉 Read Descope's analysis of passkeys and PCI DSS 4.0 authentication

Context

PCI DSS 4.0 raises the bar for customer authentication in payment environments by requiring stronger MFA, replay resistance, and broader coverage for remote and third-party access. The problem is that many organisations still rely on passwords, SMS codes, and recovery flows that are easy to phish, reuse, or intercept.

Passkeys change the authentication model by replacing shared secrets with device-bound cryptographic assertions and local biometric or device verification. For identity teams, the governance question is not only whether passkeys reduce risk, but whether enrolment, fallback, and vendor access are controlled tightly enough to satisfy payment obligations without weakening the experience.

This is primarily a human IAM and payment access control issue, but it also affects third-party and privileged access paths that touch the cardholder data environment. The starting point is typical: most organisations know passwords are weak, yet many still depend on them because migration planning, recovery design, and audit evidence are harder than the authentication change itself.

Key questions

Q: How should security teams implement passkeys for payment authentication?

A: Start with the payment paths that matter most: remote admin access, third-party access, and customer logins tied to the cardholder data environment. Replace passwords and SMS OTPs only after enrolment, recovery, and fallback flows are hardened. The goal is not just a stronger factor, but a controlled identity lifecycle around that factor.

Q: Why do passkeys reduce phishing risk compared with passwords?

A: Passkeys are bound to the original website and use cryptographic proof instead of a reusable secret. That means a fake site cannot harvest a password and replay it later. The phishing benefit is real, but it only holds if the organisation also limits weak fallback methods that attackers can abuse instead.

Q: What breaks when password fallback remains too easy after passkey rollout?

A: The organisation preserves a weaker authentication path that users can choose instead of the stronger one. That creates downgrade risk, inconsistent enforcement, and a false sense of improved security because the passkey exists but is not the default protection.

Q: Who is accountable when third-party access into the CDE still uses legacy MFA?

A: The organisation operating the cardholder data environment remains accountable for the access path, even when a vendor or contractor is involved. PCI DSS 4.0 expects remote and third-party access to meet the same authentication discipline as internal access. Teams should assign ownership for every exception and review it as a formal risk decision.

Technical breakdown

Why passwords and OTPs fail PCI DSS 4.0 scrutiny

PCI DSS 4.0 does not treat authentication as a single control. It requires independent factors, resistance to replay, and coverage across remote and third-party access into the cardholder data environment. Passwords fail because they are reusable and phishable. SMS OTPs and many app-based codes also remain vulnerable to interception, session hijacking, and real-time phishing proxies. The standard therefore pushes organisations toward authentication methods that bind the credential to the user’s device and make intercepted values unusable outside the original session.

Practical implication: map every payment-access path to the specific PCI DSS 4.0 requirement it supports, and remove any fallback that still depends on reusable secrets.

How passkeys change customer authentication architecture

Passkeys use public-key cryptography, where the private key stays on the user’s device and the service only stores the public counterpart. During login, the device signs a challenge, which makes replay attacks ineffective because no reusable secret crosses the wire. This matters for both consumer and employee authentication, because the security property comes from possession of a device plus local verification, not from a shared password. In practice, that means the authentication event is tied to the device and session context rather than a password database that can be stolen or stuffed.

Practical implication: treat passkey deployment as an authentication architecture change, not a UI update, and test replay resistance before broad rollout.

Why enrolment and recovery remain the weak points

The strongest passkey deployment can still fail if identity proofing, recovery, or fallback authentication is loose. If enrolment is weak, an attacker can register a rogue device. If recovery is over-permissive, phishing or help-desk abuse can restore access around the new control. PCI environments also need to think carefully about vendor and administrative access, because external users often inherit different support paths than consumers. The operational challenge is to ensure that the secure factor is not bypassed by a weaker recovery route.

Practical implication: harden enrolment and recovery first, then document every fallback path as part of PCI DSS evidence collection.

NHI Mgmt Group analysis

Password replacement is no longer the real problem. Recovery-path governance is. Passkeys remove the obvious weakness of reusable passwords, but the control failure usually shifts to enrollment, fallback, and account recovery. In payment environments, those paths often remain the easiest way to reintroduce phishing and social engineering risk. The practitioner takeaway is that authentication modernisation is only as strong as the weakest recovery workflow.

PCI DSS 4.0 is effectively a third-party access standard as much as an authentication standard. Requirement 8.4.3 expands MFA expectations across remote and vendor access, which means payment programmes can no longer isolate customer login design from privileged and external access governance. That makes identity ownership, auditability, and step-up policy design part of the same control conversation. Teams should evaluate remote access as a governed identity path, not a separate IT convenience.

Passkeys expose a naming gap in many IAM programmes: possession-based authentication is not the same as trust closure. A passkey can satisfy a factor requirement while still leaving recovery, device sync, and support processes outside governance. That is why PCI-aligned authentication design must be assessed as a lifecycle problem, not a point-in-time login feature. The implication is clear: teams need to govern issuance, recovery, and revocation together.

Customer authentication and workforce authentication are converging operationally, even when compliance language keeps them separate. The same patterns now affect consumers, employees, administrators, and vendors who touch card data. Once organisations accept that shared secret protection is the weak link, the next question becomes whether the same identity assurance model is being applied consistently across all access classes. Practitioners should align payment authentication policy with the broader identity programme rather than running it as a siloed compliance fix.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For the broader governance model, see Ultimate Guide to NHIs , 2025 Outlook and Predictions for how identity control expectations are shifting across machine and autonomous systems.

What this signals

Passkeys solve a phishing problem, but they do not solve an identity lifecycle problem. Once payment environments start replacing passwords with cryptographic credentials, the programme still has to govern enrolment, recovery, revocation, and exception handling with the same rigour as any other identity control.

Recovery-path debt: the hidden risk in passkey rollouts is not the factor itself, but the reappearance of weaker authentication through help-desk, sync, and fallback processes. Teams that ignore this will measure adoption but miss the real exposure.

For teams building broader identity strategy, the passkey conversation should be linked to lifecycle governance and NIST AI Risk Management Framework thinking where identity assurance, auditability, and control boundaries need to stay explicit across every access class.

For practitioners

• Replace reusable secrets on payment access paths Prioritise customer and workforce logins that reach the cardholder data environment, then remove passwords and SMS OTPs from those flows. Keep only authentication methods that resist phishing and replay, and document each approved exception.
• Harden enrolment and recovery workflows Treat device enrolment, account recovery, and help-desk identity checks as control points equal to login itself. Require strong verification before a new passkey can be added or a lost device can rebind an account.
• Separate strong authentication from weak fallback paths Inventory every fallback route used by consumers, vendors, and administrators, then measure whether it can bypass the primary passkey control. If it can, close or redesign the fallback before expanding deployment.
• Document PCI evidence alongside authentication design Map passkey flows to Requirement 8.4.2, 8.4.3, and 8.5, including remote access, third-party access, and replay resistance. Keep screenshots, policy references, and test results together for audit readiness.

Key takeaways

• PCI DSS 4.0 pushes payment authentication beyond passwords and OTPs by demanding stronger, replay-resistant controls for remote and third-party access.
• Passkeys improve resistance to phishing and credential stuffing, but recovery and enrolment remain the most likely places for control failure.
• IAM teams should treat passkey rollout as a governance programme, with explicit ownership for fallback paths, audit evidence, and exception handling.

Key terms

• Passkey: A passkey is a passwordless credential based on public key cryptography. A private key stays on the user’s device, while a public key is stored by the service. During login, the device signs a challenge after local unlock, which reduces phishing and eliminates shared secret reuse.
• Replay resistance: The degree to which an authentication factor or session token cannot be captured and reused by an attacker. Replay resistance is a practical test of MFA quality because a control that can be proxied or forwarded may look strong while still failing under phishing or man-in-the-middle abuse.
• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.

What's in the full article

Descope's full blog post covers the implementation detail this analysis intentionally leaves for the source:

• Step-by-step passkey deployment guidance for consumer-facing and remote-access payment flows
• Specific examples of how FIDO2 and WebAuthn align to PCI DSS 4.0 authentication requirements
• Practical considerations for secure enrolment, recovery, and gradual rollout with fallback handling
• Operational guidance for reducing password-reset overhead while maintaining audit evidence

👉 Descope's full post covers passkey implementation steps, compliance mapping, and user-experience trade-offs in payment environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.