Document Comparison

Addresses related PCI DSS v4.0.1 requirements as applicable.

Replaces the original Multi-Factor Authentication Guidance document.

• confirm that they are who they say they are

• prior to granting access.

This document describes industry-accepted principles and best practices associated with authentication, detailed considerations for authentication processes and implementations, and how authentication relates to PCI standards. The guidance in this document is intended for any organization evaluating, implementing, or upgrading their authentication solution, as well as providers of authentication solutions.

The guidance in this document does not extend the requirements of the Payment Card Industry Data Security Standard (PCI DSS), or any other PCI SSC standard, beyond what is stated in that standard.

Audience and Purpose This document is intended for use by all entities that may be involved in authentication aspects of PCI SSC standards and programs. This includes assessors, as well as implementors and technology providers.

The purpose of this document is to provide details on current authentication processes and technologies, and how they may be considered with respect …

 Establish the identity of an individual or process on a computer system, and  Prove or verify that the user/system associated with the identity is who they claim to be.

The ability of that user authentication process to correctly prove the user identity

• even in the presence of potentially malicious actors

• reflects the relative strength of the authentication process.

An account ID is a unique value that establishes the identity of an individual or process on a computer system. The authentication factor proves or verifies the user is the valid owner of that ID. The ID and the authentication factor together are authentication credentials.

The authentication process includes the following elements:

Element Description User The individual or system requesting to be authenticated.

Credential Combination of user ID and authentication factors provided by the user requesting access. These items are known by, or can be used by, the user for the purposes of authentication.

Authentication System …

1. User (re)enrollment The users authentication credentials are initialized in the system, either upon first use, reset, or to change existing credentials. (Re)enrollment may occur due to some system or process error (for example, the user forgetting their password), or to alter an existing credential (for example, to update a password or change from using one factor type to a different factor type).

2. User authentication This is the primary focus of this document, where the user supplies their credentials to the authentication system to validate their claimed identity.

3. Session authentication This is where the actual on-going authentication with systems and resources the user is accessing is performed.

Steps (1) and (3) are not the main focus of this document but remain important parts of any authentication and access implementation. As user authentication methods are increasingly secured, more attacks on other stages (such as hijack attacks on user enrollment or session tokens) …

 Something you know (knowledge-based factors) are credentials in the form of unique information known only to the user, such as a password, passphrase, or PIN.

 Something you have (possession-based factors) are credentials that are uniquely linked to a device the user possesses, such as a smartcard with an embedded cryptographic key or a physical token that displays a changing PIN value.

 Something you are (inheritance/biometric factors) are credentials associated with a unique aspect of the user’s physical traits, such as a fingerprint, facial recognition, or DNA.

The ‘unique’ aspects of these factors are vital to security and speak to why questions like “What is your mother’s maiden name?”, or using your dog’s name as a password, are not secure authentication factors. Knowledge-based factors should be unique

• things that are literally knowledge that is shared only by the user and the entity to which the user is authenticating themselves. The last …

Storage and Usability of Authentication Factors The authentication process often involves use and storage of secret values, such as passwords or cryptographic keys. To mitigate the potential for compromise, these secret values should be stored securely.

Passwords should never be stored in plaintext, and instead a ‘one-way function’ should be used that allows for comparison of the user-input value with the stored value but does not allow for the easy determination of the actual stored value in the case of a compromise. Best practice is to use algorithms that increase both the time and memory cost of performing the comparison (memory-hard functions), rather than using a single pass through a standard hash function, which can often be performed very quickly. Use of unique-per-password ‘salt’ values is also important to prevent pre-computation of password-hash dictionaries (also known as ‘rainbow tables’).

Additionally, usability of the authentication process should be considered. It can be difficult …

When messaging systems are used to deliver authentication factors, the device receiving the message is the possession factor, not the message. Therefore, access to the messaging account should be sufficiently controlled on all devices that may be able to receive the message.

Best practice when using messaging systems is to secure all the device(s) that can receive the messages with their own form of sufficient authentication (for example, through use of a device lockscreen) to verify the user who is able to access the messages. Individual user authentication, especially when using multi-user computing systems, is necessary to ensure that the correct person receives the authentication message.

