Skip navigation

PCI DSS 3.0 and Two-Factor Authentication

The PCI Security Standards Council released the third iteration of the PCI Data Security Standard (DSS) this month. Let's take a look at PCI DSS 3.0 and determine what has changed in the past three years with regard to two-factor authentication.

As with PCI DSS 2.0, the core requirement related to two-factor authentication is still 8.3. Since 2.0, however, the PCI Council has decided to split and refine the testing procedure section for this requirement. To help identify how this has actually changed, we'll compare 2.0 to 3.0 below.

PCI DSS 2.0 - 8.3, Testing Procedure

To verify that two-factor authentication is implemented for all remote network access, observe an employee (for example, an administrator) connecting remotely to the network and verify that two of the three authentication methods are used.

Within DSS 2.0, the testing procedure was extremely flat and didn't give much hard guidance on ensuring this important security control was being applied. When I have previously discussed this control with organizations there was distinct confusion on how important this really was based on the weakness in language for the testing procedure. As we can see within DSS 3.0, there's been an important (albeit subtle) shift in language and format for the procedure.

PCI DSS 3.0 - 8.3a, Testing Procedure

Examine system configurations for remote access servers and systems to verify two-factor authentication is required for:
- All remote access by personnel.
- All third-party/vendor remote access (including access to applications and system components for support or maintenance purposes).

Unlike DSS 2.0, the 3.0 guidance doesn't simply ask a Qualified Security Assessor (QSA) to observe a single employee logging into a remote access device to determine that two-factor authentication is deployed. With 3.0, the QSA handling the audit should inspect system/device configurations to determine that two-factor authentication is actually setup and enabled.

Further, DSS 3.0 defines classifications of users that are required to have two-factor authentication enabled for their accounts. This reduces the ambiguity previously found in 2.0 as to who actually needed to have this requirement.

PCI DSS 3.0 - 8.3b, Testing Procedure

Observe a sample of personnel (for example, users and administrators) connecting remotely to the network and verify that at least two of the three authentication methods are used.

Also modified is the language surrounding the previous requirement for observation to ensure two-factor is being utilized. In DSS 2.0, the testing procedure seemed to imply that a QSA would verify a single employee was being required to go through a two-factor process for remote access. In 3.0 the language was augmented to say "a sample" to convey that more than one person should be reviewed for this access control.

Has the PCI Council done enough, yet?

Not really. The frustration many people have with PCI DSS is the lack of clear, direct guidance within the standard. What we're seeing is a slow, measured shift to add specifics without gutting the entire 8.3 requirement and starting over. Unfortunately, this requirement like many others leaves organizations not knowing quite how to satisfy this need and the interpretation is ultimately left up to their QSA.

If, for instance, PCI DSS would declare what forms of second factor authentication were sufficient, organizations would have an easier time deciding what to implement to solve their requirement challenge. Similarly, because there isn't more explicit guidance on systems other than remote access, core systems may not have this crucial security control to prevent lateral movement by an attacker. This is a huge oversight in providing guidance by the PCI Council.

The most frustrating part of this process is that we're now likely another three years away from another update and another shot, to get it right.

Mark Stanislav

Security Evangelist


Mark Stanislav is the Security Evangelist for Duo Security. With a career spanning over a decade, Mark has worked within small business, academia, startup, and corporate environments, primarily focused on Linux architecture, information security, and web application development. Mark has spoken internationally at over 75 events including including RSA, DEF CON, ShmooCon, SOURCE Boston, and THOTCON. He earned his Bachelor of Science Degree in Networking & IT Administration and his Master of Science Degree in Technology Studies, focused on Information Assurance, both from Eastern Michigan University.