PCI DSS 4.0.1 Implementation: What Engineering Teams Actually Need to Change

Most PCI DSS coverage is written as a changelog: here is what moved from v3.2.1 to v4.0. It lists what became mandatory on March 31, 2025. Here is a checklist. That framing is accurate but not especially useful once your organization is past the "are we affected" stage. It is more useful once you reach the "what do we build" stage. The PCI Security Standards Council (PCI SSC) publishes the requirements. It does not tell your platform team how to restructure an identity provider or where to put a proxy in front of a payment page. Nor does it say what a QSA will expect to see during an assessment. That gap between requirement text and production reality is where PCI DSS implementations tend to run into unplanned engineering work.

PCI DSS v4.0.1 Is Now Fully Enforced

PCI DSS v4.0.1, published by the PCI SSC on June 11, 2024, is the currently active version of the standard. It did not introduce new requirements; it corrected wording and clarified intent on a number of clauses. It also became the only supported version once v4.0 retired at the end of 2024. The substantive shift, the one that matters to engineering teams, happened earlier and is now fully enforced. The 51 requirements that were future-dated as best practices when v4.0 published in March 2022 became mandatory on March 31, 2025. If your organization treated those as optional, your next assessment cycle will not.

Scoping Decisions Still Come First

Before any of the newer requirements matter, scope has to be right. This is where cloud infrastructure tends to complicate what used to be a fairly mechanical exercise. A traditional on-premises cardholder data environment (CDE) has physical and network boundaries that are relatively easy to draw. A CDE built on managed cloud services rarely does. Shared VPCs, service meshes, managed databases with cross-account replication, and CI/CD pipelines that touch production all create paths into the CDE. These paths are not obvious from a network diagram alone.

Systems That Can Impact the CDE

PCI DSS defines scope as any system that stores, processes, or transmits cardholder data. That scope also includes any system that could impact the security of the CDE even without touching card data directly. That second clause is where cloud environments generate the most disagreement during assessments. A logging pipeline that ingests CDE logs is in scope under that definition, as is a secrets manager that issues credentials used inside the CDE. So is a CI/CD runner with a deployment role scoped to CDE infrastructure. This is true even if none of them ever see a primary account number (PAN). Segmentation testing has to demonstrate that these adjacent systems are isolated in practice, not just that firewall rules exist on paper.

Identity-Layer Segmentation

In practice this usually means proving isolation at the identity layer as much as the network layer. That means separate IAM roles, separate service accounts, and no shared credentials between CDE and non-CDE workloads.

Authentication: Broader Coverage, With a Real Carve-Out

Requirement 8.4 is where PCI DSS v4.0 made its most disruptive change to day-to-day operations. Under v3.2.1, MFA was required for remote access and for administrative access to the CDE. Under v4.0.1 it applies more broadly. 8.4.1 requires MFA for non-console administrative access. 8.4.2 requires MFA for all access into the CDE regardless of role. 8.4.3 requires MFA for all remote access originating outside the entity's network. Taken together, this closes the gap that let internal, non-administrative users reach CDE systems with a single factor. Previously that single factor was enough as long as they were on the corporate network.

Federated Identity and Legacy Access Paths

For teams running federated identity through an IdP like Okta, Entra ID, or a self-hosted SAML/OIDC provider, the work looks different. The engineering effort is less about turning MFA on itself. It is more about making sure every path into the CDE routes through that IdP. Break-glass accounts, service accounts with interactive login enabled, and legacy jump boxes are worth checking specifically. An MFA rollout built around the primary SSO flow can leave them uncovered by default. v4.0.1 also added a useful clarification here. An applicability note states that MFA for non-administrative access into the CDE does not apply to accounts authenticated solely with phishing-resistant authentication factors.

Service and System Accounts

That is a meaningful distinction for organizations that have already moved toward FIDO2 or platform-bound credentials. It avoids stacking a second factor on top of an authentication method that was already designed to resist the attacks MFA exists to mitigate.

Service and system accounts get their own treatment. Where interactive login is not required, the standard expects those accounts to run with minimum necessary privilege. Credential rotation should be tied to risk, not a blanket calendar rule. Where a service account does support interactive login, it is treated like any other account and is subject to the same MFA expectations. This is a reasonable point to bring identity governance tooling into the conversation. That is preferable to trying to track service account sprawl manually across a growing number of cloud accounts.

