PCI DSS v4.0.1 a year after the deadline: the requirements teams still struggle with

On 31 March 2025, the roughly fifty “future-dated” requirements of PCI DSS v4 stopped being best practice and became mandatory. That deadline is now more than a year behind us, and the transition period is over in every practical sense: v4.0.1 (the June 2024 limited revision) is the only active version of the standard.

Yet in the assessments and gap analyses I’ve been involved in since, the same handful of requirements keep coming up short. Not because they’re obscure — because they require ongoing operational work rather than a one-time configuration change. Here are the ones worth re-checking in your environment.

6.4.3 and 11.6.1 — payment page scripts

The pair of requirements written in response to Magecart-style skimming attacks remains the biggest source of pain for e-commerce:

• 6.4.3 requires an inventory of all scripts loaded on payment pages, written justification for each, and a mechanism to confirm each script is authorized and its integrity assured.
• 11.6.1 requires a change- and tamper-detection mechanism on payment pages, evaluating received HTTP headers and script contents at least weekly (or at a frequency defined by a targeted risk analysis).

Common failure modes: the inventory was built once in early 2025 and never updated while marketing added three new tags; the CSP that was supposed to enforce authorization is in Report-Only mode with nobody reading the reports; the tamper-detection tool monitors the homepage but not the actual iframe-hosted payment flow. Note also the SAQ A changes announced in early 2025: 6.4.3 and 11.6.1 were removed from SAQ A itself, but replaced with an eligibility criterion — the merchant must confirm their site is not susceptible to attacks from scripts that could affect the payment page. You don’t escape the problem; you attest to having dealt with it.

12.3.1 — targeted risk analyses (TRAs)

Every place the standard says “at a frequency defined in the entity’s targeted risk analysis,” Requirement 12.3.1 expects a documented TRA: the asset, the threat, the factors contributing to likelihood and impact, the resulting frequency, and review at least every 12 months. Organizations that chose flexible frequencies for controls like POI device inspections (9.5.1.2.1), log reviews for non-critical systems (10.4.2.1), or password changes for service accounts (8.6.3) often have the frequency but not the analysis. An assessor will ask for the document, and “we decided quarterly is fine” is not a TRA.

8.3.6, 8.4.2, 8.6 — authentication, everywhere, including the accounts you forgot

• 8.3.6: minimum 12-character passwords (where passwords are used). Most IdPs were updated long ago; the stragglers are appliances, out-of-band management interfaces, and legacy applications with hard 8-character limits — each of which needs a compensating control, not silence.
• 8.4.2: MFA for all access into the CDE, not just remote access and not just administrators. The recurring gap is internal jump hosts and administrative consoles reachable from the office LAN without a second factor.
• 8.6.2/8.6.3: interactive use of system and service accounts must be controlled, and their credentials protected and rotated based on a documented risk analysis. Service accounts with passwords set in 2019 and interactive logon: allowed remain depressingly common.

10.7.2/10.7.3 — detecting the failure of your security controls

You now need to detect, alert on, and respond to failures of critical security control systems — IDS/IPS, FIM, anti-malware, logging, segmentation controls, and (for service providers) automated log review mechanisms. The gap is usually the response half: the SIEM notices the log source went quiet, but there’s no documented process for restoring the control, assessing what happened during the outage, and addressing root cause. 10.7.3 spells out exactly what that response must include; it makes a good template for the runbook.

3.x — cardholder data storage got stricter

• 3.5.1.2: disk-level or partition-level encryption may only be used to render PAN unreadable on removable media; everywhere else it must be supplemented by another mechanism (column-level encryption, tokenization, truncation). “BitLocker on the database server” stopped being a complete answer.
• 3.4.2: technical controls must prevent copy/relocation of PAN during remote access sessions except with documented authorization. Check your VDI and RDP clipboard policies.
• 3.3.2: sensitive authentication data stored before authorization completes must be encrypted — this catches pre-auth queues, debug logs, and crash dumps that engineering never thought of as “storage.”

12.5.2 — scope confirmation is now a documented exercise

Scoping was always implicitly required; now it’s an explicit, documented exercise at least every 12 months (every 6 months for service providers, per 12.5.2.1) and after significant changes. If your last scope document predates your migration to the new payment provider, that’s a finding waiting to be written.

What I’d do this quarter

1. Re-validate the payment page script inventory against what the pages actually load today, and check your 11.6.1 mechanism covers the real payment flow, weekly.
2. Collect every “frequency defined by TRA” control into one register and confirm each has a current, reviewed TRA behind it.
3. Sweep for authentication stragglers: sub-12-character limits, CDE paths without MFA, stale service accounts.
4. Tabletop a security-control failure (kill a log forwarder in a test environment) and see whether your 10.7.2/10.7.3 process actually fires.

None of this is new anymore — which is exactly why assessors have stopped accepting “we’re still transitioning” as an answer.

Cyber Twierdza supports PCI DSS projects end to end: gap analyses, internal audits, SAQ-D preparation, and pre-assessment readiness. Details on the services page.