PCI DSS 4.0.2: What Merchants Are Still Missing With the 2026 Deadlines Looming

PCI DSS 4.0 was finalized in early 2022; the 4.0.1 update landed in 2024; and 4.0.2 — the current operative version for most merchants — carries a set of future-dated requirements that move from "best practice" to "required" across 2026. For most Level 1 and Level 2 merchants, the substantive readiness work has been underway for a while. For Level 3 and Level 4 merchants, many of whom rely heavily on processor and gateway compensating controls, the 2026 deadlines are surfacing gaps that hadn't been visible during prior assessment cycles.

This is the operator-level view of where merchants actually fall short — and what good readiness looks like.

1. Client-side script management (Requirement 6.4.3 and 11.6.1)

The single most common gap in 2026 readiness assessments is client-side script management on payment pages. The requirement: maintain an inventory of scripts running on payment pages, justify their inclusion, and detect unauthorized changes to script content or to the integrity of the page itself.

The gap most merchants hit isn't that they don't understand the requirement — it's that legitimate third-party scripts (analytics, tag management, A/B testing, customer-experience tools) accumulate over time across multiple teams, and no one has end-to-end visibility into what's running on the checkout page or who owns which script. Building that inventory and the change- detection layer on top of it is a meaningful project.

Common solutions: a dedicated script-monitoring tool, CSP headers configured to enumerate allowed sources with SRI-based integrity checking, or removing third-party scripts from payment pages entirely (the cleanest answer for merchants who can architecturally afford it).

2. Customized approach rationales

4.0.2 formalizes the "customized approach" — the path that lets merchants meet a requirement's objective through a control different from the prescribed one, provided the rationale is documented, the risk analysis is complete, and the assessor agrees. The path exists for a reason, and many merchants legitimately need it. But the documentation burden is high, and merchants often discover mid-assessment that the rationale they've been relying on doesn't hold up under scrutiny.

The right approach: identify the customized-approach candidates well before the assessment, build the targeted risk-analysis documentation, and confirm sufficiency with the QSA before the assessment window opens. Discovering the gap during the assessment is a much more expensive path to the same answer.

3. Multi-factor authentication scope

MFA requirements expanded meaningfully in 4.0.2 — both in the populations covered (now reaching essentially all non-console access into the cardholder data environment) and in the specifics of what counts as a valid MFA factor. The gaps tend to cluster in a few places:

• Service accounts and break-glass paths that historically have been MFA-exempt and now aren't — without a clean operational story for how to authenticate them.
• Vendor-supplied toolingthat doesn't natively support the MFA mechanism the merchant uses everywhere else, leaving inconsistent islands.
• Legacy applicationsin the CDE that can't be retrofitted with modern MFA without significant work.

4. Authenticated vulnerability scanning

4.0.2 tightens the requirements around internal vulnerability scanning, including authenticated scans on a defined cadence. Many merchants' existing scan programs run as unauthenticated scans against the network surface — which catches a different (and narrower) set of issues than authenticated scans that can enumerate installed software, patch levels, and configuration drift inside hosts.

Standing up the authenticated scan program means agent deployment or credentialed-scan service accounts across the in-scope infrastructure, plus the operational backlog of resolving the much-longer findings list authenticated scans typically produce.

5. Targeted risk analysis

Several 4.0.2 requirements explicitly call for targeted risk analysis — documented analyses that justify the merchant's chosen frequency, scope, or implementation for specific controls. The intent is to move PCI from a purely prescriptive standard toward a risk-aware one. The operational reality is that documentation overhead has increased, and many merchants discover during their first 4.0.2-era assessment that they don't have the targeted risk analyses they need.

6. Where small-and-mid merchants are caught

Level 3 and Level 4 merchants relying on SAQ-A or SAQ-A-EP scope reduction — historically the "easy" PCI path for e-commerce merchants who fully outsource the cardholder data environment — discover in 2026 that the client-side script requirements apply to them too. The SAQ scope reduces what the merchant has to attest to about their environment, but it doesn't reduce the merchant's exposure on payment-page scripts. This is where most under-prepared merchants get caught.

7. The readiness checklist

• Build the payment-page script inventory. Either through a dedicated tool or a CSP-and-SRI implementation. Make sure ownership is assigned.
• Identify customized-approach candidates early and build the rationale documentation before the assessment window.
• Audit MFA coverage across service accounts, vendor tools, and legacy apps. Resolve the islands.
• Stand up authenticated vulnerability scanning on the in-scope infrastructure, and budget for the longer findings backlog.
• Build targeted risk analysesfor the requirements that call for them. Don't discover the gap during the assessment.
• Validate SAQ scopeif you're relying on scope-reduction paths. The script requirements still apply.

How Superior Payments helps

Superior's gateway eliminates the client-side script exposure for merchants on our hosted payment surfaces — the merchant's checkout page can be PCI-out-of-scope for the cardholder data environment entirely. For merchants on alternative integrations who need to keep the existing checkout, our compliance team can run the 4.0.2 readiness audit and surface the gaps that need addressing before the next assessment.