PCI DSS 4.0 + Frontend Script Integrity: The 2026 Ecommerce Compliance Deadline Nobody's Ready For

PCI DSS 4.0 went mandatory on March 31, 2025. By 2026, nearly every ecommerce merchant has heard "we're 4.0 compliant" from their payment processor, their hosting provider, and their checkout vendor. Most of them are wrong — not about their vendors, but about themselves. PCI DSS 4.0 added two new requirements (6.4.3 and 11.6.1) that the merchant is responsible for, regardless of how much of payment processing is delegated to a vendor. Most ecommerce stores still don't have them in place, and most QSAs are starting to flag them in 2026 audits.

What Changed in 4.0

PCI DSS 3.2.1 (the previous standard) focused heavily on server-side controls: firewalls, encryption at rest, access logging, vulnerability management of backend systems. 4.0 added a new threat model: the browser. Specifically, two requirements address the reality that modern payment pages load 10–40 third-party JavaScript files, any one of which could be compromised to skim card data without the merchant knowing.

Requirement 6.4.3 — Script Authorization and Integrity

"All payment page scripts that are loaded and executed in the consumer's browser are managed... [with] a method implemented to confirm that each script is authorized... integrity is assured."

In practice, this means three things:

1. Inventory: you have a complete, dated list of every script that loads on every page that handles card data (including the page before checkout — even the cart page if it auto-redirects to a hosted checkout).
2. Authorization: each script in the inventory has been explicitly approved by someone with authority — not just "we use Klaviyo because marketing added it" but a documented decision that this script is needed on the payment page.
3. Integrity: there is a technical control in place that detects when a script changes. This is typically implemented as Subresource Integrity (SRI) hashes on the script tag, plus a monitoring service that alerts on any change to the script content delivered.

Requirement 11.6.1 — Change Detection

"A change- and tamper-detection mechanism is deployed... to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) of the HTTP headers and the contents of payment pages."

This requires monitoring the payment page's HTML and HTTP response headers for unauthorized changes. Frequency: at least every 7 days, or more often based on a documented risk assessment (in practice, real-time monitoring is expected for any store handling more than a few thousand transactions per month).

Who's Affected

If your checkout flow loads in your customer's browser — even if the credit card form is in a hosted iframe — you are affected. Specifically:

• SAQ A-EP merchants: stores using a hosted iframe (Stripe Checkout, Adyen, etc.) but where the merchant's own page wraps the iframe. Most Shopify, WooCommerce, BigCommerce, and Magento stores fall here.
• SAQ A merchants: stores that fully redirect to a hosted checkout (no iframe). These were previously exempt from most browser-related requirements. Under 4.0, even SAQ A merchants now have requirements 6.4.3 and 11.6.1 for the page that initiates the redirect — meaning your cart and product pages, if they're the launching point for checkout.
• SAQ D merchants: stores handling card data directly on their own backend. Same requirements plus everything else in PCI DSS.

The QSA community has been consistent in 2025–2026 audits: even SAQ A merchants need a script inventory, an SRI implementation plan, and a change-detection mechanism for their cart and checkout-initiating pages.

The Practical Implementation

Step 1: Script Inventory

Audit every script that loads on your cart, checkout, and order confirmation pages. Tools that help:

• Browser DevTools → Network → JS filter → reload page → export HAR.
• Securiti, OneTrust, Source Defense, Jscrambler: commercial products that do script discovery automatically.
• StoreVitals scan: identifies all third-party JavaScript loaded on payment-adjacent pages.
• Manual audit: view-source on the page, search for every <script> tag, document each domain and the team that owns it.

The deliverable is a spreadsheet: script URL, script domain, owner (team/person), purpose (analytics, marketing, payment, accessibility, etc.), date added, business justification, risk rating (low/medium/high). This document needs to be reviewed at least annually.

Step 2: Script Authorization Workflow

Establish a process for approving new scripts. Most companies use a simple Jira/Linear/Asana workflow:

