Why the four new requirements matter
PCI DSS v4.0 was not a cosmetic update. While the overall structure and 12 requirement groups remain, the standard introduces the concept of a customised approach and includes requirements specifically designed to address the threat landscape of the 2020s: JavaScript skimming attacks on payment pages, phishing as an initial access vector, and the expansion of MFA to local CDE access (not just remote access).
Three of the four requirements discussed here (Req 5.4, 6.4.3, and 11.6.1) were introduced as future-dated requirements in early v4.0 releases — meaning they had a grace period to implement even after v4.0 became the required version. That grace period ended on 31 March 2025. All four are now mandatory and will be tested by QSAs.
Req 6.4.3: Payment page script management
What the requirement says
Req 6.4.3 requires that all payment page scripts that are loaded and executed in the consumer's browser are managed as follows:
- A method is in place to confirm that each script is authorised
- A method is in place to assure the integrity of each script
- An inventory of all scripts is maintained with a written justification of why each script is necessary
Who this applies to
This applies to merchants with payment pages that load scripts into the consumer's browser. It does not apply to merchants using SAQ A (fully outsourced to a PCI-certified hosted payment page via redirect or iframe with no scripts on your page). SAQ A-EP merchants are in scope.
What compliance looks like
A compliant implementation has four components:
- Script inventory: A documented list of every script on the payment page, including first-party code, third-party libraries, analytics tools, chat widgets, A/B testing frameworks, and CDN-loaded resources. Include the script source, purpose, and who authorised it.
- Authorisation process: A formal approval workflow for adding any new script to the payment page. This can be a PR review process with explicit security sign-off, a CAB review, or an approved-scripts allowlist enforced technically.
- Integrity verification: For third-party scripts, implement Subresource Integrity (SRI) hashes in your HTML —
<script src="..." integrity="sha384-..." crossorigin="anonymous">. For first-party scripts, ensure your CI/CD pipeline verifies build integrity. Content Security Policy (CSP) headers can enforce that only listed script sources are loaded. - Justification documentation: For each script, document why it's necessary (business purpose, owner, and when it was last reviewed).
Common compliance gaps
The most common gap is discovering that the payment page loads significantly more scripts than the team realised — analytics, retargeting pixels, live chat, A/B testing tools, and third-party libraries all add up. Many of these are loaded dynamically or conditionally, making them hard to inventory without browser-level monitoring. Tools like Feroot, PerimeterX, or a commercial script monitoring service can automate discovery and integrity checking.
Req 11.6.1: Payment page change and tamper detection
What the requirement says
Req 11.6.1 requires that a mechanism is in place to detect unauthorised changes to HTTP headers and the contents of payment pages as received in the consumer's browser. This mechanism must be used to evaluate payment pages at least weekly.
Why this exists
Magecart and similar web skimming attacks can inject malicious JavaScript at multiple points: CDN compromise, third-party script source compromise, browser extension injection, or network-level MITM. Even if your origin server is clean, the consumer's browser may receive a modified page. Req 11.6.1 requires you to detect this at the consumer browser level, not just monitor your server.
What compliance looks like
Options for implementing this requirement include:
- Automated weekly scans: Use a tool that simulates loading your payment page from multiple browser/network contexts and compares the delivered scripts and HTTP headers to a known-good baseline.
- Commercial script monitoring services: Products like Feroot SecurityAgent, PerimeterX Code Defender, or Jscrambler monitor in real-time or at scheduled intervals and alert on changes.
- Custom monitoring: A synthetic monitoring script that loads your payment page and compares the script inventory and CSP headers to a documented baseline. This can be built with Playwright or Puppeteer and run on a schedule.
Evidence for QSAs includes the monitoring tool configuration, weekly scan results, and records of what happened when changes were detected (investigation and response records).
Req 8.4: MFA for all access into the CDE
What changed from v3.2.1
In PCI DSS v3.2.1, MFA was required for:
- All remote network access originating from outside the organisation's network
- All administrator access to the cardholder data environment from within the CDE
In PCI DSS v4.0 (Req 8.4), MFA is required for all access into the CDE by all personnel — including those accessing CDE systems from inside the internal network. The previous local network exemption is gone.
What this means in practice
Every user who accesses any CDE system component — whether via VPN, direct network connection, cloud console, SSH, or application login — now requires MFA. This includes:
- Developers who SSH to CDE servers from the office network
- DBAs who connect to production databases via an internal bastion host
- Ops staff who access cloud management consoles from the office
- Support staff who access CDE applications from the corporate office
Implementation approaches
For cloud-hosted CDEs, this is typically addressed by enforcing MFA on the identity provider (IdP) for all CDE resource access — AWS IAM Identity Center, Azure AD Conditional Access, or Google Cloud Identity enforced policies. For SSH access, hardware security keys (FIDO2) or SSH certificates with MFA in the issuance flow satisfy the requirement. Document that MFA is enforced technically, not just by policy — QSAs will test bypass scenarios.
Req 5.4: Protection from phishing attacks
What the requirement says
Req 5.4 requires that phishing attacks are detected and protected against. This must include:
- Anti-phishing technical controls to protect against phishing attacks
- The awareness training programme under Req 12.6 must cover phishing specifically
Technical controls that satisfy this requirement
- Email security: SPF, DKIM, and DMARC configured for your domain (DMARC with policy of quarantine or reject). Email gateway filtering with anti-phishing analysis (Microsoft Defender for Office 365, Google Workspace Advanced Protection, Proofpoint, Mimecast).
- DNS filtering: A DNS filtering service that blocks known phishing domains (Cloudflare Gateway, Cisco Umbrella, NextDNS — several offer free tiers).
- Domain monitoring: Monitor for newly registered lookalike domains that could be used in spear-phishing. Tools like PhishLabs, Bolster, or free DNSTWIST scanning.
- Browser protection: Safe Browsing (Chrome/Firefox), Microsoft SmartScreen, or an endpoint security product with URL filtering.
Targeted risk analysis: the v4.0 meta-requirement
One often-overlooked change in v4.0 is that for requirements where the frequency is defined as "at least once every 12 months" or similar, entities must perform a documented targeted risk analysis to justify the chosen frequency. This applies to requirements like Req 8.3.9 (password change period), Req 11.3.1.1 (vulnerability scanning frequency), and others.
The targeted risk analysis must document: what's being protected, the threats considered, the effectiveness of existing controls, the resulting risk level, and why the chosen frequency is appropriate for that risk level. QSAs will ask for these analyses.
Use our free PCI DSS v4.0 Gap Assessment Generator to work through all 12 requirement groups including these four new requirements. For related controls, see the Change Management Policy Generator (Req 6 coverage) and the Password & Auth Policy Generator (Req 8 coverage).