Speak to an Expert Emergency

PCI DSS v4 Future-Dated April 2025 Requirements: 6 Months to Go

Days
Hours
Minutes
Seconds

Are you Ready for the Requirements of PCI DSS v4 Next Year?

The PCI DSS version 4 update, released in 2022, introduced a series of enhancements to ensure that organisations handling cardholder data maintain robust security practices. While many of the changes were clarifications or reordering of existing requirements, several “future-dated” requirements were added that will become mandatory after 31st March 2025. These future-dated requirements will be included in PCI DSS assessments after this date, and organisations must understand how this affects them well before their annual assessment.

Blackfoot has extensive experience as a PCI DSS QSA company. We provide our customers with consultancy and auditing services to help them achieve and maintain compliance with the PCI DSS. We have completed many assessments using version 4 of the standard and are assisting organisations in preparing for the changes coming in 2025. This post will explain these additional requirements, why they matter, and how you can start preparing today.

Why Future-Dated Requirements Matter

The new requirements matter because, as with all PCI DSS requirements, they help protect against common threats that result in cardholder data breaches. PCI DSS version 4 addresses threats that were less common when the previous version, 3.2.1, was released in 2018.

Version 4 was released in 2022 and contained two sets of future-dated requirements. The first batch of new requirements applied from April 2024, with more coming in 2025. The 31st March 2025 deadline marks a shift in PCI DSS compliance, with all changes introduced in the release of version 4 finally coming into effect after that date.

The PCI SSC clearly understood that the changes in version 4 would take time to adopt, which is consistent with previous updates to the standard, where the SSC also provided generous transition timelines. Businesses that have been proactive and implemented these practices already will have a smoother journey beyond March 2025; however, many organisations have been slow to act and may face compliance issues if new requirements aren’t addressed soon.

Broadly speaking, the 2024 requirements were straightforward and should already be in place for any compliant organisation. An additional year was provided to address the more complex requirements, which may involve infrastructure changes and financial investments and necessitate a more phased approach to ensure compliance.

Summary of Future-Dated Requirements

It may be generous to describe this as a “quick summary” because there are so many changes to work through. The details below are summaries of these changes, and as always, a QSA and the PCI DSS itself should be referred to for comprehensive information.

For organisations that complete a reduced assessment based on SAQ criteria, here is a breakdown of the future dated requirement changes per SAQ. This will enable you to focus on the changes that will impact your audits:

  • SAQ A MOTO – 3.2.1
  • SAQ A MOTO and eCommerce  – 3.2.1, 6.4.3, 8.3.6, 11.6.1
  • SAQ A Commerce only – 6.4.3 and 11.6.1
  • SAQ A-EP – 3.2.1, 4.2.1, 5.2.3.1, 5.3.2.1, 5.3.3, 5.4.1, 6.3.2, 6.4.2, 6.4.3, 7.2.4, 7.2.5, 8.3.6, 8.4.2, 8.5.1, 8.6.1, 8.6.2, 8.6.3, 10.4.1.1, 10.4.2.1, 11.6.1, 12.3.1, 12.6.3.1
  • SAQ B – None
  • SAQ B-IP – 4.2.1 only
  • SAQ C-VT – 5.3.3, 5.4.1, 8.3.6, 12.6.3.1
  • SAQ P2PE –3.2.1 only
  • SAQ D – all bar the service provider requirements noted below
  • SAQ D SP – all requirements listed below
 

Here are the requirements that will become active after 31 March 2025:

Data Storage and Encryption (Requirements 3.2, 3.3, 3.4, 3.5, 3.6, 4.2)

3.2.1 – Minimise account data storage

Organisations must implement updated data retention and disposal policies required by version 3.2.1 and extend to cover limiting sensitive authentication data (SAD) storage before authorisation completion.

3.3.2 – Encrypting sensitive authentication data (SAD)

SAD stored electronically before authorisation completion must be encrypted using strong cryptography.

3.3.3 – Issuer requirements for SAD storage

For issuers and companies supporting issuing services, any SAD storage must:

  • Be limited to legitimate business needs.
  • Be encrypted using strong cryptography.

3.4.2 – Prevent copying of PAN with remote access technologies

Technical controls must be implemented to prevent personnel from copying or relocating PAN using remote-access technologies unless explicitly authorised with a legitimate business need.

3.5.1.1 – Keyed hashes for PAN

PAN must be rendered unreadable using keyed cryptographic hashes of the entire PAN, and key management must adhere to PCI DSS Requirements 3.6 and 3.7.

3.5.1.2 – Encryption for disk/partition-level data

If disk or partition-level encryption is used for PAN storage, it must only be on:

  • Removable media, or
  • Non-removable media if another mechanism meeting Requirement 3.5.1 is also used to render PAN unreadable.

3.6.1.1 – Cryptographic architecture (service providers)

Service providers must maintain documentation of their cryptographic architecture, covering:

  • Algorithms, protocols, and keys used, including key strength and expiry.
  • Preventing the use of cryptographic keys in both production and test environments.
  • Key usage for each cryptographic key.
  • An inventory of hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices.

