PCI DSS v4.0.1 future-dated requirements explained

What are the PCI DSS v4.0.1 future-dated requirements and when did they become mandatory?

A payment brand, acquirer or contract now expects a PCI DSS v4.0.1 validation, and the question is which requirements already apply to you. 51 future-dated requirements became effective on 31 March 2025, and PCI DSS v4.0.1, published on 11 June 2024, kept that date unchanged while adding or removing no requirements. Before that date, these requirements were best practices that could be marked Not Applicable. From that date, they must be fully considered in every applicable assessment, so an assessment that still treats them as optional will not be accepted as current.

The impact depends on how you validate, which payment channel you use and whether you are a service provider. A merchant on a Self-Assessment Questionnaire may face a different subset than an entity assessed through a Report on Compliance, and service-provider-only requirements add obligations that merchants never see. Confirm with your acquirer or the requesting brand which validation path applies, then ask your team or provider to map each future-dated requirement to the systems you actually run. Your organization owns the controls. A Qualified Security Assessor, or the signed Self-Assessment Questionnaire and Attestation of Compliance process, is what produces the validation, and an implementation partner can prepare systems and evidence but cannot issue it.

Start by asking your assessor or acquirer for the written list of requirements they expect you to evidence, and confirm whether any were marked Not Applicable in your last submission. Then check that each one has an owner, a procedure and evidence before the assessment window opens. The PCI SSC blog on adopting the future-dated requirements is the natural next read for the SSC's own guidance on early adoption.

What changed on 31 March 2025 for ROCs and SAQs

The sequence moves future-dated requirements from optional best practice to mandatory assessment content, so each ROC or SAQ reports them accurately from that date. Each phase closes with a specific record that an assessor or auditor can check.

Inventory the future-dated requirements in scope
Before 31 March 2025, your team lists the future-dated requirements from the 51 that apply to your environment and your validation type, using the v4.0.1 standard and the SAQ or ROC template you expect to use. Map each one to the systems, processes and people it touches, starting from the current scope definition. The output is a register that names every future-dated requirement, its owner and whether it applies. Confirm the list with your assessor or the payment brand before you rely on it, since eligibility varies by validation path.
Mark unimplemented requirements as not applicable
Where a future-dated requirement was not yet implemented before 31 March 2025, the report could mark it Not Applicable in that assessment cycle. Your team records the reason for each entry and avoids using the option for requirements that already apply to your environment. The output is a dated gap list that shows which requirements are open, what work each one needs, and who owns it. Keep this list as evidence for the assessor, because it shows the planned implementation path rather than an unexamined omission.
Close the gaps before the mandatory date
Your engineers and control owners implement the open requirements, such as the 12-character password rule, MFA for all CDE access and authenticated internal scanning, and they update the policies, configurations and procedures that support them. The result is changed system configurations, updated procedures and new records that show each control operating. You know this step is done when each item on the gap list has implementation evidence and a named reviewer.
Confirm the risk analysis sets the periodic frequencies
From 31 March 2025, the targeted risk analyses under Requirement 12.3.1 set the frequency for activities such as malware scans, system account reviews, POI inspections and log reviews of other systems. Your team documents a risk analysis for each of these activities, following the method the standard describes, and aligns the resulting schedule with the operational calendar. The output is approved risk analysis records and a recurring task calendar that an assessor can trace from each requirement to its frequency.
Fully consider future-dated requirements in every assessment
After 31 March 2025, every applicable ROC or SAQ must consider all future-dated requirements in full, so the Not Applicable option no longer covers them for unimplemented controls. Your assessor tests each applicable requirement against current evidence, and your team supplies that evidence from the configurations, logs, scan reports and records gathered in the earlier phases. The output is assessment workpapers that show a test result for each requirement, with the Attestation of Compliance reflecting the outcome.
Report superseded requirements as not applicable
Three requirements were superseded on 31 March 2025 and are now reported as Not Applicable: 6.4.1, 8.3.10 and 10.7.1, replaced by 6.4.2, 8.3.10.1 and 10.7.2. Your team checks that the replacement requirements are assessed in full and that the superseded entries are marked consistently in the ROC or SAQ. The output is a reporting check that confirms no superseded requirement is still treated as active. Confirm this approach against the current FAQ before final submission.
Stop reporting open gaps as not yet effective
Once 31 March 2025 has passed, an open gap on a future-dated requirement cannot be reported as not yet effective, because the requirement is mandatory for applicable assessments. Your team treats any remaining gap as a finding that needs remediation, or it accepts a documented alternative only where the standard allows one and the assessor agrees. The output is a remediation plan with owners and evidence dates for each open item, reviewed with your assessor before the report is finalized.

