How To Build Strong Authentication: PCI’s Best Practices

PCI DSS v4.0 mandates multi-factor authentication (MFA) for every individual accessing the Cardholder Data Environment (CDE), and PCI SSC’s August 2025 Authentication Guidance raises the bar further: phishing-resistant factors for sensitive access, hardware-anchored credential storage, device-bound passkeys, and crypto-agility built in for the post-quantum transition. If your MFA program was scoped only for remote and privileged users under v3.2.1, it does not meet v4.0’s requirements today.

Quick Answer: What Does PCI Require for Strong Authentication?

PCI DSS v4.0 Requirement 8 mandates MFA for all CDE access, unique IDs for every user, and prohibition of shared credentials. The August 2025 PCI SSC Authentication Guidance adds best-practice recommendations for phishing-resistant authentication, device-bound passkeys, HSM-based credential storage, and crypto-agility planning. The recommended first action is scoping: map every access path into the CDE and confirm MFA is enforced at each one.

Key Takeaways

• PCI DSS v4.0 Requirement 8.4.2 requires MFA for all access to the CDE, not just remote or privileged users. This expanded scope is a mandatory requirement, effective March 31, 2024 for all v4.0 assessments.
• Accounts protected by MFA are exempt from the 90-day password rotation requirement under PCI DSS v4.0 Requirement 8.3.9. Only accounts using a password as the sole authentication factor require mandatory rotation.
• The PCI SSC Authentication Guidance (August 2025) is supplemental, not mandatory, but it identifies the attack vectors that PCI DSS v4.0’s minimums do not fully address: AI-generated phishing, deepfakes, SIM-swapping, and MFA fatigue.
• Phishing-resistant authentication using FIDO2 hardware security keys or certificate-based smart cards is the recommended approach for administrative and high-privilege CDE access. OTP codes and SMS-based MFA remain vulnerable to interception.
• Credential storage should use HSMs or Hardware Management Devices (HMDs) for the highest-sensitivity secrets. Memory-hard comparison functions with unique per-password salts are the minimum acceptable approach for password storage.
• Crypto-agility must be built into authentication infrastructure now. NIST finalized FIPS 203, 204, and 205 post-quantum standards in August 2024. RSA and ECC are targeted for deprecation around 2030 under NIST IR 8547.

What Is the PCI SSC Authentication Guidance and Why Was It Published?

The Payment Card Industry Security Standards Council (PCI SSC) published its Authentication Guidance in August 2025 as a supplemental document to PCI DSS v4.0. It is not a new version of PCI DSS and it does not introduce mandatory requirements; it is a best-practice framework that addresses the threat landscape PCI DSS v4.0’s Requirement 8 was written to counter but did not fully anticipate as attack techniques evolved.

The document reflects a security environment where attackers are no longer limited to credential stuffing and brute force. They now use AI-generated phishing at scale, deepfake audio and video to bypass helpdesk verification, automated SIM-swapping to intercept SMS OTPs, and MFA fatigue attacks that flood users with push notification requests until one is accepted. Standard MFA implementations that were sufficient against 2020-era attack techniques are not sufficient against these vectors.

The guidance also anticipates two longer-horizon shifts: the transition to post-quantum cryptography as RSA and ECC face deprecation timelines under NIST IR 8547, and the growing adoption of passkeys (FIDO2-based) as a replacement for passwords. For organizations building authentication infrastructure now, both of these transitions will arrive before the next major hardware refresh cycle.

What Does PCI DSS v4.0 Require for Authentication?

PCI DSS v4.0 Requirement 8 governs identification and authentication for all users with access to system components. The mandatory requirements that every organization in scope must meet are distinct from the August 2025 guidance recommendations. The table below maps each key Requirement 8 control to its evidence artifact and common implementation gap:

