PCI DSS 4.0 Is Live: What Engineering Teams Actually Have to Change

Compliance

PCI DSS 4.0 has been in force since March 2024 and the future-dated requirements landed in March 2025. Three clauses catch most teams off-guard. The engineering checklist we work through with clients.

By Arjun Raghavan, Security & Systems Lead, BIPI · November 15, 2025 · 8 min read

PCI DSS 4.0 has been the active version since March 2024. The requirements that were future-dated to give teams a transition runway became enforceable in March 2025. We are now in the period where assessors are scoring against the full standard, and the audits we have walked clients through this year have shown a consistent pattern. Three clauses catch most teams off-guard.

The shift: defined approach versus customized approach

Before getting to the clauses, the meta-change in PCI DSS 4.0 matters. The old standard had one path, prescriptive requirements you either met or you did not. PCI DSS 4.0 introduces a customized approach, where you can implement an alternative control if you can document that it meets the security objective.

On paper this is flexibility. In practice it is more work. The customized approach requires a documented Targeted Risk Analysis (TRA) per control, peer review, and explicit assessor agreement before the audit. Most teams that try it end up reverting to the defined approach because the documentation overhead exceeds the perceived benefit. Pick deliberately, not by default.

Clause one: MFA for all CDE access, not just admins

PCI DSS 3.2.1 required multi-factor authentication for non-console administrative access to the cardholder data environment (CDE). Many teams interpreted that as 'admins need MFA, regular users do not.' That is no longer correct.

Requirement 8.4.2 in 4.0 mandates MFA for ALL access into the CDE. A developer SSH'ing to a payment-touching server, an analyst running a SELECT query against a CDE database, an automated script with a service-account credential. All of these need a second factor unless the access is via a system that cannot support it (rare, increasingly hard to argue).

The engineering work this triggers is not the MFA enrolment itself. It is the audit trail. You need to evidence, per access event, which factor was used. SSO with conditional access is the cleanest path. JIT access via Vault or Teleport is the next-cleanest. Service accounts that cannot do MFA require a documented compensating control and tight scoping.

Clause two: targeted risk analysis for every flexibility

Several requirements in 4.0 say 'do this at a frequency you determine via a targeted risk analysis.' Patch cadences, log review intervals, password rotations. The phrase looks like flexibility. The audit reads it as 'show me your TRA.'

The TRA template is short. Threat, likelihood, impact, control, frequency, justification. One page per requirement. Skip it and the assessor falls back to the strictest default. We have seen teams forced into 90-day password rotation because their TRA for 8.3.9 was missing.

Clause three: payment page e-skimming defence

Requirement 6.4.3 and 11.6.1 are the new requirements that hit any merchant that takes card details on a webpage. Magecart-style attacks, where an attacker compromises a third-party script tag (chat widget, analytics) and uses it to skim card data, are the threat the standard is targeting.

The control is two-part. First, you must inventory and authorize every script that loads on a payment page. Second, you must detect unauthorized changes to that page or its scripts. A Subresource Integrity (SRI) hash is the cheap path. A script-monitoring service is the next tier. Either way, the inventory has to be a living document, refreshed every release.

The engineering checklist we run

• MFA enforced for every access path into the CDE, with audit evidence per session.
• Service accounts in CDE either do MFA via cert-based auth or have a documented compensating control.
• TRA filed for every requirement that allows risk-based frequency.
• Inventory of payment-page scripts, signed off quarterly, with SRI or equivalent monitoring.
• Tamper detection on payment pages, alerting into the SOC pipeline.
• Quarterly internal vulnerability scans by a credentialed scanner, not just unauthenticated.
• Automated checks for the new requirements integrated into CI so audit prep is a non-event.

Closing

PCI DSS 4.0 rewards the teams that treat compliance as engineering. Inventory in code. TRAs in git. Evidence generated by automation, not pulled together the week before the audit. That is the cleanest path through the new requirements, and the only path that scales as the CDE grows.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.