As you read through the PCI 4.0 requirements and standards, several sections will say, “This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.”
This deadline is approaching!
More than 50 requirements were future-dated to give organizations time to implement these changes, some of which can take up to 12 months. A complete summary of the changes from PCI DSS Version 3.2.1 to 4.0 can be found in this document from the PCI Security Standards Council. The summary of new requirements will list all new requirements, the entity to which the new requirement applies, and the effective date of the new requirement.
We’ve called out a few of the most impactful updates below.
Multi-Factor Authentication
The new requirement is to implement multi-factor authentication (MFA) for all access into the cardholder data environment. This was a best practice and now applies to anyone storing PCI data. It also may require the most engineering effort.
Implementing MFA is not the same as the other updates because it cannot be handled with a documentation or policy update. This is technical implementation work and is a high effort for most engineering teams.
This requirement predominantly applies if you are storing cardholder data in-house. If you are vaulting card data with a PSP or other third-party, this update does not apply to you because there is no card data environment to secure, keeping the costs of PCI compliance much lower. In that case, the assumption is whoever the merchant is working with meets this standard of PCI compliance. However, it doesn’t hurt to check with those platforms to ensure they have MFA properly set up.
Payment Page Script Security
Arguably, the single biggest topic at the PCI DSS North America Community Meeting in August was Payment Page Script Security (also known as Subresource Integrity or Payment Page Resource Integrity.)
Requirements 6.4 and 11.6 require a way to guarantee the authenticity and authorization of every third-party script enabled on the checkout page, plus a documented inventory and justification for every script. Each security team should be monitored and alerted if an unauthorized script is loaded into the checkout flow.
This update protects against web skimming, e-skimming, or formjacking, techniques that hackers use to capture sensitive data from users on legitimate payment pages. Solutions that have been identified are nuanced and, in some cases, could be considered less than ideal:
- Remove all third-party libraries that don’t serve a function within a checkout page. If it’s unrelated to the business process of collecting payment details, it shouldn’t be on the checkout page. If it’s there, it should be justified and documented.
- Have a payment service provider (PSP) or token orchestration platform completely host the payment page. This would be an entirely separate page to which the consumer would be routed, where they would enter their payment details. While not always ideal from a customer experience standpoint, most PSPs already offer this.
QSAs that we spoke with said the most straightforward way to address Payment Page Script Security is for the third-party to fully host the payment page for its customers.
Enhanced Web Protection
See: 6.4.2, 6.4.3, 11.6.1. You will need a Web Application Firewall, or equivalent functionality, to detect and prevent web-based attacks. Additionally, you must implement a system to inventory, authorize, and justify changes to any scripts that execute in your customer's browser, particularly on your payments page.
SAQ and RoC Updates
Updates to the SAQ and RoC templates that are intended to help complete the forms.
The expectation is that if you make a change in your environment (e.g., adding a new firewall), you need to do a risk assessment on that change. Formal risk assessments may not seem like a big change based on some of the other future-dated requirements that have been added to the standard, but this change may result in additional effort in the transition process.
Moving Forward
It can feel like the only thing harder than becoming PCI compliant is staying PCI compliant. If any of these updates come as a surprise to security teams—or were perhaps underestimated—not being fully implemented by March 31, 2025, means falling out of PCI compliance.
Merchants will work with providers like Basis Theory to reduce most of the PCI scope, making these changes significantly easier to comply with. Why Basis Theory?