PCI DSS v4.0 Requirement	What it mandates	Evidence artifact	Common gap
8.2.1	All users must have a unique ID before allowing access to system components or cardholder data	IAM system user roster; no shared or group accounts for CDE access; provisioning records	Shared admin accounts on legacy systems; generic service accounts with multiple users
8.3.6	Passwords used as authentication factors must meet a minimum of 12 characters (or 8 if the system does not support 12) including both numeric and alphabetic characters	Password policy documentation; IAM system configuration showing minimum length enforcement	Legacy systems enforcing 8-character minimums; no audit of third-party system password policies
8.3.9	Passwords must be changed at least every 90 days if used as the only authentication factor	Password rotation policy; evidence of enforcement; accounts excluded from rotation due to MFA coverage	Applying 90-day rotation to MFA-protected accounts unnecessarily; not documenting MFA exemptions
8.4.2	MFA is required for all access to the CDE, including all users (not limited to remote or privileged users)	MFA configuration records for all CDE-touching systems; access logs confirming MFA challenges at login; exception register for any gaps	MFA scoped only to remote access or administrators as carried over from v3.2.1 interpretation; service accounts and API access paths excluded
8.4.3	MFA is required for all remote network access originating from outside the entity’s network, including personnel and third parties	VPN and remote access configuration; MFA enforcement logs; third-party access records	Third-party vendor access paths that bypass internal MFA enforcement; legacy VPN clients without MFA support
8.5.1	MFA systems must not be susceptible to replay attacks; all MFA factors must be validated before indicating authentication success or failure	MFA platform configuration documentation; penetration test results; OTP time-window configuration	MFA implementations that indicate username validity before prompting for the second factor (enabling enumeration); TOTP windows wider than 30 seconds
8.6.1	System and application accounts must be managed to prevent misuse; interactive use of system accounts must be limited and monitored	Service account inventory; interactive login restrictions; monitoring alerts for interactive system account use	Unaudited service accounts with interactive login capability; no monitoring of service account authentication events

What Are the Three Authentication Factors PCI Recognizes?

PCI DSS defines authentication factors across three categories. MFA requires at least two factors from different categories used together, so that compromising one factor does not compromise the authentication event. The three categories are:

Factor category	Definition	Examples	Relative strength against modern attacks
Something you know (Knowledge factor)	A secret the user memorizes and enters at authentication	Password, PIN, security question answer	Weakest. Vulnerable to phishing, credential stuffing, brute force, and social engineering. Should never be used as the sole factor in a CDE access path.
Something you have (Possession factor)	A physical or digital object the user possesses at authentication time	Hardware security key (FIDO2/CTAP2), TOTP authenticator app, smart card with certificate, hardware OTP token, SMS OTP (weakest possession factor due to SIM-swap risk)	Moderate to strong depending on implementation. FIDO2 hardware keys are phishing-resistant; SMS OTPs are vulnerable to SIM-swapping and interception. PCI SSC August 2025 guidance recommends moving away from messaging-based factors.
Something you are (Inherence factor)	A physical characteristic of the user verified by a biometric system	Fingerprint scan, face recognition, iris scan, voice recognition	Strong when implemented on-device with a FIPS 140-3 validated module. Weakest when biometric templates are stored in centralized databases susceptible to breach. PCI SSC guidance recommends local on-device biometric verification.

What Are the Key Best Practices from PCI SSC’s August 2025 Authentication Guidance?

The August 2025 guidance groups its recommendations across credential security, MFA implementation, passkey and device trust, and crypto-agility. The following table maps each recommendation to its implementation action, the evidence artifact an assessor would expect to see, and the owner responsible:

