PCI DSS 4.0 — Year One: What Operators Got Wrong

On March 31, 2025, fifty-one requirements that had been listed as “best practice” under PCI DSS v4.0 became mandatory. No grace period. No transitional assessment mode. If you filed a Report on Compliance after that date — or validated via SAQ — those requirements were live.

PCI DSS v4.0.1, published in June 2024, was a minor editorial revision (zero new requirements, zero deletions — typographical corrections and intent clarifications only). The effective date did not change. The version that matters operationally is still v4.0/4.0.1, and the 51 requirements that accumulated during the two-year transition period all hit the same cliff edge.

First post-enforcement assessment cycles are now wrapping up, and the pattern of findings is clearer than it was when those requirements were published. This is what operators actually got wrong — not the theoretical compliance gaps, but the ones appearing in real assessments.

Failure 1: Script inventory (Requirements 6.4.3 and 11.6.1)

These two requirements are the most significant new obligations introduced in v4.0 for e-commerce and payment page operators, and they are generating the most findings.

Requirement 6.4.3 mandates that every script loaded or executed on a payment page must be:

• Inventoried, with documented justification for its presence
• Integrity-protected (via Sub-Resource Integrity hash or an equivalent method)
• Authorized — the entity must confirm that each script is needed and that its use is justified

The intent is direct: Magecart-style skimming attacks — which inject malicious JavaScript into checkout pages to harvest card numbers in the browser before they reach the PSP — have been the dominant card-data theft vector since 2022. The AI fraud detection layer catches these attacks after exfiltration; PCI DSS 6.4.3 and 11.6.1 are the prevention layer, required before any transaction fires. The PCI Council is requiring operators to know what JavaScript runs on payment pages and to detect unauthorized changes. Magecart attacks surged 103% in a six-month window in 2024–2025 (Recorded Future threat intelligence), and a network of skimmers operating since 2022 was still harvesting data from checkout pages across thousands of e-commerce sites as of January 2026 (Silent Push research).

Requirement 11.6.1 requires active monitoring of payment page HTTP security headers and scripts for unauthorized modification — at a minimum weekly, or at the frequency determined by a Targeted Risk Analysis.

Where operators failed:

The inventory obligation catches most operators off-guard because modern payment pages accumulate JavaScript silently. A typical Stripe-hosted checkout page running a site built with a common e-commerce platform will load: the PSP JavaScript SDK, a tag manager (Google Tag Manager, Segment, or Tealium), analytics (GA4 or Mixpanel), a live chat widget (Intercom, Drift, Zendesk), an A/B testing framework, a cookie consent script, and possibly affiliate tracking pixels. Each of these is a script on the payment page that must be inventoried and integrity-protected under 6.4.3.

Sub-Resource Integrity (SRI) hashes work well for static scripts — add integrity="sha256-..." to the <script> tag and the browser refuses to execute a modified version. They break down for dynamic scripts that are updated frequently by the vendor (Google Tag Manager’s gtm.js, for example, cannot be pinned to a specific hash without breaking when the vendor updates it). Operators either need to implement SRI where feasible and document compensating controls where it isn’t, or use a dedicated content security policy with real-time monitoring to satisfy the intent of the requirement.

The most common gap: operators knew about 6.4.3 but treated it as a one-time exercise. 11.6.1’s ongoing monitoring requirement — detecting changes to HTTP response headers like Content-Security-Policy, X-Frame-Options, and the script inventory itself — requires a continuous control, not a point-in-time audit.

Failure 2: MFA scope (Requirements 8.4.2 and 8.5.1)

Under PCI DSS v3.2.1, MFA was required for remote access into the cardholder data environment (CDE) and for administrator access. That phrasing created a widely-exploited loophole: internal non-admin users accessing CDE systems from the corporate network were outside the MFA requirement.

Requirement 8.4.2 closes this. MFA is now required for all access into the CDE — any role, any user, regardless of whether the access originates from inside or outside the network perimeter. The boundary is the CDE itself, not the corporate network edge.

Requirement 8.5.1 adds configuration requirements for those MFA systems: protection against replay attacks, prevention of bypass, all factors must succeed before access is granted, and MFA cannot be disabled for any individual user (including administrators).

Where operators failed:

The “inside the network doesn’t count” assumption was widespread. Operators who had deployed MFA for VPN access and admin consoles considered themselves compliant. Post-enforcement assessments found them missing MFA for:

• Database administrators accessing payment databases from internal workstations
• Support staff accessing customer record systems in the CDE
• Automated application service accounts that use interactive login flows
• CI/CD pipeline runners deploying to CDE systems

