PCI DSS v4.0 and Multi-Factor Authentication

Before we look at these aspects, let’s go back to basics and define MFA.  It is a process where a user is required to provide two or more independent authentication factors before they can gain access to a system, account or application.  The most common form of MFA is based on the principle of something you know and something you have.  Many will be familiar with the 2-stage process of entering a password and then confirming your identity by submitting a one-time code which is only received by your personal mobile.  The purpose of MFA is simply to make it more difficult for attackers to compromise a user's account by increasing the levels of authentication.

‍

‍

What about MFA in relation to PCI DSS?

MFA is nothing new to PCI DSS and has been referred to in numerous earlier versions, however, the scale of references/requirements has changed significantly.  For example, in PCI DSS v3, MFA was only required in two specific situations: for administrative access to the cardholder data environment (CDE) and for remote access to the scope from outside the organisation’s network.  And in practice, most organisations avoided the second requirement by placing a jump box in their corporate network and only allowing remote connections to the PCI scope from the jump box, thereby removing the possibility of remote access from outside their network.

Why are we seeing increased requirements for MFA in v4.0?

There are a couple of factors at play here.  The reason for the more limited use of MFA within earlier versions of the Standard was a practical one, in that it was often difficult and cumbersome to deploy suitable MFA systems.  Now, with the rise of mobile devices and apps for those devices, it has become significantly easier to implement.  The second factor is quite simply that the Payment Card Industry Security Standards Council (PCI SSC) has introduced more MFA requirements to better protect against security threats and prevent data breaches.  The increased use of cloud services and the rise in online transactions, combined with the growing sophistication of cyber attackers, have led to organisations to seek stronger security measures to protect payment card data, and MFA is a very effective security measure.

So what new MFA requirements have been made with PCI DSS v4.0?

The first major change is that MFA is now required for all access to the CDE, which means that any user accessing a device in the CDE must use multiple factors.  There are some exceptions for sales staff in shops using point-of-sale (POS) or till devices, again for practicality reasons, but that’s it.  This should be relatively simple to implement as there are many MFA systems on the market that integrate with Active Directory (AD), and the latest version of AD comes with native support for Microsoft Authenticator.  Beware however, as it requires some implementation thought and will need to be set up correctly.  In addition, staff may need some training on it.

The next big change is that MFA is required for any remote access that could result in access to the CDE.  This means that if an account has the ability to access the CDE then, when being used remotely, it must use MFA irrespective of whether the user actually accesses the CDE on any given session.  An immediate implication of this is that, even in the jump-box scenario presented earlier, the user logging into the jump box will still need to use MFA if they have access to the CDE.  Having said that, this is not difficult to implement for the reasons stated above.  It is worth noting that the UK government-backed Cyber Essentials scheme, aimed predominantly at small and medium-sized businesses, now has a requirement for all cloud services’ users to have some form of MFA, so the requirement is clearly becoming commonplace.

Need for double dose of MFA

It is important to note that the Standard specifically states that the MFA requirement for ‘any remote access’ is separate to the requirement for ‘access to the CDE’.  This means that any user logging in remotely to the CDE will need to carry out MFA twice, on two separate occasions: once when they remotely log in and again when they log into the CDE device.  From a technical perspective, this is easy to implement, but it may prove challenging in terms of staff ‘buy in’, as the process may seem overly laborious.  As such, there is likely to be a very real push to educate users on the greatly increased risks that remote access to the CDE presents to the organisation.

Is there any reduction in administrative burden?

There is also some good news relating to MFA in v4, in that any account which uses MFA doesn’t need to change its password every 90 days.  As many of you will be aware, forced and frequent password changes have always been difficult to get users to buy into and can result in the adoption of less secure practices (such as writing passwords down!).  So this change will allow you to do away with this often unpopular security practice.

In conclusion, the MFA changes in v4 are seen as a positive move from a security perspective and, due to the ubiquitous nature of MFA applications, should now be quite straightforward to implement.

Want to learn more about other key changes being introduced by PCI DSS v4.0?  

Then register now for our ‘PCI DSS – Preparing for v4.0’ webinar on Wednesday 22 February.

‍