Where SIMs are used as part of such a system, a SIM PIN should be implemented in addition to blocking message content on the device lockscreen (for any message types in scope), to mitigate lost and stolen attacks. Finally, consider controls around replay and relay attacks …

Use of ‘phishing-resistant’ authentication helps to prevent these types of attacks. This type of authentication ensures that there is no sharing of authentication secrets without first validating the authentication system making the request. NIST SP800-63 defines phishing-resistant authentication as follows:

“The ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier without reliance on the vigilance of the claimant.”2 Often, phishing-resistant authentication includes the use of a ‘zero knowledge proof’ confirming the user possesses a secret value without the user disclosing any information about that secret value.

Because phishing-resistant authentication relies on the use of cryptography, it requires the user to possess a unique cryptographic key and the ability to perform operations with that cryptographic key. Therefore, phishing- resistant authentication is a type of possession factor. Phishing-resistant authentication may also implement another factor type, such as a PIN or biometric to ‘unlock’ …

Passkeys are a form of phishing-resistant authentication because there are no shared credentials to steal and no sign-in data to use in attacks, and because each passkey is tied specifically to a unique authentication system. Passkeys help to reduce attacks, such as phishing, credential stuffing, and account takeovers.

Passkeys may be device-bound or synced across devices (synced passkeys).

Device-Bound Passkeys A device-bound passkey is where the user component of the passkey (the private key) is locked to a single device, often stored in a dedicated security area within the device, such as a TPM, TEE, or SE. Device-bound passkeys can be considered to provide proof of the possession of the device to which the passkeys are bound.

Best practice 10: Implement device-bound factors (such as device-bound passkeys, smartcards, tokens, etc.) for sensitive access operations (such as administrative access or access for high- security areas and tasks).

Synced Passkeys Synced passkeys are not bound to …

The purpose of MFA is to provide a higher degree of assurance of the identity of the individual attempting to access a computing resource. This higher degree of assurance is similar to other defense in depth security measures; forcing an attacker to compromise at least two authentication methods prior to gaining access.

This is why MFA requires at least two different types of factors: For example, use of two (or more) different passwords does not represent an increase in difficulty if passwords as an authentication mechanism have been compromised. Only one factor type is used, and so it is not MFA.

Best practice 12: Implement multi-factor authentication wherever possible.

Cross-Device Authentication and Authentication Downgrade Cross-device authentication is a method of authentication where a user provides their authentication credentials through a different system/application to the one they are actually intending to log into. This usually occurs when credentials are not synced across all systems/devices.

Use …

Step-up authentication does not meet PCI SSC requirements for MFA.

Not all authentication methods provide the same level of security assurance, even those of the same authentication type. For example, some MFA methods are better practice than others because they mitigate multiple attack types.

Replay Attacks A replay attack is an attack that intercepts or otherwise obtains valid authentication data and then resends or redirects this communication for malicious purposes. In authentication implementations, replay attacks are typically used to gain unauthorized access by leveraging legitimate credentials and can be used to attack multiple factors at one time.

Examples of methods to help protect against replay attacks include mechanisms that detect and reject duplicated or delayed authentication attempts, including, but not limited to, the use of unique session identifiers and session keys, timestamps, and time-based one-time passwords or passcodes.

Relay Attacks A relay attack is similar to a replay attack in that the attack captures valid authentication data from a legitimate user and uses …

Table 1 includes references to different types of attacks or vulnerabilities. The details of these types of attacks and vulnerabilities are as follows.

 Phishing

• a malicious party attempts to trick or coerce the user into providing a secret credential value to the attacker instead of the authentication system. Phishing is a type of relay or replay attack, where the attacker relays or replays user credentials to impersonate that user.

 Authenticator compromise

• an application or device that provides authentication credential data to the user is compromised. This includes theft/loss of physical authenticators, as well as compromise of authenticator software or key-files, user passwords and password files, and presentation attacks on biometric systems, such as deep fakes.

 Account compromise

• the authentication method relies on a second user account, which if compromised, can compromise the authentication process. Examples include compromise of an email account that is used to receive an OTP, compromise of …

