PCI DSS Requirement 8: Identify & Authenticate User Access to System Components

PCI DSS Requirement 8 provides detailed guidance on the two fundamental principles for identifying and authenticating users: establishing the identity of a person through an identifier, and verifying the identity of the user. 

The first principle is establishing identity by associating an identifier, like a user or system ID, with a person or process. This ensures accountability and the ability to trace actions to known users or processes. 

The second principle is using an authentication factor, which can be something the user knows (like a password), something they have (like a token device), or something they are (like a biometric element), to prove or verify their identity.

The combination of the ID and authentication factor is called authentication credentials and is used to access rights and privileges. 

The requirements found in PCI DSS Requirement 8 are based on accepted security principles and best practices, with additional information available in the NIST Digital Identity Guidelines, intended for US Federal Agencies. It's important to consider these guidelines as a complete framework rather than individual parameters.

For additional details on all 12 of the Requirements, read our PCI DSS Requirements overview.

Requirement 8 Details and Sections

Requirement 8 contains six sections that detail the means of securing account data by carefully assigning user permissions and access controls.

Detailed section requirements include:

• Requirement 8.1: Processes for identifying users and authenticating access to system components are defined and understood.
• Requirement 8.2: User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
• Requirement 8.3: Strong authentication for users and administrators is established and managed.
• Requirement 8.4: Multi-factor authentication (MFA) is implemented to secure access into the CDE.
• Requirement 8.5: MFA systems are configured to prevent misuse.
• Requirement 8.6: Use of application and system accounts and associated authentication factors is strictly managed.

Requirement 8.1: Processes for identifying users and authenticating access to system components are defined and understood.

Like other requirements found in PCI DSS 4.0, the first section of the requirement - 8.1 - explains the importance of creating and maintaining policies for adherence. These processes must be consistently monitored and updated whenever required, and all involved personnel must understand their responsibilities.

Detailed requirement sections include:

• Requirement 8.1.1: All security policies and operational procedures that are identified in Requirement 8 are documented, up-to-date, in use, and known to all parties.
• Requirement 8.1.2: Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. 

Requirement 8.2: User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.

Traceability of the actions performed on all systems ensures accountability and is critical to the foundation of effective access controls. Ensuring each user has a unique identifier gives the company effective records of actions by each user and holds them accountable for the actions performed on company systems. 

Likewise, companies should steer away from group or shared accounts, and will need to provide extensive documentation for the business case if shared accounts exist on in-scope systems.

Detailed requirement sections include:

• Requirement 8.2.1: All users must have a unique ID before access to system components or cardholder data is allowed.
• Requirement 8.2.2: Group shared accounts, or other shared authentication credentials, are only used on an exception basis, and are managed as follows:
  • Account use is prevented unless needed for an exceptional circumstance.
  • Use is limited to only the time necessary for the exceptional circumstance.
  • Business justification is documented and explicitly approved by management.
  • All actions are attributable to an individual user, and individual user identity is confirmed before access is allowed.
• Requirement 8.2.3 (Additional requirement for service providers only): Service providers with remote access to customer premises must use unique authentication factors for each customer premises.
• Requirement 8.2.4: Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are authorized with the appropriate approval and implemented with only the privileges specified on the documented approval.
• Requirement 8.2.5: Access for terminated users is immediately revoked.
• Requirement 8.2.6: Inactive user accounts are disabled within 90 days of inactivity.
• Requirement 8.2.7: Accounts used by third parties to access or maintain system components via remote access are enabled only during the time period needed and disabled after.
• Requirement 8.2.8: If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the session. 

Requirement 8.3: Strong authentication for users and administrators is established and managed.

Malicious individuals will commonly attempt to compromise a system by exploiting weak or nonexistent authentication factors, therefore, authentication factors should be a bare-minimum system requirement.

Detailed requirement sections include:

• Requirement 8.3.1: All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
  • Something you know, such as a password or passphrase.
  • Something you have, such as a token device or smart card.
  • Something you are, such as a biometric element
• Requirement 8.3.2: Strong cryptography - such as tokenization - is used to render all authentication factors unreadable during transmission and storage on all system components.
• Requirement 8.3.3: User identity is verified before modifying any authentication factor.
• Requirement 8.3.4: Invalid authentication attempts lock out the user ID after 10 attempts or fewer, and for a minimum of 30 minutes or until the user’s identity is confirmed.
• Requirement 8.3.5: If passwords are used as authentication factors to meet Requirement 8.3.1, they are set to a unique value for first-time use and upon reset, and are forced to be changed immediately after the first use. 
• Requirement 8.3.6: If passwords are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:
  • A minimum length of 12 characters (or eight, if the system does not support 12).
  • Contain both numeric and alphabetic characters. 