Targeted Risk Analysis Is Documentation, Not a Shortcut

Requirement 12.3.1 introduced targeted risk analysis (TRA) as the mechanism for justifying a non-default frequency on the subset of requirements that allow one. Examples include log review cadence, malware scan intervals, or how often to address lower-severity vulnerabilities under 11.3.1.1. This gets misread fairly often as flexibility to relax controls. It is closer to the opposite: a TRA has to identify the asset being protected, the specific threat, and the factors affecting likelihood and impact. It also requires a documented justification for the chosen frequency, reviewed at least every 12 months. Some frequencies cannot be adjusted this way at all. External vulnerability scanning by an Approved Scanning Vendor (ASV) still has to happen at least quarterly. Penetration testing still has to happen at least annually and after significant changes, regardless of what any internal risk analysis concludes.

The Customized Approach Under 12.3.2

The related Customized Approach under 12.3.2 is a separate and more demanding path. It is reserved for organizations implementing a control that meets the security objective of a requirement without following its exact specification. An example would be an advanced behavioral detection system replacing a prescriptive control. It requires its own risk analysis, a documented controls matrix, and QSA validation as part of the annual assessment. It typically adds assessor time rather than reducing it. For most organizations without a mature, already-differentiated security program, the Defined Approach remains the more practical route. A TRA under 12.3.1 is the tool worth spending time on.

Payment Pages: The Scripts You Didn't Know You Were Running

Requirements 6.4.3 and 11.6.1 exist because of e-skimming: Magecart-style attacks that compromise the browser rendering of a payment page rather than the server behind it. These attacks often work by tampering with a third-party script an organization never directly controls. Both became mandatory on March 31, 2025, and both apply to e-commerce merchants regardless of size.

Requirement 6.4.3: Script Inventory

6.4.3 requires an inventory of every script that loads or executes on a payment page, along with a documented business justification for each one. It also requires a method to confirm the integrity and authorization of each script. In practice this is harder than it sounds for any site that has accumulated analytics tags, A/B testing tools, chat widgets, and marketing pixels. Most sites collect these over a few years. Often no one has treated the payment page as a distinct security boundary. Content Security Policy and Subresource Integrity are the standard tools here. Together they form an allowlist of approved script sources plus a hash check against the expected script content. But they have real limits worth naming rather than glossing over. A legitimately updated third-party script silently breaks an SRI hash unless someone is managing that lifecycle.

The Limits of CSP and SRI

CSP allowlists a domain, not a specific script, so a compromised or misconfigured resource on an already-trusted origin can still execute. Neither control watches for drift on its own; both need an operational process behind them.

Requirement 11.6.1: Tamper Detection

11.6.1 is the change and tamper detection requirement that follows from that gap. It calls for a mechanism that alerts personnel to unauthorized changes in security-impacting HTTP headers and payment page script content. This is performed at least every seven days by default, or at a frequency set through a targeted risk analysis under 12.3.1. This is where real-time monitoring, whether custom-built or via a specialized client-side security vendor, earns its place. CSP and SRI define what should be true, and a monitoring layer confirms whether it still is. The most durable reduction in this attack surface, though, is architectural rather than a compliance checkbox. That means minimizing the number of third-party scripts with any execution path near the payment form. It also helps to isolate the actual card entry fields in a tightly scoped iframe served from its own origin where practical.

Encryption Beyond the Disk

Requirement 3.5.1.2 addresses a specific and common misconception. Full-disk or partition-level encryption, BitLocker, LUKS, or an equivalent, does not satisfy this requirement. Stored PAN must be rendered unreadable on systems that are online and in active use. Disk encryption alone is not sufficient for non-removable media. Disk-level encryption protects data at rest against physical theft of the media. It does not protect against an authenticated user or a compromised application reading PAN off a running system. That is because the operating system transparently decrypts it during normal operation. The requirement's own wording is specific about this. If disk-level or partition-level encryption is used to render PAN unreadable, it is acceptable on its own only for removable electronic media.

What Disk Encryption Does Not Protect

On non-removable media, it must be combined with another mechanism that independently meets Requirement 3.5.1. That requirement lists several acceptable approaches: keyed one-way hashes of the full PAN, truncation, index tokens, or strong cryptography with associated key management. It is not limited to file-, column-, or field-level database encryption specifically. Which of those a team chooses is an architectural decision. What the requirement rules out is treating disk or partition encryption as sufficient by itself on a running, non-removable system.

