PCI DSS 4.0 Compliance Guide for Developers: What Changed and What to Do

PCI DSS 4.0: What Changed

PCI DSS 4.0, released March 2022 and fully enforceable since March 31, 2025, is the most significant update to the Payment Card Industry Data Security Standard in over a decade. The transition deadline from v3.2.1 has passed — compliance is now mandatory.

Aspect	PCI DSS 3.2.1	PCI DSS 4.0
Approach	Prescriptive only	Defined + Customized approaches
MFA	Admin access only	All access to CDE
Password length	Minimum 7 chars	Minimum 12 chars
Script management	Not addressed	Integrity verification required
Vulnerability scanning	Quarterly external	Authenticated internal + quarterly external
Risk assessment	Annual	Targeted risk analysis for each flexible req
Encryption	TLS 1.1+	TLS 1.2+ only (1.0/1.1 banned)
Detection	Required logging	Automated log review mechanisms

Key Changes for Developers

1. Client-Side Script Management (Req 6.4.3)

This is the biggest new requirement for web developers. All payment page scripts must be inventoried, authorized, and integrity-verified.

What It Means:

Every JavaScript file loaded on your payment page must be explicitly authorized
Script integrity must be verified (Subresource Integrity - SRI, Content Security Policy)
Unauthorized script changes must be detected and alerted

<!-- Subresource Integrity (SRI) — Verify script hasn't been modified -->
<script 
  src="https://js.stripe.com/v3/"
  integrity="sha384-exactHashOfTheExpectedFile"
  crossorigin="anonymous">
</script>

<!-- Content Security Policy — Only allow approved script sources -->
<meta http-equiv="Content-Security-Policy" 
  content="script-src 'self' https://js.stripe.com; 
           frame-src https://js.stripe.com;">

2. MFA for All CDE Access (Req 8.4.2)

Multi-factor authentication is now required for all access to the Cardholder Data Environment (CDE), not just administrative access.

3. Stronger Password Requirements (Req 8.3.6)

Parameter	Old (3.2.1)	New (4.0)
Minimum length	7 characters	12 characters
Complexity	Alpha + numeric	Alpha + numeric (or equivalent)
Change frequency	90 days	90 days (or continuous risk analysis)
Failed attempts lockout	After 6 attempts	After 10 attempts
Lockout duration	30 minutes	30 minutes

4. Authenticated Vulnerability Scanning (Req 11.3.1.1)

Internal vulnerability scans must now use authenticated scanning — meaning the scanner logs in with credentials to find vulnerabilities that anonymous scans would miss.

5. Targeted Risk Analysis (Req 12.3.1)

For any requirement where PCI DSS 4.0 offers flexibility (e.g., password change frequency, log review frequency), you must perform a documented targeted risk analysis to justify your chosen approach.

Payment Flow Security Architecture

Reducing PCI Scope with Tokenization

                    ┌────────────────── PCI SCOPE ──────────────────┐
                    │                                                │
Traditional:       [Browser] ──► [Your Server] ──► [Payment Gateway]
                    │    Card data touches your server (SAQ D)       │
                    └────────────────────────────────────────────────┘

                    ┌── NO PCI SCOPE ──┐   ┌─── PCI SCOPE ───┐
Tokenized:         [Browser] ──────────►  [Stripe.js / PSP]
                    │ Your server never  │   │ Card data stays │
                    │ sees card data     │   │ at processor    │
                    │ (SAQ A / SAQ A-EP) │   │                 │
                    └────────────────────┘   └─────────────────┘

Secure Payment Implementation (Stripe Elements)

// Client-side — Card data never touches your server
import { loadStripe } from "@stripe/stripe-js";

const stripe = await loadStripe("pk_live_...");
const elements = stripe.elements();
const cardElement = elements.create("card");
cardElement.mount("#card-element");

// On submit - tokenize client-side
const { token, error } = await stripe.createToken(cardElement);

// Send only the TOKEN to your server (not card data)
await fetch("/api/checkout", {
  method: "POST",
  body: JSON.stringify({ token: token.id, amount: 9999 }),
});

PCI DSS 4.0 Compliance Checklist for Developers

Network & System Security

TLS 1.2 minimum (remove TLS 1.0/1.1 support)
Network segmentation isolating CDE from other systems
Firewall rules documented and reviewed every 6 months
No unnecessary ports, protocols, or services

Authentication & Access

MFA for all CDE access (including developers, support)
12-character minimum passwords
Account lockout after 10 failed attempts
Unique IDs for all users (no shared accounts)

Application Security

Client-side script inventory and integrity verification
Input validation on all payment-related inputs
Content Security Policy on payment pages
SRI on all third-party scripts
Authenticated vulnerability scanning quarterly
Annual penetration testing
Secure SDLC practices (code review, SAST)

Data Protection

No storage of sensitive authentication data post-authorization
Encryption of stored PAN (AES-256 or equivalent)
Key management procedures documented
Tokenization implemented to reduce scope

Monitoring & Logging

Automated log review mechanisms
All CDE access logged with tamper detection
Alerting on security-relevant events
Log retention: minimum 12 months (3 months readily available)