Is two-step authentication acceptable for PCI DSS Requirement 8.3?

Is two-step authentication acceptable for PCI DSS Requirement 8.3?

by Natasja Bolton, Senior Acquirer Support QSA


In our May 2016 article on the changes brought in by PCI DSS v3.2, we discussed both the PCI Council’s amended terminology from Two-Factor Authentication to Multi-Factor Authentication (MFA) as well as the introduction of an additional MFA PCI DSS requirement: 8.3.1.


Since then, due to many queries being raised by QSAs, ISAs, Participating Organisations and other businesses, the Council has issued further guidance.  They have published a number of FAQs clarifying the MFA changes and intent, as well as an Information Supplement giving guidance on MFA principles and practices based on industry best practice and standards.   In this article, we consider some of the key points from the Council’s guidance.


Firstly, as a reminder, the PCI DSS requirements for MFA are:


8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication
8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. MFA is required for non-console connections to the Cardholder Data Environment (CDE) for personnel with the ability to make changes to CDE systems, and hence to potentially weaken security controls or introduce vulnerabilities (i.e. administrative access). This includes connections that originate from within the company’s internal, “trusted” network.

This requirement is a best practice until January 31, 2018, after which it becomes a requirement.

8.3.2 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. MFA is required for all personnel—including general users, administrators, and vendors (for support or maintenance) – with remote network access that originates from outside the entity’s own network, where that remote access could lead to access to the CDE.

This typically applies where the access originates either from the Internet or from an “untrusted” network, such as a from a third-party location.

The change to Multi-Factor Authentication’ instead of Two-Factor Authentication, was made to ensure consistency across all PCI standards and guidance, such as the Tokenisation Product Security Guidelines and PCI Token Service Provider Requirements.  The PCI Council also hoped that the change provided greater clarity as to what is meant by ‘Two-Factor Authentication’.


Authentication is the method by which an individual proves that they are who they claim to be – by providing at least one authenticating factor that corresponds to the identifier (unique ID, userID or logon) they have provided.  The factor could be:


  • A password or passphrase (something the user knows)
  • A token, smartcard or digital certificate unique to the user (something the user has)
  • A biometric identifier, such as a fingerprint (something inherent in the user; something they are)

With MFA, the individual is required to provide at least two separate factors to confirm the validity of their claimed identity and thereby be allowed access.  MFA gives a much greater level of assurance in the identity of the individual, as it is much less likely that an attacker will be able to compromise both authenticating factors.  This is why PCI DSS requires MFA for remote access and for non-console administrative access to CDE systems.  Using MFA to more strongly authenticate those accessing the CDE from untrusted networks and those with the ability to make changes to CDE systems, reduces the risk of weakened security controls, compromise and data breaches.


By requiring the use of two different authentication factors MFA creates strong, multi-layered, defence in depth authentication.  If two or more of the same factor are used, the strength of the authentication is no greater than just one factor used alone.  An attack that successfully obtained one instance of the factor could obtain all instances of the same factor.  A system is no more protected by authentication relying on two separate passwords instead of just one, as both passwords could be obtained by a successful password cracking attack.  When two or more different factors are used for authentication, two or more different attack methods must be successfully employed by an attacker to obtain all the authentication information needed to gain unauthorised access to the system.  For example, if a system used a password as the first factor and a token as the second, then both a password crack and a physical theft must be simultaneously successful for the attacker to gain access.  This was often misunderstood when MFA was referred to as ‘Two-Factor Authentication’, many people thought that meant the same factor could be used twice.


The PCI SSC has also clarified (in FAQ 1426), that ‘two-step’ or ‘multi-step’ authentication is not the same as MFA.  As the FAQ explains, ‘’Two-step’ or ‘multi-step’ authentication involves the subsequent presentation of one or more authentication steps after the first authentication step is successfully performed’.  MFA requires that all authentication factors be verified, as a single step, prior to access being granted. Although overall the ‘two-step’ or ‘multi-step’ authentication may indeed rely on multiple authentication factors, each step relies on only a single authentication factor.  As the Information Supplement states: ‘If an unauthorised user can deduce the validity of any individual authentication factor, the overall authentication process becomes a collection of subsequent, single-factor authentication steps, even if a different factor is used for each step’.


An example of two-step authentication where the use of two different factors does not equate to MFA:

Step 1:

  • User provides their userID (identifier) and its associated password (something they know)
  • Authentication mechanism validates these credentials

Step 2:

  • The user provides a software token one-time password (something they have)
  • Authentication mechanism validates the second set of credentials


As can be seen, each step relies on single-factor authentication.


However, the most recent FAQ (FAQ 1449), the PCI Council confirmed that if certain, specific conditions can be met, then ‘two-step’ or ‘multi-step’ authentication may be acceptable.

Figure 1: FAQ 1449 Is two-step authentication acceptable for PCI DSS Requirement 8.3?


The second of the conditions is explained as:

  • Access to one factor does not grant access to any other factor, and;
  • The compromise (or breach) of any one factor does not affect the integrity or confidentiality of any other factor.

Going back to the ‘two-step’ authentication example:

Step 1:

  • User provides their userID (identifier) and its associated password (something they know)
  • Authentication mechanism validates these credentials

Step 2:

  • The user provides a software token one-time password (something they have)
  • Authentication mechanism validates the second set of credentials

If the password used in Step 1 to gain access to a device also gave access to the software token on the device, this would mean that while the first of the conditions specified in FAQ 1449 is met, the second condition is not.


The Information Supplement further illustrates what is meant by the independence of authentication mechanisms with useful scenarios, including this one:

Figure 2: Guidance for Multi – Factor Authentication: Scenario 2

The user shown logs into their computer using one set of credentials (userID and Password A).  Those credentials also provide access to the software token stored on the computer.


To connect to the CDE, the user launches a browser window that relies on a different set of credentials: Password B in conjunction with the software token generated one-time password.  However, Password B is cached in the browser or stored on the computer in a password manager.


The first set of credentials (userID and Password A) provides access to both factors used in the second step (Password B and the software token); therefore, there is no independence between authentication factors.


The Information Supplement provides further advice on how to achieve independence between factors.  Sysnet recommend that all businesses review both the guidance in the information supplement and the associated FAQs, to make sure the authentications mechanisms they have already in place for remote access, and those they may be working on to meet the Requirement 8.3.1 2018 deadline, fulfil the intent and conditions specified:



You might also be interested in this article:


PCI DSS v3.2 – What’s changed