Table 1: Authentication Types, Strengths, and Attack Types Rank Authentication Factor and [Type] Examples Attack types How to increase Best practice Phishing-resistant authentication [Possession] FIDO2-based passkeys  Authenticator compromise  Cryptographic vulnerability Use device-bound keys Cryptographic challenge / response [Possession] Token/smartcard- based user private key, host public key  Phishing  Authenticator compromise  Attacker-in-the-middle  Cryptographic vulnerability  Secret compromise  Use device-bound keys  Notify of / detect changes to requesting server (this can add phishing resistance) Good practice Long, randomly generated password [Knowledge] Passwords generated by password manager  Phishing  Account compromise  Attacker-in-the-middle  Brute force  Secret compromise  Use a secure password manager  Ensure password generation rules are sufficiently complex Locally-generated OTP [Possession] An OTP generated by an authenticator app or fob  Phishing  Authenticator compromise  Attacker-in-the-middle  Cryptographic vulnerability  Brute force  Secret compromise  Use device-bound keys …

(Re)Enrollment Securing the process of enrolling a user into an authentication system is vital to security. A lack of trust in the enrollment process implies a lack of trust across the entire authentication lifecycle. However, this step can be challenging because it is common for the enrollment step to occur remotely with a centralized IT service.

Initial credentials should be supplied to the user in a way that verifies the user’s identity. This can be achieved through a trusted local staff member who provides credentials to the user and can verify the user’s identity, or through validation of another form of identity. Some forms of digital ID (known as verifiable credentials (VCs)) can implement methods that allow for secure remote proof of identity and may be useful in the (re)enrollment process. VCs include mobile drivers’ licenses and digital passports.

Ultimately, an authentication system is only as secure as the method used to …

PCI DSS Authentication Requirements The PCI DSS v4.0.1 authentication requirements are included in Requirements 8.3, 8.4, and 8.5, and are summarized as follows:

Req. 8.3.1: All user access to system components is authenticated via at least one authentication factor.

Req. 8.4.1: MFA is implemented for all non-console access into the CDE by administrative personnel.

Req. 8.4.2: MFA is implemented for all non-console access into the CDE with a note that the requirement does not apply to user accounts only authenticated with phishing-resistant authentication factors.

Req. 8.4.3: MFA is implemented for all remote access originating from outside the entity’s network that could access or impact the CDE.

Req. 8.5.1: MFA systems are configured with several characteristics to prevent misuse.

Figure 3: Authentication Implementations for PCI DSS Environments

Note: Requirements under 8.3.x apply to all types of user authentication unless a requirement specifically calls out passwords/passphrases. For example, requirements such as 8.3.6 for password/passphrase complexity do not apply to …

Requirement 8.4.2 includes an Applicability Note that the requirement does not apply to “User accounts that are only authenticated with phishing-resistant authentication factors.” For this requirement, credentials implemented according to FIDO2 requirements, including both device-bound and synced passkeys, may be used as single-factor authentication in place of MFA.

For Requirements 8.4.1 and 8.4.3 (which do not include the Applicability Note mentioned above for Requirement 8.4.2), phishing-resistant authentication may still be used but must be accompanied by an additional authentication factor (for example, password, PIN, or biometric) to meet these MFA requirements. This second factor may be supplied to unlock the use of the phishing-resistant credential or supplied as a separate credential during the authentication process.

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, …

Similarly, console access excludes the use of systems that do not provide a direct physical connection to the user input device, (for example, a keyboard). Therefore, access through networked KVM switches, USB keyboards that are attached to a shared USB hub (not dedicated to only providing console access), or wireless keyboards are examples of non-console access. The implementation of systems that may have non-direct connections, but where all connections are immediately apparent and can be validated as not including malicious equipment such as with a server crash-cart system are console access.

Use of keyboards that implement a direct connection from the keyboard to a port on the system being accessed is console access.

Authentication and Cryptography Authentication is often intrinsically linked with cryptography, either in how the authentication process itself occurs (for example, with passkeys), as part of securing the storage of secret values, or in providing the secure channel that is …

Scenario 1

• Password(s) Only An individual uses one set of credentials (username/password A) to log onto a computing system. If sent to a remote authentication server, the user may be provided with session credentials that permit access to other non-local computing systems or resources.

In a similar scenario, the user may supply two passwords: password A to log on to the local computing system and password B to gain session credentials for other network resources.