The 8.5.1 configuration requirements also caught MFA implementations that technically met the letter of prior requirements but had administrative bypass mechanisms (break-glass accounts without MFA, or “remember this device” settings that could suppress the second factor indefinitely).

Failure 3: Targeted Risk Analysis documentation (Requirement 12.3.1)

PCI DSS v4.0 introduced “flexible” requirements — controls where the standard allows an entity to define its own performance frequency based on a documented risk assessment rather than prescribing a specific interval. Requirement 12.3.1 governs how those flexible requirements work: for each one, the entity must perform a Targeted Risk Analysis (TRA) that identifies the assets being protected, the threat types, the likelihood and impact of threats, and how frequently the control needs to run.

This was designed to give large, sophisticated entities flexibility to calibrate controls to actual risk exposure rather than comply with one-size-fits-all annual minimums.

Where operators failed:

The TRA was treated as a checkbox rather than a risk analysis. Operators submitted TRA documentation that named the requirement, described the control, and stated a frequency — without demonstrating the actual threat modeling that justified that frequency. QSAs reviewing these documents found them formulaic: the same boilerplate risk language used across every flexible requirement, with no entity-specific threat assessment.

A TRA for Requirement 11.6.1 script monitoring that states “weekly, because that is the minimum required frequency” does not satisfy 12.3.1. The TRA must demonstrate why weekly is appropriate for that entity’s specific risk profile — what attack vectors exist, what the detection window needs to be, what compensating controls reduce residual risk. Operators who copied published TRA templates without tailoring them to their environment found those TRAs rejected during assessment.

The practical implication: if you used the TRA to justify less-frequent controls (shifting from weekly to monthly for script monitoring, for example), you need a defensible risk argument, not just a policy document asserting the lower frequency.

Failure 4: SAQ-A scope (Requirement 6.4.3, SAQ-A update)

SAQ-A is the lightest self-assessment questionnaire — historically available to merchants that fully outsource card data handling to a third-party PCI DSS-compliant provider, redirecting customers off their site for payment or using a hosted payment form in an iframe. The logic: if no card data ever touches the merchant’s systems, the merchant is out of scope.

PCI DSS v4.0 updated SAQ-A eligibility in a way that affected this assumption. Merchants using embedded payment iframes on pages they serve must now either implement protections against client-side script attacks on those pages, or obtain written confirmation from their payment provider that the provider’s embedded payment form includes such protections and that the merchant’s page configuration meets those requirements.

Where operators failed:

E-commerce operators — particularly smaller merchants on hosted platforms — assumed that using Stripe Elements, Braintree’s hosted fields, or a similar embedded iframe product automatically kept them fully out of scope for script-related requirements. The updated SAQ-A made clear that the merchant’s own page — which serves the iframe and may load its own JavaScript — is still in scope for requirements related to protecting the payment page.

Operators using tag managers, chat widgets, and analytics scripts on the same page as an embedded payment iframe need to address 6.4.3 for those scripts even if the card data is captured within the iframe and never touches the merchant’s DOM. The rationale: a malicious script on the page hosting the iframe can potentially intercept keystrokes, manipulate the page, or exfiltrate data through browser APIs even if it cannot read within the iframe’s sandbox.

Failure 5: Disk encryption alone (Requirement 3.5.1.1)

This one is less common than script requirements but generates significant findings at infrastructure-heavy operators. PCI DSS v3.2.1 was ambiguous about whether full-disk encryption of a server constituted sufficient protection for cardholder data at rest. Many operators implemented FDE (full-disk encryption via BitLocker, FileVault, or dm-crypt) and treated stored PANs as protected.

Requirement 3.5.1.1 in v4.0 explicitly states that disk-level or partition-level encryption is not sufficient as the sole protection mechanism for cardholder data at rest unless the decryption keys are managed and secured separately from the operating system and data, and the data is inaccessible to the operating system processes that access the disk in normal operation.

In practice, if your FDE key is stored in TPM or derived at boot from a local credential (the standard FDE deployment model), the disk is effectively decrypted while the system is running — any process with access to the OS can read the files. That doesn’t protect cardholder data against the attacker who has compromised the running system, which is the primary threat model for stored PANs.

Operators maintaining legacy PAN storage (for legitimate purposes like recurring billing without network tokenization) who relied on FDE found this a gap. The remediation path is either database-level or field-level encryption with key management independent of the application — or migrating to network tokens or PSP vault tokens that eliminate PAN storage entirely.

Failure 6: Service accounts and system accounts (Requirement 8.6)

