The New Multi-Factor Authentication Requirements in PCI DSS 4.0

In the film classic, Indiana Jones and the Raiders of the Lost Ark, our hero Indy tries to beat the booby trap security in a cave to steal a golden idol. He thinks he’s won when he switches the idol for a similarly sized bag of sand, but then finds he has to navigate flying darts, a dropping wall, and a chasm before he’s through.

When you think about it, Indiana Jones had to beat multi-factor authentication (MFA).

But even if he did, he’s fictional. Here in the real world, some heroic archaeologist and professor wouldn’t beat you, because your organization is better equipped than a dank Peruvian temple. Or at least, you’d better be with the advent of PCI DSS v4.0.

In this seismic new update for the flagship payment security standard, many requirements have changed or been added to accommodate for changes in technology, improved clarity, and strengthened objectives—that includes some that address MFA.

In short, everyone has to implement MFA going forward under the standard.

It may seem like a big step, but in this article, we will examine what the PCI Security Standards Council (SSC) considers to be valid MFA, what version 3.2.1 previously required, and how that compares to the new and expanded 4.0 requirements.

That way, you’ll conquer these updates ahead of your first PCI DSS v4.0 assessment just as successfully as Indiana Jones was in pilfering that idol.

What is Multi-Factor Authentication?

First, let’s define MFA. The SSC has issued a very clear and helpful information supplement regarding what should be acceptable as MFA. To summarize, here are the three acceptable factors, of which your solution must include 2 or more:

• Something you know. This could be a username, a password, a passphrase, a pin, or a combination of any of those elements.
  Something you have. Usually, this is something like a smart card, a physical or logical security token, or a one-time password (OTP) generated by a smartphone app. These components are complemented by another cryptographic element such as a certificate or key that’s actually on your device.
  Something you are. This includes biometric data such as a fingerprint, retina scan, palm print, iris scans, or any other factor that is inherent and unique to an individual.

For any of these three factors to be usable in your MFA solution, they must be independent of each other. Meaning that each cannot depend on access to any other factor so that should one become compromised, the breach wouldn’t affect the integrity or confidentiality of any other factor.

Here’s a practical example of MFA. Say you used your smartphone to generate an OTP that you used to access a laptop in conjunction with a username and password. If the OTP became compromised, it wouldn’t lead directly to access to the laptop if the attacker didn’t also have those credentials.

Multi-Factor Authentication in PCI DSS v3.2.1

When it comes to MFA in payment security, you’re likely used to it only being required in these cases:

• For all remote network access that originates outside your network; and
• For all non-console administrative access into the cardholder data environment (CDE).

These requirements are described within Requirement 8.3 of PCI DSS 3.2.1, but as we mentioned before, things are changing.

Multi-Factor Authentication Changes in PCI DSS v4.0

In PCI DSS version 4.0, those two requirements remain in effect, but there are some significant differences:

• The requirement for MFA for access to the CDE will extend beyond just administrators to secure all access to the CDE.
  • As described in Requirement 8.4.2., applying MFA to remote access will not replace the need to apply MFA to another request for CDE access that does originate from within the same network. In such a scenario, MFA must challenge users twice.
  • All users requiring access to the CDE must now be challenged with MFA.
  • Not only that but they must be challenged every time they attempt to access the CDE. As per the applicability statement in Requirement 8.4.2, this will be formidable and time-consuming to implement, so this remains a best practice until March 31, 2025.
• Similarly, Requirement 8.4.2 also no longer limits the scope of MFA to only non-console access.” If every user must be repeatedly challenged for CDE access every time, they will also need to be challenged in more places. Now, you’ll need to get MFA into place for all types of system components, including:
  • Cloud environments,
  • Hosted systems,
  • On-premises applications,
  • Network security devices,
  • Workstations,
  • Servers, and
  • Endpoints.

You’ll also need to implement MFA into anything that can be used to gain direct access to your networks or systems as well as any web-based access applications. Requirement 8.4.3 specifically says that all access originating from outside your network must include MFA and explicitly includes administrative, non-administrative, and all third-party or vendor remote access.

Given these unambiguous scope definitions and the overall serious departure from v3.2.1, it will take some work to confirm your previous MFA configurations and access entitlements are validated to ensure that all remote user access complies with this updated requirement. 

How to Configure MFA Under PCI DSS v4.0’s New Requirement 8.5

But the new standard didn’t stop with just those two significant expansions. In a brand new requirement—8.5—it is now mandated that all MFA systems that grant CDE access must be configured correctly to prevent misuse.

This is so weaknesses, vulnerabilities, and potential misconfigurations of your MFA solution itself can be identified. As such, here are four characteristics of your solution that your assessor will validate. 

1. Your MFA Solution Must Not Be Susceptible to Replay Attacks.

If a valid user sends a message to a legitimate target, they expect to receive information back. But in a replay attack, an attacker intercepts this message, sends it to the target, and receives the information intended for the user.

If this legitimate target is an authentication service, that would mean that the attacker would be incorrectly authenticated and given access. Requirement 8.5 now mandates that your MFA solution disrupt this attack method, which usually occurs either through direct interception or means of spoofing the identity of the target.

2. Your MFA Solution Must Not Allow Any Bypass Unless Specific Exception is Granted by Management.

To comply with Requirement 8.5, your MFA must not allow bypass. There are several common ways attackers manage this:

• They install a malicious application on your user’s device and continue using that application after the legitimate user has authenticated.
• They re-route or intercept the SMS message generated by your user and use the MFA code within to authenticate.
• They might leverage session re-use, as Many MFA solutions include a “Remember me on this device for 30 days” feature. If enabled, this kind of attack becomes a possibility.

3. Your MFA Solution Must Use At Least Two Different Factors for Authentication. 

As we agreed earlier, there are three possible authentication options—something you know, something you have, or something you are.

Rather than rehash that, let’s clear up a common misconception. Some believe that if two different passwords are used, or if two different possession factors are used, the solution is offering MFA—that’s not the case, as is explicitly addressed by the Council in the Guidance associated with Requirement 8.5.

Your MFA solution must use at least two independent factors to comply with Requirement 8.5.

4. Your MFA Solution Must Not Grant Access Unless All Required Authentication Factors are Successful.

Similarly, if the user attempting to authenticate does not provide the correct second factor, there should be no option for that user to gain access.  

If they can, your MFA solution will not comply.

Next Steps in Your Transition to PCI DSS v4.0

The expansion and addition of requirements regarding multi-factor authentication may make it seem like you’ll need to pull an Indiana Jones trying to consider all the booby traps ahead. But having read through this breakdown, you now understand how to evaluate your current MFA solutions to ensure their future compliance.

As your organization begins planning the transition to PCI DSS 4.0, it will be critical to consider all the new and changed requirements and their timelines for implementation. To help facilitate your adaptation, read our other articles that de-mystify other elements within the new standard:

• How to Define Time in PCI DSS v4.0
• Decrypting Cryptographic Requirements in PCI DSS v4.0
• How to Keep Legacy Systems Compliant under PCI DSS v4.0

We will continue to publish new content so we may deconstruct this standard as much as possible for you. But if you’d prefer, please feel free to contact us directly with any questions you may have so that we can have a conversation to address your specific concerns.