Learn how to comply with PCI DSS 4.0 Requirement 8, focusing on multi-factor authentication (MFA) and password management.
Complying with PCI DSS Requirement 8 deals with passwords and password management. This requirement is all about having unique, difficult-to-discover account information. Part of securing your account information is enabling multi-factor authentication (MFA).
Multi-factor authentication (or more commonly known as 2FA, two factor authentication) is an effective way to secure your CDE, and is a requirement under PCI DSS. When multi-factor authentication is properly enforced, you must provide at least two of these three categories of credentials to authenticate:
Your authentication mechanisms should be out-of-band and independent of each other. There should be a physical separation between mechanisms, so that access to one factor does not grant access to another, and if one factor is compromised, it does not affect the integrity and confidentiality of any other factor.
Additionally, make sure that you “incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network."
This diversity of required credentials greatly reduces the risk of unauthorized access to your secure environments.
While MFA is not new to the PCI standard, there have been some updates to the latest version.
Multi-factor authentication will be required for all access to the CDE, not just from external locations. This applies to internal administrative access to servers, firewalls, networking gear, etc. Note that MFA will not apply if you are standing in front of a physical server in a data center and logging in to that keyboard . . . in that case the second factor is your physical presence at the console).
Requirement 8.5.1 (March 31, 2025)
PCI DSS 4.0 added a new detail to MFA requirements that might be a bit tricky. Success of all the factors has to happen before authentication, and it can’t be known from the process which factor has failed.
Presently, most systems ask for a username and password (i.e., something you know) and only move on to the second factor if you have the correct username/password. This will no longer be allowed.
Both factors will have to be presented and entered without revealing any information about which factor might have been wrong if authentication fails. This may require checking with your MFA solution provider to find out if it can be configured to authenticate in this pattern or you may have to switch solutions. It is expected that many MFA solutions providers will be making modifications in the near future to help their clients meet this requirement.
In version 4.0.1, you either have to change your password every 90 days or you have to have some other form of authentication other than just a username and password, in other words an MFA solution.
This means that if you have already implemented multi-factor authentication (MFA) in your environment (e.g., logging in to your ecommerce server even from behind your firewall), you don't have to change passwords every 90 days in version 4.0.1.
Mostly what these requirement changes are trying to do is increase your authentication security on all systems within the CDE.
Here’s a list of applications that should use multi-factor authentication:
Remember, multi-factor authentication is an additional layer of security you should apply to all of your sensitive data.
The PCI SSC guidance document gives examples of some commonly used MFA solutions. Some are better than others. But there are many more methods and configurations. You can work with your QSA to find the best solution for your organization.
If you use this method, make sure the software token is embedded carefully. It can’t be moved to another physical device. Protect that physical device and maintain proof of possession by the user.
This is an example of a poor MFA solution because it does not provide independence between the two authentication factors. Password B came from a password vault stored on the device, not from memory. So, password A provides access to two factors.
System security should not be based solely on the complexity of a username and password, and no password should be considered uncrackable. That’s why multi-factor authentication (MFA) is an effective solution to secure remote access and is a requirement under the PCI DSS.
If a remote access application configuration only requires a username and password to access sensitive data or systems and devices that store, process, or transmit cardholder data, the application has been configured insecurely.
Remember PCI DSS is a protection for your business and is intended to keep you safe from threat actors. It can help you frame PCI compliance as a positive experience instead of a checklist item.
You will need to be compliant with all future dated PCI DSS 4.0.1 requirements by March 31, 2025 . . . time is running out.
.svg)
