On March 31, 2025, the 51 future-dated requirements in PCI DSS v4.x stop being best practice and become mandatory. That's about five and a half months away. PCI DSS v4.0.1, published in June 2024, is now the current version, and v4.0 retires on December 31, 2024. The revision added no requirements, removed none and didn't move the March 2025 date. Below is a checklist of every future-dated requirement, grouped by theme, with separate tables for requirements that apply to all entities, to service providers only, and to a few specific situations.
How many future-dated requirements are there?
The PCI Security Standards Council puts it simply: of the 64 new requirements introduced in v4.0, 51 are future-dated to March 31, 2025. By our count from the Council's Summary of Changes, 40 apply to all entities, nine apply to service providers only, and two apply only in specific circumstances.
A few are a single new bullet inside an existing requirement rather than a whole requirement: 3.2.1, 4.2.1 and 12.10.5. Only the new bullet is future-dated. The rest of each requirement already applies.
How should you use this checklist?
For each row, record a status (in place, in progress, not started, or not applicable with a written reason), an owner and the evidence you'd show an assessor.
Several requirements depend on a targeted risk analysis (TRA) under Requirement 12.3.1. Version 4.0.1 clarified that 12.3.1 applies only to requirements that specifically call for a TRA, so you don't need one for every periodic activity. Those that do are marked "TRA" below.
Future-dated requirements for all entities
Account data protection and cryptography
| Req. | What's required |
|---|---|
| 3.2.1 (bullet) | Retention and disposal policies cover sensitive authentication data (SAD) stored before authorization completes |
| 3.3.2 | SAD stored electronically before authorization completes is encrypted with strong cryptography |
| 3.4.2 | Technical controls prevent copying or relocating PAN over remote-access technologies, except for personnel with documented authorization and a business need |
| 3.5.1.1 | Hashes used to render PAN unreadable are keyed cryptographic hashes of the entire PAN, with key management |
| 3.5.1.2 | Disk- or partition-level encryption is used only on removable media, or PAN is also rendered unreadable another way |
| 4.2.1 (bullet) | Certificates protecting PAN over open, public networks are confirmed valid and not expired or revoked |
| 4.2.1.1 | An inventory of trusted keys and certificates is maintained |
| 12.3.3 | Cipher suites and protocols in use are documented and reviewed at least every 12 months, with a plan for cryptographic vulnerabilities |
Malware protection and end users
| Req. | What's required |
|---|---|
| 5.2.3.1 | TRA sets how often systems considered not at risk from malware are re-evaluated |
| 5.3.2.1 | TRA sets the frequency of periodic malware scans, where you use them |
| 5.3.3 | Removable electronic media is scanned for malware when in use, or covered by continuous behavioral analysis |
| 5.4.1 | Processes and automated mechanisms detect and protect personnel against malicious email |
Secure software and payment pages
| Req. | What's required |
|---|---|
| 6.3.2 | An inventory of bespoke and custom software, including third-party components, supports vulnerability and patch management |
| 6.4.2 | An automated technical solution protects public-facing web applications by continually detecting and preventing web-based attacks |
| 6.4.3 | Every payment page script loaded in the consumer's browser is authorized, integrity-checked and inventoried with a justification |
| 11.6.1 | A change- and tamper-detection mechanism alerts on unauthorized changes to security-impacting HTTP headers and script contents of payment pages, weekly or at a TRA-defined frequency |
| 12.10.5 (bullet) | The incident response plan covers alerts from the 11.6.1 mechanism |
Access control and authentication
| Req. | What's required |
|---|---|
| 7.2.4 | All user accounts and their access privileges are reviewed at least every six months |
| 7.2.5 | Application and system accounts are assigned and managed on least privilege |
| 7.2.5.1 | TRA sets how often access by application and system accounts is reviewed |
| 8.3.6 | Passwords are at least 12 characters (eight if the system can't support 12) and contain letters and numbers |
| 8.4.2 | MFA for all non-console access into the CDE |
| 8.5.1 | MFA systems resist replay attacks, can't be bypassed, use two different factor types and require every factor to succeed |
| 8.6.1 | Interactive login with system or application accounts is limited to documented, approved, time-limited exceptions |
| 8.6.2 | Passwords for those accounts aren't hard-coded in scripts, configuration files or custom code |
| 8.6.3 | Those passwords are protected against misuse and changed at a TRA-defined frequency and on suspected compromise |
Logging, monitoring and testing
| Req. | What's required |
|---|---|
| 10.4.1.1 | Automated mechanisms perform audit log reviews |
| 10.4.2.1 | TRA sets the log review frequency for all other system components |
| 10.7.2 | Failures of critical security control systems are detected, alerted and addressed promptly, now for all entities and with a longer list of systems |
| 10.7.3 | Failures of critical security control systems are responded to promptly |
| 11.3.1.1 | Vulnerabilities not ranked high-risk or critical are addressed according to a TRA |
| 11.3.1.2 | Internal vulnerability scans are authenticated |
Governance, risk and people
| Req. | What's required |
|---|---|
| 9.5.1.2.1 | TRA sets how often point-of-interaction devices are inspected |
| 12.3.1 | A documented TRA exists for each requirement that calls for one, reviewed at least every 12 months |
| 12.3.4 | Hardware and software technologies are reviewed at least every 12 months, with a plan for end-of-life technology |
| 12.6.2 | The security awareness program is reviewed at least every 12 months and updated as needed |
| 12.6.3.1 | Awareness training covers threats and vulnerabilities that could affect CDE security |
| 12.6.3.2 | Awareness training covers acceptable use of end-user technologies |
| 12.10.4.1 | TRA sets how often incident response personnel are trained |
| 12.10.7 | Incident response procedures start when stored PAN turns up somewhere it isn't expected |
Future-dated requirements for service providers only
| Req. | What's required |
|---|---|
| 3.6.1.1 | Cryptographic architecture documentation includes preventing the same keys being used in production and test |
| 8.3.10.1 | If passwords are the only factor for customer users, they change at least every 90 days or account security posture is analyzed dynamically |
| 11.4.7 | Multi-tenant service providers support customers' external penetration testing |
| 11.5.1.1 | Intrusion detection or prevention detects, alerts on or prevents, and addresses covert malware communication channels |
| 12.5.2.1 | PCI DSS scope is confirmed at least every six months and after significant change |
| 12.5.3 | Significant organizational changes trigger a documented review of scope and controls, communicated to executive management |
| A1.1.1 | Multi-tenant service providers logically separate their environment from customers' environments |
| A1.1.4 | Multi-tenant service providers confirm logical separation with penetration testing at least every six months |
| A1.2.3 | Multi-tenant service providers have processes for reporting and addressing suspected or confirmed security incidents and vulnerabilities |
Service providers should also note that 10.7.2 supersedes Requirement 10.7.1, which already covers them, on March 31, 2025.
Requirements that apply only in specific situations
| Req. | Who it applies to | What's required |
|---|---|---|
| 3.3.3 | Issuers and companies that support issuing services | Any stored SAD is encrypted with strong cryptography |
| A3.3.1 | Designated entities under Appendix A3 | Failures of additional critical security controls, such as automated log review mechanisms, are detected, alerted and reported promptly |
Which items take the longest?
Prioritize by lead time, not by requirement number. These usually need budget, tooling, architecture work or vendor cooperation:
- MFA for all CDE access and a compliant MFA configuration (8.4.2, 8.5.1)
- Web application protection (6.4.2)
- Payment page script management and tamper detection (6.4.3, 11.6.1)
- Automated audit log reviews (10.4.1.1)
- Authenticated internal scanning and the backlog it creates (11.3.1.2, 11.3.1.1)
- Removing hard-coded passwords from applications and scripts (8.6.2)
- Replacing disk-level encryption as the sole protection for PAN on non-removable storage (3.5.1.2)
Most of the rest is process and documentation: TRAs, the cryptography and technology reviews (12.3.3, 12.3.4), awareness program updates (12.6.x) and the stored-PAN procedure (12.10.7). These are faster, but they still need time for review and sign-off.
For anything with a recurring cycle, such as six-monthly access reviews under 7.2.4, run the first cycle before March 31, 2025. That way you have evidence ready when the requirement starts counting.
What did v4.0.1 change about these requirements?
The v4.0.1 announcement confirmed there are no new or deleted requirements and no change to the effective date. A few clarifications affect how you read the checklist:
- 8.4.2 now explicitly says non-console access.
- 6.4.3 and 11.6.1 have notes on embedded payment forms. Scripts on your own page are yours to manage, and scripts inside a provider's embedded form are the provider's.
- 11.6.1 now refers to security-impacting HTTP headers and script contents, with "weekly" in place of "once every seven days."
- 12.3.1 applies only to requirements that specify a TRA.
- 3.5.1.1 gained a customized approach objective.
Frequently asked questions
Will the March 31, 2025 date move?
There's no sign of it. Version 4.0.1 left the date unchanged, and the Council continues to urge organizations to adopt the future-dated requirements now.
What if a requirement won't be ready in time?
Without a valid compensating control, it will be assessed as not in place. A compensating control needs a legitimate technical or documented business constraint and a completed compensating controls worksheet, so it isn't a shortcut. Tell your QSA early.
Do SAQ merchants need every item on this list?
No. You're assessed on the requirements in your SAQ. Check which future-dated requirements your SAQ includes and focus there.
Next steps
- Assign an owner and a status to every row that applies to you.
- Start the long-lead technical items first.
- Write the TRAs your environment needs and get them approved.
- Run first cycles of recurring activities before March 31, 2025.
- Confirm with your QSA which version, v4.0 or v4.0.1, your next assessment will use.