PCI DSS 4.0 – Major Future-Dated Requirements

Part 4 of the PCI DSS 4.0 Launch Series

The content of this blog is based solely on the PCI Data Security Standard (DSS) version 4.0 and related validation documents and does not incorporate any additional clarification/guidance provided by the PCI Security Standards Council (SSC) after the date of this blog.

In addition to the new requirements that are effective immediately in PCI DSS 4.0, there is a long list of additional requirements that become effective on March 31, 2025 – one year after version 3.2.1 is fully retired.  These requirements need to be reviewed immediately, as they represent significant additional effort and investment for assessed entities; corresponding changes to in-scope environments in preparation for 4.0 certification need to accommodate these requirements and may take significant time to implement.  However, many of these requirements are modern cyber security best practices anyway and address other risks, in addition to fulfilling compliance requirements.

• Disk-level encryption will no longer qualify as encryption at rest, except on removable electronic media (Req. 3.5.1.2).
• Certificates used for transmitting PAN over open, public networks must be valid and not expired or revoked (Req. 4.2.1).
• Additional inventories must be developed maintained for trusted keys and certificates (Req. 4.2.1.1); bespoke/custom software, including third-party components (Req. 6.3.2); payment page scripts (Req 6.4.3); and cipher suites/protocols (Req. 12.3.3).
• All in-scope systems must be periodically evaluated to determine susceptibility to malware (Req. 5.2.3.1).  (See our prior blog regarding the definition of “periodically” in Version 4.0.)
• Removable media must be scanned or continuously analyzed for the presence of malware (Req. 5.3.3).
• Processes and automated mechanisms to protect against phishing must be implemented (Req. 5.4.1).
• Public-facing Web applications must be protected by an automated technical solution, such as a Web application firewall; manual application review will no longer be allowed (Req. 6.4.2).
• Payment page scripts must be managed to ensure authorization and integrity (Req. 6.4.3).
• User accounts must be reviewed at least every six months (Req. 7.2.4).  Application and system accounts are now addressed separately and must be reviewed periodically (Req. 7.2.5).
• Where passwords are used:

• The minimum password length is twelve (12) characters UNLESS the system does not support 12-character lengths, in which case the minimum length is eight (8) characters (Req. 8.3.6).
• Passwords cannot be hard-coded (Req. 8.6.2).
• Application and system account passwords must be changed periodically (Req. 8.6.3).

• Multi-factor authentication (MFA) is required for ALL access into the CDE (req. 8.4.2).  MFA for remote access terminating outside the CDE will not fulfill this requirement.
• Additional conditions are attached to accounts that are used by system or applications AND can be used for interactive login (Req. 8.6.1).
• Identified vulnerabilities not ranked as high-risk or critical must still be “addressed” according to the Req. 12.3.1 risk analysis (Req. 11.3.1.1).
• Internal vulnerability scans must be authenticated (Req. 11.3.1.2).
• A change/tamper mechanism must be deployed to prevent unauthorized modification of HTTP headers and the contents of payment pages (Req. 11.6.1).
• Cryptographic suites and protocols in use must be formally reviewed annually and must include “active monitoring” of industry cryptography trends (Req. 12.3.3).
• All hardware and software technologies in use must be formally reviewed annually to ensure the technologies are effective and not “end of life” (Req. 12.3.4).
• The security awareness program must be reviewed and updated annually and address phishing, social engineering, and acceptable use of end-user technologies (Req. 12.6.2).
• The incident response plan must specifically address incidents where PAN is found outside expected/authorized locations (Req. 12.10.7).

On top of all this, there are four additional future-dated requirements for service providers as well. The overhaul of the DSS resulted in a significant redo of the Report on Compliance (ROC) as well.  In our final entry of this blog series, we’ll take a look at the changes to the ROC template and their impact on PCI assessments.