PCI DSS Requirement 8 - Changes from v3.2.1 to v4.0 Explained

Published on : 28 Feb 2024

PCI DSS Requirement 8

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) 

Requirementv3.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.
Requirementv3.2.1 (8.2.3)v4.0 (8.3.6) Changes
Core PrinciplePasswords must meet complexity standards (length, mix of characters).Same core principle. No changes.
Minimum Length7 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 FrequencyPasswords 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 principleNo 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 FocusLimiting 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. 


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. 



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.


5/5 - (1 vote)
Narendra Sahoo
Narendra Sahoo

Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.