Best practice	Category	Implementation action	Evidence artifact	Owner
Educate users on how to generate secure passwords	Credential hygiene	Deliver security awareness training covering password manager use, passphrase construction, and credential reuse risks. Document training completion.	Training completion records; training content showing password guidance	Security Awareness / HR
Implement controls to mitigate deepfake attacks	Identity verification	Update helpdesk and account recovery procedures to require multi-step identity verification that cannot be defeated by voice or video deepfakes. Use out-of-band challenges (e.g., registered callback numbers, supervisor confirmation, physical token verification).	Updated identity verification procedure; helpdesk training records; escalation process documentation	IT / Security Operations
Provide suitable time limits for OTP use; allow paste into password and OTP fields	Usability and security	Configure TOTP validity windows to 30 seconds maximum. Remove JavaScript or HTML controls that block paste into authentication fields.	MFA platform configuration showing OTP time window; web application configuration or test evidence confirming paste is not blocked	Application Engineering / IAM
Store authentication secrets securely using memory-hard functions with unique per-password salts, or HSMs/HMDs	Credential storage	Replace MD5 or SHA-1 password hashing with bcrypt, scrypt, Argon2id, or PBKDF2. For highest-sensitivity systems, store credential material in FIPS 140-3 validated HSMs.	Application code review or penetration test confirming approved hashing algorithm; HSM deployment documentation with CMVP certificate number	Application Engineering / Security Engineering
Implement online and offline brute-force protections	Credential protection	Enforce account lockout or progressive delay after failed authentication attempts. Implement CAPTCHA or rate limiting for online credential attacks. Audit offline credential databases (hashed password stores) access and alert on bulk extraction.	Lockout policy configuration; WAF or rate-limiting rules; audit log evidence of lockout triggers	IAM / Application Engineering
Secure systems that can access authentication factors (SIM PINs, lockscreen, notification blocking, account porting controls)	Factor delivery security	Enforce SIM PINs and carrier-level account porting restrictions for accounts associated with SMS-based MFA. Require lockscreen enforcement on all devices used for authenticator apps. Document controls for mobile device management.	MDM policy configuration; carrier account security settings documentation; lockscreen enforcement evidence	IT / Mobile Device Management
Consider more secure authentication factors instead of messaging-based (SMS/voice OTP) factors	Factor selection	Migrate high-privilege and CDE access accounts from SMS OTP to TOTP authenticator apps, FIDO2 hardware keys, or certificate-based authentication. Maintain SMS OTP only where stronger options are operationally unavailable and document the exception.	MFA factor type inventory by access level; migration plan for SMS-based accounts; exception register with mitigating controls	IAM / Security Architecture
Consider all locations where a credential exists or may be compromised as in scope for security controls	Credential scope	Map the full credential lifecycle: where passwords and authentication secrets are created, stored, transmitted, cached, and destroyed. Apply security controls at every point, including backup systems, password managers, and help desk tools.	Credential lifecycle map; security control evidence at each storage/transmission point	Security Architecture / IAM
Implement phishing-resistant authentication wherever possible	Factor strength	Deploy FIDO2 hardware security keys (CTAP2) or certificate-based smart cards for administrative access, privileged accounts, and all direct CDE access. Document phishing resistance as a selection criterion in authentication procurement.	FIDO2 key deployment records; smart card or certificate-based auth configuration; procurement policy referencing phishing resistance	IAM / Security Architecture
Use device-bound factors for sensitive access operations	Device trust	Configure authenticator apps or FIDO2 keys to be device-bound, not synced to cloud accounts. For administrative and CDE access, require hardware security keys rather than software-based authenticators that sync across devices.	MDM or IAM configuration showing device-bound enforcement; FIDO2 attestation records; prohibited sync configuration evidence	IAM / IT
Limit the business use of synced passkeys to minimize scope	Passkey governance	Define a passkey policy that restricts synced passkeys to lower-risk access paths and requires device-bound passkeys for CDE access. Document scope rationale in the authentication policy.	Authentication policy with passkey classification; IAM configuration enforcing device-bound passkeys for CDE scope	Security Architecture / Compliance
Implement MFA wherever possible	MFA coverage	Extend MFA beyond the mandatory CDE scope to all internal systems, cloud consoles, developer tools, and third-party portals. Document coverage and exception rationale for any systems where MFA is technically unavailable.	MFA coverage map across all systems; exception register with compensating controls for non-MFA systems	IAM / Security Operations
Secure the (re)enrollment process to prevent account takeover	Identity lifecycle	Require out-of-band identity verification before any MFA factor re-enrollment or account recovery. Do not allow helpdesk agents to reset MFA factors based solely on knowledge-based verification that can be defeated by social engineering or deepfakes.	Re-enrollment procedure documentation; identity verification checklist used by helpdesk; training records for helpdesk staff	IAM / IT Helpdesk
Bind session credentials to specific devices or users wherever possible	Session security	Implement session tokens that include device fingerprint or certificate-bound session attributes. Invalidate sessions when device trust cannot be re-established (e.g., network change, certificate expiry, device posture failure).	Session management configuration; certificate-bound session documentation; session invalidation policy	Application Engineering / IAM
Validate all MFA factors before indicating success or failure	MFA implementation integrity	Configure MFA platform to collect all authentication factor inputs before returning any success or failure indication. This prevents username enumeration attacks where an invalid username returns an error before the second factor is requested.	MFA platform configuration documentation; penetration test confirming no factor-step enumeration vulnerability	IAM / Application Engineering
Include authentication methods in crypto-agility planning	Crypto-agility	Audit all authentication-related cryptographic dependencies: certificate signing algorithms, FIDO2 key types, TLS versions used in authentication flows. Map each to the NIST IR 8547 deprecation timeline. Plan migration to post-quantum algorithms for authentication systems before 2030.	Cryptographic inventory (CBOM) covering authentication systems; crypto-agility policy; migration roadmap with timelines	Security Architecture / Compliance

