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)
[table id=49 /]
[table id=50 /]
[table id=51 /]
[table id=53 /]
[table id=54 /]
[table id=55 /]
[table id=56 /]
[table id=57 /]
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.
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.