• Requirement 8.3.7: Individuals are not allowed to submit a new password that is the same as any of the last four passwords used. 
• Requirement 8.3.8: Authentication policies and procedures are documented and communicated to all users including:
  • Guidance on selecting strong authentication factors.
  • Guidance for how users should protect their authentication factors.
  • Instructions not to reuse previously used passwords.
  • Instructions to change passwords if there is any suspicion that the passwords have been compromised, and how to report the incident. 
• Requirement 8.3.9: If passwords are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
  • Passwords are changed at least once every 90 days, OR
  • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
• Requirement 8.3.10 (Additional requirement for service providers only): If passwords are used as the only authentication factor for customer user access to cardholder data, then guidance is provided to customer users including:
  • Guidance for customers to change their user passwords periodically.
  • Guidance as to when, and under what circumstances, passwords are to be changed. 
• Requirement 8.3.10.1 (Additional requirement for service providers only): If passwords are used as the only authentication factor for customer user access then either:
  • Passwords are changed at least once every 90 days, OR
  • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.
• Requirement 8.3.11: Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
  • Factors are assigned to an individual user and not shared among multiple users.
  • Physical and/or logical controls ensure only the intended user can use that factor to gain access.

Requirement 8.4: Multi-factor authentication (MFA) is implemented to secure access into the CDE.

Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system, because the attacker would need to compromise multiple authentication factors to get into the system. Implementing Multi-factor Authentication for all individuals with administrative access, at a minimum, can help reduce the chances of account takeover.

Detailed requirement sections include:

• Requirement 8.4.1: MFA is implemented for all non-console access into the CDE for personnel with administrative access.
• Requirement 8.4.2: MFA is implemented for all access into the CDE. 
• Requirement 8.4.3: MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
  • All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
  • All remote access by third parties and vendors.
    
    

Requirement 8.5: MFA systems are configured to prevent misuse.

Multi-factor authentication is only effective if properly implemented; Otherwise, attackers could bypass and still gain access to secured systems. Proper implementation includes using two distinct methods of authentication - not, for instance, two different passwords - to reduce the risks of account takeover.

Detailed requirement sections include:

• Requirement 8.5.1: MFA systems are implemented as follows:
  • The MFA system is not susceptible to replay attacks.
  • MFA systems cannot be bypassed by any user, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period.
  • At least two different types of authentication factors are used.
  • Success of all authentication factors is required before access is granted.

Requirement 8.6: Use of application and system accounts and associated authentication factors is strictly managed. 

Like individual user accounts, system and application accounts require accountability and strict management to ensure they are used only for the intended purpose and are not misused.

Detailed requirement sections include:

• Requirement 8.6.1: If accounts used by systems or applications can be used for interactive login, they are managed as follows:
  • Interactive use is prevented unless necessary for an exceptional circumstance.
  • Interactive use is limited to the time necessary for the exceptional circumstance.
  • Business justification is documented and explicitly approved by management.
  • All actions are attributable to an individual user, and individual user identity is confirmed before access is allowed.
• Requirement 8.6.2: Passwords for any application and system accounts that can be used for interactive login are not hard-coded in scripts, configuration/property files, or bespoke or custom source code.
• Requirement 8.6.3: Passwords for all application and system accounts are protected against misuse as follows:
  • Passwords are changed periodically and upon suspicion or confirmation of compromise.
  • Passwords are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords.

How Basis Theory can help you Satisfy PCI DSS Requirement 8

Securing cardholder data in a CDE satisfies many PCI DSS requirements and provides companies greater control and flexibility over their payment stack. However, building and maintaining the necessary infrastructure and programs can require hundreds of thousands of dollars and months to implement and assess. Basis Theory provides the platform, infrastructure, and tools to secure cardholder data in minutes and without these costs and distractions.

As a PCI Level 1 compliant service provider, Basis Theory extends an independently assessed and approved CDE to customers. Combined with a suite of configurable tools, services, and tokens, companies can collect, secure, and share credit cards without bringing their systems into scope. This approach allows companies to avoid the costs and distractions associated with 95% of the requirements in the Payment Card Industry Data Security Standard (PCI DSS) while retaining complete control over their cardholder data.

*PCI DSS Requirement information contained in this post is for educational purposes only and references material from the guide "Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0" published by the PCI SSC in March 2022. Please refer to the PCI Security Standards Council website for the complete, up-to-date, accurate requirements.