In our ongoing series of articles on the Payment Card Industry Data Security Standard (PCI DSS), we’ve been examining each requirement in detail. Today, we turn our attention to Requirement 8: Identify Users and Authenticate Access to System Components.
This requirement is built on two fundamental principles User identification and authentication,1) identifying individuals or processes on a system and 2) verifying their authenticity.
This is done by assigning unique identifiers and employing authentication factors (like passwords, tokens, or biometrics) to access rights and privileges associated with user, application, system, or service accounts. These practices adhere to industry security standards and the NIST Special Publication 800-63 guidelines, supporting the payment ecosystem.
In this blog post, we will delve into the changes introduced in PCI DSS Requirement 8 from version 3.2.1 to 4.0. We aim to provide a clear understanding of what these changes mean for your organization and how to implement them effectively. check out our comprehensive guide on the “12 requirements of PCI DSS.”
Note: These requirements do not apply to consumers (cardholders)
| Requirement | v3.2.1 (8.5) | v4.0 (8.2.2) | Changes |
|---|---|---|---|
| Overall Focus | Strong emphasis on eliminating shared accounts. | Acknowledges rare cases where shared accounts may be unavoidable, provides a framework for their secure use. | Significant shift in approach. |
| Specific Requirement | - | New: Rules for limited shared account use (duration, documentation, approval, auditability). | New framework for unavoidable exceptions. |
| 8.5.a (v3.2.1) -> 8.2.2.a (v4.0) | Eliminate generic accounts (e.g., "admin"). | Very similar, emphasizes limiting (ideally eliminating) shared accounts. | Minor emphasis shift. |
| 8.5.b (v3.2.1) -> 8.2.2.b (v4.0) | Policies prohibiting shared logins. | Similarly, adds the need for a process to handle potential exceptions. | Wording update, more focus on processes. |
| 8.5.c (v3.2.1) -> 8.2.2.c (v4.0) | Verify user lists, prevent sharing. | Verifying admin understanding of strict shared login rules. | No major change in emphasis. |
| Requirement | v3.2.1 (8.2) | v4.0 (8.3.1) | Changes |
|---|---|---|---|
| Core Requirement | Authentication must use at least one of the following: - Something you know (password) - Something you have (token) - Something you are (biometrics) | Same core requirement. | No changes. |
| Scope | Applies to "non-consumer users and administrators" on all system components. | Slightly less specific, mentions "users and administrators" accessing system components. | The core concept remains, but scoping language has minor modification. |
| Requirement | v3.2.1 (8.1.6 & 8.1.7) | v4.0 (8.3.4) | Changes |
|---|---|---|---|
| Max Invalid Attempts | Lockout occurs after SIX failed attempts. | Lockout occurs after a MAXIMUM of TEN failed attempts. | Increased flexibility on attempts before lockout. |
| Lockout Duration | Minimum of 30 minutes OR until administrator unlocks. | Minimum of 30 minutes OR until administrator confirms the user's identity. | Added emphasis on identity confirmation before unlocking. |
| Requirement | v3.2.1 (8.2.3) | v4.0 (8.3.6) | Changes |
|---|---|---|---|
| Core Principle | Passwords must meet complexity standards (length, mix of characters). | Same core principle. | No changes. |
| Minimum Length | 7 characters minimum. | 12 characters minimum or 8 characters if 12 isn't supported by the system. | Increased minimum lengths for greater security. |
| Character Mix | Must include numbers and letters. | Must include numbers and letters. | No changes. |
| Scope | Broad requirement, password rules apply generally. | Applies specifically when passwords are used as authentication factors for Requirement 8.3.1. | Added clarification of where this complexity rule is mandatory. |
| Requirement | v3.2.1 (8.2.6) | v4.0 (8.3.5) | Changes |
|---|---|---|---|
| General Rule | Passwords must be unique for each user, set on first use/reset, and changed immediately after initial use. | The same core rule applies. | No changes |
| Scope | Applies broadly to all passwords/passphrases. | Specifically applies when passwords/passphrases are used as authentication factors in line with Requirement 8.3.1 (something you know, something you have, something you are). | Added clarification on when this rule is mandated. |
| Requirement | v3.2.1 (8.2.4) | v4.0 (8.3.9) | Changes |
|---|---|---|---|
| Mandatory Change Frequency | Passwords must be changed every 90 days (about 3 months). | Only mandatory if passwords are the sole authentication method (single-factor authentication). | Less rigid password expiration rule. |
| Alternative Option | None. | Allows "dynamic analysis" - systems adapt security based on risk factors, potentially avoiding frequent password changes. | Major flexibility added. |
| Scope | Broadly applies to changing user passwords. | Applies specifically to situations where passwords are the only authentication factor. | Increased specificity. |
| Requirement | v3.2.1 (8.6) | v4.0 (8.3.11) | Changes |
|---|---|---|---|
| Core Principle | Authentication methods (tokens, smart cards, etc.) must be assigned individually, not shared, with controls enforcing this. | Identical principle | No changes. |
| Terminology | Uses the term "authentication mechanisms" throughout. | Shifts to "authentication factors" for consistency. | Terminology update to reflect broader authentication technologies. |
| Requirement | v3.2.1 (8.7) | v4.0 (7.2.6) | Changes |
|---|---|---|---|
| Core Focus | Limiting database access to programmatic methods (apps, stored procedures) and database administrators. | Similar principle, with an emphasis on role-based access and the principle of least privilege. | Greater emphasis on granular access control. |
| Terminology | Applications should use their own IDs, not individual user IDs to access the database. | Apps access data in line with their user roles (authorization levels). | A more nuanced permission system. |
Also Read : PCI DSS Requirement 7
New Requirements in PCI DSS v4.0:
Requirement 8.1.2:
Clearly define who is responsible for each security task related to user accounts and passwords.
(This requirement is effective immediately for all v4.0 assessments.)
- Make sure these records outline who does what in terms of managing user accounts.
- Check that the people in charge of these tasks understand their specific duties.
Requirement 8.3.6:
Passwords must be at least 12 characters long (or 8 if your system has limits). It must include both numbers and letters.
(This requirement is a best practice until 31 March 2025.)
- Look at your system settings to make sure these password rules are enforced.
- This requirement is all about making passwords harder to crack, protecting your sensitive data.
Requirement 8.3.10.1:
Applies to all Service providers (companies that store or process payment card data for others)
The Rule: If customers log in with only a password:
- Option 1: Force password changes every 90 days (about 3 months).
- Option 2: Use technology to constantly analyze account security and limit access if things look suspicious.
Look at the service provider’s system settings to see which option they’ve chosen.
This is about protecting customer data. Single-factor authentication (just a password) is the easiest to hack, so these extra measures are vital.
Requirement 8.5.1: (This requirement is a best practice until 31 March 2025.)
- Systems must prevent login replay attacks.
- No bypasses allowed, even for admins, without time-limited documented management approval.
- Require two-factor authentication for access using different identity proof types (e.g. password and token). Both factors must succeed to login.
- Verify compliance by checking vendor supports replay prevention, reviewing system settings mandate MFA, confirming exceptions are documented and rare, and observing logins remotely and within the card data environment require both factors.
Requirement 8.6.1: (This requirement is a best practice until 31 March 2025.)
- System or application accounts (i.e., not tied to a specific person) are generally banned from interactive logins (directly typing in username and password to access).
- Exceptions Must Be:
– Rare
– Time-limited
– Have a well-documented reason
– Be approved by management
- Each login and action must be tied to a specific person.
- Check your list of system/application accounts.
- Interview those in charge: do these accounts follow these strict procedures?
Requirement 8.6.2: (This requirement is a best practice until 31 March 2025.)
Passwords for accounts that allow direct login must NEVER be stored directly in code or configuration files.
- Hardcoded passwords are easy for hackers to find and exploit.
- This rule forces safe storage of passwords for better security.
- Check that they have clear methods to avoid storing passwords within code.
- Search scripts, configuration files, and custom code to make sure no passwords are directly visible.
Requirement 8.6.3: (This requirement is a best practice until 31 March 2025.)
Change passwords often based on risk level. Higher risk systems need more frequent changes. Use password complexity commensurate with change frequency.
To comply, have clear password policy based on risk assessment, confirm passwords are changed per policy, and verify password strength settings match policy.
Conclusion:
PCI DSS v4.0 requirement 8 emphasizes strong authentication and access controls, while providing flexibility to tailor security to your organization’s risks. Updates like multi-factor authentication, password change alternatives, and a framework for shared accounts address evolving security practices. By prioritizing cardholder data security, v4.0 promotes least privilege, identity verification, and breach accountability to reduce risks in today’s complex business world. Companies should implement v4.0’s guidance to upgrade data protection. Early adoption is key to staying ahead of cyber threats.
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
