Merchant Services
September 7, 2026
Before March 31, 2026: PCI DSS 4.0 Fixes Security Teams Need
Practitioner focused breakdown of PCI DSS 4.0 changes with a prioritized remediation checklist to meet March 31, 2025 and CARDZ3N tips.
PCI DSS 4.0 replaces the one-size-fits-all checklist with a risk-based, customized approach, backed by new requirements for multi-factor authentication, password standards, and continuous scope confirmation, several of which carry future dates rather than immediate enforcement. The 4.0.1 update, released in June 2024, clarifies wording and applicability. It adds no new requirements and changes no deadlines.
The headline shift in PCI DSS 4.0 is structural: merchants can now choose the Customized Approach, validating a control by its security outcome rather than following the prescribed method line by line, provided they run a formal, documented risk assessment. That flexibility comes bundled with harder technical baselines everywhere else.
Priority items security teams are tracking right now:
A merchant running an unmanaged third-party checkout script, for instance, can lose SAQ A eligibility purely on that scope issue, independent of anything else in their environment.
Requirement 3 (Protect Stored Account Data) tightens how sensitive authentication data and primary account numbers get handled at rest. PCI DSS 4.0 requires keyed cryptographic hashes (HMAC, not a bare hash) when PAN is rendered unreadable through hashing, and it sharpens disk-level encryption expectations. Teams storing SAD outside of authorization flows need to document why, because the standard assumes that data should not persist at all.
Requirement 4 (Protect Cardholder Data With Strong Cryptography During Transmission) now expects a maintained inventory of trusted keys and certificates used for transmission security, plus validation that those certificates have not expired or lapsed into weak configurations. This is a documentation gap for most organizations, not a technology gap: the certificates already exist, but nobody owns the list.
Requirement 8 (Identify Users and Authenticate Access) carries the standard’s most operationally disruptive change: MFA is required for all access into the CDE, including internal non-console access, not just remote connections as under PCI DSS 3.2.1. Password minimums move to 12 characters, and the standard’s terminology shifts from “password” to “passwords/passphrases” to reflect longer, more usable credential design.
Requirement 11 (Test Security of Systems and Networks Regularly) affects e-commerce merchants directly. SAQ A merchants now face expectations for quarterly ASV scans tied to their internet-facing environment, and merchants using a third-party service provider for that scanning must be able to show the scans actually happened on their behalf.
Requirement 12 (Support Information Security With Organizational Policies) introduces 12.5.2, a formal scope confirmation performed at least annually and after significant changes. It also demands documented staff roles for security responsibilities and clearer information sharing with third-party service providers (TPSPs) about which controls each party owns.
PCI DSS v3.2.1 retired on 31 March 2022 when v4.0 was published, but the council built in an overlapping adoption window. A large share of the new requirements in the Summary of Changes were future-dated, meaning best practice only until they became mandatory on March 31, 2025.
Items that were effective from day one of v4.0 adoption:
Items that stayed best practice only until March 2025:
If your assessor engagement is scheduled anywhere near that March 2025 date, book the assessment window now rather than treating it as a soft deadline.
SAQ eligibility is where the abstract requirement changes turn into real operational pain. E-commerce merchants who thought they qualified for the simplest self-assessment questionnaire are discovering that unmanaged payment scripts, iframes, and third-party checkout widgets can knock them into SAQ A-EP or a full Report on Compliance (ROC), because those integrations touch cardholder data flows the merchant does not directly control.
SAQ A merchants are now expected to run ASV scans on a quarterly cadence, and if a TPSP performs that scanning, the merchant needs evidence the scans actually ran and covered the right assets. That evidence gap causes more assessment delays than any technical control failure does.
TPSPs, meanwhile, carry a documentation burden they did not have before. They must clearly state which PCI DSS requirements they manage on the merchant’s behalf and which stay the merchant’s responsibility. Disputes over scope and shared controls remain one of the most common friction points during assessments, and a signed responsibility matrix resolves most of them before the assessor asks.
Work through this in order, not all at once. Each step depends on the one before it.
Pro Tip: Centralize third-party payment scripts through a vetted gateway or hosted checkout method before your next assessment. Unmanaged client-side scripts are the single most common reason SAQ A merchants get bumped into a more demanding validation tier.
PCI DSS v4.0.1, published in June 2024, is a limited revision. It adds no new requirements and removes none. Treat it as clarifying documentation, not a new compliance obligation.
Notable fixes include applicability language for Requirement 3, a clarification that certain MFA applicability notes don’t apply to accounts authenticated with phishing-resistant factors, and restored language confirming that critical vulnerabilities still require patching within 30 days. The council also removed some sample templates that had caused confusion. Updated ROC and SAQ templates reflecting these fixes are available through the PCI SSC Document Library. No effective dates moved.
Coordinating gateway integrations and managing TPSP handoffs shows the same pattern repeatedly: scope creep is the real threat, not the requirements themselves. Merchants underestimate how a single unmanaged checkout script or an undocumented TPSP relationship can pull them into a heavier validation tier. Compliance, security, and payments teams need to talk before the assessor shows up, not after.
— Joshua Benedetti
Meeting these requirements gets considerably easier when your payment stack is built to minimize CDE scope from the start. CARDZ3N configures gateway integrations, coordinates TPSP documentation, and handles chargeback defense through ChargebackZ3N, work that overlaps directly with what PCI DSS 4.0 now asks you to prove. Instead of chasing scan evidence and responsibility matrices from multiple vendors, merchants working with CARDZ3N get integrations and coordination handled as part of the account relationship, not as a separate compliance project. If you’re evaluating your payment setup ahead of the 2025 enforcement milestones, review CARDZ3N’s high-risk merchant account and payment processing services to see how a managed gateway relationship can cut your scope confirmation workload before your next assessment.
Primary sources should anchor every remediation decision your team makes, not blog summaries of blog summaries.
For platform-level hardening examples relevant to targeted risk analyses, the security plugin guidance for BigCommerce merchants is a useful reference on vulnerability management practices.
PCI DSS 4.0 adds the Customized Approach for outcome-based validation, requires MFA for all CDE access, raises password minimums to 12 characters, and mandates annual scope confirmation under Requirement 12.5.2.
No. PCI DSS v4.0.1 is a limited revision that corrects wording and clarifies applicability; it adds no requirements and changes no effective dates.
Future-dated requirements, including MFA for all CDE access and 12.5.2 scope confirmation, became mandatory on March 31, 2025.
SAQ A merchants are expected to complete ASV scans at least quarterly, with evidence available if a TPSP performs the scan on their behalf.
Centralizing gateway integrations and hosted checkout methods through a managed processor like CARDZ3N can reduce how much of your environment falls inside the CDE, which lowers the documentation and testing burden under v4.0.
Start protecting your revenue from chargebacks today — schedule your complimentary consultation with CARDZ3N’s dispute management specialists.