Note: These scenarios are not MFA because only a single factor type is required for access. Even though the second example uses two different passwords, they are both knowledge-based factors, which are the same factor type.

Note: This scenario is MFA because two different factor types are required for access. The first factor is knowledge-based (a password), and the second factor is possession-based (an OTP).

Recommended Practice: Implementations where the credentials are verified at the same time, with no indication of success for any factor until all factors have been successfully verified, help to prevent credential stuffing attacks. If the credentials are to be verified separately, it is better to verify the OTP value first prior to verifying the password. Use of SMS or email to deploy an OTP or PIN is not as secure as using an authenticator application that generates the OTP locally for the user. Access to authenticator applications used in this scenario should be secured with their own authentication method, such as a PIN or biometric.

In this scenario, it is important to note that the device credential is assumed to implement some form of replay protection; that is, it cannot be a simple password or unchanging token. The device credential is assumed to be a cryptographic credential that can be used in a challenge/response protocol.

Note: With the use of replay-resistant locally stored device credentials, such as cryptographic keys, this scenario is MFA because two factor types are required for access. The first factor is either knowledge-based (a PIN) or inheritance-based (biometric), and the second factor is possession-based (device credentials).

Note: If instead this scenario unlocks an unchanging value, or if the PIN/biometric can be directly passed to the authentication server to generate a new session credential, this scenario is not MFA because only a single factor is required to gain access.

Recommended Practice: Use phishing-resistant credentials in this type of scenario.

Alternative 1: If the previous scenario is modified so that the initial PIN/biometric does not immediately unlock access to the device credential, use of the device credential later would not be MFA, but step-up authentication.

Note: The scenario described in Alternative 1 is not MFA because only a single factor is required for access.

Alternative 2: For Alternative 1 to be MFA, the user must reenter the PIN/biometric into the system to unlock the on-device credential at the later time. This scenario describes how many authenticator applications work, requiring the reentry of the device biometric/PIN to unlock access to the stored credentials.

Note: The scenario described in Alternative 2 is MFA because two factor types are required for access. The first factor is either knowledge-based (PIN) or inheritance based (biometric), and the second factor is possession- based (device credential).

Note: This scenario is MFA because two factor types are required for access. The first factor is knowledge-based (password), and the second factor is possession-based (OTP or magic link).

This scenario provides additional assurance beyond use of a simple password because it verifies the user has access to the out-of-band method used to convey the session credentials or OTP. However, this method is not as secure as other MFA methods, and more secure methods should be prioritized where possible.

An alternative scenario is where the user does not provide a password, and the link/OTP is supplied as a single factor. Such implementations are not MFA.

Note: This alternative scenario is not MFA because only a single factor is required for access. A password is not provided; the only factor provided is the link/OTP.

Note: The scenario described in Alternative 1 is not MFA because only a single factor is required for access.

Alternative 1: The user simply unlocks the use of the credentials by pressing a button on the fob (or similar). No PIN, password, or biometric is used.

Alternative 2: A second factor in the form of a biometric, PIN, or password is required to unlock the credentials on the external device. This additional factor can be entered directly into the device itself or through the system to which the device is connected. For example, a PIN entered through the computer keyboard passed to the device that is connected into a USB port.

Note: The scenario described in Alternative 2 is MFA because two factor types are required for access. The first factor is either knowledge based (PIN or password) or inheritance based (biometric), and the second factor is possession based (phishing-resistant credential on the external device).

Note: The scenario described in Alternative 3 is MFA because two factor types are required for access. The first factor is possession based (phishing-resistant credential on the external device) and the second factor is either knowledge based (PIN or password) or inheritance based (biometric) sent to the authentication server.

This scenario does not focus on the use of factors: the identity provider may require a single factor type or multiple factor types to validate the user identity. However, once authenticated, the user is not required to re- authenticate for access to multiple computing systems. Instead, the user is required to prove that the identity was validated previously with the identity provider.

Although the user is not required to reauthenticate, some systems allow for the identity provider to confirm details about the factors initially used to identify the user. This can be used, for example, to confirm that MFA was used before granting access to resources within a CDE.

Note: This federated example could implement a single-factor or MFA, depending on the implementation. The use of federated identity does not eliminate the need to implement MFA where it is required or advisable.