PCI DSS v4.0.1 in 2026: The 51 Future-Dated Requirements Are Now Mandatory

PCI DSS has governed how the global payment industry protects cardholder data for nearly two decades. Until 2022, the version in active use — v3.2.1 — had remained substantially stable through years of incremental clarification. PCI DSS v4.0, released in March 2022, ended that period of stability. It was the first major revision to the standard in over a decade and introduced 64 new or updated requirements, a more flexible "customised approach" option alongside the traditional prescriptive method, and a clear shift in philosophy: security is a continuous, business-as-usual process, not an annual compliance event.

The Council gave organisations a long transition window. Thirteen of the 64 new requirements became effective immediately when entities began validating against v4.0; the other 51 were designated "future-dated" and treated as best practices only — they did not need to be in place for compliance — until 31 March 2025. That window closed more than a year ago. Every assessment conducted in 2026 measures against the full set of v4.0.1 requirements with no future-dated exceptions.

For many organisations, this is fine. The future-dated requirements were always going to become mandatory and the responsible path was to implement them progressively across the transition window. For others — particularly entities that validated under v4.0 in 2024 and treated the future-dated items as out of scope, or entities whose last assessment was under v3.2.1 — the next assessment will look very different from the last one. This piece walks through the timeline, what changed substantively, and the practical implications.

Where Things Stand Now

The standard's path from v3.2.1 to fully-active v4.0.1 took roughly three years from publication to enforcement. The major waypoints:

• March 2022

  PCI DSS v4.0 published

  The first major revision in over a decade. Introduced 64 new or updated requirements — 13 effective immediately on adoption, 51 designated future-dated. Introduced the customised approach as an alternative to the defined approach. Added an explicit emphasis on security as a continuous practice rather than an annual cycle.

• 31 March 2024

  v3.2.1 retired

  All assessments and validations conducted after this date had to be against v4.0 or later. Entities could no longer attest to v3.2.1 compliance.

• June 2024

  v4.0.1 published as a limited revision

  A clarification update. Corrected typographical errors, refined applicability notes, and improved guidance. Critically, v4.0.1 added no new requirements and removed none — and it did not move the 31 March 2025 deadline for future-dated items.

• 31 December 2024

  v4.0 retired

  From 1 January 2025, v4.0.1 became the only supported version. All assessments are now conducted against v4.0.1.

• 31 March 2025

  All 51 future-dated requirements mandatory

  The transition window closed. From this date, every requirement introduced in v4.0 is in scope for every assessment. Auditors and ASVs now score the full standard.

• 2026 onward

  Continuous compliance era

  Assessments now examine not just point-in-time control state but evidence of ongoing operation — log review cadence, vulnerability scan results across the year, MFA enrolment coverage, payment-page script change-detection alerts, and the targeted risk analyses that justify control frequencies.

The Substantive Changes That Matter Most

Of the 64 new or updated requirements, a smaller number drive most of the implementation work. The following clusters are where the bulk of remediation effort in 2026 assessments tends to sit.

Multi-factor authentication for all CDE access

Under v3.2.1, MFA was required for all administrative access into the cardholder data environment (CDE) and for all remote access. Under v4.x, MFA is required for all access into the CDE — administrative or not, remote or local. This is the requirement that most frequently expands MFA's scope: jump boxes, internal user accounts that touch the CDE, application accounts with CDE access, vendor accounts, single sign-on edges, API service accounts. The applicability note exempting user accounts that authenticate only with phishing-resistant factors (introduced in v4.0.1) provides some relief in modern environments, but the default expectation is broad MFA coverage.

Payment-page script controls (6.4.3 and 11.6.1)

E-skimming attacks — where malicious code injected into a payment page captures card data as it is entered — have become one of the most prevalent attacks against e-commerce merchants. Requirements 6.4.3 and 11.6.1 directly address this risk.

6.4.3 requires entities to maintain an inventory of every script that executes in the consumer's browser on a payment page, authorise each script for its specific business purpose, and assure the integrity of each script. 11.6.1 requires tamper-detection or change-detection mechanisms that alert when any script or HTTP header on a payment page changes unexpectedly. Both apply broadly: entities with embedded payment iframes, hosted payment pages where the entity controls outer-page content, and any payment flow where the entity can influence what scripts execute in the browser at the moment of card capture.

The Council has issued specific guidance on these requirements ("Payment Page Security and Preventing E-Skimming"), and the most recent update to SAQ A makes clear that even merchants who fully outsource payment processing must confirm these controls operate on their behalf.

Targeted Risk Analyses

Several v4.x requirements explicitly permit entities to determine their own frequency for periodic activities — for example, how often to review user accounts, run anti-malware scans, or inspect log entries from systems outside the CDE that could affect it. To use a frequency other than the prescriptive default, the entity must perform and document a Targeted Risk Analysis (TRA) justifying the chosen cadence based on threat scenarios, control effectiveness, and residual risk.

This is not optional documentation. Where an entity uses a non-default frequency for any in-scope activity and cannot produce the TRA, the assessment finding is straightforward: the activity is not being conducted at the required frequency. The Council has published a TRA guidance document and template; using these supports an assessor's review.

Password strength and authentication

