PCI DSS Requirement 8 Explained

PCI DSS Requirement 8: Identify and authenticate access to system components

To ensure that people are responsible for their actions, assigning a unique identification (ID) to each person with access is necessary. In this way, accountability is in question, and transactions on critical data and systems can be performed and monitored by known and authorized users and processes.

See Also: What Are the PCI DSS Password Requirements?

The effectiveness of the password is determined mainly by the design and implementation of the authentication system. Specifically, how often an attacker may attempt to password entry, and the design and implementation of security methods to protect user passwords during login, transmission, and storage determines effectiveness.

These requirements apply to all accounts with administrative features, including point-of-sale accounts. All accounts are used to view cardholder data or access cardholder data or access systems with cardholder data.

See Also: Identify and Authenticate Access to System Components

These requirements also include accounts used by vendors and other third parties. Requirements do not apply to end-user accounts used by consumers.

PCI DSS Requirement 8 covers identification and authentication for all access to system components.

The aim is to ensure that users are responsible for their actions and make traceable transactions performed by those who have access to the cardholder data environment.

Let’s take a look at the sub-requirements in PCI DSS Requirement 8.

PCI DSS Requirement 8.1-1: Define and implement policies and procedures to provide accurate user identity management for non-consumer users and administrators in all system components.

All users must be assigned a unique ID before they can access system components or cardholder data.

Instead of using a single identity for several employees, an organization can maintain individual responsibility for actions and an adequate audit trail per employee, ensuring that they are uniquely identified. Assigning unique identities to users will help speed up problem resolution and control when a misuse or malicious purpose occurs.

PCI DSS Requirement 8.1.2: Control the addition, deletion, and modification of user IDs, credentials, and other identifying objects.

Robust processes must be defined to ensure that all user accounts allowed access to the systems are valid and well-known users. All changes to other authentication credentials, including adding new user IDs and changing or deleting existing ones, need to be managed and controlled.

Privileged user IDs and general user IDs should be reviewed and verified that each user ID and privileged user IDs only have the privileges specified in the documented approvals.

PCI DSS Requirement 8.1.3: Immediately revoke access for terminated users.

If an employee leaves the company and accesses the network through their user account, unnecessary or malicious access to cardholder data may occur, and the cardholder data may be compromised.

Likewise, the unused account of the former employee may be used by a malicious user to gain unauthorized access to cardholder data. To prevent unauthorized access, user credentials must be revoked as soon as possible after the employee has left.

Furthermore, all physical authentication methods, such as smart cards or badges belonging to the former employee, must be returned or disabled as soon as possible.

PCI DSS Requirement 8.1.4: Remove or disable inactive user accounts within 90 days.

Accounts that are not regularly used are often targets for attacks. Because any changes in unused accounts are less likely to be noticed; as a result, attackers can more easily take advantage of these accounts and use them to access cardholder data.

User accounts must be reviewed regularly to verify that inactive accounts older than 90 days have been deleted or disabled.

PCI DSS Requirement 8.1.5: Manage the IDs used by third parties to access, support, or protect system components remotely.

Allowing third-party service providers unlimited access to your network 24/7 when they need to support your systems increases an unauthorized user’s chances in the environment or a malicious person finding and using an existing external entry point.

See Also: PCI DSS Remote Access Requirements – What You Need to Know

Enabling third-party service provider access only for the time needed and disabling them when they are no longer required will help prevent misuse of these connections.

Tracking third-party service providers’ access will ensure that these people only access the required systems within approved timescales.

Identities used by third parties to access system components via remote access must be managed as follows:

• It should only be activated for the required time.
• It should be disabled when not in use.
• Should be monitored during use.

PCI DSS Requirement 8.1.6: Limit repeated access attempts by locking the user ID after six attempts.

In the absence of account lockout mechanisms, attackers can continuously try to guess passwords through manual or automatic password cracking and guessing tools until they succeed and access a user’s account.

Therefore, locking user accounts after more than six invalid login attempts will prevent such password guessing attacks.

Non-consumer customer user accounts must also be temporarily locked out after more than six invalid access attempts for service providers. This additional requirement only applies if the assessed organization is a service provider.

PCI DSS Requirement 8.1.7: Set the user ID lockout time at least 30 minutes or until a system administrator reset the account.

Locking accounts while attackers are continually trying to guess a password and delaying the reactivation of locked accounts will stop the constant guessing of the password, preventing guess attacks’ success.

The account must remain locked for at least 30 minutes until it is reactivated. Also, in case of requesting reactivation for the account, the administrator or help desk must verify that the real account owner requests reactivation.

PCI DSS Requirement 8.1.8: If a session has been idle for more than 15 minutes, ask the user to re-authenticate to reactivate the terminal or session.

When users move away from an open machine with access to critical system components or cardholder data, this machine may be used by others in the user’s absence, which may result in unauthorized access or misuse of the account.

See Also: PCI DSS Session Timeout Requirements