What Is the Authentication Maturity Model for PCI Environments?

Organizations can use a four-level maturity framework to assess their current authentication posture and plan their progression toward the strongest recommended practices. Each level maps to both PCI DSS v4.0 mandatory requirements and the August 2025 guidance recommendations:

Maturity level	Authentication characteristics	PCI DSS v4.0 status	Key gaps to close before advancing
Level 1: Basic credentials	Username and password only. Password policies enforce complexity and 90-day rotation. No MFA on CDE access paths.	Non-compliant with PCI DSS v4.0 Requirement 8.4.2 (mandatory MFA for all CDE access)	MFA deployment across all CDE access paths is required before any other improvement. This is not optional under v4.0.
Level 2: MFA for all CDE access	MFA enforced for all CDE access (mandatory under PCI DSS v4.0 Req 8.4.2). Independent factors from two or three categories. Unique IDs for all users. 90-day password rotation applies only to accounts without MFA.	Compliant with PCI DSS v4.0 Requirement 8 mandatory baseline	MFA factor type may still be SMS OTP or TOTP app (vulnerable to SIM-swap and phishing). No phishing-resistant factor enforcement. No device-bound factor requirement. Re-enrollment process may still be susceptible to social engineering.
Level 3: Risk-adaptive and context-aware	Authentication adjusts based on risk signals: user behavior, device trust level, geolocation, time of day, and threat intelligence. Continuous session monitoring. Session credentials bound to specific trusted devices. Privileged access uses stronger factors than standard users.	Exceeds PCI DSS v4.0 mandatory baseline; aligns with August 2025 guidance recommendations	Authentication factors may still include SMS OTP or non-device-bound passkeys. Crypto-agility planning not yet formalized. Re-enrollment process may not address deepfake vectors.
Level 4: Phishing-resistant, hardware-anchored, crypto-agile	FIDO2 hardware security keys or certificate-based smart cards for all CDE and administrative access. Device-bound passkeys enforced. HSM-based credential storage for highest-sensitivity secrets. Deepfake-resistant re-enrollment procedures. Crypto-agility roadmap covering authentication systems documented and scheduled.	Fully aligned with PCI DSS v4.0 and August 2025 Authentication Guidance recommendations; positioned for post-quantum transition	Ongoing: NIST PQC migration for FIDO2 key algorithms and certificate signing; monitor PCI SSC for future mandatory requirements that formalize current best practices.

PCI Authentication Audit-Ready Checklist

Use this checklist to verify your PCI authentication posture before a QSA assessment or internal review. Items marked as mandatory are required under PCI DSS v4.0; items marked as recommended are from the August 2025 Authentication Guidance:

