Overview
The 51 future-dated requirements in PCI DSS 4 are becoming mandatory on 31st March 2025. Some of these requirements only apply to service providers and some may not apply to all entities, especially those using specific Self-Assessment Questionnaires (SAQs).
Although some of these requirements may already be in place at an entity, some may not and may require significant work. The key new requirements, which each have their own detailed requirements, are as follows:
- Inventories of certificates and keys (4.2.1.1), bespoke software and software components (6.3.2), and cryptographic cipher suites (12.3.3)
- Web Application Firewall on public facing web applications (6.4.2)
- Payment page script management and change detection (6.4.3 and 11.6.1)
- Management, review and password requirements for application and system accounts (7.2.5, 7.2.5.1, 8.6.1, and 8.6.3)
- Additional MFA requirements (8.4.2, 8.5.1)
- No hard coded passwords in scripts or configuration files (8.6.2)
- Automated audit log reviews (10.4.1.1)
- Detection of and response to failures of critical security control systems (10.7.1 and 10.7.3)
- Authenticated internal vulnerability scans (11.3.1.2)
- Targeted Risk Analysis (TRA) for several requirements (12.3.1)
- Security awareness program includes phishing, social engineering and acceptable use of technologies, and the program is reviewed annually (12.6.2, 12.6.3.1, and 12.6.3.2)
You can of course take the Customized Approach for most of the requirements, however that still requires significant work.
List of Future Dated PCI DSS 4 Requirements
Specific future-dated requirements are listed as follows. Please read the guidance column and applicability notes for each requirement in PCI DSS 4, which provide more context. The future dated requirements for Appendix A are not included in the following list of requirements, as they do not apply to most entities.
3.3.2 Encrypt SAD Stored Prior to Authorization
Sensitive Authentication Data (SAD) that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
This also applies to issuers who may store SAD (requirement 3.3.3).
3.4.2 Prevent Copying of PANs via Remote Access
When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need.
3.5.1.1 Keyed Hashes of PANs
Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.
Any hashed PANs must now use randomly generated secret keys using an appropriate keyed cryptographic hashing algorithms including but are not limited to HMAC, CMAC, and GMAC, with an effective cryptographic strength of at least 128-bits.
3.5.1.2 No Reliance on Disk Encryption for Non-Removable Disks
If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows: on removable electronic media or if used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.
3.6.1.1 Prevent Use of Same Cryptographic Keys in Production and Test Environments.
Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes […] preventing the use of the same cryptographic keys in production and test environments […].
4.2.1 Certificates on Public Networks are Valid and Not Expired or Revoked
Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: […] certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked […].
This requires that certificates that are not valid are rejected, as per the Certificate Revocation List (CRL) and the Online Certificate Status Protocol (OCSP).
4.2.1.1 Inventory of Keys and Certificates
An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.
The guidance states that an inventory of trusted keys helps the entity keep track of the algorithms, protocols, key strength, key custodians, and key expiry dates.
5.2.3.1 Targeted Risk Analysis for System Components Not at Risk of Malware
The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
5.3.2.1 Targeted Risk Analysis for Frequency of Malware Scans
If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1
5.3.3 Malware scans or analysis on Removable Electronic Media
For removable electronic media, the anti-malware solution(s): performs automatic scans of when the media is inserted, connected, or logically mounted, or performs continuous behavioural analysis of systems or processes when the media is inserted, connected, or logically mounted.
This applies to removable media, so an effective control can be to prevent removable media from being used through an enforced technical control.
5.4.1 Protection Against Phishing Attacks
Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.
The mechanisms may include technical controls on the entity’s email system and phishing protection as part of anti-malware.
6.3.2 Inventory of Bespoke and Custom Software and Software Components
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
This can be facilitated by using third-party software component management tools that are commonly used to identify and update third-party software components.
6.4.2 Protect Public-Facing Web Applications with WAF
For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks; actively running and up to date as applicable; generating audit logs; configured to either block web-based attacks or generate an alert that is immediately investigated.
In practice this is commonly a web application firewall (WAF). The 6.4.1 choice of an application vulnerability scan is no longer an option.
6.4.3 Payment Page Scripts Management
All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: a method is implemented to confirm that each script is authorized; a method is implemented to assure the integrity of each script; an inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
This requirement is discussed in more detail in another Dionach blog: https://www.dionach.com/pci-dss-4-requirements-for-code-and-payment-pages/.
7.2.4 User Account Access Reviews Every 6 Months
All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: at least once every six months; to ensure user accounts and access remain appropriate based on job function; any inappropriate access is addressed; management acknowledges that access remains appropriate.
7.2.5 Application and System Accounts are Managed
All application and system accounts and related access privileges are assigned and managed as follows: based on the least privileges necessary for the operability of the system or application; access is limited to the systems, applications, or processes that specifically require their use.
7.2.5.1 Application and System Accounts are Periodically Reviewed
All access by application and system accounts and related access privileges are reviewed as follows: periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1); the application/system access remains appropriate for the function being performed; any inappropriate access is addressed; management acknowledges that access remains appropriate.
8.3.6 Passwords Must Have Minimum Length of 12 Characters
If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: a minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters); contain both numeric and alphabetic characters.
8.3.10.1 Customers of Service Providers with Single Factor Passwords Change Passwords Every 90 Days
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either: passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analysed, and real-time access to resources is automatically determined accordingly.
It may be better to enforce MFA on customer accounts.
8.4.2 MFA for Non-Console CDE Access
MFA is implemented for all non-console access into the Cardholder Data Environment (CDE).
8.5.1 MFA System Requirements Prevent Replay and Bypass
MFA systems are implemented as follows: the MFA system is not susceptible to replay attacks; MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period; at least two different types of authentication factors are used; success of all authentication factors is required before access is granted.
Commonly used MFA systems such as YubiKeys and TOTP with authenticator apps should support these requirements.
8.6.1 System or Application Accounts Limit Interactive Login
8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows: interactive use is prevented unless needed for an exceptional circumstance; interactive use is limited to the time needed for the exceptional circumstance; business justification for interactive use is documented; interactive use is explicitly approved by management; individual user identity is confirmed before access to account is granted; every action taken is attributable to an individual user.
If possible, ensure that any systems or application accounts cannot be logged in interactively.
8.6.2 No Hard Coded Passwords in Scripts or Configuration Files
Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.
There are source code repository tools that can identify potential hard coded passwords in files.
8.6.3 Passwords are Changed Periodically for Application and System Accounts
Passwords/passphrases for any application and system accounts are protected against misuse as follows: passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise; passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.
If you use cloud service providers, then use of built-in or service accounts from cloud service providers, where passwords are never known or controlled by the entity, may help with this requirement.
9.5.1.2.1 Targeted Risk Analysis for Periodic POI Device Inspections
The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
10.4.1.1 Automated Audit Log Reviews
Automated mechanisms are used to perform audit log reviews.
Audit log reviews can no longer be just a manual process.
10.4.2.1 Targeted Risk Analysis for Periodic Log Reviews for All Other System Components
The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
10.7.2 Detection of Failures of Critical Security Control Systems
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: network security controls; IDS/IPS; change-detection mechanisms; anti-malware solutions; physical access controls; logical access controls; audit logging mechanisms; segmentation controls (if used); audit log review mechanisms; automated security testing tools (if used).
As with 10.7.3, this is now a requirement for all entities, not just service providers.
10.7.3 Response to Failures of Critical Security Control Systems
Failures of any critical security control systems are responded to promptly, including but not limited to: restoring security functions; identifying and documenting the duration (date and time from start to end) of the security failure; identifying and documenting the cause(s) of failure and documenting required remediation; identifying and addressing any security issues that arose during the failure; determining whether further actions are required as a result of the security failure; implementing controls to prevent the cause of failure from reoccurring; resuming monitoring of security controls.
As with 10.7.2, this is now a requirement for all entities, not just service providers.
11.3.1.1 Targeted Risk Analysis for Vulnerabilities Not Ranked as Higher Risk
All other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows: addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1; rescans are conducted as needed.
11.3.1.2 Authenticated Internal Vulnerability Scans
Internal vulnerability scans are performed via authenticated scanning as follows: systems that are unable to accept credentials for authenticated scanning are documented; sufficient privileges are used for those systems that accept credentials for scanning; if accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2.
This is commonly addressed using scanning agents installed on each system component where the operating systems support scanning agents.
11.4.7 Multi-Tenant Service Providers Allow External Penetration Tests
Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing as per requirements 11.4.3 and 11.4.4.
11.5.1.1 IDS/IPS for Service Providers Detect Covert Malware Communication Channels
Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.
11.6.1 Payment Pages Change- and Tamper-Detection Mechanism
A change- and tamper-detection mechanism is deployed as follows: to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser; the mechanism is configured to evaluate the received HTTP headers and payment pages; the mechanism functions are performed as follows: at least weekly or periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
This requirement is discussed in more detail in another Dionach blog: https://www.dionach.com/pci-dss-4-requirements-for-code-and-payment-pages/.
12.3.1 Targeted Risk Analysis for Applicable Requirements
For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented and includes: identification of the assets being protected; identification of the threat(s) that the requirement is protecting against; identification of factors that contribute to the likelihood and/or impact of a threat being realized; resulting analysis that determines, and includes justification for, how the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact of the threat being realized; review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed; performance of updated risk analyses when needed, as determined by the annual review.
Refer to the following documents on the PCI SSC website: Information Supplement: TRA Guidance; Sample Template: TRA for Activity Frequency.
12.3.3 Inventory of All Cryptographic Cipher Suites and Protocols in Use
Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following: an up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used; active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use; documentation of a plan, to respond to anticipated changes in cryptographic vulnerabilities.
12.3.4 Plan for End-of-Life Hardware and Software
Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following; analysis that the technologies continue to receive security fixes from vendors promptly; analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance; documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology; documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans.
12.5.2.1 Service Providers Must Validate PCI DSS scope Every 6 Months
Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2.
12.5.3 Service Providers Must Review Impact of Significant Changes
Additional requirement for service providers only: significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.
12.6.2 Annual Review of Security Awareness Program
The security awareness program is reviewed at least once every 12 months, and updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s cardholder data and/or sensitive authentication data, or the information provided to personnel about their role in protecting cardholder data.
12.6.3.1 Security Awareness Training Includes Phishing and Social Engineering Training
Security awareness training includes awareness of threats and vulnerabilities that could impact the security of cardholder data and/or sensitive authentication data, including but not limited to phishing and related attacks, and social engineering.
Most organisations already have these types of training in their security awareness program.
12.6.3.2 Security Awareness Training Includes Acceptable Use of End-User Technologies
Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1.
Most organizations have an acceptable use policy, however specific security awareness training content needs to include this requirement.
12.10.4.1 Targeted Risk Analysis for Periodic Training for Incident Response
The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
12.10.5 Security Incident Response Plan Includes Change-And Tamper-Detection Mechanism for Payment Pages
The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to: […] The change-and tamper-detection mechanism for payment pages. […].
This relates to requirement 11.6.1.
12.10.7 Incident Response Procedures for Unexpected PAN Storage
Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include: determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable; identifying whether sensitive authentication data is stored with PAN; determining where the account data came from and how it ended up where it was not expected; remediating data leaks or process gaps that resulted in the account data being where it was not expected.
Summary
Some of the future-dated requirements need further policies, procedures and records, which may be more straightforward than the requirements needing further technical controls. The technical controls may require significant work, and so entities should focus on those.
For assistance and advice with becoming compliant with the new controls, contact Dionach. Dionach have QSAs that can provide expert help.