PCI DSS v4.0.1: What Changed and What You Need to Do

Requirement 6.4.3 — Payment Page Script Management (Critical)

This is the highest-impact new requirement for e-commerce companies. Every script that is loaded and executed in the consumer's browser on a payment page must be:

• • Authorized: You must maintain a documented inventory of all scripts and confirm each is authorized
• • Integrity-protected: Each script must have a method to confirm it hasn't been tampered with (e.g., Subresource Integrity / SRI hash)
• • Justified: You must document why each script is necessary

This requirement directly targets Magecart-style attacks — JavaScript skimming where attackers inject malicious scripts into payment pages to steal card data. Payment pages with dozens of third-party scripts (analytics, A/B testing, chat widgets) face significant effort to inventory and protect every one.

Requirement 6.4.1 — HTTP Security Headers

All web-based payment pages (delivered to a consumer's browser) must implement anti-skimming security controls. This includes HTTP security headers that protect against the most common client-side attacks:

• • Content-Security-Policy (CSP) — restricts script sources
• • X-Frame-Options or frame-ancestors directive — prevents clickjacking
• • X-Content-Type-Options — prevents MIME type sniffing
• • Referrer-Policy — controls referrer information leakage

Requirement 8.4.2 — MFA for All Access to the CDE

Multi-factor authentication (MFA) is now required for all access into the cardholder data environment (CDE) — not just remote access. This extends to all personnel accessing the CDE from within the internal network.

Previously, MFA was required only for remote access and non-console administrative access. v4.0 expanded this to any access into the CDE, including from trusted internal networks. If you have internal staff accessing CDE systems from your corporate network without MFA, you're now non-compliant.

Requirement 8.3.6 — Password Complexity Update

Minimum password length for user accounts increased from 7 to 12 characters (or 8 characters if the system doesn't support 12). Passwords must also meet complexity requirements including both numeric and alphabetic characters.

This sounds simple but impacts every authentication system that accesses the CDE. Update your password policies, enforce the new minimums, and document the change. During the next credential rotation cycle, users will need to update passwords that don't meet the new minimums.

Requirement 10.7.2 — Automated Monitoring of Security Controls

Automated mechanisms must detect and alert on failures of critical security controls. This includes failures of: firewalls, IDS/IPS, FIM (file integrity monitoring), antivirus, access controls, and audit logging.

Manual monitoring processes are no longer sufficient. You need automated detection and alerting for security control failures — not just for detecting attacks, but for detecting when your defenses themselves go down.

Requirement 12.3.2 — Targeted Risk Analysis (TRA)

The Targeted Risk Analysis approach allows organizations to use risk analysis to justify customized frequencies for certain controls — rather than defaulting to the prescriptive timelines in the standard.

For example, PCI DSS v3 required quarterly vulnerability scans. Under TRA, you can document a risk-based justification for a different frequency if your environment and threat profile support it. However, the TRA itself must be documented, reviewed annually, and kept on file for your QSA.

TRA is a powerful tool — but also a compliance trap. Organizations that adopt TRA without rigorous documentation create audit findings. Every TRA decision requires: the identified risk factor, the impact analysis, the defined control frequency, and annual review documentation.