What changed in PCI-DSS 4.0 vs 3.2.1 (web/email subset)

PCI-DSS 4.0 was published 2022-03-31. Transition deadline was 2024-03-31; new requirements effective 2025-03-31. We're a year past full enforcement now. If you process card data and haven't moved off 3.2.1, your latest QSA assessment didn't go well.

Below is the engineer's-eye summary — what actually changed for the web and email surfaces. The full standard runs 350+ pages and addresses the entire stack including physical security, vendor management, etc. We're focused on the slice UnveilScan touches.

The headlines

For TLS specifically (§4.2.1)

"Use of strong cryptography and security protocols". The list of "strong" excludes SSL, all TLS < 1.2, and any cipher suite with known weaknesses. TLS 1.0 and 1.1 are now formally barred from the cardholder data environment. There is no exception for "compatibility with legacy clients".

This is the requirement we map our tls.legacy_protocol_enabled finding to. CRITICAL severity is calibrated against this. See our writeup on why even Google fails it.

For email (§5, indirectly)

PCI-DSS doesn't directly mandate SPF/DKIM/DMARC, but auditors expect them as part of "protect against malware" + "monitor for phishing". A QSA who finds you have no DMARC record on a CHD-handling domain will write it up. We surface this through the dmarc_alignment + spf_dkim checkers.

For web applications (§6.4)

New requirement 6.4.3: an automated technical mechanism authorising scripts on payment pages. In practice, this means CSP. Specifically:

• Each script must be authorised (by source whitelisting, nonce, or hash).
• Inline scripts allowed by 'unsafe-inline' alone are not authorised.
• The mechanism must alert on changes to the script inventory.

This was a big push from Visa specifically (driven by Magecart skimmer concerns). Our csp checker grades this directly — a payment page with 'unsafe-inline' on script-src is now a PCI failure.

Customised approach (the escape hatch)

4.0 introduces "customised approach" — instead of meeting the literal control text, you can document a different control that meets the same security objective. Approval requires a targeted risk analysis (§12.3.1).

In practice, this lets technically sophisticated organisations propose alternatives. Example: instead of "password rotation every 90 days", you might propose "MFA + breach monitoring + per-account anomaly detection". As long as the QSA agrees the objective is met, approved. This is the most contentious change with auditors.

What auditors actually look for in our scope

1. External scan results from an ASV (Approved Scanning Vendor) — UnveilScan is not an ASV; we complement, we don't replace.
2. TLS 1.2/1.3 only on every public-facing endpoint touching CHD.
3. HSTS preload on the payment domain.
4. CSP that whitelists every script on payment pages.
5. SPF/DMARC on every domain that sends mail.
6. WAF rules + alerting (we can confirm a WAF is in front via our cdn checker but can't audit the rules).
7. Internal scan + triage process — periodic, documented.

How UnveilScan helps

On every Extended scan we now embed a compliance mapping in the JSON report — each finding cross-referenced against PCI-DSS 4.0 controls (and ISO 27001:2022, SOC 2, NIS 2, GDPR). Run an Extended, export the JSON, hand the compliance section to your QSA. Saves hours of mapping.