Back to Resources | Blogs

PCI DSS Future-Dated Controls: 7 Critical Changes that Will Shape Your Security Strategy

February 7, 2025 | PCI DSS

New cybersecurity requirements are fast approaching for organizations that process payment card transactions.

In 2022, the PCI Security Standards Council (SSC) introduced PCI DSS 4.0 (now 4.0.1), a major update to the framework that expanded the list of mandatory security controls and introduced greater flexibility for businesses that must comply. Among the most impactful changes are 51 “future-dated” controls designed to address emerging threats in the payment industry, including phishing, e-commerce fraud, and skimming attacks.

These future-dated controls will become mandatory after March 31, 2025. Here are some of the most impactful changes that you need to know about before the deadline:

Revised Password Policy and Configuration Requirements

Increased Password Length (Requirement 8.3.6)

Minimum password length requirements are increasing to 12 characters in the latest version of PCI DSS; however, if the associated system does not support this 12-character requirement, then they must be at least eight characters. Passwords must also be unique, complex, and rotated periodically in accordance with previously defined PCI DSS requirements.

Password and Password-less Authentication (Requirements 8.4.2 & 8.5.1)

The latest version of PCI DSS strengthens password security by supporting password-less authentication in addition to traditional password-based methods. This comes after NIST recently supplemented publication 800-63B, approving properly implemented passkeys as AAL2-compliant, meaning they are recognized as a phishing-resistant form of multi-factor authentication (MFA). Organizations can now implement authentication methods such as Windows Hello, Google Passkeys, and Mac equivalents, as well as through cloud hosting providers (e.g., Google Cloud Platform) that integrate these tools for secure MFA access. 

If your organization does decide to go “password-less,” then you are no longer required to adhere to the following requirements:

Requirements 8.3.5, 8.3.6, 8.3.7, & 8.3.9: These requirements cover initial password reset after first login, minimum password length, restricted use of previously used passwords, and password rotations, respectively.

Application and System Account Passwords (Requirements 8.6.2 & 8.6.3)

Organizations must ensure that passwords used for application and system accounts are not hard-coded into scripts, configuration or property files, or bespoke or custom source code. Instead, organizations should opt to use password vaults or other means of automated credential management and protection, including those offered by popular cloud service providers. This requirement aims to prevent unauthorized use of application and system accounts with escalated privileges, especially those with interactive login capabilities.

Additionally, organizations are required to enforce password complexity and password rotation frequencies as defined by their Targeted Risk Analysis (TRA). The TRA is one of the most sweeping and cumbersome future-dated changes to PCI DSS. 

Updated Rules Surrounding MFA 

MFA Access into the CDE (Requirement 8.4.2) 

MFA must be implemented for all access to the cardholder data environment (CDE), including:

  • Administrators, users, and third parties accessing CDE systems.
  • Remote access and console-based access to environments handling payment card data.

This may sound like second nature given the current cybersecurity landscape and existing PCI DSS requirements, including 8.4.1 and 8.4.3. However, it is important to note that these standing requirements only cover non-console CDE access for administrators, and remote access that could impact the security of the CDE, respectively. Requirement 8.4.2 can best be thought of as the next logical step from 8.4.1, in that all non-console access into the CDE requires MFA, irrespective of user or admin status and regardless of in-network or out-of-network connectivity.

MFA System Standards (Requirement 8.5.1) 

It is now required that MFA system capabilities be assessed to ensure:

  • They are not susceptible to replay attacks;
  • They cannot be bypassed by any users, including admins, unless specifically documented and approved on a per-instance basis, for a limited time period;
  • At least two different authentication factors are used (something you know, something you have, and/or something you are); and,
  • Success of all authentication factors is required before access is granted.

For many organizations, these items will already be satisfied by an off-the-shelf MFA system; however, your organization must still do its due diligence and ensure the above requirements are met.

Enhanced Security for Payment Pages

Script Security (Requirement 6.4.3)

Organizations with payment pages or portals are now required to enforce the security and integrity of their payment pages. Specifically, scripts loaded and executed in a consumer’s browser must be authorized and their integrity assured. Additionally, an inventory of relevant scripts must be maintained, along with justification as to why each is necessary.

Payment Page Tamper-Detection (Requirement 11.6.1)

Organizations must also implement a change- and tamper-detection mechanism on all payment pages that operates at least weekly (or periodically, as defined in their TRA). These are intended to alert personnel of unauthorized modifications to payment pages, including HTTP headers and script contents. Common methods of ensuring payment page security and integrity are:

  • Content Security Policies (CSPs) to prevent unauthorized scripts from executing on payment pages, reducing risks such as cross-site scripting (XSS).
  • Subresource Integrity (SRI) to ensure that externally loaded scripts (e.g., JavaScript libraries) have not been modified or tampered with before execution.

What This Means For Your Organization

With PCI DSS now on version 4.0.1, time is running out for organizations to ensure compliance with the new standards. If you are required to comply, you must implement these new requirements by March 31, 2025, regardless of the timing of your annual audits.

However, not all of the future-dated controls are applicable to all organizations. PCI DSS 4.0 also introduced a new, customized method of meeting the framework’s requirements that allows organizations to adjust their implementation process to fit their unique control environment. During a PCI DSS assessment, a Qualified Security Assessor (QSA) will validate that your customized controls meet PCI DSS requirements by reviewing your organization’s unique documented approach and developing a procedure for validating the controls.

Whether you’re just beginning your PCI DSS journey or preparing for the transition to 4.0.1, BARR Advisory can help you assess your current security posture, implement required controls, and ensure full compliance before the March deadline. Contact us today to get started.

Let's Talk