PCI DSS v4.0

PCI DSS v4.0 is the most significant update to the standard since its creation. Released in March 2022 after years of industry feedback, it modernized authentication, targeted the e-commerce skimming attacks that dominate modern card theft, and introduced flexibility mechanisms for mature security programs. Version 3.2.1 was retired on March 31, 2024; the last of the v4.0 "future-dated" requirements became mandatory on March 31, 2025. As of today, the transition is over: the full v4.x requirement set is in force, and the current document is v4.0.1 (published June 2024), a limited revision that clarified language and corrected errors without adding or removing requirements.

If your organization validated under v4.0 while treating the future-dated items as "best practices," this lesson doubles as a punch list — those items are now assessed like any other requirement.

The Two Validation Approaches

The biggest philosophical change in v4.0 is the choice of how to meet each requirement:

The defined approach works like every previous version — implement the requirement as written, and the assessor executes the standard testing procedures. This remains the right choice for most organizations and for most requirements.

The customized approach lets an organization design its own control to meet the stated Customized Approach Objective of a requirement, when the prescribed method doesn't fit how it operates. The price is rigor: a documented controls matrix, a targeted risk analysis for each customized control, evidence of effectiveness, and an assessor who must design bespoke testing procedures. The customized approach is only available in QSA assessments (not SAQs, except SAQ-eligible entities doing a full assessment), and a handful of requirements explicitly prohibit it.

Practical guidance: the customized approach is a scalpel, not a strategy. Mature organizations use it for a small number of requirements where their architecture genuinely diverges from the standard's assumptions (say, passwordless authentication schemes). Using it broadly multiplies documentation and assessment cost.

Don't confuse the customized approach with compensating controls, which still exist: compensating controls address a constraint preventing compliance as written; the customized approach is a choice to meet the objective differently.

Targeted Risk Analysis

Version 4.0 replaced several one-size-fits-all frequencies with entity-defined frequencies justified by a targeted risk analysis (TRA) — a documented, requirement-specific analysis, reviewed at least annually, following the elements in requirement 12.3.1. Examples: how often you perform POI device inspections, malware scans on removable media, non-console access re-authentication for certain scenarios, and log reviews for lower-risk systems.

The trap: a TRA is not "we decided quarterly is fine." Assessors expect identification of the assets and threat being addressed, factors affecting likelihood and impact, the resulting frequency, and evidence the analysis is maintained. If you don't want to write TRAs, you can simply adopt conservative fixed frequencies — the TRA is an option, not an obligation, for most of these controls.

The Requirements That Became Mandatory in March 2025

The v4.0 rollout deliberately staggered its hardest requirements. All of the following were "best practice" until March 31, 2025 and are now required:

Area	Requirement (abbrev.)	What It Demands
Authentication	8.3.6	Passwords minimum 12 characters with letters and numbers
Authentication	8.4.2, 8.5.1	MFA for all access into the CDE; MFA systems replay-resistant, not bypassable
Authentication	8.6.1–8.6.3	Interactive use of system/application accounts controlled; their passwords protected and rotated per TRA
Accounts	7.2.4, 7.2.5	Semi-annual review of all user accounts and of application/system account privileges
E-commerce	6.4.3	Inventory, authorization, and integrity assurance of all payment page scripts
E-commerce	11.6.1	Tamper/change detection on payment pages and HTTP headers, at least weekly or per TRA
Logging	10.4.1.1	Automated mechanisms for audit log review
Detection	10.7.x	Detect, alert on, and respond to failures of critical security control systems
Scanning	11.3.1.1, 11.3.1.2	Manage all other (non-high) vulnerabilities per TRA; internal scans performed with authenticated scanning
Malware/Phishing	5.3.3, 5.4.1	Anti-malware for removable media; mechanisms to detect and protect personnel against phishing
Web apps	6.4.2	Automated technical solution for public-facing web apps that actively blocks attacks (WAF-style), replacing the review-or-WAF choice
Data at rest	3.5.1.2, 3.5.1.1	Disk-level encryption alone insufficient for non-removable media; keyed cryptographic hashes if hashing PANs
SAD	3.3.2, 3.3.3	SAD stored before authorization encrypted; issuer SAD storage limited and protected
Cert/keys	4.2.1.1	Inventory of trusted keys and certificates for PAN transmission
Governance	12.3.1	Targeted risk analyses documented for each TRA-permitted requirement
Scope	12.5.2.1, 12.5.3 (SPs)	Service providers: scope confirmation every six months and after significant org changes
Training	12.6.2, 12.6.3.x	Security awareness updated per threat landscape; covers phishing and acceptable use

If any row in that table is news to your team, treat it as a gap today, not a roadmap item — assessments and SAQs signed after March 2025 test these outright.

The Changes That Hit Hardest in Practice

MFA everywhere in the CDE. Under v3.2.1, MFA applied to remote access and non-console admin access. Under v4.x it applies to all access into the CDE, for all users, applications aside. Organizations with legacy POS back-of-house systems, thick clients, or shared workstations have found this the single most expensive uplift.