4.2.1 – Safeguard PAN during transmission

Organisations must ensure:

  • Only trusted keys and certificates are used.
  • Certificates are valid, not expired or revoked.
  • Secure versions of protocols are used without fallback to insecure versions.
  • Appropriate encryption strength is used based on the encryption methodology.

4.2.1.1 – Inventory of trusted keys and certificates

An inventory of all trusted keys and certificates used to protect PAN during transmission over open, public networks must be maintained.

System and website protection (Requirements 5.2, 5.3, 5.4, 6.3, 6.4)

5.2.3.1 – Evaluating system components not at risk for malware

The frequency of evaluations for system components identified as not at risk for malware must be defined by the entity’s targeted risk analysis.

5.3.2.1 – Conduct a risk assessment for periodic malware scans

A risk assessment must be conducted for organisations relying on periodic malware scans to meet requirement 5.3.2. This doesn’t apply if continuous behavioural analysis is used.

5.3.3 – Anti-Malware for removable media

The anti-malware solution for removable media must:

  • Perform automatic scans when media is inserted or connected, or
  • Use continuous behavioural analysis when media is inserted.

5.4.1 – Detecting and protecting against phishing attacks

Processes and automated mechanisms must be in place to detect and protect personnel from phishing attacks.

6.3.2 – Inventory of software components

Organisations must maintain a bespoke and custom software inventory, including third-party components, to facilitate vulnerability and patch management.

6.4.2          – Web application attack detection

An automated technical solution must be deployed in front of public-facing web applications to detect and prevent web-based attacks. This solution must be actively running, up to date, and configured to block attacks or generate alerts that are immediately investigated.

6.4.3 – Management of payment page scripts

Payment page scripts that load in consumers’ browsers must be managed with methods to:

  • Authorise each script.
  • Ensure script integrity.
  • Maintain an inventory with a written justification for each script’s necessity.
For more about this requirement, visit our detailed breakdown here. 

Authentication and authorisation (Requirements 7.2, 8.3, 8.4, 8.5, 8.6)

7.2.4 – Review of user accounts and access privileges

User accounts, including those of third parties, must be reviewed every six months to ensure appropriate access privileges based on job function. Inappropriate access must be addressed, and management must acknowledge the appropriateness of access.

7.2.5 – Implement least privilege access for application or system accounts

Any accounts used by applications or systems, rather than assigned to individual users, must be configured with the least privileges necessary for the application or system and prevented from being used for anything else.

7.2.5.1 – Review of application and system accounts

Access for application and system accounts must be reviewed periodically based on a targeted risk analysis to ensure access remains appropriate, with any inappropriate access addressed. Management must acknowledge the appropriateness of access.

8.3.6 – Password complexity

If passwords are used for authentication, they must:

  • Have a minimum of 12 characters (or eight if the system doesn’t support 12).
  • Include both numeric and alphabetic characters.

8.3.10.1 – Service provider password requirements (service providers)

For service providers, if passwords are the sole authentication factor:

  • Passwords must be changed at least every 90 days, or
  • Security posture must be dynamically analysed to determine access in real-time.

8.4.2 – MFA for non-console access

Multi-factor authentication (MFA) must be implemented for all non-console access into the cardholder data environment (CDE).

8.5.1 – MFA implementation

MFA systems must:

  • Be protected from replay attacks.
  • Only be bypassed by users, including administrative users, if specifically authorised for a limited time.
  • Use two different types of authentication factors.
  • Require all factors to be successful before granting access.

8.6.1 – Interactive login for application/system accounts

If application or system accounts can be used for interactive login, access must be controlled, justified, and monitored, and every action must be attributable to an individual user.

8.6.2 – No hard-coded passwords in scripts

Passwords for application and system accounts used for interactive login must not be hard-coded into scripts, configuration files, or custom source code.

8.6.3 – Password management for application/system accounts

Application and system account passwords must be managed by:

  • Periodically changing passwords based on a targeted risk analysis or when compromise is suspected.
  • Constructing passwords with sufficient complexity.

POI devices (Requirement 9.5)

9.5.1.2.1 – Frequency of POI device inspections

The entity’s targeted risk analysis must define the frequency and type of point-of-interaction (POI) device inspections.

Logging, monitoring, and security testing (Requirements 10.4, 10.7, 11.3, 11.4, 11.5, 11.6)

10.4.1.1 – Automated audit log reviews

Automated mechanisms must be used to perform audit log reviews.

10.4.2.1 – Frequency of log reviews

The entity’s targeted risk analysis must define the frequency of log reviews for other system components.

10.7.2 – Prompt detection and response to security control failures

Failures of critical security control systems, such as network security controls, IDS/IPS, anti-malware solutions, or audit logging mechanisms, must be promptly detected and addressed.

10.7.3 – Responding to security control failures

Organisations must have procedures in place to promptly restore security functions, document failure durations, investigate causes, and prevent recurrence.

11.3.1.1 – Management of vulnerabilities

All applicable vulnerabilities (not ranked as high-risk or critical) must be addressed based on a targeted risk analysis, with rescans conducted as necessary.

