TL;DR
PCI DSS v3.2.1 retired on 31 March 2024. All assessments now use v4.0.1. Of the 64 new requirements introduced in v4.0, most were best-practice with a grace period until 31 March 2025. The most significant post-March-2025 requirements are MFA for all cardholder data environment access (Req. 8.4.2), payment page script inventory and integrity monitoring (Req. 6.4.3 and 11.6.1), and targeted risk analysis for all scheduled control activities (Req. 12.3.2).
Compliance Blog
PCI DSS v4.0.1 Deadlines: What Became Mandatory in March 2025
PCI DSS v4.0 was published by the PCI Security Standards Council (PCI SSC) in March 2022. It replaced v3.2.1, which retired on 31 March 2024. Version 4.0.1, a minor clarification update, was published in June 2024. All assessments from 1 April 2024 onward must be conducted against v4.0.1.
The transition introduced 64 new requirements. At launch, many were designated "best practice" with a compliance deadline of 31 March 2025. After that date, all 64 became fully mandatory. This post explains which requirements became mandatory in 2025 and what they mean in practice for merchants and service providers.
For an interactive checklist of all 12 PCI DSS requirements, see the PCI DSS compliance checklist.
What was already mandatory from 1 April 2024
When v4.0 became the only valid version in April 2024, the immediately mandatory changes were primarily structural. The customised implementation approach, which allows organisations with mature security programmes to demonstrate compliance through alternative controls rather than the prescribed approach, became available. Targeted risk analyses, which organisations must now perform for several requirements to justify chosen frequencies and timeframes, became required. The PCI DSS v4.0 assessment report format (Report on Compliance, SAQ) became the only valid format for submitting compliance evidence.
Some requirements that existed in v3.2.1 were clarified, tightened, or restructured. The fundamental 12-requirement framework remained in place. The change was in depth and specificity, not in overall architecture.
Key requirements mandatory from 31 March 2025
The following table summarises the most significant "future-dated" requirements that became mandatory on 31 March 2025. All citations refer to PCI DSS v4.0.1.
| Requirement | What it requires | Who is most affected |
|---|---|---|
| 8.4.2 | Multi-factor authentication for all access to the cardholder data environment (CDE), not just remote access. Applies to all personnel with CDE access regardless of connection type. | Any merchant or service provider whose staff access systems in the CDE |
| 6.4.3 | Maintain an authorised inventory of all scripts loaded on payment pages. Confirm authorisation, integrity (e.g. subresource integrity or hash), and purpose for each script. Review and update when scripts change. | All merchants with e-commerce payment pages, including those using hosted checkout |
| 11.6.1 | Implement a mechanism to detect unauthorised changes to HTTP headers and payment page content. Review alerts at least weekly. | All merchants with e-commerce payment pages |
| 12.3.2 | Perform a targeted risk analysis to justify the frequency chosen for all periodic control activities in the standard. Document the analysis, the chosen frequency, and the review cycle. | All entities using the standard approach (not customised implementation) |
| 3.4.2 | Technical controls preventing copy/paste or export of primary account numbers (PAN) from remote-access technologies (e.g. RDP, VDI, screen sharing) wherever technically feasible. | Entities using remote-access tools to access systems in the CDE |
| 5.3.3 | Anti-malware solutions must scan removable electronic media when inserted. Applies to all systems in the CDE that are capable of connecting removable media. | Entities with physical point-of-sale or CDE systems that accept USB drives |
| 10.7.2 / 10.7.3 | Failures of critical security controls must be detected, alerted, and addressed promptly. For automated audit log systems, failures must be addressed within the same audit log review interval. | All entities |
Requirements 6.4.3 and 11.6.1 in depth: the e-commerce skimmer controls
Requirements 6.4.3 and 11.6.1 are among the most significant new requirements for online merchants, and they are widely misunderstood. They were introduced specifically in response to Magecart-style payment page skimmer attacks, where malicious code is injected into or appended to JavaScript on a checkout page to harvest card numbers in real time as customers type them.
Requirement 6.4.3 requires that all scripts loading on a payment page be documented in an inventory that includes: the name and purpose of each script, the business or technical justification for its presence, and a method for verifying its integrity. Subresource integrity (SRI) attributes are the most common technical approach for third-party scripts. For first-party scripts, a hash or version-controlled deployment process serves the same function.
Requirement 11.6.1 requires an active monitoring mechanism, not just a policy. Weekly review of an automated monitoring output is the minimum. Tools that detect DOM modifications, unexpected new script elements, or changes to HTTP headers on payment pages satisfy this requirement. Several dedicated script monitoring vendors and WAF products provide this capability.
These requirements apply even if you use a hosted payment page (Stripe Elements, Braintree Drop-in, PayPal Hosted Fields) if your checkout page loads any JavaScript at all. If your webpage includes Google Analytics, Hotjar, Intercom, a cookie consent banner, or any other tag before or during the payment flow, Requirements 6.4.3 and 11.6.1 apply to those scripts. The payment form being hosted externally does not eliminate the obligation.
Requirement 8.4.2: MFA for all CDE access
Prior to v4.0, MFA was explicitly required only for remote access to the CDE. Requirement 8.4.2 extends this to all access. If a system administrator uses a workstation inside the office network to access the CDE, MFA is now required for that access.
In practice, this means: any administrative console access to databases, servers, or applications in the CDE should require MFA regardless of network location. Jump boxes, bastion hosts, and privileged access workstations are common implementation patterns. Cloud platforms with IAM roles and conditional access policies can satisfy the requirement through configuration rather than additional tooling.
What SMB merchants should do
For Level 3 and Level 4 merchants (fewer than 1 million and fewer than 20,000 card-not-present transactions per year respectively), the following steps address the most common gaps from the March 2025 requirements:
- Confirm your current SAQ type with your acquiring bank. The correct SAQ determines which requirements apply to you.
- Audit all scripts on your payment page. Use browser developer tools or a tag audit tool to list every script that loads on the checkout page. Document each one's purpose and add SRI attributes to third-party scripts where possible.
- Set up weekly monitoring of your payment page. At minimum, a manual review of loaded scripts in a browser session weekly. Better: an automated monitoring tool or WAF with payment page change detection.
- Enable MFA for all accounts with access to your hosting environment, payment gateway admin console, e-commerce platform admin, and any other system in scope for PCI. Most platforms support TOTP authenticator apps at no additional cost.
- Complete a targeted risk analysis for control frequencies. For each periodic control in your SAQ (e.g. quarterly vulnerability scans, annual penetration testing), document why you chose that frequency based on your risk environment.
FAQ
Is PCI DSS v3.2.1 still valid?
No. PCI DSS v3.2.1 retired on 31 March 2024. All assessments from that date onward must be conducted against PCI DSS v4.0 or v4.0.1.
What is the difference between PCI DSS v4.0 and v4.0.1?
PCI DSS v4.0.1 is a minor clarification update released in June 2024. It corrects errata and clarifies language but does not add or remove substantive requirements.
Do Requirements 6.4.3 and 11.6.1 apply if I use Stripe or PayPal hosted checkout?
Yes, in most cases. These requirements apply to any payment page that loads scripts, even if the payment form itself is hosted externally. If your checkout page includes any JavaScript tags, those scripts must be inventoried and monitored.