Which future-dated requirements matter most, by requirement

The future-dated requirements that became mandatory on 31 March 2025 cover identity, monitoring, testing, and risk-based frequency setting. The six cards below pick the requirements that most often change day-to-day operations, and each one names the evidence an assessor will ask to see.

12-character passwords (8.3.6)

Requirement 8.3.6 raises the minimum length for passwords used as authentication factors to 12 characters, with a mix of numeric and alphabetic characters. Systems that cannot enforce the longer length need a documented review of which accounts and platforms are affected. Check directory policy, application password rules, and any service accounts that still carry shorter passwords. An assessor will typically ask for the configuration export that enforces the rule, not only the written policy. Confirm every authentication system in scope enforces the new length.

MFA for all CDE access (8.4.2)

Requirement 8.4.2 expects multi-factor authentication for all access into the cardholder data environment, not only remote or administrative access. Many organizations secured the VPN and admin consoles first and left internal application logins on single-factor authentication. The gap is usually a legacy application, a jump host, or a database client that bypasses the identity provider. Assessors look for the MFA enforcement setting on each access path and a list of the access paths in scope. Map every route into the CDE, then prove MFA applies to each one.

MFA system configuration (8.5.1)

Requirement 8.5.1 covers how MFA itself is configured so that it resists bypass. The requirement addresses protection against replay, the independence of factors, and preventing bypass by individual administrators unless properly authorized. Reviewing the MFA product configuration is often the step teams underestimate, because the feature can be enabled while exceptions or fallback methods weaken it. Evidence typically includes configuration screenshots or exports, documented exception approvals, and the admin list for MFA settings. Check fallback and exception settings, not just whether MFA is switched on.

Authenticated internal scanning (11.3.1.2)

Requirement 11.3.1.2 asks for internal vulnerability scans performed with authenticated credentials, so the scanner can see installed software and missing patches rather than only open ports. Unauthenticated scans miss a large share of host-level weaknesses, which is why assessors check the scan configuration. Organizations need a scanning account with appropriate read rights, credential storage that meets the organization's own standards, and scan reports that show successful logins. Confirm that scan results list the hosts that authenticated, since a scan that silently failed on login is a common finding. Review scan reports for failed credential checks before the assessor does.

Automated log review (10.4.1.1)

Requirement 10.4.1.1 asks for automated mechanisms to perform log reviews, rather than relying on staff to read logs by hand. A SIEM rule set, a log analytics platform, or a scripted review job can meet the intent, provided the organization defines what the automation looks for and how alerts are triaged. Assessors usually request the rule or query definitions, examples of generated alerts, and records showing that alerts were investigated. A tool that collects logs but nobody reviews is not enough. Keep the detection rules and the alert handling records together as one evidence set.

Anti-phishing mechanisms (5.4.1)

Requirement 5.4.1 expects mechanisms that detect and protect personnel against phishing attacks, in addition to anti-malware on systems. Typical controls include email filtering with link and attachment inspection, user reporting channels, and phishing simulations that measure response. The assessor will want to see how the controls are deployed to in-scope personnel, not only that a product exists. Ask your email or security vendor which of these capabilities it provides, and confirm the configuration is active for every mailbox that handles cardholder data. Show deployment coverage across in-scope users, not only a product license.

How superseded requirements are reported after the deadline

This table pairs each of the three requirements superseded on 31 March 2025 with its replacement and the reporting treatment assessors apply after that date. Read each row as a reporting instruction: the old requirement is no longer assessed, and the replacement carries the obligation. The main takeaway is that a ROC or SAQ should show the superseded requirement as Not Applicable, not as a gap.

