PCI DSS 4.0 (now v4.0.1) pushes the real work onto engineers, not just the security team. As of 3/31/2025, the future-dated requirements are mandatory: multi-factor authentication for every way into the cardholder data environment, inventory and integrity checks for payment-page scripts, APIs become an explicit audit target, and documented risk analyses. This article explains each part in plain English.
PCI DSS is the Payment Card Industry Data Security Standard: the set of rules that any system storing, processing, or transmitting cardholder data must follow. Version 4.0 was published in March 2022, and the errata version v4.0.1 (6/11/2024) is now the standard in effect; v4.0 was retired on 12/31/2024.
The old version (3.2.1) read like a checklist for infrastructure and compliance staff. Version 4.0 changes that. A large batch of "future-dated" requirements moved from best practice to mandatory on 3/31/2025, and many of them fall squarely into the developer's lap: how you authenticate, how you ship your payment page, how you build APIs, and how you document your own decisions. If you build or maintain anything that touches a payment transaction, this is now your job too.
This is the change most teams feel first. Under the previous standard, multi-factor authentication (MFA) was mainly required for administrators and for remote access into the cardholder data environment (CDE). Under Requirement 8.4.2, MFA is now required for all access into the CDE, for every user, every role, no matter where the connection comes from.
For developers, that means:
In practical terms, design CDE access so the second factor is applied right at the boundary (identity provider, bastion, or gateway) instead of being bolted onto each application piecemeal.
Because attackers stopped breaking into servers and moved to skimming right in the browser. E-skimming (commonly called Magecart) injects malicious JavaScript into the payment page to steal card numbers the moment the customer types them, where server-side measures never see it. Two new requirements address this, and both center on the client-side scripts you ship.
Requirement 6.4.3 — manage your scripts. For every script loaded on the payment page, you must:
Requirement 11.6.1 — detect tampering. Deploy a change-and-tamper detection mechanism that alerts staff to unauthorized modifications of the HTTP headers and the script/content of the payment page exactly as the customer's browser receives it. The page must be evaluated on a defined schedule — at least once every seven days — or at a frequency you justify with a targeted risk analysis.
One thing to note: this scope includes third-party scripts too — analytics, tag managers, chat widgets, A/B testing. If it runs on your payment page, it is in scope.
Yes. PCI DSS 4.0 consolidates secure coding expectations under Requirement 6.2.4, which states that software engineering techniques must be defined and applied to prevent or mitigate common attacks in bespoke and custom software — and this explicitly includes APIs. The named attack classes include injection (SQL, LDAP, OS command, and the like), along with the client-side flaws and access-control flaws that commonly show up on modern API surfaces.
For developers, the practical reading is that an API endpoint handling payment data is held to the same standard as a web form. Input validation, parameterized queries, output encoding, authentication and authorization on every route, and protection against business-logic abuse are all expectations — and an assessor can ask you to show how you meet them.
Version 4.0 introduces flexibility: for some requirements, you choose the frequency at which you perform an activity rather than following a fixed interval. In exchange, you must justify the chosen frequency with a documented targeted risk analysis (TRA) under Requirement 12.3.1, reviewed at least once every 12 months.
So if you decide to scan payment-page integrity every seven days instead of daily, the TRA is where you record the reasoning, the assets involved, and the residual risk. The PCI Security Standards Council publishes a TRA template you can use. For engineers, this is mostly a documentation habit: decide deliberately, write down the reasoning, review it annually.
Every requirement above applies only to systems that are in scope — that is, the CDE and everything connected to it. The most effective architectural lever is making that scope as small as possible. Fewer things in scope means fewer things to test, fewer things to monitor, and fewer things that can go wrong.
Common techniques:
Designed well, scope reduction can take entire services outside the audit boundary — which is exactly why we treat it as an architectural decision, not an afterthought.
| Requirement | What it says | What the developer does |
|---|---|---|
| 8.4.2 | MFA for all access into the CDE | Apply a second factor at the boundary for every user and role |
| 8.5.1 | The MFA system must resist tampering | Remove easy bypasses and weak fallback flows |
| 6.2.4 | Prevent common attacks in bespoke/custom software, including APIs | Input validation, parameterized queries, per-route authorization |
| 6.4.3 | Inventory, authorize, and verify integrity of payment-page scripts | Track every script; justify it; verify it has not been altered |
| 11.6.1 | Detect change and tampering on the payment page | Monitor headers/content as the browser receives them, at least weekly |
| 12.3.1 | Targeted risk analysis for flexible-frequency items | Document the reasoning for the chosen cadence; review annually |
Yes. PCI DSS v4.0.1 is the version of the standard in effect, and the future-dated requirements that were "best practice" became mandatory on 3/31/2025. They are now assessed in a normal PCI DSS assessment.
Version 4.0.1 is a limited errata published on 6/11/2024. It fixes wording and clarifies guidance; it does not add new requirements and does not move any deadlines. If you are reading "4.0," the measures still apply, and 4.0.1 is the current document.
Usually yes, just a smaller subset. Even when a payment gateway handles the card data, your payment page and the scripts on it can still bring requirements like 6.4.3 and 11.6.1 into scope. The specific obligations depend on how you integrate; scope reduction (hosted fields, iframes, tokenization) is how you reduce them.
Yes. Requirement 8.4.2 requires MFA for all access into the cardholder data environment, including engineers, support staff, and every automated path, not just administrators as before.
We architect fintech software to PCI DSS 4.0 and build the controls in, but compliance is a status your organization achieves with an assessor or acquiring bank. We are transparent about the controls and the scope; we do not claim to hold a certification we do not have.
BeevR is a founder-led software and AI studio of senior engineers in Hanoi, serving clients worldwide. We architect fintech software to PCI DSS 4.0 — payment orchestration, reconciliation, and audit logging built in — at a fixed price, and you own 100% of the source code. Tell us what you're building and book a call.