5 Key Concepts of the New PCI SSC Authentication Guide

At the end of August 2025, the ICP SSC published two new guides (information supplements) related to authentication y cryptography. Although these documents do not change the applicability and/or obligation to comply with the related PCI SSC controls, they do complement and detail a series of technical and administrative aspects that must be taken into account by both QSA advisors and the entities that must comply with these requirements.

In this first article we will analyze 5 key concepts of the Authentication Guide (Information supplement – Authentication Guidance) Version 2.0 Revision 1, published in August 2025. This document replaces the guide published in February 2017, including very important changes in the implementation processes of multi-factor authentication (Multifactor Authentication – MFA) and contains recommendations aligned with the PCI DSS v4.x standard. extends its scope to the whole concept of authentication and not just multi-factor authentication, as was the case in the first version of this guide, offering very interesting recommendations applicable to this process.

It is equally important to note that this document is accompanied by a infographic It contains a graphical summary of the concepts described in the guide, including 16 best practices in the use of authentication systems.

Best practices in the use of authentication systems

Introduction and basic concepts

Before starting with the analysis of the 5 most important concepts of the New Authentication Guide, an introduction to the basic concepts of this process should be made, for which an extract from the article is presented below:Analysis of PCI DSS v4.0 – Part V: Requirements 7, 8 and 9«, where changes to these requirements were analyzed in version 4.0 of PCI DSS:

• The identification is the attribution of a unique identity to a person or system.
• The authentication is the process of verifying the identity of the user/system. By requesting access and submitting a unique User/System ID, the User/System provides a set of private data to which only the User/System has access or knowledge. Validation of one or more of the following factors is used for this process:
  • Something that is known (something you know – SYK), as a password,
  • Something you have (something you have – SYH), such as a token or smart card (smart card),
  • Something that is (something you are -SYA), as a biometric control.

Authentication factors. Source: https://www.yubion.com

• The authorisation is the process of defining the specific resources a user/system needs (access) and determining privileges over those resources. The management of the authorisation should be based on the following criteria:
  • ‘Need to know» (Need-to-know) refers to providing access only to the least amount of data necessary to perform a job.
  • The "minimum privileges» (Least privileges) refer to providing only the minimum level of privileges necessary to perform a job.
  • The “separation of responsibilities” (Separation of duties) allow the division of mission critical functions between different individuals and/or functions, defines roles and responsibilities for each individual or role and ensures that security personnel who manage access control functions do not also manage audit functions to avoid conflicts of interest using dual control and divided knowledge:
    • Dual control (dual control): A process that uses two or more separate entities (usually individuals) that operate in concert to protect sensitive functions or information. No single entity may access or use the material.
    • Divided knowledge (Split knowledge): Separation of data or information into two or more parts, each of which is constantly kept under the control of separately authorized persons or teams, so that no person or team knows the whole of the data.

The relationship between these three important concepts is simple:

• Identification provides uniqueness
• Authentication provides validity
• Authorization provides control

The management of these three concepts is called ‘Identity and access management’ (Identity and Access Management – IAM) and its implementing rules are assessed in the checks of these requirements 7, 8 and 9 of PCI DSS.

1. All MFA systems are acceptable, but some are more acceptable than others

To paraphrase George Orwell's novel,Rebellion on the farm‘, conceptually, the use of two or more authentication factors is considered multifactor authentication (MFA) in the PCI DSS standard. However, depending on the authentication factors involved, the scenario to be protected and other elements external to authentication (use of time limits (timeouts), crashes by failed attempts, data transmission channels, etc.), one MFA authentication system may be more robust than another. It is not the same to use a password (something that is known) and a code One-Time Password (OTP) sent to e-mail (something you have) that use an authentication system based on secure physical devices (something you have) in conjunction with biometrics (something that is). Both meet the MFA criteria (use of two different authentication elements), but, as can be easily concluded, the security of the first cannot be compared to the security of the second ….

