8 — Identify Users and Authenticate Access to System Components
28 requirements in the Identify Users and Authenticate Access to System Components requirement
8.1.1All security policies and operational procedures that are identified in Requirement 8 are: Documented.
8.1.2Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.
8.2.1All users are assigned a unique ID before access to system components or cardholder data is allowed.
8.2.2Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: ID use is prevented unless needed for an exceptional circumstance.
8.2.3Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises.
8.2.4Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: Authorized with the appropriate approval.
8.2.5Access for terminated users is immediately revoked
8.2.6Inactive user accounts are removed or disabled within 90 days of inactivity.
8.2.7Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows: Enabled only during the time period needed and disabled when not in use.
8.2.8If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session.
8.3.1All 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.
8.3.2Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
8.3.3User identity is verified before modifying any authentication factor.
8.3.4Invalid authentication attempts are limited by: Locking out the user ID after not more than 10 attempts.
8.3.5If passwords/passphrases are used as authentication factors to meet Requirement 8.
8.3.6If passwords/passphrases are used as authentication factors to meet Requirement 8.
8.3.7Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
8.3.8Authentication policies and procedures are documented and communicated to all users including: Guidance on selecting strong authentication factors.
8.3.9If passwords/passphrases are used as the only authentication factor for user access (i.
8.3.10Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.
8.3.11Where 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.
8.4.1MFA is implemented for all non-console access into the CDE for personnel with administrative access.
8.4.2MFA is implemented for all non-console access into the CDE.
8.4.3MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE.
8.5.1MFA systems are implemented as follows: The MFA system is not susceptible to replay attacks.
8.6.1If accounts used by systems or applications can be used for interactive login, they are managed as follows: Interactive use is prevented unless needed for an exceptional circumstance.
8.6.2Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.
8.6.3Passwords/passphrases for any application and system accounts are protected against misuse as follows: Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.