Notifications
Clear all
Topic starter
16/08/2026 1:13 pm
TL;DR: Passwords and OTPs remain weak points in payment authentication, while PCI DSS 4.0 tightens MFA, replay-resistance, and third-party access requirements; Descope argues passkeys built on FIDO2 can satisfy those controls while improving login success and reducing password-reset overhead. For IAM teams, the real issue is not whether passkeys work, but how quickly they can replace brittle fallback paths without creating new enrollment and recovery gaps.
NHIMG editorial — based on content published by Descope: The Impact of PCI DSS 4.0 on Customer Authentication
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Harden enrolment and recovery workflows Treat device enrolment, account recovery, and help-desk identity checks as control points equal to login itself.
- 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.
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
👉 Read Descope's analysis of passkeys and PCI DSS 4.0 authentication →
PCI DSS 4.0 and passkeys: are payment logins ready yet?
Explore further
16/08/2026 1:14 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PCI DSS 4.0 shifts customer authentication toward passkeys
