QSA-authored guide · PCI DSS v4.0.1

The PCI DSS 4.0 transition, in plain English.

PCI DSS 3.2.1 is retired. Every merchant and service provider is now assessed against PCI DSS v4.0.1. This guide covers what actually changed, the two requirements that trip up small and mid-sized businesses the most — MFA and authenticated internal scans — and the practical steps to get ready.

Timeline: where the standard is today

The PCI Security Standards Council released PCI DSS v4.0 in March 2022 and the minor errata release v4.0.1 in June 2024. PCI DSS 3.2.1 was formally retired on 31 March 2024. Since 1 April 2024 every SAQ and every Report on Compliance must be completed against v4.0.1 — there is no falling back to 3.2.1.

A second wave of “future-dated” requirements — the ones marked as best practice through 31 March 2025 — became mandatory on 1 April 2025. Those are the ones this guide focuses on, because they are the changes that force new tooling, new evidence, and new conversations with third parties.

Change 1 — MFA everywhere in the CDE

Under 3.2.1, multi-factor authentication was required for administrative access and remote access into the cardholder data environment (CDE). Under v4.0.1 Requirement 8.4.2, MFA is required for all non-console access into the CDE — administrator or not. That includes a support engineer opening a ticket console, a developer SSHing into a jump box, and a finance user opening a payment application that lives inside the CDE.

Two more sub-requirements matter for SMBs: 8.4.3 (MFA for all remote access originating from outside the entity's network into the CDE, regardless of user type) and 8.5.1, which sets minimum MFA implementation properties — factors must be independent, replay-resistant, and can't be bypassed by any user, including admins, unless explicitly documented and authorised.

  • Inventory every human account that can reach the CDE — including vendor and shared service accounts.
  • Confirm your MFA solution meets 8.5.1 — SMS-only OTP is discouraged; app-based TOTP or FIDO2 is expected.
  • Document any bypasses (glass-break accounts, break-fix workflows) and the compensating controls around them.

Change 2 — Authenticated internal vulnerability scans

Requirement 11.3.1.2 is new to v4.0.1 and is the change most SMBs discover late. Internal vulnerability scans must now run with credentials — the scanner authenticates into the target system and inspects it from the inside, not just from the network. That surfaces missing patches, weak local configurations, and dormant packages that unauthenticated scans miss entirely.

Practically, this means your scanner needs a service account on every in-scope system, and that account needs enough privilege to enumerate installed software and configuration state. Coordinate with your MSSP or scanning vendor early — retro-fitting authenticated scans across a large fleet is a multi-week project, not a same-week change.

Other changes SMBs feel

  • Targeted risk analysis (12.3.1). Any control you perform at a frequency other than the standard needs a documented risk analysis justifying the frequency. This is a paperwork requirement — but it is a new one and QSAs are asking for it.
  • Anti-skimming for e-commerce (6.4.3 and 11.6.1). If your site takes card data — even through an iframe — you must inventory and integrity-check the scripts loaded on the payment page. This is the requirement that added Content Security Policy hygiene and script-monitoring tooling to a lot of SAQ A-EP scopes.
  • Roles and responsibilities. Almost every requirement family now asks you to document who is responsible for the control. A single named owner per requirement family is enough for most SMBs.
  • Password length. Minimum interactive-account password length moved from 7 to 12 characters (or the maximum the system supports, if less than 12).

A practical migration checklist

  1. 1Re-confirm your SAQ. Scope changes between 3.2.1 and v4.0.1 are rare, but the eligibility criteria for the short-form SAQs were tightened — run the guided selector to verify.
  2. 2Enumerate every CDE ingress path and confirm MFA covers it (Requirement 8.4.2 and 8.4.3).
  3. 3Talk to your vulnerability-scan provider about authenticated internal scans (11.3.1.2). Get service accounts provisioned and the first authenticated scan on the calendar.
  4. 4For e-commerce merchants: inventory payment-page scripts and stand up integrity monitoring (6.4.3, 11.6.1).
  5. 5Write the targeted risk analyses for any customised control frequency (12.3.1). A one-page template per control family is enough.
  6. 6Assign a named owner to every requirement family (Requirement 12.5). Save the ownership matrix — the QSA will ask for it.
  7. 7Rehearse the SAQ before submitting. Every 'Not Applicable' now requires an explanation; every 'Compensating Control' needs a completed Compensating Controls Worksheet.

Next step

The fastest way to see how the v4.0.1 changes affect your organisation is to run the guided self-assessment — it walks the official PCI SSC eligibility criteria and cites the requirement number behind every question. When you need a signed SAQ or Attestation of Compliance, a QSA takes it from there.