PCI DSS 4.0: New multi-factor authentication requirements

Since 2004, the Payment Card Industry's Data Security Standard (PCI DSS) has been the leading standard for protecting payment card data, with the ultimate goal of preventing fraud using stolen cardholder data. The PCI DSS requires organizations that store or process cardholder data to implement a wide array of security measures in the areas of security policies, network security, vulnerability management, and user authentication, among others.

Recently the Payment Card Industry's Security Standards Council (PCI SSC) published version 4.0 of PCI DSS, with enhanced multi-factor authentication (MFA) requirements, which companies need to adhere to by March 31, 2025.

In this blog post, we will explore the MFA requirements in PCI DSS v4.0, including the changes from previous iterations, their significance, and practical tips for organizations to comply with these requirements.

1. Background on PCI DSS

• In 2006, security representatives from five major payment brands (American Express, Discover, JCB International, Mastercard, and Visa) came together to create the "Payment Card Industry Security Standards Council" (PCI SSC). This governing entity is responsible for providing practical resources, managing and establishing standards that protect payment card data, and ensuring the safety of the entire payment ecosystem worldwide.

  The Council designed a global data security industry standard called the Payment Card Industry Data Security Standard (PCI DSS) to ensure companies that accept, process, store or transmit credit card information maintain a secure environment and security controls around cardholder data to reduce payment card fraud.

• All merchants and service providers that process, transmit or store cardholder data must comply with the PCI DSS. This includes merchants who accept debit or credit card payments, and service providers who are directly involved in processing, storing, or transmitting cardholder data on behalf of another entity.
• PCI SSC released the latest iteration of the PCI DSS, version 4.0 in late March 2022, marking a two-year transition period to update security controls to conform to the new version. During the transition period, both v3.2.1 and v4.0 were active. New requirements that are identified as "future-dated" in v4.0 need to be phased in by the end of Q1 2025. After 31 March 2025, all the best practice recommendations become mandatory.

Source: https://blog.pcisecuritystandards.org/updated-pci-dss-v4.0-timeline

One of the key changes in PCI DSS v4.0 focuses on the implementation of MFA to access Cardholder Data Environment (CDE). This is defined as the people, processes, and technology that store, process, or transmit cardholder or sensitive authentication data, and any system that has unrestricted access to system components that store, process, or transmit cardholder /sensitive authentication data. This could have a major impact on industry stakeholders.

2. Definition of multi-factor authentication in PCI DSS

According to PCI SSC, an individual attempting to access a resource must demonstrate their identity through a minimum of two separate forms of authentication before access can be granted. The two forms of authentication must be chosen from the three authentication factors below:

• Something you know: a knowledge factor, such as a password/passphrase, PIN, or secret questions (challenge-response)
• Something you have: Also known as possession factor. Examples are hardware tokens, smart cards, or mobile devices.
• Something you are: Inheritance factor (i.e. biometric characteristics) such as a fingerprint, iris scan, or facial or voice recognition.

Furthermore, the PCI SSC guidelines contain the following key considerations about MFA:

• Geolocation data and time: These factors may be included as additional information in the authentication process to reduce the risk of malicious activity. However, two of the three factors defined above must always be used.
• Independence of authentication factors: All the authentication factors used in MFA should be independent of one another. This means each factor used to verify a user's identity should provide a unique layer of security independent of any other factor. For example, one factor won't grant access to another factor, and the compromise in one factor doesn't affect the security provided by any other factor. For example, using a password will not impact the use of a fingerprint, and the compromise of a PIN number won't affect the security provided by facial recognition.
• Replicating one authentication factor: Using the same authentication factor twice, such as using two different passwords, is not considered MFA.

3. MFA requirements in PCI DSS v3.2.1

Earlier versions of PCI DSS already contained requirements related to MFA. More specifically, in PCI DSS v3.2.1, requirement 8.3 stipulates that MFA needs to be applied in the following cases:

• Remote network access (including for users, administrators, and third parties) that originates outside the company's network
• Non-console administrative access into the CDE

As such, with regard to access to the CDE, PCI DSS v3.2.1 only requires MFA for administrative access, and not for non-administrative access.

4. Enhanced MFA requirements in PCI DSS 4.0