That being so, it is important to differentiate between compliance and security. While the use of two or more factors can be used in PCI DSS as MFA and is fully acceptable (compliance), its security can be more or less robust depending on other aspects that must be evaluated by the entity BEFORE proceeding with the implementation of the authentication system and by the QSA/ISA during the compliance assessment. Among these aspects are the resistance to different types of attacks and vulnerabilities such as phishing, engagement of authenticators (applications or devices that provide authentication credentials), engagement of accounts, relay attacks (attacker-in-the-middle), cryptographic vulnerabilities, compromise of secrets and/or brute force attacks.

To do this, this new guide includes a very interesting table that analyzes the different types of authentication and their level of security, organized by strength. In this case, this table can be used as a reference to choose the authentication methods to be used in the MFA process and their associated risks to adapt them to the environment to be protected:

Strength of each authentication factor

2. Use of PIN: Is it acceptable?

For many years we have been instilled that for a password (something that is) is ‘robust’, must comply with a number of controls at the level of complexity, expiration (change/rotation), history (reuse), etc. Some criteria have changed over time (such as, for example, the length and change periods of passwords in the update of the NIST guides). SP 800-63 Digital Identity Guidelines in 2025).

However, when we think of a personal identification number (Personal Identification Number – PIN), what comes to mind is a set of digits with a short length that – by no means – could comply with the security controls applicable to a password. But, still, the PCI SSC allows the use of a PIN as an authentication element. But how is this possible?

According to this new guide (paragraph Use of PINs and Other Low Entropy Knowledge-Based Factor), the use of a PIN (such as four numbers chosen by the user) may be acceptable as long as additional controls are added such as blocking after a certain number of failed attempts (to prevent brute force attacks), specific actions after exceeding the threshold of failed attempts, secure storage, etc.

When these additional controls cannot be implemented, then the PIN must comply with the controls applicable to passwords.

3. Multi-Step vs. Multi-Factor: Changes in acceptance criteria

One of the concepts that generated the most debate (and even forced specific implementations to achieve compliance, as was the case with Fortinet FortiAuthenticator and PCI DSS 3.2) was the difference between multi-step authentication (multi-step) and multi-factor authentication.

The 2017 guide stated that:

PCI DSS requires that all factors in multi-factor authentication be verified prior to the authentication mechanism granting the requested access. other, no prior knowledge of the success or failure of any factor should be provided to the individual until all factors have been presented. If an automated 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. For example, if an individual submits credentials (e.g. username/password) that, eleven successfully verified, lead to the presentation of the second factor for validation (e.g. biometrics), this would be considered “multi-step” authentication.

Accordingly, ALL authentication factors should be evaluated BEFORE giving access to the user and NO notification could be given to the user regarding the successful or erroneous validation of these factors. However, in PCI DSS v4.x and this new authentication guide, the following is clarified:

PCI DSS v4.x requires the success of all authentication factors before access is granted. MFA implementations that indicate the success of one factor prior to presenting any subsequent factor(s) meet applicable PCI DSS requirements for MFA. However, access cannot be provided until success of all factors is verified.

As you can see, the difference is subtle but very important: It is acceptable to be notified if one of the authentication factors is successful BEFORE you ask the user for the following factor. This is also emphasized in the FAQ #1584: For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?

Although, the strangest thing about all this, is that that 2017 restriction related to the notification of success or error in the presentation of authentication factors and that is now allowed, has moved to a better practice:

It is a best practice that systems either 1) provide no feedback about the success of any factor until all factors are provided, or 2) authenticate with a session-unique factor (for example, a one-time password (OTP) or phishing-resistant factor) before authenticating any factor that is the same across different sessions (such as a password).

In conclusion: is accepted if successful submission of a factor is reported BUT better if this is not done, as it is a good practice … ¯\_ (ツ) _/¯

4. Phishing resistant systems: The big bet of PCI DSS