Therefore, if the session is idle for 15 minutes, the session must be locked automatically, and the user must re-authenticate to reactivate the session.

Re-authentication can be used at the system or application level to protect all sessions running on that machine.

PCI DSS Requirement 8.2: Provide accurate user authentication management for non-consumer users and administrators in all system components.

When these authentication methods are used in addition to unique identities, it helps to prevent the identity of users from being compromised as a person attempting to violate the security needs to know both the unique ID and the password or other authentication used.

In addition to assigning a unique identity, it is necessary to ensure correct user authentication management for non-consumer users and administrators on all system components using at least one of the following methods to authenticate all users:

• Something you know (such as a password)
• Something you have (like a smart card)
• Something you are (such as biometrics, fingerprint)

A digital certificate is also a valid option for “something you have” as long as it is unique to a specific user. Since one of the first steps a malicious person can take to compromise the system is to use weak or non-existent passwords, it is essential to implement strict authentication management processes.

PCI DSS Requirement 8.2.1: Make all authentication information unreadable using strong encryption during transmission and storage on all system components.

Many network devices and applications transmit unencrypted readable clear-text passwords over the network or keep passwords clear-text without encrypting them.

Using a “sniffer,” a malicious person can easily intercept unencrypted clear-text passwords during transmission, or directly access unencrypted clear-text passwords in the files they are stored in and use it gain unauthorized access.

Therefore, it is imperative to make all authentication information unreadable using strong encryption during transmission and storage in all system components.

PCI DSS Requirement 8.2.2: Verify user identity before changing any authentication credentials.

Most malicious people use “social engineering” attacks to capture a user ID or change their password. Acting as a legal user, calling a help desk, and asking for user information are examples of social engineering attacks.

If the user requests that their authentication certificates be reset by phone, email, web, or other non-face-to-face methods, the user’s identity must be verified.

Using a “secret question” that can only be answered by the actual user can mitigate such attacks to help administrators identify the user before resetting or changing the authentication information.

PCI DSS Requirement 8.2.3: Passwords must be at least seven characters and contain numeric and alphabetic characters.

Strong passwords are the first defense line for a network because a malicious person often tries to find accounts with weak or non-existent passwords.

As passwords are short or predictable, it is relatively easy for a malicious person to find these inadequate accounts and compromise the network with the valid user ID they have captured.

Passwords used must meet the following requirements:

• Passwords must be at least seven characters.
• Passwords must contain both numerical and alphabetical characters.
• Alternatively, passwords should have complexity and strength at least equivalent to the parameters mentioned above.

In cases where this minimum requirement cannot be met due to technical limitations, organizations may use passwords with equivalent strength for alternative methods they implement.

For detailed information on the variability and equivalence of password strength or entropy for different formats of passwords, see industry standards such as NIST SP 800-63.

PCI DSS Requirement 8.2.4: Change user passwords at least every 90 days.

Passwords that have been valid for a long time without change give malicious people more time to crack a password. User passwords should, therefore, be changed at least every 90 days.

Service providers must also meet the following additional requirements:

• Non-consumer customer user passwords should be changed periodically.
• Non-consumer customer users should be given guidance on when and under what conditions passwords should change.

PCI DSS Requirement 8.2.5: Do not allow a new password to be created that is the same as any of the last four passwords used.

If the password history is not preserved, changing passwords’ effectiveness will decrease, as previous passwords can be used repeatedly.

Requiring passwords not to be reused for a while reduces the likelihood that passwords will be used by guessing or brute-force attacks in the future.

PCI DSS Requirement 8.2.6: Ensure that passwords are changed immediately after first use and after reset.

If a new user uses the same password, an internal user, an ex-employee, or a malicious person can easily find this password and then use it to access accounts. 

Passwords must therefore be changed on first use and after reset.

PCI DSS Requirement 8.3: Secure all non-console administrative access and all remote access to CDE using multi-factor authentication.

Multi-factor authentication requires at least two of the three authentication methods to be used for authentication purposes. Using a factor twice, such as using two separate passwords, is not considered multi-factor authentication. This method is multi-step authentication.

See Also: PCI Multi Factor Authentication Checklist

For multi-factor authentication, at least two of the three authentication methods listed below must be used:

• Something you know (such as a password)
• Something you have (like a smart card)
• Something you are (such as a biometric, fingerprint)

Multi-factor authentication requires that a person submit at least two separate forms of authentication before access is granted. Multi-factor authentication provides additional assurance that the individual trying to gain access is who they claim to be.

With multi-factor authentication, an attacker needs to bypass or take over at least two authentication mechanisms, thereby reducing the risk.

Multi-factor authentication is not required for a particular system component, either at the system level or at the application level. Multi-factor authentication can be performed when a specific network or system component has been authenticated.

Examples of multi-factor authentication technologies include methods such as RADIUS or TACACS.

PCI DSS Requirement 8.3.1: Use multi-factor authentication for all non-console access to the CDE personnel with administrative access.