Requirement 8.6 in v4.0 introduced explicit requirements for interactive use of application and system accounts. System and service accounts (used by applications, scripts, and services rather than humans) must now have policies that:

• Restrict interactive login capability to only when operationally necessary
• Expire or rotate credentials at defined intervals
• Require an authorized reason to be logged when used interactively

Where operators failed:

Service account sprawl. Environments that had grown organically — SaaS-era deployments with dozens of microservices, CI/CD systems, and integration scripts — frequently had service accounts with static, long-lived passwords and no restriction on interactive login. The interactive login restriction is particularly awkward for operations teams that have historically used service account credentials to debug application issues.

The logging requirement for interactive use is easy to overlook during implementation: it requires not just that interactive sessions are possible and logged at the authentication layer, but that there is a mechanism to capture the business reason for the session before access is granted.

Failure 7: Anti-phishing (Requirement 5.4.1)

Requirement 5.4.1 requires entities to implement and maintain processes to detect and protect personnel from phishing attacks. The minimum baseline referenced in assessment guidance includes anti-phishing training and email security controls — specifically, DMARC (Domain-based Message Authentication, Reporting, and Conformance) at enforcement policy (p=quarantine or p=reject), SPF, and DKIM.

Where operators failed:

Email authentication configuration gaps. DMARC at monitoring policy (p=none) does not satisfy 5.4.1. Operators that had deployed DMARC in monitoring mode — a reasonable first step for domain owners watching for spoofing activity — found during assessment that monitoring-mode DMARC was not treated as meeting the intent of the requirement.

The enforcement policy requirement also exposes gaps in subdomain handling: operators with p=reject on the primary domain but sp=none (subdomain policy not specified, defaulting to inherit) or explicit sp=none had enforcement gaps that DMARC scanners identified.

Failure 8: Annual scope confirmation (Requirement 12.5.2)

Requirement 12.5.2 requires entities to confirm the accuracy and appropriateness of PCI DSS scope at least every 12 months, and whenever significant changes occur to the environment. This includes documenting what is in scope, why it is in scope, and confirming that scope reduction controls (segmentation, tokenization) are still effective.

Where operators failed:

Scope confirmation existed as a practice, but the documentation rarely survived assessment scrutiny. The requirement is specific: the scope review must confirm that all system components in scope are identified, that segmentation controls are verified as effective, and that the outcome is documented. Operators who treated this as a verbal exercise by the security team rather than a documented review — with evidence of segmentation testing, asset inventory validation, and sign-off — found gaps.

Segmentation verification is the harder part. If you segment your CDE from the rest of the corporate network using firewalls, 12.5.2 requires annual confirmation that the segmentation is actually working — typically demonstrated through penetration testing of the network controls or equivalent evidence. Operators who tested network segmentation during their initial PCI assessment but had no annual re-verification cadence were out of compliance.

What to do if your next assessment is coming up

The 51 requirements enforced from March 2025 are not going away, and assessment scrutiny will increase as QSAs become more familiar with the failure modes. The practical priorities:

Script inventory and monitoring (6.4.3, 11.6.1) is the highest-effort item for most web-facing operators. Start with a full audit of what loads on your payment pages — a browser developer tools network capture during checkout, combined with a Content Security Policy report-only deployment, will surface every script origin. Then work through: what can be SRI-pinned, what requires CSP controls, and what needs to be removed entirely. Build the monitoring before the next assessment, not after.

MFA scope review (8.4.2) should map every role and access path that touches the CDE and verify MFA coverage. This is often an IAM audit exercise that turns up stale accounts, service account login paths, and CI/CD runner credentials that predate the MFA rollout.

TRA review (12.3.1): if you used the flexible requirement pathway, pull your TRAs and stress-test whether they contain actual risk arguments or just documented conclusions.

For operators evaluating whether payment tokenization or 3DS2 authentication investments also serve compliance goals — they often do. Reducing PAN storage scope shrinks the 6.4.3 inventory burden (fewer payment pages to cover); strong authentication reduces the MFA gap surface. The compliance investment and the revenue-protection investment are increasingly the same investment.

PCI DSS v4.0 will be superseded eventually — but the requirements added in this version reflect the actual threat landscape for payment operators: browser-side skimming, credential attacks on cloud-hosted CDEs, and persistent e-commerce compromise. For the broader risk-and-compliance stack — KYB/KYC, 3DS2, chargebacks, and PSD3 — that topic page covers all five compliance areas together. Year one made clear which operators treated the transition period as runway and which treated it as a grace period. The assessment process is now catching up.