11.3.1.2 – Authenticated internal vulnerability scans

Internal vulnerability scans must be performed via authenticated scanning, with sufficient privileges granted for systems that accept credentials. Systems unable to accept credentials for authenticated scans must be documented.

11.4.7 – External penetration testing for multi-tenant providers

Multi-tenant service providers must support external penetration testing for their customers.

11.5.1.1 – Covert malware communication detection (service providers)

Service providers must detect and prevent covert malware communication channels through intrusion detection or prevention techniques.

11.6.1 – Tamper-detection for payment pages

A tamper-detection mechanism must be deployed to alert personnel to unauthorised modifications to payment page HTTP headers or scripts. This mechanism must function weekly or at a frequency defined by a targeted risk analysis.

For more about this requirement, visit our detailed breakdown here.

Risk, documentation, and reviews (Requirements 12.3, 12.5, 12.6, 12.10)

12.3.1 – Targeted risk analysis documentation

For each requirement specifying a targeted risk analysis, organisations must document the protected assets, the threats being mitigated, and the analysis results. These analyses must be reviewed annually or when a significant change occurs.

12.3.3 – Cryptographic protocol review

All cryptographic cipher suites and protocols must be documented, monitored, and reviewed at least annually to address anticipated cryptographic vulnerabilities.

12.3.4 – Hardware/software review

Organisations must review hardware and software annually to ensure they receive timely security fixes, support compliance, and have a plan to address any end-of-life technologies.

12.5.2.1 – PCI DSS scope validation (service providers)

Service providers must document and confirm the PCI DSS scope at least every six months or after significant changes in the in-scope environment.

12.5.3 – Documenting organisational structure changes

Significant changes to the organisational structure must result in a documented review of the impact on PCI DSS scope, with results communicated to executive management.

12.6.2 – Security awareness program review

The security awareness program must be reviewed and updated at least annually to address new threats and vulnerabilities.

12.6.3.1 – Security awareness training

Security awareness training must cover threats such as phishing and social engineering.

12.6.3.2 – Acceptable use training

Security awareness training must include the acceptable use of end-user technologies.

12.10.4.1 – Incident response training frequency

The frequency of incident response training must be defined in the entity’s targeted risk analysis.

12.10.5 – Incident response plan for security alerts

The incident response plan must include monitoring and responding to alerts from systems such as IDS/IPS, network security controls, and anti-malware solutions.

12.10.7 – Incident response for stored PAN

Organisations must establish procedures to respond when PAN is detected outside the CDE, including secure deletion, investigation of the source, and remediation of any data leaks.

Preparing for PCI DSS Version 4 Changes in 2025

If any changes explained above apply to your PCI DSS scope, you should prepare for them now. Here are a few practical steps to ensure compliance:

  1. Conduct a gap analysis: Identify which of the future-dated requirements your organisation is not yet compliant with. This will give you a clear picture of the changes you must make before April 2025. Blackfoot can help organisations with structured PCI DSS gap analysis services or ad-hoc support.
  2. Engage with a QSA early: Work with a Qualified Security Assessor (QSA) to get expert guidance on implementing these new requirements effectively. Your QSA can also help determine the applicability of any new requirements and discuss scope-reduction options if the requirements are challenging to implement.
  3. Allocate resources: Whether it’s budget, personnel, or technology, ensure that you have the resources in place to implement the required changes. This could include investing in new security tools, such as anti-phishing software, upgrading your encryption systems, and website changes.
  4. Update policies and procedures: Many new requirements involve implementing or refining policies, such as data retention or incident response. Review your current documentation and make the necessary updates.
  5. Start now: With the deadline approaching, there’s no time to waste. Organisations that wait too long could struggle to meet the requirements at the last minute. If your next assessment is before April 2025, it’s worth considering implementing the new requirements early. Otherwise, it may be 2026 before your QSA first assesses them. By including some or all of these requirements in your next assessment, your QSA can provide assurance that you’ll be prepared in 2026.

Conclusion

The future-dated requirements in PCI DSS version 4 may seem daunting, but they are crucial for maintaining the highest security standards required to protect cardholder data. By implementing these practices now, your organisation will ensure compliance going into 2025 and beyond and strengthen its overall security posture.

Do you need help preparing for PCI DSS v4 changes? Contact us today to discuss how we can help your organisation stay ahead of the curve and ensure a smooth transition to PCI DSS version 4 compliance.

Share this Article:

Related Articles

Cybersecurity
Insights

Cybersecurity Awareness Month

Cybersecurity Awareness month is celebrated annually to raise awareness about the importance of cybersecurity and encourage safer online practices. This article explores the history of cybersecurity, emerging threats, and the significance of celebrating this initiative annually.

Read More
Newsletters

Autumn 2024 Newsletter

In this edition, we delve into the multifaceted world of cybersecurity, the persistent ransomware threat and the latest requirements for e-commerce websites.

Read More

Speak to an Expert

Call us on +44 (0) 203 393 7795

We value what our customers think of us

Get The Latest Industry News

We’ll keep you informed about potential risks and vulnerabilities that could impact your digital assets.