Payment page script controls (6.4.3 + 11.6.1). These two requirements exist because of Magecart: attackers injecting or replacing JavaScript on checkout pages to skim cards client-side, invisible to server-side defenses. Compliance requires knowing every script that loads on card-capture pages, having a reason and authorization for each, assuring integrity (SRI hashes, CSP, or script-monitoring tools), and detecting unauthorized changes to page content and security headers on a weekly-or-justified cadence. An ecosystem of specialized monitoring vendors has grown around exactly these two requirements. Even SAQ A merchants are affected via eligibility criteria — see the SAQ lesson.

Authenticated internal scanning. Unauthenticated scans see what an outsider sees; authenticated scans see the missing patches and misconfigurations that matter. Standing up credentialed scanning safely (vaulted credentials, scoped scan accounts) is a real project for teams that ran unauthenticated for years.

Automated log review. "An engineer eyeballs the logs daily" no longer flies for most environments. In practice this requirement means a SIEM or log analytics platform with correlation and alerting — and evidence that alerts get triaged.

Keyed hashes and the end of disk-encryption-only. If you protected stored PANs with full-disk encryption on servers, or with plain SHA-256 hashes, both patterns are now non-compliant on their own. Field/column-level encryption, tokenization, or keyed hashing (HMAC or equivalent) are the compliant patterns.

What v4.0.1 Changed

v4.0.1 is a limited revision: it corrected typographical errors, clarified guidance and applicability notes (notably around 6.4.3/11.6.1 applicability and TPSP responsibilities), and realigned some wording — it added no new requirements and removed none, and no new deadlines came with it. v4.0 itself was retired as a validation document at the end of 2024, so current assessments and SAQs use v4.0.1 templates. If your policies cite "v4.0," updating references to v4.0.1 is housekeeping, not remediation.

Closing Remaining Gaps: A Practical Sequence

Re-run your gap assessment against v4.0.1, specifically flagging the March 2025 items above — many organizations gap-assessed in 2023 and never revisited.
Fix authentication first: 12-character passwords, CDE-wide MFA, and system-account controls. These changes touch the most users and need the longest change-management runway.
Stand up the e-commerce controls if you take cards online: script inventory and authorization workflow, integrity mechanism (CSP/SRI or a monitoring tool), and weekly tamper detection with alerting.
Upgrade detection: automated log review, security-control-failure alerting, authenticated scans, phishing protection.
Write the TRAs for every frequency you've customized — or eliminate the need by adopting fixed conservative frequencies.
Refresh documentation: roles and responsibilities per requirement family (a v4.x formalization), TPSP responsibility matrices, certificate inventory, and updated policies referencing v4.0.1.
Brief your assessor early on any customized-approach or compensating-control plans — surprises at assessment time cost weeks.

v4.x Readiness Checklist

Frequently Asked Questions

Is the v4.0 transition period really over?

Yes, on both axes. v3.2.1 retired on March 31, 2024, and the 50-plus future-dated v4.0 requirements became mandatory on March 31, 2025. Any assessment, SAQ, or AOC completed now is against the full v4.0.1 requirement set with no deferred items.

Do we need to redo anything because of v4.0.1?

No remediation — v4.0.1 added no requirements. You should use v4.0.1 report and SAQ templates for new validations and update document references, and it's worth reading the clarified applicability notes for 6.4.3/11.6.1 and TPSP requirements, which resolved several ambiguities in your favor or against, depending on your architecture.

Should we use the customized approach?

Only if a specific requirement genuinely conflicts with a well-designed architecture you don't want to change, you undergo QSA assessments (it's unavailable for standard SAQ validation), and you're prepared to write and maintain a controls matrix plus TRA per customized control. Most organizations — including most mature ones — validate everything under the defined approach and customize nothing or one or two items.

We're SAQ A — how much of v4.x affects us?

More than under v3.2.1. Beyond the modest question count, the e-commerce anti-skimming intent reaches SAQ A merchants through eligibility criteria requiring that your site is not susceptible to script-based attacks on the payment flow, and your acquirer may ask how you ensure that (script management, CSP, or a monitoring service on the page hosting the redirect/iframe).

What is a targeted risk analysis and how many do we need?

A TRA is a short, structured, per-requirement analysis justifying a frequency or practice you've chosen where the standard allows discretion (12.3.1 lists the required elements). You need one for each requirement where you exercise that discretion — commonly POI inspection frequency, certain log review cadences, non-high vulnerability handling, and system-account password rotation. Adopting the conservative default frequency instead eliminates the TRA for that item.

When is PCI DSS v5 coming?

The Council has signaled that the next major version is years out and will follow its usual multi-year RFC process, with v4.0.1 as the stable baseline for the foreseeable future. Plan your program around v4.0.1 as a steady state — the recent history of the standard suggests future-dated grace periods will accompany whatever comes next.

Closing v4.x gaps usually means new tooling — script monitoring, SIEM, scanning, evidence automation — and sometimes a new assessor. AuditXYZ helps you compare compliance automation platforms and auditors so you can see which vendors already map their controls to PCI DSS v4.0.1.

PCI DSS v4.0: What Changed and How to Prepare