PCI DSS Requirement 8 - Identify Users and Authenticate Access to System Components
Requirement 8 of PCI DSS asks you to give every person their own user ID and to prove who they are before they can reach systems in your card data environment. That means no shared logins, passwords of at least 12 characters, lockouts after repeated failed attempts, and multi-factor authentication (MFA) for all remote access and all non-console access into the card data environment. Since 31 March 2025, that MFA rule covers every user who accesses the card data environment, not just administrators.
Why does every user need a unique ID?
So that every action can be traced to one person. Requirement 8.2.1 says all users get a unique ID before they can access systems or card data. Requirement 8.2.2 says shared, group, or generic accounts are allowed only when necessary, on an exception basis, with a documented business reason, management approval, and a way to confirm who used the account each time. Without unique IDs, the logs that Requirement 10 asks for can't show who did what. A single "frontdesk" login shared by five people makes every entry anonymous.
How should accounts be managed over time?
Requirement 8.2.4 says adding, changing, and removing user IDs and credentials must be authorized and match the documented approval. Requirement 8.2.5 says access for anyone who leaves must be revoked immediately. Requirement 8.2.6 says accounts that have been inactive for 90 days must be removed or disabled. Requirement 8.2.7 says accounts that third parties use to access, support, or maintain your systems are enabled only for the time needed and monitored while in use. A vendor's remote support account that stays switched on all year is a common finding.
What are the password rules?
Requirement 8.3.6 says passwords must be at least 12 characters and include both letters and numbers. If a system can't support 12, the minimum is eight. The 12-character minimum became mandatory on 31 March 2025. Requirement 8.3.7 says a new password can't match any of the last four. Requirement 8.3.5 says first-time and reset passwords must be unique for each user and changed right after first use. Requirement 8.3.9 says that where a password is the only factor protecting an account, it must be changed at least every 90 days, unless the account's security posture is analyzed in real time and access is granted based on that. Requirement 8.3.4 says an account must lock after no more than 10 failed attempts, for at least 30 minutes or until the user's identity is confirmed. Requirement 8.2.8 says a session idle for more than 15 minutes requires the user to log in again.
When is multi-factor authentication required?
MFA means proving who you are with at least two of three factor types: something you know, such as a password; something you have, such as a phone app or hardware token; and something you are, such as a fingerprint. Two passwords are not MFA, because they are the same type of factor. Requirement 8.4.1 says anyone with administrative access needs MFA for non-console access into the card data environment. Requirement 8.4.2, mandatory since 31 March 2025, extends that to all non-console access into the card data environment, by every user. Non-console means anything other than sitting at the machine itself, including connections across your own internal network. Requirement 8.4.3 says all remote network access from outside your network that could reach or affect the card data environment needs MFA, whether the person is an employee, an administrator, or a vendor.
What makes an MFA setup acceptable?
Requirement 8.5.1, also mandatory since 31 March 2025, says an MFA system must resist replay attacks, must use at least two different types of factors, and must require every factor to succeed before access is granted. It also can't be bypassed by any user, administrators included, unless management documents and approves a specific exception for a limited time. If an administrator can click past the second factor, or a failed code still lets someone in, the setup doesn't meet the requirement.
What about system and application accounts?
Accounts used by software, such as a service account that runs backups, are covered too. Since 31 March 2025, Requirement 8.6.1 says that if such an account can be used for interactive login, that use is prevented unless it is needed for an exceptional circumstance, limited in time, approved by management, and traceable to a person. Requirement 8.6.2 says passwords for those accounts must not be hard-coded in scripts, configuration files, or custom source code. Requirement 8.6.3 says the passwords must be protected against misuse and changed periodically, at a frequency set by a targeted risk analysis. A service account that can log in interactively, with its password typed into a backup script, is the classic example.
How does an ASV scan relate to Requirement 8?
An outside scan can't see your password policy. But it can see the login points you expose to the internet, such as remote desktop, SSH, an admin panel, or a database port, and any service that sends passwords without encryption. Those are the doors Requirement 8 is meant to guard. ServerScan is a PCI Approved Scanning Vendor, and our quarterly external scans meet Requirement 11.3.2. The pricing page shows what a plan includes, and Requirement 7 covers what each user is allowed to do once they are logged in.
Go on to Requirement 9 - Physical Access.
Go back to Requirement 7 - Restricting Access.