Control area	Requirement	Mandatory or recommended	Evidence artifact	Status
Unique IDs	Every user has a unique ID; no shared or group accounts for CDE access	Mandatory (Req 8.2.1)	IAM user roster; no shared credential audit evidence	To action
Password minimum length	Minimum 12 characters (or 8 if system limitation) with numeric and alphabetic characters	Mandatory (Req 8.3.6)	Password policy; IAM configuration evidence	To action
Password rotation	90-day rotation for password-only accounts; MFA-protected accounts documented as exempt	Mandatory (Req 8.3.9)	Rotation policy; MFA exemption documentation	To action
MFA for all CDE access	MFA enforced for every individual accessing the CDE, including non-remote users	Mandatory (Req 8.4.2)	MFA configuration for all CDE-touching systems; access logs confirming MFA challenges	To action
MFA for remote access	MFA enforced for all remote access originating outside the entity’s network	Mandatory (Req 8.4.3)	VPN and remote access MFA configuration; third-party access records	To action
MFA factor independence	MFA factors are from independent categories; compromising one factor does not compromise the authentication event	Mandatory (Req 8.4.1)	MFA platform configuration; factor category documentation	To action
No factor enumeration	All MFA factors validated before success or failure is indicated; no username enumeration via factor-step responses	Mandatory (Req 8.5.1)	MFA platform configuration; penetration test confirming no enumeration	To action
Service account controls	System and application accounts managed; interactive use limited and monitored	Mandatory (Req 8.6.1)	Service account inventory; monitoring alert configuration	To action
Password storage	Passwords hashed with memory-hard function and unique per-password salt; or stored in FIPS-validated HSM	Recommended (Aug 2025 guidance)	Application code review; HSM deployment documentation	To action
Phishing-resistant authentication	FIDO2 hardware keys or certificate-based auth deployed for administrative and high-privilege CDE access	Recommended (Aug 2025 guidance)	FIDO2 key deployment records; certificate-based auth configuration	To action
Device-bound passkeys	Device-bound passkeys enforced for sensitive access; synced passkeys limited to lower-risk access paths	Recommended (Aug 2025 guidance)	IAM or MDM configuration; passkey policy documentation	To action
Re-enrollment security	MFA re-enrollment requires out-of-band identity verification resistant to deepfake social engineering	Recommended (Aug 2025 guidance)	Re-enrollment procedure; helpdesk training records	To action
Brute-force protection	Account lockout or progressive delay after failed attempts; rate limiting on authentication endpoints	Recommended (Aug 2025 guidance)	Lockout policy configuration; WAF or rate-limiting rules	To action
OTP time window	TOTP validity window 30 seconds or less; paste not blocked in password or OTP fields	Recommended (Aug 2025 guidance)	MFA platform configuration; web application test evidence	To action
Session binding	Session credentials bound to specific devices or users; sessions invalidated on device trust failure	Recommended (Aug 2025 guidance)	Session management configuration; certificate-bound session documentation	To action
Crypto-agility planning	Authentication cryptographic dependencies inventoried; migration roadmap to post-quantum algorithms documented	Recommended (Aug 2025 guidance)	Cryptographic inventory (CBOM); crypto-agility policy; PQC migration roadmap	To action

Why These Practices Matter Now: The Threat Landscape Driving the August 2025 Guidance

PCI SSC does not publish supplemental guidance without a reason. The August 2025 Authentication Guidance reflects seven specific threat and technology shifts that make the PCI DSS v4.0 mandatory minimums insufficient on their own for organizations in high-risk payment environments:

• AI-generated phishing at scale: Attackers now generate highly convincing, personalized phishing emails, SMS messages, and voice calls using large language models. Volume and quality have both increased to the point where user education alone cannot be the primary defense. The recommended response is phishing-resistant authentication where the mechanism itself cannot be deceived by a fake login page.
• Deepfake-based social engineering: Synthetic audio and video convincing enough to impersonate executives or IT staff are now accessible to criminal groups. Standard helpdesk identity verification using knowledge-based questions or voice recognition is no longer reliable. PCI SSC recommends out-of-band verification channels that deepfakes cannot compromise.
• SIM-swapping targeting SMS OTP: SIM-swap fraud allows attackers to reroute SMS messages by convincing mobile carriers to transfer a victim’s phone number to an attacker-controlled SIM. Every SMS OTP sent to the victim is then received by the attacker. The guidance explicitly recommends moving away from messaging-based authentication factors for sensitive access.
• MFA fatigue attacks: Attackers who have compromised a user’s password flood the user with push notification approval requests until the user approves one. Number-matching push notifications and context-aware prompts reduce but do not eliminate this vector. Phishing-resistant hardware keys eliminate it entirely.
• Authentication factors as primary attack targets: Attackers now directly target the systems, devices, and delivery channels that store or provide authentication factors. A compromised authenticator app, a SIM card, or a hardware token with a known vulnerability is a higher-value target than a single password. The guidance addresses this by recommending device-bound factors, HSM-stored credentials, and regular audit of all locations where authentication secrets exist.
• Cloud perimeter dissolution: With authentication now functioning as the effective security perimeter in cloud and hybrid environments, weak authentication is a more directly exploitable entry point than network perimeter gaps. The guidance addresses this by extending strong authentication recommendations beyond on-premises CDE systems to all access paths.
• Post-quantum cryptography transition timeline: NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Authentication systems that depend on RSA-based certificates or ECC-based FIDO2 keys will require migration before RSA and ECC are deprecated around 2030 under NIST IR 8547. Organizations that build crypto-agility into their authentication infrastructure now will execute that migration without system redesign.

