PCI DSS v4.0 — effective March 31, 2025 as the mandatory standard for all entities handling payment card data — introduces 64 new requirements over PCI DSS v3.2.1, with a particular focus on targeted risk analysis, customised implementation, and technical controls that address modern payment security threats including API security, multi-factor authentication, and cryptographic agility. For fintech developers and payment engineers, understanding the specific technical requirements that directly affect software development, API design, and infrastructure configuration is essential. This compliance guide translates PCI DSS v4.0 into developer-actionable requirements.
PCI DSS v4.0 Core Requirements (Developer-Relevant)
| Requirement | PCI DSS v4.0 Change | Developer Action |
|---|---|---|
| Req 6: Secure systems and software | New: software security testing for public-facing apps every 12 months; automated technical testing; script integrity for payment pages | Annual DAST scan; CSP/SRI headers for all payment page scripts |
| Req 8: Strong authentication | MFA required for ALL access to CDE (not just remote access) | MFA enforced for all admin, developer, and operator access to payment systems |
| Req 10: Log review | Automated log review required (not just manual) | Implement SIEM alert rules for anomalous CDE access |
| Req 11: Security testing | Pentest network segmentation annually; internal vulnerability scans quarterly | Quarterly internal scans + annual penetration test scheduled |
| Req 12: Policies and processes | Targeted Risk Analysis (TRA) required for customised controls | Document TRA for any v4.0 "customised approach" controls |
The Cardholder Data Environment (CDE) — Scope Determination
PCI DSS applies to your Cardholder Data Environment (CDE) — all systems that store, process, or transmit cardholder data (PAN, CVV, expiration date) and all systems connected to them. Scope minimisation is the most impactful PCI DSS programme decision: eliminate your CDE entirely by using a payment processor's hosted payment page (Stripe Elements, Braintree Hosted Fields, Adyen Drop-in) — if cardholder data never touches your servers, your PCI scope is minimal. If you cannot eliminate CDE, use network segmentation to contain it and reduce the number of in-scope systems.
March 2025
PCI DSS v4.0 mandatory compliance date — all v3.2.1 assessments are no longer valid; all entities processing payment cards must comply with v4.0. "Future-dated" requirements in v4.0 are effective March 31, 2025
SRI/CSP
Two of the most impactful new PCI DSS v4.0 requirements for web developers: Subresource Integrity (SRI) hashes on all payment page scripts (prevents Magecart-style skimming attacks), and Content Security Policy (CSP) headers restricting script sources on payment pages
64 new
New requirements in PCI DSS v4.0 vs v3.2.1 — the largest revision to the standard. Most additions reflect modern security practices that were already considered best practice; v4.0 makes them mandatory with specific implementation criteria
Requirement 6: Payment Page Script Security
New in v4.0: all scripts on payment pages must be authorised and their integrity protected. Implementation: (1) Content Security Policy header:
Content-Security-Policy: script-src 'self' https://js.stripe.com; object-src 'none' — only whitelisted sources can load scripts on payment pages; (2) Subresource Integrity for CDN-loaded scripts: <script src="..." integrity="sha384-..." crossorigin="anonymous">. Generate SRI hashes with openssl dgst -sha384 -binary script.js | openssl base64 -A. These two controls prevent Magecart JavaScript skimming attacks that have compromised major retailers.Requirement 8: MFA for CDE Access
v4.0 extends MFA requirement from remote access to ALL access to the CDE — including internal developer access to production payment systems. Implementation: (1) Enforce MFA on all cloud console access to CDE accounts (AWS IAM Identity Center, Azure AD Conditional Access, GCP Identity Platform); (2) MFA for all jump server / bastion host access; (3) MFA for all database access to payment-related tables; (4) Privileged Access Management (PAM) solution (CyberArk, Delinea) with MFA integration for all privileged accounts. No exemptions for internal network access — this is the most commonly missed v4.0 requirement.
Cryptographic Requirements (Req 3 & 4)
v4.0 cryptographic requirements: (1) Disk-level encryption of cardholder data at rest using AES-256 (minimum); (2) TLS 1.2 minimum for all CDE data in transit — TLS 1.0 and 1.1 are prohibited; (3) Key management: dedicated HSM or cloud KMS (AWS KMS, Azure Key Vault) for all payment encryption keys; (4) Key rotation: payment data encryption keys rotated annually minimum; (5) No deprecated algorithms (MD5, SHA-1, DES, 3DES) in any CDE cryptographic function. Audit with:
testssl.sh your-payment-endpoint.com to verify TLS configuration; AWS Security Hub for KMS key rotation compliance.PCI DSS v4.0 Developer Checklist
(1) Use Stripe Elements / Braintree Hosted Fields — eliminate CDE scope if possible; (2) CSP and SRI on all payment pages — prevents script skimming; (3) MFA on all CDE system access — no exceptions for internal access; (4) TLS 1.2+ everywhere in CDE — verify with testssl.sh; (5) Quarterly DAST scan of payment page/API — schedule now; (6) Annual penetration test covering CDE network segmentation; (7) SIEM alert rules for anomalous CDE access; (8) Key rotation scheduled — annual minimum for payment keys; (9) Tokenise PANs in your application layer — never store raw PANs; (10) Log all CDE access with immutable retention (12 months minimum). Our DevOps team implements PCI DSS technical controls.
PCI DSS v4.0 Technical Compliance
Our DevOps, software development, and API integration teams implement PCI DSS v4.0 technical controls for fintech developers and payment platforms. Book a free advisory session.