PCI DSS v4.0 includes new evolving requirements on MFA. In particular, it requires MFA for all accounts accessing cardholder data, not just administrators. It also focuses on the secure implementation and configuration of MFA.

Let's take a look in more detail at the new requirements related to MFA:

• Requirement 8.4.2 mandates MFA be implemented for all access into the CDE, not just administrative access. This requirement applies to all types of system components, such as cloud environments, hosted systems, and workstations, servers, and endpoints. The standards acknowledge that it will be challenging and time-consuming for organizations to implement, hence it will be considered a best practice until 31 March 2025.

  The new standard stipulates that MFA is required for both access to the CDE and remote access to the company's network. Therefore, implementing MFA for one type of access does not eliminate the need to apply another instance of MFA for the other. If an individual initially connects to the entity's network via remote access, and then later establishes a connection into the CDE from within the network, the individual needs to authenticate using MFA twice - first when connecting via remote access to the company's network and again when connecting via non-console administrative access from the entity's network into the CDE.

• Requirement 8.5 focuses on the secure implementation and configuration of MFA.
  The standard lists the following key points to consider:
  • Protection against replay attacks: The MFA system should be designed to prevent the unauthorized reuse of an authentication code. In practice, this means that an authentication code should be usable only once.
  • No bypass by users: Users, including administrators, should not be able to bypass the MFA and access CDE data. Exceptions could only be made in exceptional circumstances for a limited period of time, but this requires approval from management and should be well documented.
  • Use of two different authentication factors: The MFA system should require authentication factors taken from at least two different categories, as discussed above.
  • Success of all authentication factors: The MFA system must validate both authentication factors before granting access. For example, if the MFA mechanism consists of a PIN-protected hardware token that generates an authentication code after successful validation of the PIN, both authentication factors are validated if the authentication code is successfully validated.

5. How to comply with the MFA requirements in PCI DSS v4.0

Here are some practical tips that can help organizations to comply with the new MFA requirements:

• Consider phishing-resistant and passwordless MFA. The PCI SSC's definition of MFA remains relatively classic. It does not refer (yet) to more advanced properties of MFA mechanisms, such as phishing resistance or passwordless authentication. Nevertheless, MFA mechanisms with these properties offer higher security and better user convenience and should therefore be considered by companies updating their MFA mechanisms.

  Phishing resistance ensures the authentication code generated by the MFA mechanism can only be used with the intended application and can therefore not be stolen via a phishing website. Passwordless authentication avoids the use of knowledge-based authentication factors that are validated server-side (e.g. passwords), which are subject to phishing and may be hard to manage.

• Ensure MFA implementation for all accounts. Every user should have a unique ID so all actions can be traced back to them. Organizations should also implement MFA for all access to the CDE to prevent anyone from gaining access using just one authentication factor. Organizations may examine their network and/or system configurations to verify MFA is implemented for all access into the CDE, and for remote access servers and systems to verify MFA is enabled following all elements specified in requirement 8.4.2 of the V4.
• Monitor audit logs. Monitor MFA usage and audit logs regularly to detect any unauthorized access attempts or anomalies. Keep track and maintain a list of personnel/users logging in to the CDE or connecting remotely to the network.
• Adhere to local rules and regulations. Organizations should be aware of legislation that imposes requirements related to MFA. For example, the European Network and Information Security directive (NIS2) requires organizations that meet certain size requirements in certain critical business sectors to implement MFA for access to privileged accounts and assets. Similarly, the European Digital Operational Resilience Act (DORA) imposes strong authentication requirements for employees of companies active in the financial services sector, as well as their ICT service providers. PCI SSC advises organizations to consider the potential impact of local laws and regulations on their MFA implementations. PCI DSS requirements for multi-factor authentication do not override local or regional laws, government regulations, or other legal requirements.

6. Conclusion

Compliance with PCI DSS is vital for organizations that handle payment card transactions. With the release of PCI DSS 4.0, there are significant updates, especially relating to MFA. PCI SSC has broadened the scope of MFA requirements for all accounts accessing cardholder data and is mandating its implementation. Although these new MFA requirements remain best practice until 31 March 2025, the clock is ticking.

Public link

Please use the above public link if you want to share this noodl on another website.