The new standard requires 12-character passwords for user authentication where passwords are the only factor (previously 7 characters). Legacy systems that cannot enforce 12-character passwords may continue with 8 characters only if the entity has documented why the legacy constraint exists and has a remediation path. "Difficult to change" is not a sufficient justification.

Cryptographic rendering of PAN at rest

Under v3.2.1, disk-level or partition-level encryption was an acceptable method to render primary account numbers unreadable at rest. Under v4.x, this is no longer the case (except for removable electronic media). File-level, column-level, or field-level encryption is required, with keys managed independently of the operating system's user authentication. Entities that relied on full-disk encryption alone as their PAN-at-rest control under v3.2.1 typically need to introduce additional cryptographic measures at the application or database layer.

Software inventory implying SBOMs (6.3.2 and 11.3.1.1)

6.3.2 requires an inventory of all bespoke and custom software including third-party components integrated into that software — effectively a Software Bill of Materials for in-scope applications. 11.3.1.1 requires that vulnerabilities affecting third-party components be addressed based on their actual risk to the entity. Together these are pushing the standard toward something approaching SBOM-based vulnerability management, even though the term "SBOM" does not appear explicitly in the requirements.

Anti-phishing controls (5.4.1)

Entities must have processes and automated mechanisms in place to detect and protect personnel against phishing attacks. This typically translates into email security gateways with anti-phishing features, browser-based controls, ongoing user awareness training, and the ability to evidence that such mechanisms are operational — not just procured.

What Assessors Are Looking For Now

A v4.0.1 assessment in 2026 is different in structure from a v3.2.1 assessment. The differences come up most often in four areas:

1. Evidence of ongoing operation, not just point-in-time state. Quarterly scan results across the assessment period. Log review evidence with consistent dates. MFA enrolment reports showing coverage over time. Payment-page script tamper-detection alert history. The annual-event compliance model does not produce the kind of evidence v4.x assessments examine.
2. The TRAs behind any non-default frequency. Where the entity has chosen its own cadence for an activity, the documented analysis behind that choice. Without the TRA, the assessor must default to assuming the prescriptive frequency applies and check that the entity met it.
3. Payment-page scripts and tamper detection. The script inventory, the authorisation records, and the alerts produced by tamper detection (and, ideally, the documented investigation of those alerts). This is the single most common newly-active requirement to trip up e-commerce merchants in 2026.
4. Customised approach documentation, if used. Where the entity has chosen the customised approach for any requirement, the documented control objective, alternative method, validation and testing performed, and the residual risk assessment. The customised approach is powerful and explicitly permitted, but the documentation burden is substantial.

Implications for Small Merchants and Service Providers

The 31 March 2025 deadline applied uniformly regardless of merchant level or transaction volume. A small e-commerce merchant validating compliance through SAQ A faces the same v4.0.1 standard as a large issuer running a full Report on Compliance. The practical implementation effort is different — SAQ A is much shorter than the ROC — but the underlying controls expectations are not optional based on size.

A few specific implications for smaller merchants:

• SAQ A merchants must run quarterly external vulnerability scans by an Approved Scanning Vendor. This is new in v4.x and was previously not in scope for fully-outsourced e-commerce merchants. Many SAQ A merchants in 2026 are encountering this requirement for the first time.
• SAQ A merchants must confirm payment-page script controls. Even though scripts on the outsourced payment page are typically managed by the service provider, the merchant must obtain and retain evidence that 6.4.3 and 11.6.1 are being met on their behalf.
• Service provider attestations now matter more. Where a merchant relies on a third-party service provider for any aspect of card data handling, the provider's PCI DSS attestation and the specific requirements it covers become a key piece of the merchant's own compliance evidence. Where the provider's attestation does not cover a particular requirement, the merchant must meet it directly.

What to Do This Quarter

For entities preparing for their next PCI DSS assessment, the highest-leverage activities are:

1. Gap-assess against v4.0.1, not against v4.0 or v3.2.1. If your last gap analysis was done against v4.0 with future-dated items in scope and your environment has not changed since, the gap report is largely current. If your last gap analysis was against v3.2.1, treat it as outdated and start fresh.
2. Expand MFA scope. If MFA is currently limited to administrative access and remote access only, expand it to cover all access into the CDE. This is often the largest single piece of remediation work.
3. Inventory payment-page scripts. If you run any e-commerce flow where the consumer's browser executes scripts on a page that captures card data, build the inventory now and confirm the tamper-detection mechanism is in place and generating evidence.
4. Document Targeted Risk Analyses for any non-default frequencies. List every periodic activity where you currently use a non-default cadence, and produce the TRA that justifies it.
5. Refresh password policy and authentication systems. Push the user-authentication password floor to 12 characters; identify and remediate (or formally accept and document) any legacy 8-character exceptions.
6. Confirm cryptographic rendering of PAN at rest. Where full-disk encryption is your current control, layer in file/column/field-level encryption or tokenisation with independent key management.

The Bottom Line

PCI DSS v4.0.1 is not a future regulation. The transition window closed on 31 March 2025, more than a year ago, and the 51 previously future-dated requirements are now part of every assessment. The change of philosophy from annual event to continuous practice is well established, and assessors expect to see evidence that the standard is being lived in the operating rhythm of the business — not just demonstrated at the moment of the audit. Entities that have moved progressively over the transition window are well placed. Entities that deferred should approach the next assessment with realistic expectations.