Another new concept that has been added to this new guide and that was not contemplated in the 2017 MFA guide is that of authentication factors resistant to phishing attacks (Phishing-Resistant Authentication Factors). Using such authentication systems minimizes an attacker's ability to capture credentials through phishing to later reuse them in attacks of replay (in which the attacker intercepts a user's credentials and then forwards them to gain access) or relay (man-in-the-middle). This implementation depends on cryptographic functions that ensure that no authentication credentials are shared without first validating the authentication system that is making the request. This is achieved by validating the possession of specific cryptographic keys by the systems involved, so these systems are categorized as "something you have" (SYH).

Generally, these cryptographic keys are stored in security devices that, on their own, are not considered MFAs. In these cases, this authentication factor must be combined with another authentication element (such as a PIN or password) in order to be considered as such.

Phishing Resistant Authentication Systems Operating Model

The use of phishing-resistant authentication systems is not mandatory. However, its use does have some advantages in PCI DSS compliance, such as in the implementation of control 8.4.2 MFA is implemented for all non-console access into the CDE. In this particular case, this requirement does not apply if user accounts are authenticated only with phishing resistant authentication factors (including systems implemented in accordance with FIDO2).

5. Authentication of sessions: What follows after MFA

Once the user's identity has been verified in an authentication process (using MFA) and their privileges have been assigned (authorization), a trust relationship is established between the systems linked to the process that is represented in a session. In subsequent requests, instead of re-validating the user again and again using MFA (which would not be practical or operational), the associated session is validated. Therefore, attackers, instead of focusing on the authentication process (reinforced by MFA), focus their efforts on obtaining the credentials linked to the session.

What is interesting at this point is that the PCI DSS standard includes controls to reinforce the process of identity management and authentication (including MFA) but, explicitly, does not stipulate controls for session protection. The authentication guide includes a number of best practices for minimizing potential attacks on sessions, including:

• Once the authentication process has been completed, the sessions should be linked to users and/or devices. In this way, if an attacker manages to compromise a session, he will not be able to use it since it would be linked to a device (computer, mobile, etc.) or a specific user.
• Implementation of controls time-out.
• Using secure communication channels that add additional protection controls, such as TLS.

Many of these concepts are framed within the strategy of Zero Trust Architectures (ZTA), in which it is assumed that there is no implicit trust given to the assets or user accounts based solely on their physical location or ownership of the assets.

Bonus: Configuring Passwords in MFA Authentication

Despite all efforts to implement authentication processes that are not password-based (passwordless authentication), passwords remain a widely used authentication factor and cannot be replaced in the short term.

The methods to breach the security provided by a password are widely known and – therefore – it is imperative that when these elements are used, password management policies are implemented, including protection during storage and transmission, blocking by failed attempts, secure processes of change and assignment, complexity, history of use and periodicity to change them.

However, when a password is used accompanied by another authentication factor, it does not need to be changed every 90 days, as required by requirement 8.3.9 (Passwords/passphrases are changed at least eleven every 90 days). This is the only exception in implementing password policy. In all other cases where the password is used as the sole authentication factor, all controls (from 8.3.1 to 8.3.10) are applicable.

Final comments

Apart from this five key concepts, this new authentication guide explains in detail new concepts introduced in PCI DSS v4, such as MFA strings.MFA chains), where MFA authentication is required when accessed remotely from outside the entity's network (req. 8.4.3) and when accessing the CDE (req. 8.4.1/8.4.2), as explained above in PCI Hispano:

Authentication processes in PCI DSS

Another additional value provided by this guide is this table that includes types of authentication and their applicability in PCI DSS, solving many of the doubts that existed in the implementation of MFA in the previous versions of PCI DSS:

Types of authentication and their applicability in PCI DSS

Finally, six (6) scenarios of implementation of authentication processes are included, where their advantages and problems are analyzed, as well as their compliance and alignment with the PCI DSS criteria, especially MFA.

In conclusion, this is an essential document for any entity that is affected by PCI DSS that must be used as a basic reference to analyze, choose and configure authentication systems. Likewise, all QSA/ISA advisors should be familiar with the terminology and concepts explained in this guide before proceeding with a compliance assessment.