Superseded requirement	Replacement	How it is reported after 31 March 2025
6.4.1 (public-facing web application protection)	6.4.2 (automated technical solution for public-facing web applications)	Mark 6.4.1 as Not Applicable in the ROC or SAQ, per FAQ 1593. Assess 6.4.2 in full.
8.3.10 (customer password requirement for service providers)	8.3.10.1 (customer password and authentication controls for service providers)	Mark 8.3.10 as Not Applicable in the ROC or SAQ, per FAQ 1593. Assess 8.3.10.1 in full.
10.7.1 (failure detection for critical security control systems, earlier wording)	10.7.2 (expanded failure detection for critical security controls)	Mark 10.7.1 as Not Applicable in the ROC or SAQ, per FAQ 1593. Assess 10.7.2 in full.
Any superseded requirement reported as a gap	The replacement requirement	Reporting the old number as Not in Place creates a finding that the replacement already covers. Confirm the treatment with your QSA before submission.
Evidence for the replacement	The replacement requirement	Keep evidence dated and mapped to the new requirement number, since assessors test the current wording only.

What the deadline means for SAQ merchants, ROC entities and service providers

E-commerce merchants that fully outsource payment pages to a provider through redirects or embedded iframes validate on SAQ A. Since 31 March 2025, the payment page controls that were previously absent from this path apply to the merchant's own page code and the pages it serves. The Council removed two of these items from SAQ A in January 2025 and added an eligibility criterion covering script attacks, so the merchant must confirm that its checkout pages cannot be altered by script injection before it can use SAQ A at all.

Payment page script management (6.4.3): Scripts on payment pages must be inventoried, authorized and have their integrity assured.
Payment page change and tamper detection (11.6.1): A mechanism must detect unauthorized changes to the HTTP headers and payment page content as received by the consumer's browser.
Script-attack eligibility criterion: Added in January 2025, this is a condition for using SAQ A, not just a control to report.
Quarterly ASV scanning (11.3.2): The Council highlighted this for SAQ A merchants as a change to adopt early, ahead of the effective date.
Not applicable marking: Superseded items are reported as Not Applicable, so the SAQ must reflect the current requirement set.

Confirm your eligibility with your acquirer and your payment provider, and ask the provider in writing which script and page controls it covers.

Can a customized approach replace a future-dated requirement?

Sometimes, but only as a documented validation decision, and only for entities with robust security and risk management. PCI DSS v4.x lets an entity meet a requirement through the defined approach, which follows the standard's stated method, or through the customized approach, which achieves the requirement's stated objective in a different way. A future-dated requirement that became effective on 31 March 2025 can be addressed this way, but the customized approach does not move that date. Once the requirement is in force, the entity must still show that the objective is met in every applicable assessment.

Treat this as a decision to make early, with your QSA or acquirer, not as a finding to negotiate at the end of an assessment. Your team needs to write down the objective the requirement is meant to achieve, the design that meets it, the risk analysis behind the choice, and the evidence an assessor can test, such as configuration exports, tool reports or review records. Confirm with your QSA or acquirer whether they accept the customized approach for the specific requirement and validation type you are reporting, because the Attestation of Compliance records how each requirement was met. Ask them what they will need to see before you build the design, so you do not discover a gap during fieldwork.

Customized approach is not the same as a compensating control. A compensating control is used when a requirement cannot be met as written because of a legitimate technical or business constraint, and it is documented as an alternative with its own assessment steps. A customized approach is designed from the objective up and is expected to be sustained through a documented targeted risk analysis and ongoing monitoring. Read the SSC's comparison of compensating controls and the customized approach before choosing a route, and confirm with your assessor which one fits each future-dated requirement in your environment.

How to check readiness before the next assessment

Readiness for PCI DSS v4.0.1 comes down to a handful of checks that assessors run every cycle. Each card below names one area the organization owns, what a partner can prepare, and the evidence to hold ready before the QSA or the SAQ process begins.

Confirm validation path and scope

Start by confirming which validation path applies, a ROC or an SAQ, and which future-dated requirements reach your environment. A service provider has extra requirements that a merchant does not, so the answer changes the checklist. Confirm the path with your acquirer or the payment brand before you collect evidence. A partner can map requirements to your environment, but the organization decides the validation method and owns the outcome.

Inventory 12.3.1 risk analyses

Requirement 12.3.1 made targeted risk analyses mandatory, and each one sets the frequency of an activity such as malware scans, system account reviews, POI inspections and log reviews of other systems. Keep one record per analysis that names the activity, the chosen frequency, the rationale and the approver. The organization owns the risk decisions. A partner can prepare the analysis template and check that the stated frequencies match what teams actually perform.