The practical implication is direct for a team relying on managed database encryption or full-disk encryption as their sole control. A second, independent mechanism needs to sit alongside it. Decryption keys and access logic need to be managed independently of native OS accounts.

Choosing an Independent Protection Mechanism

Key management gets more scrutiny too. Requirement 12.3.3 expects a documented inventory of cryptographic algorithms, key lengths, protocol versions, and certificate expiration dates, reviewed annually. Deprecated algorithms need to be identified and remediated rather than left in place because nothing has broken yet. Requirement 3 also expects access to keys restricted to the fewest custodians necessary. Key-encrypting keys must be stored separately from the data-encrypting keys they protect, with documented acknowledgment from each custodian of their responsibilities. None of this mandates a specific architecture. A cloud KMS or dedicated HSM service can form the basis of a compliant key-management architecture. Examples include AWS KMS, Azure Key Vault, or GCP Cloud KMS. Bring-your-own-key or hold-your-own-key setups are an architectural choice some organizations make for reasons beyond PCI DSS, not something the standard itself calls for.

Key Management Under Requirement 12.3.3

The engineering question PCI DSS does put in scope is different. It is whether the chosen key management approach, whatever it is, meets the custodian, separation, and access-logging requirements above. It should not simply rely on a provider's default configuration unexamined.

Vulnerability Management Sits Inside a Larger Loop

PCI DSS treats vulnerability management as a continuous obligation rather than a point-in-time scan. Both external scanning by an ASV and internal vulnerability scanning under Requirement 11.3.1 are fixed at least quarterly. Neither cadence can be relaxed through a targeted risk analysis. What a TRA does apply to is Requirement 11.3.1.1. That covers how an organization addresses vulnerabilities that scans turn up but that are not ranked high-risk or critical. Critical and high-risk findings still have to be resolved and rescanned. For everything else, the organization can document a risk-based remediation timeline rather than following a fixed clock, provided the risk ranking itself is defensible. This is commonly anchored to a standard severity scoring model such as CVSS from FIRST.

Extending Vulnerability Management Into CI/CD

For CDE-adjacent workloads built and shipped through CI/CD, this obligation extends naturally upstream into the pipeline rather than stopping at production infrastructure scanning. Static analysis, software composition analysis for third-party dependencies, and container image scanning integrated into build stages give an organization useful evidence. They show vulnerabilities are being caught before deployment, not only detected afterward by a quarterly scan. This is general industry practice rather than a PCI-specific mandate, but it materially changes how defensible a vulnerability management program looks during assessment. A QSA reviewing scan cadence and remediation timelines is effectively asking whether the program is reactive or built into the delivery process.

What the Evidence Needs to Show

A recurring theme across the requirements above is that PCI DSS v4.0.1 asks for evidence of ongoing operation, not a one-time configuration snapshot. A targeted risk analysis left on a shelf for eighteen months is one example. Another is a CSP policy nobody has touched since it was written. So is an MFA rollout that covers SSO but not a handful of legacy jump boxes. These are the kinds of gaps that surface during a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ). This is not because the underlying control was wrong when implemented, but because it was not maintained as the environment changed around it. Building the operational habit, not just the initial control, is what separates an implementation that holds up year over year. Without that habit, an implementation has to be re-done at every assessment cycle.

Where This Fits for SiegePal

SiegePal's work is implementation and engineering, not certification; formal audits are performed by independent QSAs. Our documented experience includes PCI DSS gap assessment and remediation alongside cloud security engineering, identity and access management, cryptographic engineering, and continuous vulnerability management. These are the areas this article has focused on. More detail on that work is on our PCI DSS compliance page.

References

• PCI Security Standards Council, `PCI DSS` v4.0.1 (June 2024)
• PCI Security Standards Council, Just Published: `PCI DSS` v4.0.1, PCI Perspectives blog
• PCI Security Standards Council, `PCI DSS` v4.x Targeted Risk Analysis Guidance (November 2023)
• PCI Security Standards Council, Information Supplement: Payment Page Security and Preventing E-Skimming
• FIRST.org, Common Vulnerability Scoring System (`CVSS`)