PCI DSS 4.0 requirements are now fully mandatory. PCI DSS 3.2.1 retired on March 31, 2024, and the 51 future-dated requirements that were previously best practices became mandatory on March 31, 2025. If you’re building payment software, the requirements that matter most to you are in Requirement 6 (secure development), Requirement 8 (authentication), and the new client-side script controls.
27.9% of organizations are fully PCI DSS compliant according to Verizon’s Payment Security Report. Just 5% felt ready for the March 2025 deadline.
Source: Help Net Security, WiFi Talents
The compliance rate for PCI DSS trails behind HIPAA (92%) and GDPR (87%), which suggests many development teams are still catching up.
Key takeaways:
- 51 future-dated requirements became mandatory on March 31, 2025
- Requirement 6.4.3 requires script inventory, authorization, and integrity verification for payment pages
- MFA is now required for all CDE access, not just administrators (8.4.2)
- Non-compliance penalties range from $5,000 to $100,000 per month
- Scope reduction through tokenization remains the most effective way to reduce compliance burden
This article covers the specific PCI DSS 4.0 requirements that affect payment software developers, the deadlines you need to know, and practical approaches to reducing your compliance scope.
PCI DSS 4.0 timeline and key deadlines
The transition from PCI DSS 3.2.1 to 4.0 happened in stages:
| Date | Event |
|---|---|
| March 2022 | PCI DSS 4.0 published |
| June 2024 | PCI DSS 4.0.1 released (minor clarifications) |
| March 31, 2024 | PCI DSS 3.2.1 retired |
| March 31, 2025 | 51 future-dated requirements become mandatory |
PCI DSS 4.0 introduced 64 new requirements total. Of those, 13 were immediately effective, while 51 were designated as best practices until March 2025. The future-dated requirements include the expanded MFA rules (8.4.2), the client-side script management controls (6.4.3), and the change detection requirements (11.6.1).
$4.88 million average data breach cost in 2024 (record high). Financial sector breaches averaged $5.9 million.
Source: Accutive Security
Non-compliance penalties range from $5,000 to $100,000 per month until compliance is restored.
Major changes from PCI DSS 3.2.1
PCI DSS 4.0 shifts from prescriptive controls to outcome-based security objectives. The standard now allows two validation approaches (defined and customized) and places heavier emphasis on continuous security rather than point-in-time assessments.
Key structural changes:
- Customized approach allows organizations to implement alternative controls that meet the intent of a requirement, rather than following the exact defined controls
- Targeted risk analysis is now required for multiple requirements, documented and approved by executive management
- Authentication requirements expanded to require MFA for all cardholder data environment (CDE) access, not just remote administrative access
- Client-side security addressed for the first time with requirements for script inventory and integrity checking on payment pages
For developers, the most significant changes are:
Requirement What changed 6.4.3 Inventory all scripts on payment pages, authorize each, verify integrity 8.4.2 MFA required for everyone accessing the CDE, not just administrators 11.6.1 Change detection for HTTP headers and payment page content with weekly review 6.2.2 Annual training on secure software development is now explicit
Requirements specific to payment software developers
Requirement 6 covers secure development practices. Here’s what it means for your codebase:
Requirement 6.2: Secure development training
Requirement 6.2.2 mandates that developers working on bespoke or custom software receive training on secure coding at least annually. The training must be relevant to their job function and include common vulnerabilities. This isn’t optional supplemental education; it’s a compliance requirement.
Requirement 6.2.3: Code review
All bespoke and custom software must be reviewed before release to production. The review can be manual code review by a qualified individual, automated code analysis tools, or a combination. The person reviewing cannot be the original developer. For teams of one, automated tools become the practical path.
Requirement 6.3.2: Software inventory
You must maintain an inventory of bespoke and custom software with documented business or technical justification for each component. This includes third-party libraries. If you’re using npm packages or similar dependency managers, you need to know what’s in your dependency tree and why.
Requirement 6.4.3: Payment page script management
This is the requirement that affects front-end payment implementations most directly. For scripts executed in the consumer’s browser on payment pages, you must:
- Maintain a method to confirm each script is authorized
- Implement integrity verification for each script
- Maintain an inventory with written justification for each script
Implementation approaches include Content Security Policy (CSP) to whitelist authorized script sources and Subresource Integrity (SRI) to verify script hashes:
Content-Security-Policy: script-src 'self' https://js.stripe.com;
Third-party solutions like Feroot, Reflectiz, and Jscrambler provide script inventory and monitoring capabilities if you don’t want to build this in-house.
The requirement targets JavaScript skimming attacks (Magecart-style compromises) where attackers inject malicious scripts into payment pages to steal card data.
Requirement 8.4.2: MFA for CDE access
Under PCI DSS 3.2.1, MFA was required only for remote administrative access to the CDE. Under 4.0, MFA is required for all access to the CDE, regardless of user role or network location.
This means if you work from home, connect via VPN, and then access the CDE, you need MFA twice: once for the VPN and once for CDE access. The PCI SSC guidance mentions FIDO-based authentication as a preferred method for its phishing resistance.
Customized approach vs defined approach
PCI DSS 4.0 offers two validation methods:
Aspect Defined approach Customized approach Control design Follows PCI DSS 4.0 specified controls Implements alternative controls meeting security objective Documentation Standard testing procedures Targeted risk analysis required for each requirement Validation Self-assessment (SAQ) or QSA audit QSA assessment required (no SAQ option) Compensating controls Available if needed Not applicable
The defined approach is what most organizations know from previous versions: specific controls with specific testing procedures. The customized approach allows flexibility but requires significantly more documentation.
For each requirement met via customized approach, you must:
- Document the customized approach objective
- Perform a targeted risk analysis
- Create a controls matrix showing how your implementation meets the objective
- Get executive approval for the risk analysis
The templates are in Appendix E of the PCI DSS standard. You can use a hybrid approach, meeting most requirements through the defined approach and using customized approach only where your architecture genuinely differs from the standard controls.
Organizations with mature security programs and specific technical constraints benefit from customized approach. Organizations newer to PCI DSS or without dedicated compliance resources should stick to defined approach.
Implementation checklist for developers
Here’s what to verify in your payment software:
Script management (6.4.3)
- [ ] Inventory all JavaScript on payment pages
- [ ] Document business justification for each script
- [ ] Implement CSP headers or equivalent authorization mechanism
- [ ] Add SRI hashes for scripts from external sources
- [ ] Set up monitoring for unauthorized script changes
Authentication (8.4.2, 8.3.6)
- [ ] MFA required for all CDE access paths
- [ ] Password minimum 12 characters (future-dated requirement now mandatory)
- [ ] MFA factors are independent (compromise of one doesn’t compromise another)
Secure development (6.2, 6.3)
- [ ] Annual secure coding training documented
- [ ] Code review process documented with qualified reviewers
- [ ] Software inventory with dependency tracking
- [ ] Vulnerability scanning integrated in CI/CD
Change detection (11.6.1)
- [ ] Mechanism to detect unauthorized changes to HTTP headers on payment pages
- [ ] Mechanism to detect unauthorized changes to payment page content
- [ ] Alerts generated for detected changes
- [ ] Weekly review of detection results
Architecture consideration: scope reduction
The most effective way to reduce PCI DSS compliance burden is to reduce scope. If card data never touches your systems, many requirements don’t apply to your code.
Payment orchestration platforms that handle tokenization can remove your systems from scope for card data storage and transmission requirements. When you integrate through an orchestration layer, the PCI-certified provider handles the card data directly, and your systems only see tokens.
This doesn’t eliminate all PCI DSS requirements. If you have a payment page that collects card numbers (even if they’re immediately tokenized), requirements like 6.4.3 still apply. But it substantially reduces the scope of what you need to build and maintain.
The trade-off: you add a network hop and a dependency on the orchestration provider’s uptime. For most teams, the reduced compliance scope and maintenance burden outweigh the latency cost.
Frequently asked questions
When did PCI DSS 4.0 become mandatory?
PCI DSS 4.0 became the only active version on March 31, 2024, when PCI DSS 3.2.1 was retired. The 51 future-dated requirements that were previously best practices became mandatory on March 31, 2025.
What is the customized approach in PCI DSS 4.0?
The customized approach allows organizations to implement alternative security controls that meet the intent of a requirement, rather than following the exact defined controls. It requires a targeted risk analysis and documented justification for each requirement, with executive approval. The customized approach requires QSA validation and cannot be used with self-assessment questionnaires.
Which PCI DSS 4.0 requirements affect payment software developers?
Key requirements include Requirement 6 (secure software development), Requirement 8 (authentication and access), Requirement 11 (security testing), and the new requirements for client-side script management (6.4.3) and change detection (11.6.1). Requirement 6.4.3 specifically addresses JavaScript on payment pages, requiring inventory, authorization, and integrity verification.
What are future-dated requirements in PCI DSS 4.0?
Future-dated requirements were best practices until March 31, 2025, after which they became mandatory. They include enhanced authentication (8.4.2 requiring MFA for all CDE access), targeted risk analysis requirements, 12-character minimum passwords (8.3.6), and script management requirements (6.4.3).
How does PCI DSS 4.0 affect API security?
PCI DSS 4.0 adds requirements for securing APIs that process cardholder data, including inventory management, authentication controls, and protection against common API vulnerabilities. The change detection requirements in 11.6.1 apply to payment page APIs, requiring monitoring for unauthorized modifications.
