PCI DSS 4.0 for mid-market merchants: what actually changed in 2026 and what the payments stack must do about it.

PCI DSS v4.0 was published in March 2022. v3.2.1 was retired March 31, 2024. v4.0.1 landed June 11, 2024 as a clarifying revision. The material inflection was March 31, 2025, when 51 previously best-practice future-dated requirements became mandatory and testable during any assessment. Sixteen months in, mid-market merchants — retail chains at Level 2 and Level 3, restaurant groups, healthcare providers taking card copays, ecommerce operators, SaaS with card-on-file, B2B services — are systematically behind on three of the five clusters that actually matter.

PCI DSS 4.0.1 is the mid-market merchant's new baseline, and the March 31, 2025 future-dated requirements are where mid-market operators are behind.

The v4.0 → v4.0.1 revision confused a number of mid-market compliance leads into thinking a fresh transition window had opened. It did not. v4.0.1 is a clarification release — same requirement numbers, same mandatory dates, sharper applicability notes. What actually happened on March 31, 2025 is that 51 requirements previously flagged as “best practice until March 31, 2025” became testable during any PCI DSS assessment. Any Report on Compliance or Self-Assessment Questionnaire attested to on or after that date must demonstrate compliance with the full v4.x requirement set. Enterprise Level 1 merchants working with QSAs like A-LIGN, Coalfire, Kirkpatrick Price, or Schellman generally cleared the deadline. The pattern at Levels 2 and 3 — merchants attesting via SAQ rather than a full RoC — is that the self-assessment was reused from the prior year with the new requirements not substantively re-scoped. That gap is what the 2026 audit cycle is now surfacing.

The client-side script requirement (Req 6.4.3 and 11.6.1) is the sleeper mandate that most SAQ-A merchants missed.

Requirement 6.4.3 requires the merchant to inventory and authorize every script that loads on any page that accepts payment card data. Requirement 11.6.1 requires a change-and-tamper detection mechanism on the payment page and HTTP headers received by the browser, with alerts on unauthorized modification. Together they close the browser-supply-chain attack surface exposed by Magecart-style incidents. The mid-market misread is architectural. Merchants using Stripe Checkout, Adyen Hosted Payment Pages, Braintree Drop-in, Worldpay's HPP, or Fiserv/CardConnect's Hosted iFrame Tokenizer assumed the iframe boundary pushed 6.4.3 and 11.6.1 onto the processor. It does not. The iframe is sandboxed, but the merchant's own page — which frames the iframe — is not. Google Tag Manager, Segment, Heap, FullStory, Hotjar, Intercom, Drift, Zendesk widgets, Optimizely, Sentry, and any marketing pixel loaded on the checkout page execute in the same top-level browser context and are therefore in scope. The client-side script monitoring category — Jscrambler, Feroot, Reflectiz, HUMAN (formerly PerimeterX), DataDome, and Akamai's Page Integrity Manager — exists specifically to satisfy 6.4.3 and 11.6.1 with a script inventory, authorization workflow, and integrity monitoring. It did not meaningfully exist as a procurement category before v4.0.

Multi-factor authentication now applies to all access into the CDE, not just administrative access.

Under v3.2.1, MFA was required for administrators accessing the CDE and for remote access originating outside the network. Under v4.0's Requirement 8.4.2, MFA is required for all access — every user, every session, administrative or not — into the CDE, and under Requirement 8.5.1 the MFA implementation itself must be resistant to replay attacks and cannot permit bypass without documented exception. For a mid-market restaurant group running Toast or Aloha (NCR Voyix), or a retail chain running Lightspeed, Clover, or Shopify POS, this expansion touches every back-office user who reviews settlement reports, every finance analyst who touches the reconciliation portal, every developer with production access, and every third-party support technician. The architectural implication is that identity providers — Okta, Microsoft Entra ID, Duo, JumpCloud — become in-scope PCI systems, and the shared authentication surface between the CDE and the rest of the corporate estate must be documented in the network diagram the QSA will ask for.

The targeted risk analysis (Req 12.3.1) shifts responsibility for control frequency to the merchant — with documentation to prove it.

The most philosophically significant change in v4.0 is the introduction of the customized approach and, alongside it, the targeted risk analysis. Where v3.2.1 prescribed “quarterly,” “annually,” or “every 90 days” for many recurring controls, v4.0 allows the merchant to define a defensible frequency based on a documented TRA. In practice this means every merchant with a variable control frequency now owns a set of TRA artifacts — one per applicable requirement — that must be reviewed at least annually and made available on assessment. Mid-market compliance functions treated this as a paperwork nuisance and generic-templated the TRAs. QSA feedback in the 2025-2026 assessment cycle has been consistent that generic templates are being challenged. TRAs must reference the merchant's actual environment, threat landscape, and control effectiveness data, or the flexibility they were designed to grant collapses back into the prescriptive default.

