PCI DSS 4.0 is now mandatory — what engineering teams need to build

On 31 March 2025, 51 PCI DSS requirements that had been sitting in a "best practice" holding pen became mandatory. If you process card payments and haven't done the engineering work yet, you're already non-compliant.

Most of the coverage around PCI DSS 4.0 has been compliance-focused. Auditors talking to auditors. But the hard part isn't understanding the requirements. It's building the systems that meet them. Here's what's actually involved from an engineering perspective.

MFA everywhere, not just for admins

Under 3.2.1, multi-factor authentication was only required for remote administrative access. Now it's required for all access to the cardholder data environment. Anyone who touches the CDE — developers, ops, support staff — needs MFA.

This isn't a policy change you can handle with a document update. It's infrastructure work. You need to integrate an identity provider, configure access controls per environment, and probably rethink how your team accesses production systems day to day.

If you're using a third-party vault or payment service provider and never touch cardholder data directly, this one might not apply to you. But if you're storing card data in-house, it's a significant build.

Payment page scripts need an inventory

Requirements 6.4 and 11.6 are the ones that will catch people out. You now need a documented inventory of every script running on your payment pages. That analytics tag, the chat widget, the retargeting pixel — all of them need to be explicitly authorised. And you need a mechanism to detect when something unauthorised loads.

This is the requirement that closes the door on Magecart-style attacks — those skimming scripts that inject themselves into checkout pages and quietly siphon card data from the browser. The PCI Council saw enough of those incidents to make this mandatory.

In practice, this means Content Security Policy headers, Subresource Integrity checks, and runtime monitoring on your payment pages. If you've been loading third-party scripts loosely on checkout, that stops now.

Passwords get longer

Minimum password length goes from 7 to 12 characters. If your system still enforces 8-character minimums, that needs updating. Not complicated, but it touches authentication flows, validation logic, and user-facing copy. The kind of change that's easy to spec and annoying to ship across every service that handles credentials.

Continuous risk analysis replaces annual box-ticking

The old model was: do a risk assessment once a year, file it, move on. The new model requires a targeted risk analysis for any change to the environment. Add a new integration? Risk analysis. Change your hosting provider? Risk analysis.

For engineering teams, this means building change management into your deployment pipeline more formally. It's not enough to have a CI/CD pipeline that runs tests. You need a documented process for evaluating whether infrastructure changes affect your PCI scope.

What this means if you're building payment systems

We work with payment processors and merchant service providers. The pattern we keep seeing is teams that treated PCI 4.0 as a future problem and are now scrambling. The requirements aren't unreasonable, but they're real engineering work. MFA integration, script monitoring, logging changes. None of it ships itself.

If you're in the middle of this, the practical move is to triage by risk. MFA and payment page script controls are the highest-impact requirements. Get those done first. Password length and risk analysis processes can follow.

The deadline has passed. The question now is how quickly you can close the gaps.