Verify MFA and password configuration

Requirements 8.3.6, 8.4.2 and 8.5.1 cover password length, multi-factor authentication for all CDE access and MFA system configuration. Assessors look for configuration exports and sampled login evidence, not policy statements alone. Export identity provider settings, confirm that no CDE access path bypasses MFA, and retain the output. A partner can script the configuration exports and test the sample paths, while the organization approves the settings.

Confirm scanning cadence

Requirement 11.3.1.2 requires authenticated internal scanning, and quarterly external scans by an ASV apply under Requirement 11.3.2 where they are required. Check the scan calendar against the last four quarters, confirm that failed scans were re-run, and keep credentialed scan configurations on file. The organization must schedule and act on scan results. A partner can build the calendar and reconcile scan reports against it, but ASV passing status comes from the ASV, not from the partner.

Check superseded requirements are marked correctly

Requirements 6.4.1, 8.3.10 and 10.7.1 were superseded by 6.4.2, 8.3.10.1 and 10.7.2 on 31 March 2025, and PCI SSC FAQ 1593 says the superseded items should be reported as Not Applicable. Check that the ROC or SAQ marks each superseded item correctly and that the replacement requirement carries the evidence. Mismatched markings are a common reason for assessor queries. The organization confirms the markings, and a partner can review the draft against the current templates.

Keep scope and data-flow diagrams current

Network and data-flow diagrams must match the live environment, and scope must be confirmed at least every 12 months under Requirement 12.5.2. Service providers also confirm scope every six months under Requirement 12.5.2.1 and review scope after organizational change under Requirement 12.5.3. Compare each diagram against recent configuration changes and cloud account inventories. The organization owns the scope decision, and a partner can prepare diagrams and a change-review checklist.

Who owns controls, who prepares evidence, and who validates

Your organization owns every PCI DSS control, including each future-dated requirement that now applies to your environment. No vendor or assessor can take that accountability over. Your team decides how each requirement is met, approves the risk analyses that set the frequency of periodic activities, and signs off on the policies and roles the standard expects. Your team also runs the recurring operational work that assessors sample throughout the year.

Control ownership: Name an accountable owner for each requirement that became effective on 31 March 2025, including 8.4.2 (MFA for all CDE access) and 10.4.1.1 (automated log review).
Risk analyses: Approve the targeted risk analyses under Requirement 12.3.1 that set how often activities such as malware scans and system account reviews must happen.
Policies and roles: Keep the policies, responsibility assignments and recurring task calendar current and approved by management.
Operational evidence: Perform and record the daily, weekly, quarterly and annual activities, such as authenticated internal scanning under 11.3.1.2.
Superseded requirements: Confirm that 6.4.1, 8.3.10 and 10.7.1 are reported as Not Applicable where they have been replaced.

Confirm that your internal owners can show dated evidence for each requirement before any external party looks at it.

Frequently asked questions about future-dated PCI DSS requirements

Does PCI DSS v4.0.1 add any new requirements?

No. PCI DSS v4.0.1, published on 11 June 2024, is a limited revision of v4.0 and added or deleted no requirements. The 64 new requirements introduced in v4.0 carry over, and 51 of them were future-dated, becoming effective on 31 March 2025. The revision kept that effective date unchanged. For planning, the work you did against v4.0 still counts, and the open question is whether each future-dated requirement is now implemented, operating and backed by evidence. Confirm with your acquirer or QSA which v4.0.1 template and validation path they expect before you start collecting evidence.

Can we still mark future-dated requirements as Not Applicable?

Not for the period after 31 March 2025. Before that date, future-dated requirements that were not yet implemented could be marked Not Applicable in a Report on Compliance or Self-Assessment Questionnaire. From 31 March 2025, they must be fully considered in every applicable assessment. A requirement that applies to your environment now needs an actual test result, not a placeholder. Requirements cannot be backdated, so any control still missing on that date is a gap to close and document. Review the PCI SSC guidance on reporting future-dated requirements and confirm with your validating entity how they want the gaps recorded.

Which future-dated requirements did the PCI SSC highlight for early adoption?