Payment service providers and gateways carry more of the compliance burden — but the merchant still owns the SAQ.

Every major processor — Stripe, Adyen, Braintree (PayPal), Worldpay (FIS/GTCR), Fiserv (Clover, CardConnect), Global Payments (TSYS), Elavon, Square — updated its shared-responsibility documentation between mid-2024 and Q1 2025. Tokenization and vault vendors — Basis Theory, TokenEx, Very Good Security, Spreedly, Skyflow — did the same. The documentation is materially better than under v3.2.1. Most responsibility matrices now enumerate v4.0 requirements line by line and specify what the provider attests to, what the merchant retains, and what is shared. But the SAQ is still the merchant's attestation. Requirement 12.8.5 (managing service providers) and Requirement 12.9 (the provider's own attestation to the merchant) mean the merchant must collect, review, and preserve each provider's Attestation of Compliance and confirm the mapping to their own scope. The 2026 procurement implication is that any renewal conversation with a gateway, POS, or tokenization vendor should request the updated v4.0.1 responsibility matrix in writing before signature — and the matrix should be reviewed by whoever is signing the merchant's SAQ.

Run the SAQ selection re-check before renewing your gateway or POS contract.

Because SAQ eligibility narrowed in the January 2025 SAQ A revision, the SAQ selection itself is the highest-leverage control decision a mid-market merchant will make this year. The seven-question re-check below is designed to surface the misclassification before the QSA does.

What breaks: SAQ over-scoping, script inventory blindness, gateway assumptions.

SAQ over-scoping (or, more commonly, under-scoping). A merchant asserts SAQ A because “we use Stripe Checkout” but has custom JavaScript, a card-form autocomplete helper, or a validation script on the payment page. Under the January 2025 SAQ A revision, that merchant is not eligible for SAQ A and drops into SAQ A-EP — with a materially larger requirement set including full 6.4.3 and 11.6.1 obligation. The remediation is either removing the custom JS (and the analytics that live on the page) or accepting the broader SAQ.

Script inventory blindness. Marketing adds a new pixel through the tag manager. The tag manager is authorized. The pixel is not individually inventoried. It runs same-origin with the payment page. Requirement 11.6.1 fails silently because no one is looking, and the failure only surfaces during an assessment — or, worse, an incident. The structural fix is treating the payment page as change-controlled infrastructure, not a marketing surface, and gating tag manager changes to that page through a security review.

Gateway assumptions. The merchant reads “PCI Level 1 Service Provider” on the gateway's website and assumes the compliance obligation transferred. It did not. The shared-responsibility matrix — every major processor now publishes one — explicitly reserves for the merchant everything that runs in the customer's browser under the merchant's origin, plus the merchant's own SAQ signature. In the 2026 procurement cycle, this assumption is what a QSA will find first.

What this means for procurement in 2026.

The 2026 mid-market procurement implication is narrow and executable. First, treat the January 2025 SAQ A narrowing and the March 31, 2025 mandatory date as a single event, and re-scope any SAQ signed against them. Second, add the shared-responsibility matrix (in v4.0.1 form) to the standard RFP and renewal checklist for every gateway, PSP, tokenization vendor, and POS. Third, budget for a client-side script monitoring line item — this is a new category, and finance will not recognize it. Fourth, staff the TRA discipline: whoever owns compliance needs enough environmental knowledge to write defensible risk analyses, or the customized-approach flexibility is not usable. Fifth, revisit the QSA relationship if the 2025 attestation was not substantively reworked against the future-dated requirements. The 2026 audit cycle will not be forgiving of a rolled-over SAQ.

This is the second piece in the Financial Services Analyst Note series. The anchor is How mid-market financial services operators should source technology contracts in 2026. Every vendor named here is in The Cardinal Source's active supplier pool.

Sources

• PCI Security Standards Council, Document Library. pcisecuritystandards.org
• PCI SSC blog, “Just Published: PCI DSS v4.0.1.” blog.pcisecuritystandards.org
• PCI SSC, “PCI DSS v4.0 Resource Hub” (Prioritized Approach, quick reference guides, summary of changes). blog.pcisecuritystandards.org
• PCI SSC blog, “Now is the Time to Adopt the Future-Dated Requirements of PCI DSS v4.x.” blog.pcisecuritystandards.org
• Visa, Merchant PCI DSS compliance and merchant levels. usa.visa.com
• Mastercard, Site Data Protection / merchant levels. mastercard.us

All linked sources were live at time of publish (July 2026). Verify before quoting in a procurement document.