What Encryption Consulting Recommends: Our Practical Perspective

Having worked with organizations across healthcare, financial services, and payment processing on PCI DSS v4.0 assessments, the single most common gap we find is the MFA scope assumption carried over from v3.2.1: teams that scoped MFA for remote and privileged users under the old standard and have not yet extended it to all CDE access as required by v4.0 Requirement 8.4.2. This gap is discoverable in any competent QSA assessment and it represents a mandatory requirement failure, not a best-practice gap.

The second most common gap is the FIPS Capable problem applied to authentication: organizations have deployed MFA solutions that support FIDO2 or certificate-based authentication, but those features are not enabled in production. The MFA product is present; phishing-resistant authentication is not. An assessor checking for MFA will find it; a penetration tester checking whether the MFA is defeatable via phishing will not.

For organizations that have cleared the v4.0 mandatory baseline, the highest-leverage next investments from the August 2025 guidance are: re-enrollment procedure hardening (because account takeover through helpdesk social engineering bypasses even strong MFA), and crypto-agility documentation for authentication systems (because the 2030 window for RSA/ECC deprecation will arrive during your next hardware refresh cycle whether you plan for it or not).

How Encryption Consulting Can Help You Meet PCI DSS Authentication Requirements

Encryption Consulting is an ISO/IEC 27001:2022 and SOC 2 certified applied-cryptography firm. Our PCI DSS compliance advisory services cover the full scope of Requirement 8 authentication controls, from gap assessment through QSA-ready evidence packages.

• PCI DSS v4.0 Authentication Gap Assessment: We review your current MFA deployment scope against PCI DSS v4.0 Requirement 8’s expanded CDE access definition, identify accounts and access paths without MFA coverage, and produce a prioritized remediation roadmap with QSA-ready evidence templates. This is the right starting point for organizations that have not yet verified their v4.0 compliance posture against the full scope of Requirement 8.4.2.
• HSM-Based Credential Storage: For organizations implementing the August 2025 guidance’s recommendation for hardware-anchored credential storage, HSM-as-a-Service provides FIPS 140-3 Level 3 validated key custody for authentication secrets without the capital expense and procurement lead time of on-premises HSM hardware. This directly satisfies the guidance’s recommendation for HSM or HMD-based storage of the highest-sensitivity authentication secrets.
• Certificate-Based Authentication and PKI: For organizations deploying certificate-based smart cards or client certificate authentication as phishing-resistant MFA, PKI-as-a-Service provides the issuing CA infrastructure with CP/CPS governance documentation, always-offline root CA with ceremony records, and automated certificate lifecycle management via CertSecure Manager. This covers both the authentication mechanism and the certificate lifecycle evidence that PCI assessors require.
• Cryptographic Inventory for Authentication Systems: The August 2025 guidance’s crypto-agility recommendation requires knowing what cryptographic algorithms your authentication systems depend on before you can plan their migration. CBOM Secure runs a discovery pass across your authentication infrastructure, TLS configurations, certificate signing algorithms, and FIDO2 key types to produce a Cryptographic Bill of Materials that maps each dependency to the NIST IR 8547 deprecation timeline.
• PQC Readiness for Authentication: Our PQC Readiness service assesses which authentication systems and cryptographic modules support post-quantum algorithm firmware updates versus requiring hardware replacement, and produces a migration roadmap calibrated to your PCI compliance obligations and the NIST 2030 deprecation window.

Frequently Asked Questions

What does PCI DSS v4.0 require for authentication?

