PCI DSS v4.0: What Actually Changed vs. v3.2.1
PCI DSS v3.2.1 retired on March 31, 2024. Version 4.0.1 — a clarifying revision of v4.0 — is now the sole active standard. Here is what the update actually requires, sourced directly to the PCI Security Standards Council’s own summary of changes.
The Short Version
PCI DSS v4.0 added 64 new requirements on top of v3.2.1’s baseline: 13 became mandatory immediately when v3.2.1 retired (April 2024), and the remaining 51 — the “future-dated” requirements — became mandatory on March 31, 2025. The headline changes are a new Customized Approach option, mandatory MFA for all access into the cardholder data environment, a minimum 12-character password length, and a formal Targeted Risk Analysis process for setting your own control frequencies.
The Version Timeline
PCI DSS v4.0 was published in March 2022 after a three-year development process incorporating roughly 6,000 feedback items from more than 200 organizations. The Council gave the industry two years to prepare before v3.2.1 retired.
Source: PCI Security Standards Council, “Just Published: PCI DSS v4.0.1” and the Council’s official Summary of Changes, v3.2.1 to v4.0.
The Six Changes That Actually Matter
Under v3.2.1, MFA was required only for remote access and administrative access to the CDE. v4.0 expands this to all access into the cardholder data environment, not just remote and admin paths. The v4.0.1 clarifying revision added a narrow exception for phishing-resistant authentication factors.
Minimum password length increases from seven to twelve characters (eight where a system cannot yet support twelve). This was one of the future-dated requirements, mandatory since March 31, 2025.
A new, formal Targeted Risk Analysis (TRA) process lets an entity define the frequency of certain activities — such as specific log reviews or periodic scans — based on a documented risk analysis rather than a fixed schedule the standard used to dictate outright.
v4.0 keeps the traditional prescriptive (“Defined Approach”) method and adds an optional Customized Approach, letting an organization design and validate its own control to meet a requirement’s stated objective through its own testing methodology and risk analysis — more implementation flexibility, more assessor scrutiny.
“Firewall” terminology throughout the standard was replaced with “network security controls” — a deliberate broadening to recognize cloud-native constructs (security groups, NSGs, service meshes) that provide equivalent boundary enforcement without being a traditional firewall appliance.
Point-in-time scanning gives way to more continuous vulnerability management expectations, including authenticated internal vulnerability scanning and more explicit roles-and-responsibilities documentation for every requirement.
The Future-Dated Requirements Are Already in Force
Because all 51 future-dated requirements became mandatory on March 31, 2025, “we’ll get to v4.0 eventually” is no longer a viable posture for any organization undergoing an assessment or ROC today. If your last assessment predates that deadline, assume your control set has a gap until you’ve specifically verified MFA scope, password policy, and segmentation testing evidence against the current standard.
Armorstack’s VERITY portfolio runs a targeted v4.0.1 gap assessment against your last ROC or SAQ to identify exactly which of the 51 future-dated controls are already covered by existing infrastructure work and which require net-new implementation — typically the fastest path to closing the gap without re-scoping the entire environment.
Continue Reading
v4.0.1 SAQs were republished with the updated controls baked in. Find your type.
Requirement 11.4.5’s segmentation penetration testing didn’t change in substance in v4.0 — see what it requires.
Back to the full guide on the 12 requirements and who has to comply.