This requirement is intended to apply to all administratively accessible CDE personnel. This requirement only applies to personnel with administrative access and to access to the CDE only for non-consoles.

Besides, this requirement does not apply to application or system accounts that perform automatic functions. If the organization does not use segmentation to separate the CDE from other networks, the administrator must use multi-factor authentication when logging into the CDE network or any system.

Suppose the CDE is segmented from the rest of the organization’s network. In that case, if the same segmentation is used, the administrator must use multi-factor authentication when connecting to the CDE system from a non-CDE network.

Multi-factor authentication can be used at the network, system, or application level, but neither must be used. If the administrator uses MFA when logging in to the CDE network, they also do not need to use MFA to log in to a particular CDE system or application.

PCI DSS Requirement 8.3.2: Use multi-factor authentication for all remote network access originating outside the enterprise network.

This requirement is intended to be applied to all personnel, including general users with remote access to the network, administrators, and manufacturers providing access for support or maintenance.

Suppose remote access is made so that the cardholder cannot access or affect the data medium. In that case, it is unnecessary to use multi-factor authentication for remote access to that network.

However, multi-factor authentication is required for any remote access to systems that have access to the cardholder data environment. It is recommended to use the organization’s networks for all remote access.

PCI DSS Requirement 8.4: Document and communicate authentication policies and procedures to all users.

Communicating authentication policies and procedures to all users to help them understand and comply with the guidelines. For example, the guide to selecting strong passwords may contain suggestions to help staff choose difficult-to-guess passwords that do not contain dictionary words and do not contain information about user identity.

Guidance on the protection of credentials will help identify malicious people who will prevent passwords from being written or saved in unsafe files and try to exploit their passwords.

If the password is no longer secure, instructing users to change the password can prevent malicious users from using legitimate passwords to gain unauthorized access.

Authentication Policies and procedures should include the following:

• Guidance on choosing robust authentication information
• Guidance on how users should protect their authentication information
• Instructions not to reuse previously used passwords
• Instructions to change passwords in case of suspicion that the password has been exposed.

PCI DSS Requirement 8.5: Do not use group, shared, or public IDs, passwords, or other authentication methods.

If multiple users share the same authentication information, it becomes impossible to track their system access and activities. Shared ids prevent an organization from assigning accountability or effectively logging a person for their actions.

A specific action may have been carried out by anyone familiar with authentication information in the group.

The use of group and shared identities or passwords or other authentication methods in policies and procedures should be explicitly prohibited as follows:

• Public user IDs must be disabled or removed.
• Shared user IDs should not be used for system administration and other critical functions.
• Shared and public user IDs are not used to manage any system component.

PCI DSS Requirement 8.5.1: Additional requirement for service providers only: Service providers with remote access to customer premises should use unique authentication information for each customer.

This requirement only applies when the assessed organization is a service provider. This requirement is not intended to apply to shared hosting providers that access their hosting environments in which multiple client environments are hosted.

To avoid compromising multiple customers using a single set of credentials, manufacturers with remote access accounts to customer environments need to use different authentication credentials for each customer.

Technologies such as multi-factor mechanisms that provide a unique credential for each connection via a one-time password may also meet this requirement’s purpose.

PCI DSS Requirement 8.6: Where other authentication mechanisms are used, the use of these mechanisms should be assigned.

If multiple accounts can use user authentication mechanisms such as tokens, smart cards, and certificates, it may not be possible to identify the individual using the authentication mechanism.

Having physical or logical controls such as biometric data or passwords to identify the account’s user uniquely prevents unauthorized users from gaining access using a shared authentication mechanism.

The use of authentication mechanisms such as physical or logical security tokens, smart cards, or certificates should be assigned as follows:

• Authentication mechanisms should be assigned to a single account and should not be shared among multiple accounts.
• Physical or logical controls must be in place to ensure that only the intended account can use this mechanism to gain access.

PCI DSS Requirement 8.7: Restrict all access to any database containing cardholder data.

Unauthorized or malicious access potential increases in the absence of user authentication when accessing databases and applications. Also, because the user is not authenticated, the system cannot be known, and this access cannot be logged.

Besides, database access should only be provided by program-based methods rather than end-users’ direct access. DBAs that require direct access to the database for administrative tasks to this rule are excluded.

All access to any database containing cardholder data by applications, administrators, and all other users should be limited as follows:

• All user access, user queries, and user actions to databases must be programmatic methods.
• Only database administrators can directly access or query databases.
• Application IDs for database applications can only be used by applications.

PCI DSS Requirement 8.8: Ensure security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties.

Personnel must be aware of and comply with security policies and operational procedures to continuously manage identification and authorization securely.

For detailed information, see the PCI DSS Quick Reference Guide from the PCI SSC Documentation library.

To review all of the PCI DSS Requirements, you can review our PCI DSS Requirements and PCI Compliance articles.