1. Anyone wanting to add a new script (marketing wants Klaviyo's newest pixel, analytics wants a new heatmap tool) files a ticket with the script URL, source, and business purpose.
2. Engineering reviews the script source (or a known-safe vendor reputation) and decides if SRI hashing is possible.
3. Security/compliance reviews the privacy implications.
4. Once approved, the script is added with an SRI hash and the inventory is updated.

Critical point: this workflow needs to apply to payment-adjacent pages specifically. It's fine to have looser controls on blog pages or product pages that don't precede checkout.

Step 3: SRI Implementation

Subresource Integrity is the W3C standard for verifying script integrity. The script tag looks like:

<script
  src="https://cdn.example.com/script.js"
  integrity="sha384-Hashvaluehere"
  crossorigin="anonymous">
</script>

The browser computes the hash of the downloaded script and refuses to execute it if the hash doesn't match. This protects against CDN compromise — if an attacker swaps the script for a card skimmer, the hash changes and the browser blocks it.

The challenge for ecommerce: many third-party vendors don't publish stable SRI hashes because they push frequent updates to their scripts (Klaviyo, Optimizely, dynamic GTM containers). For these, SRI is impractical. The alternative is:

1. Self-host the script (proxy the third-party script through your own CDN). You control versioning and can apply SRI.
2. Use a script integrity monitoring service (Source Defense, Jscrambler, Akamai Page Integrity Manager) that hooks into the page and validates script behavior at runtime.
3. For low-risk scripts (analytics that don't have payment page access), document the residual risk and use Content Security Policy (CSP) restrictions to limit what the script can do.

Step 4: Change Detection Monitoring

For requirement 11.6.1, you need a system that monitors the rendered HTML and response headers of your payment pages for unauthorized changes. Options:

• Commercial: Source Defense, Jscrambler PCI Compliance, Akamai PIM, Imperva Client-Side Protection. Generally $500–5,000/month depending on traffic.
• Open-source / self-built: Cron job that fetches the page, computes a hash of the stripped HTML + relevant headers, compares to the previous hash, alerts on diff. Cheap but requires ownership.
• Bundled with WAF: Cloudflare, Akamai, and AWS all offer page integrity monitoring as part of their enterprise WAF tiers.

The monitoring needs to cover both the HTML content (specifically the script tags and form elements) and the HTTP response headers (CSP, X-Frame-Options, etc.). Alert thresholds should be configured to ignore expected changes (CSRF tokens, cart counts) and flag unexpected changes.

Step 5: Documentation and Annual Review

QSAs auditing PCI DSS 4.0 in 2026 want to see:

• Current script inventory document with dates and owners.
• Authorization workflow documentation with examples of recent approvals/denials.
• SRI implementation status report (which scripts have SRI, which don't, why not, mitigating controls).
• Change detection monitoring configuration and incident logs.
• Annual review meeting minutes confirming all scripts are still authorized.

The Top 5 Mistakes Stores Make

1. Assuming the Payment Vendor Covers This

Stripe, Adyen, Braintree, and other vendors handle the iframe's PCI compliance. They do not cover scripts that load on the page surrounding the iframe — that's the merchant's responsibility. Klaviyo, GTM, Hotjar, and dozens of other scripts on your checkout page are not the vendor's problem.

2. Treating Cart and Product Pages as Out of Scope

If a customer can initiate checkout from the cart page (or even from a "Buy Now" button on a product page), that page is now in scope for 11.6.1. Most stores discover this in their first 4.0 audit and have to retroactively add monitoring.

3. Skipping SRI for Vendor Scripts

"Klaviyo doesn't publish SRI hashes, so we can't do SRI" — true, but the requirement doesn't say SRI specifically. It says "integrity is assured." If you can't use SRI, you need an alternative control (script monitoring service, self-hosted proxy, CSP restrictions). Doing nothing is not compliant.

4. Ignoring HTTP Header Changes

11.6.1 covers headers too. If your CSP changes from "script-src 'self' cdn.example.com" to "script-src *" because a developer was debugging, your monitoring should catch it. Many stores monitor HTML but not headers.

5. No Documentation

The QSA doesn't care if you have monitoring in place if you can't show them documentation of the policy, the technical implementation, the alert thresholds, and the response procedures. "We have a script monitoring service" is not sufficient evidence.

What StoreVitals Can Do Here

StoreVitals isn't a PCI compliance product — we don't replace Source Defense or a QSA. What we do is identify the foundational issues that block PCI DSS 4.0 compliance:

• Complete inventory of every third-party script loading on your checkout-adjacent pages.
• Identification of scripts that lack SRI hashes (so you know your starting position).
• CSP header analysis — is your Content Security Policy actually restrictive, or is it set to "default-src *" because someone gave up?
• Change detection for the foundational HTTP security headers (CSP, X-Frame-Options, HSTS, etc.).
• Crawler-style scan of the cart and checkout pages from an outside-in view, matching what an attacker would see.

The Deadline Reality

The March 31, 2025 deadline has passed. QSAs are auditing against the new requirements in 2026. Most stores audited in 2025 were given remediation timelines (typical: 90–180 days for 6.4.3, 60–120 days for 11.6.1). Stores being audited in 2026 are expected to be fully compliant on day one. Failed audits result in:

• Increased per-transaction fees from the acquiring bank (often 0.05–0.20% on top of standard processing).
• Restricted ability to add new payment methods.
• In severe cases, loss of card-acceptance privileges entirely.
• If a breach occurs and non-compliance is discovered post-incident, fines from card brands ranging from $5,000 to $100,000+ per month until remediation.

Run a StoreVitals scan on your checkout-adjacent pages. We'll surface the script inventory, SRI gaps, and CSP weaknesses that are the foundational starting point for a PCI DSS 4.0 compliance roadmap. The scan takes 60 seconds; the compliance roadmap takes 3–6 months, and the deadline already passed.