The PCI SSC highlighted two changes in its August 2024 guidance: Requirement 12.5.2, which requires an annual confirmation of PCI DSS scope, and Requirement 11.3.2, which requires quarterly external scanning by an Approved Scanning Vendor for SAQ A merchants. Requirement 12.3.1 also became mandatory on 31 March 2025 and sets the frequency of activities such as malware scans (5.3.2.1), system account reviews (7.2.5.1) and log reviews of other systems (10.4.2.1). Other requirements effective since that date include 12-character passwords (8.3.6), MFA for all access to the cardholder data environment (8.4.2) and automated log review (10.4.1.1). Start with scope confirmation and MFA, because they touch many other controls.

How do superseded requirements appear on the attestation?

Three requirements were superseded on 31 March 2025 and are reported as Not Applicable: 6.4.1, replaced by 6.4.2, 8.3.10, replaced by 8.3.10.1, and 10.7.1, replaced by 10.7.2. PCI SSC FAQ 1593 says they should be marked Not Applicable after that date in both Reports on Compliance and Self-Assessment Questionnaires. The Attestation of Compliance summarizes the outcome of the assessment, while the ROC or SAQ shows the requirement-by-requirement marking. Make sure the replacement requirements are tested in full, because the obligation moves to them. Ask your validating entity to confirm that their template and reviewer accept this marking.

Who decides which validation path applies to us?

The payment brands and your acquirer decide, not the PCI SSC. The PCI SSC maintains the standard but does not enforce compliance or impose penalties. The payment brands determine which entities must validate, how, and what enforcement programs apply. In practice, your acquirer usually confirms your merchant or service provider level and whether you file a Report on Compliance from a Qualified Security Assessor or a Self-Assessment Questionnaire. Ask for that decision in writing, including the template version, because it determines which future-dated requirements you must report and how. Your implementation partner can prepare evidence, but it cannot make that call.

How much effort does closing these gaps take, and what drives it?

No official effort figure exists for this, so the answer depends on your environment. The main drivers are how many future-dated requirements are not yet in place, the size of the cardholder data environment and its connected systems, how many accounts and access paths need MFA, and how many periodic activities your risk analyses under 12.3.1 set. One-time work includes implementing controls, writing policies and building the first set of evidence. Recurring work includes quarterly ASV scans, penetration testing, periodic reviews and annual scope confirmation. Ask any provider for a quote itemized by requirement, showing which costs are one-time and which recur. Your QSA is paid for the assessment, the ASV for scans, and an implementation partner for the work it scopes in writing.

Can DeployOpen issue the PCI DSS report for us?

No. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it can prepare systems, controls and evidence for a PCI DSS assessment. It does not issue Reports on Compliance, Attestations of Compliance or certificates. Only an independent Qualified Security Assessor issues a ROC, and your acquirer or the payment brand decides whether that route applies to you. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope. Your organization still owns its controls and the final attestation.

How DeployOpen works on this

DeployOpen prepares the self-hosted systems, controls and evidence your organization needs to show the future-dated PCI DSS v4.x requirements that became effective on 31 March 2025. Your organization owns its controls and validation, and an independent QSA or the applicable SAQ process issues the result.

How we scope

Confirm which future-dated requirements apply to your validation type, ROC or SAQ, before any build work starts.
Map which systems, accounts and periodic activities fall under requirements such as 8.4.2 and 11.3.1.2 in your environment.
Agree the scope, deliverables and timelines in writing, since engagements are fixed-scope.

How we build

Configure self-hosted open-source platforms for requirements such as 8.3.6 password length and 8.5.1 MFA system configuration.
Set up automated log review for 10.4.1.1 and risk-based frequencies tied to the 12.3.1 targeted risk analyses.
Test authenticated internal scanning under 11.3.1.2 and anti-phishing controls under 5.4.1 inside your own infrastructure.

How we hand over

Document each control, its owner and the evidence an assessor would request for the requirement.
Record superseded requirements 6.4.1, 8.3.10 and 10.7.1 as Not Applicable with the reasoning your assessor will review.
Deliver runbooks and evidence collection steps so your team can reproduce results for the next assessment cycle.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Re-check periodic evidence, such as scope confirmations under 12.5.2, on the cadence your validation requires.
Confirm with your QSA or acquirer which evidence they accept, since DeployOpen does not issue reports or attestations.

PCI DSS v4.0.1 future-dated requirements