PCI DSS v4.0 Requirement 8 mandates MFA for all access to the CDE, not just remote or privileged users. Every individual accessing the CDE must use at least two independent factors from the three categories: something they know, something they have, and something they are. All factors must be validated before success or failure is indicated. Shared or group credentials are prohibited for any CDE access. Passwords must be a minimum of 12 characters. 90-day rotation applies only to accounts using password as the sole authentication factor.

What is the PCI SSC Authentication Guidance published in August 2025?

The PCI SSC Authentication Guidance (August 2025) is a supplemental best-practice document addressing modern authentication threats that PCI DSS v4.0’s mandatory minimums do not fully counter: AI-generated phishing, deepfake social engineering, SIM-swapping, and MFA fatigue attacks. It recommends phishing-resistant authentication using FIDO2 hardware security keys or certificate-based methods, device-bound passkeys, HSM-based credential storage, and crypto-agility planning for the post-quantum transition. It is not mandatory but reflects the direction of future PCI DSS versions.

What is phishing-resistant authentication and why does PCI recommend it?

Phishing-resistant authentication means the mechanism is cryptographically bound to the specific site being accessed, making intercepted credentials useless on any other site. FIDO2 hardware security keys and certificate-based smart cards are the primary phishing-resistant methods. Unlike TOTP codes or SMS OTPs, which can be captured via fake login pages or social engineering, FIDO2 keys verify the origin of the authentication request cryptographically so stolen credentials cannot be replayed elsewhere.

Does PCI DSS v4.0 still require 90-day password rotation?

PCI DSS v4.0 Requirement 8.3.9 requires password changes at least every 90 days only for accounts where a password is the sole authentication factor. Accounts protected by MFA are exempt from mandatory periodic rotation. Organizations that have deployed MFA for all CDE access as required by Requirement 8.4.2 can eliminate 90-day password rotation for those accounts, reducing administrative overhead while meeting the spirit of the security requirement.

What is the difference between a device-bound passkey and a synced passkey?

A device-bound passkey stores the private key exclusively on the device where it was created and cannot be exported or synced to cloud accounts. This makes it a strong phishing-resistant authenticator appropriate for sensitive CDE access. A synced passkey is backed up and synchronized via cloud services such as iCloud Keychain or Google Password Manager. While more convenient, synced passkeys expand the attack surface because the private key exists in cloud infrastructure outside the organization’s control. PCI SSC recommends device-bound passkeys for high-security operations and limiting synced passkeys to lower-risk access.

What is MFA fatigue and how does PCI guidance address it?

MFA fatigue is an attack where an attacker with a stolen password floods the user with push notification approval requests until one is accepted out of exhaustion or confusion. PCI SSC’s August 2025 guidance recommends number-matching or context-aware push notifications to prevent accidental approvals, and phishing-resistant FIDO2 hardware keys for administrative and high-privilege access where MFA fatigue attacks are most likely to be targeted. FIDO2 hardware keys are immune to this attack class because approval is a physical action on a bound device, not a notification prompt.

How does crypto-agility relate to PCI authentication requirements?

Crypto-agility is the ability to swap cryptographic algorithms without re-architecting dependent systems. PCI SSC’s August 2025 guidance explicitly recommends including authentication methods in crypto-agility planning. NIST finalized post-quantum standards FIPS 203, 204, and 205 in August 2024, and NIST IR 8547 targets RSA and ECC for deprecation around 2030. Authentication systems relying on RSA certificates or ECC-based FIDO2 keys will need post-quantum migration. Organizations that inventory authentication cryptographic dependencies now using tools like CBOM Secure can plan that migration without emergency re-architecture under deadline pressure.

Conclusion

The PCI SSC Authentication Guidance is both a response to current threats and a roadmap for where PCI DSS requirements are heading. Organizations that treat it as optional guidance for later will find that the attack techniques it addresses, AI phishing, deepfakes, SIM-swapping, and MFA fatigue, are already active in the threat environment their payment systems operate in today.

The path forward is sequential: close the mandatory PCI DSS v4.0 Requirement 8 gaps first, with particular attention to the expanded MFA scope that catches most organizations still operating under v3.2.1 assumptions. Then advance through the maturity model toward phishing-resistant factors, hardware-anchored credentials, and crypto-agility documentation. The organizations that build authentication infrastructure to Level 4 maturity today are the ones positioned to absorb the post-quantum transition without emergency re-architecture in 2028.