ComplianceCompliance Briefing — September 28, 2021
PCI Security Standards Council releases PCI DSS version 4.0 draft for public review, introducing flexible authentication approaches, expanded validation methods, and modernized security requirements for evolving payment technologies and threat landscapes.
Executive briefing: The Payment Card Industry Security Standards Council (PCI SSC) released PCI DSS version 4.0 draft on September 28, 2021, marking the first major revision since version 3.0 in 2013. The draft introduces significant updates addressing cloud computing, mobile payments, IoT devices, and evolving cyber threats while maintaining backward compatibility with v3.2.1 during a multi-year transition period. Organizations processing, storing, or transmitting payment card data should review the 280-page draft specification, participate in feedback processes closing January 2022, and begin planning for compliance transitions expected to commence in 2024. Key changes include flexible authentication mechanisms, expanded multi-factor authentication requirements, enhanced encryption standards, and customized implementation approaches replacing prescriptive controls.
Major framework enhancements
PCI DSS v4.0 introduces structural improvements reflecting lessons learned from a decade of implementations and changing technology landscapes. The updated standard moves from purely prescriptive requirements toward outcome-based security objectives that allow organizations to demonstrate compliance through customized approaches. This flexibility enables adoption of emerging technologies and security innovations while maintaining baseline protection levels. New requirements address passwordless authentication, phishing-resistant multi-factor authentication, and automated compliance validation tools. The standard expands scope guidance for cloud service providers, third-party service providers, and software vendors to clarify shared responsibility models. Enhanced validation procedures require assessors to evaluate not just control implementation but also their effectiveness in achieving stated security objectives. Organizations can now propose alternative controls through defined customized approach processes, subject to qualified security assessor approval and documentation requirements.
Authentication and access control updates
Requirement 8 undergoes substantial revision to address modern authentication paradigms beyond traditional passwords. The draft mandates multi-factor authentication for all access to cardholder data environments, expanding from previous requirements that focused primarily on remote access and privileged users. Organizations must implement phishing-resistant authentication factors resistant to man-in-the-middle attacks, push notification fatigue, and SIM-swapping attacks. Acceptable mechanisms include hardware security keys, platform authenticators with device binding, and cryptographic certificates. Password complexity requirements evolve to emphasize password length over character composition, with minimum lengths increasing from 7 to 12 characters for most use cases. The standard introduces formal support for passwordless authentication using FIDO2, WebAuthn, and platform biometrics when combined with device attestation. Service accounts and application credentials receive explicit requirements for rotation frequencies, encryption at rest, and access logging. Just-in-time privileged access workflows receive formal recognition as acceptable alternatives to persistent administrative accounts when properly architected and monitored.
Network security and segmentation clarifications
Requirements 1 and 2 receive updates addressing software-defined networking, micro-segmentation, and cloud-native architectures that were uncommon when v3.0 launched. The standard now explicitly permits cloud security groups, network policies in container orchestration platforms, and service mesh configurations as acceptable network security controls when properly configured and validated. Segmentation validation requirements become more rigorous, requiring annual penetration testing specifically focused on validating network isolation between cardholder data environments and other network segments. Organizations must document dataflows through segmentation boundaries and demonstrate that no unauthorized paths exist for accessing cardholder data. Wireless networking requirements expand to address Wi-Fi 6, Bluetooth Low Energy, and NFC payment terminals with specific guidance on encryption protocols, authentication mechanisms, and monitoring approaches. The standard introduces requirements for securing application programming interfaces (APIs) exposing payment functionality, including API gateway configurations, rate limiting, input validation, and token-based authentication.
Cryptography and key management modernization
Requirement 3 and 4 updates mandate stronger cryptographic algorithms reflecting advances in computing power and cryptanalytic capabilities. The standard phases out TLS 1.0 and 1.1 with sunset dates requiring migration to TLS 1.2 minimum, with TLS 1.3 recommended for new implementations. Disk encryption requirements expand beyond full-disk encryption to include file-level and database-level encryption options when properly key-managed. Encryption key management receives detailed guidance on hardware security modules, key derivation functions, key rotation frequencies, and cryptographic key lifecycle management. Organizations storing primary account numbers must implement additional protection layers including tokenization, format-preserving encryption, or secure cryptographic hashing with appropriate salt and iteration counts. Point-to-point encryption requirements clarify acceptable encryption scope from payment terminal to acquirer processor, with explicit guidance on key injection procedures, tamper-evident device requirements, and secure key distribution channels.
Vulnerability management and security testing expansion
Requirements 6 and 11 introduce more comprehensive vulnerability management and security testing obligations reflecting sophisticated attack techniques. Organizations must conduct authenticated vulnerability scans in addition to traditional network scans to identify configuration weaknesses, missing patches, and application-layer vulnerabilities. Web application security testing expands to require both automated scanning and manual testing for business logic flaws, access control issues, and injection vulnerabilities not detectable by automated tools alone. Penetration testing requirements increase in rigor, mandating testing of all external-facing systems annually and internal environments following significant changes. The standard introduces requirements for container image scanning, infrastructure-as-code security analysis, and software composition analysis to detect vulnerable open-source components. Bug bounty programs receive formal recognition as supplementary security testing approaches when properly scoped to cardholder data environments and integrated with vulnerability management processes. Organizations must establish metrics tracking time-to-remediate critical vulnerabilities and demonstrate continuous improvement in remediation velocity.
Transition timeline and planning
PCI SSC outlines a multi-year transition accommodating organizational planning cycles and assessment schedules. Following final publication expected mid-2022, version 4.0 enters a three-year transition period during which both v3.2.1 and v4.0 remain valid for compliance assessments. Organizations can voluntarily adopt v4.0 requirements immediately or maintain v3.2.1 compliance until transition deadlines. Beginning in 2025, all new compliance assessments must use v4.0 standards. The phased approach enables organizations to align PCI DSS upgrades with technology refresh cycles, budget planning, and other compliance initiatives. Assessors receive training and certification on v4.0 requirements throughout 2022-2023 to ensure consistent interpretation and validation. Organizations should conduct gap analyses comparing current v3.2.1 implementations against v4.0 requirements to identify necessary investments in authentication infrastructure, encryption capabilities, vulnerability management tools, and assessment processes. Early adoption provides competitive advantages through reduced transition pressure and opportunities to influence assessor interpretation through real-world implementation feedback.
Action plan
Organizations should initiate PCI DSS v4.0 readiness planning immediately despite extended transition timelines. Conduct comprehensive gap analysis comparing current security controls against draft v4.0 requirements, focusing on authentication mechanisms, encryption implementations, and vulnerability management processes. Submit feedback to PCI SSC during public comment period if draft requirements create implementation challenges or lack clarity for specific use cases. Engage qualified security assessors to discuss interpretation questions and validation approaches for customized implementation methods. Update multi-year technology roadmaps incorporating PCI DSS v4.0 requirements into authentication platform upgrades, network segmentation projects, and encryption infrastructure investments. Establish cross-functional working groups including IT security, application development, infrastructure operations, and compliance teams to coordinate implementation efforts. Budget for assessor training, documentation updates, policy revisions, and potential tool acquisitions supporting enhanced validation requirements. Consider voluntary early adoption for portions of v4.0 that align with existing security improvement initiatives to distribute implementation effort across multiple budget cycles.
Zeph Tech analysis
PCI DSS v4.0 represents maturation of the payment security standards from prescriptive checklist toward risk-based framework enabling innovation while maintaining baseline protections. The flexibility introduced through customized approaches acknowledges that diverse organizational architectures require tailored security controls rather than one-size-fits-all mandates. However, this flexibility transfers burden to organizations and assessors to demonstrate that alternative approaches achieve equivalent or superior security outcomes. Organizations lacking mature security engineering capabilities may find prescriptive v3.2.1 requirements easier to implement despite their limitations. The authentication enhancements reflect industry recognition that passwords alone provide insufficient protection in modern threat landscapes. Requirements for phishing-resistant multi-factor authentication will accelerate adoption of hardware security keys and platform authenticators while reducing reliance on SMS and mobile app push notifications vulnerable to social engineering. Organizations should view authentication upgrades as foundational investments benefiting not just PCI compliance but broader identity security programs. The three-year transition period provides adequate planning time but may create complacency risks. Organizations deferring gap analysis and planning until 2024 will face compressed implementation timelines, budget constraints, and resource competition. Early movers gain implementation expertise, influence assessment interpretation through real-world cases, and avoid last-minute compliance crises. The updated standard positions payment security frameworks to remain relevant through the 2020s as digital payments continue evolving.
Continue in the Compliance pillar
Return to the hub for curated research and deep-dive guides.
Latest guides
-
Third-Party Risk Oversight Playbook — Zeph Tech
Operationalize OCC, Federal Reserve, EBA, and MAS outsourcing expectations with lifecycle controls, continuous monitoring, and board reporting.
-
ESG Assurance Operating Guide — Zeph Tech
Deploy credible ESG assurance across CSRD, SEC climate disclosure, and ISSA 5000 requirements with regulator-aligned controls, data governance, and audit-ready evidence.
-
Compliance Operations Control Room — Zeph Tech
Implement cross-border compliance operations that satisfy Sarbanes-Oxley, DOJ guidance, EU DORA, and MAS TRM requirements with verifiable evidence flows.
Comments
Community
We publish only high-quality, respectful contributions. Every submission is reviewed for clarity, sourcing, and safety before it appears here.
No approved comments yet. Add the first perspective.