PCI DSS Requirement 8: Identification, Authentication and MFA

PCI DSS Requirement 8, Identify users and authenticate access to system components, makes every action on a card data system traceable to one person and makes that person prove who they are. Each user needs a unique ID. Passwords, where used, must be at least 12 characters with letters and numbers. Accounts lock after no more than 10 failed attempts. Multi-factor authentication (MFA) is required for all non-console access into the cardholder data environment (CDE) and for any remote access that could reach it. System and application accounts must be tightly controlled, with no passwords hard-coded in scripts.

Several of these rules, including the 12-character minimum, MFA for all CDE access and the system account controls, became mandatory on 31 March 2025, so a password policy written for v3.2.1 will not pass today. This guide covers Requirement 8 in PCI DSS v4.0.1; for the other requirements, see our overview of the PCI DSS requirements, or take our free PCI compliance check to see your likely SAQ and where you stand across all 12.

What does PCI DSS Requirement 8 cover?

Requirement 8 has six sections, from user identification (8.2) through password and authentication rules (8.3), MFA (8.4 and 8.5) to system and application accounts (8.6). Items marked † became mandatory on 31 March 2025.

Why does every user need a unique ID?

Because the rest of PCI DSS depends on it. Logs under PCI DSS Requirement 10 are only useful if each entry points to one person. Requirement 8.2.1 requires a unique ID before anyone can reach system components or card data, and 8.2.2 allows shared or generic accounts only by exception: approved by management, limited in time, with the user’s identity confirmed and every action attributable to an individual.

The lifecycle rules matter as much: account changes need approval (8.2.4), leavers lose access immediately (8.2.5), accounts unused for 90 days are removed or disabled (8.2.6), and vendor remote access accounts are enabled only when needed and monitored while in use (8.2.7). Sessions idle for more than 15 minutes must require re-authentication (8.2.8).

What are the PCI DSS password requirements?

Passwords must be at least 12 characters and contain both numbers and letters (8.3.6), must not repeat any of the last four (8.3.7), and the account must lock after no more than 10 failed attempts (8.3.4). The 12-character minimum is the main PCI DSS 4.0 password change: v3.2.1 asked for seven, and the new length has been mandatory since 31 March 2025. A system that cannot support 12 characters may use eight. Passwords are not compulsory: Requirement 8.3.1 accepts something you know, something you have (such as a token or smart card) or something you are (a biometric), so the rules below apply only where passwords are used.

The length and reuse rules do not apply to cashier IDs on point-of-sale terminals that can access only one card number at a time, and system and application accounts are governed by 8.6 instead. For stored passwords, the OWASP Password Storage Cheat Sheet describes the salted, slow hashing that meets 8.3.2 in practice.

Where is MFA required under PCI DSS?

PCI multi-factor authentication is required in two places: on all non-console access into the CDE (8.4.1 for administrators, and since 31 March 2025, 8.4.2 for every user), and on all remote access from outside your network that could access or affect the CDE, by staff and third parties alike (8.4.3). Non-console access means any logical access over a network rather than at the machine itself, including from inside your own office.

MFA at the remote-access gateway does not replace MFA into the CDE: someone who connects remotely and then into the CDE authenticates with MFA twice. MFA into the CDE can sit at the network or the system level; it does not have to be applied at both. PCI DSS v4.0.1 added an exception to 8.4.2 for user accounts that authenticate only with phishing-resistant factors, such as FIDO2 security keys. The administrator and remote access rules in 8.4.1 and 8.4.3 still apply.

What counts as two-factor authentication for PCI compliance?

Two-factor authentication is the most common form of MFA, and it counts only if the two factors are of different types: something you know, something you have, something you are. A password plus a security question is one type used twice. Requirement 8.5.1, mandatory since 31 March 2025, adds that the MFA system must resist replay attacks, must not be bypassable by anyone, administrators included, except by documented and time-limited management exception, and must require every factor to succeed before access is granted.

Our glossary entry on two-factor and two-step verification explains why some “two-step” logins are not true MFA. If you also hold Cyber Essentials, our guide to MFA under Cyber Essentials covers that scheme’s separate rule for cloud services.

How should PCI service accounts be managed?

Treat them as privileged credentials that nobody logs in with. Requirement 8.6, mandatory since 31 March 2025, sets three controls:

• 8.6.1: if a system or application account can be used for interactive login, that use is prevented unless needed for an exceptional circumstance, limited in time, justified, approved by management, and traceable to a named person.
• 8.6.2: passwords for system and application accounts that can be used for interactive login are not hard-coded in scripts, configuration or property files, or bespoke and custom source code. A password vault or secrets manager is the usual answer.
• 8.6.3: passwords are changed periodically and on suspicion of compromise, at a frequency you set through a targeted risk analysis, and are complex enough for that frequency.

Expect your assessor to examine scripts, configuration files and custom source code for embedded credentials, as the 8.6.2 testing procedure directs. Hard-coded passwords are quick to find and often slow to fix, because each application has to be changed to fetch its credentials from a vault.

How do you prepare Requirement 8 evidence?

Export the user list for every CDE system and check it against HR leaver records. Screenshot authentication and lockout settings on each platform, not just your directory service, because databases, network devices and payment applications often have their own. Document every MFA path into the CDE and be ready to demonstrate it live. Keep an exception register for shared accounts and MFA bypasses. Our PCI DSS compliance checklist lists the evidence for every requirement in one place, and our guide to PCI documentation covers the Requirement 8 policies and procedures that 8.1.1 asks for.

Why work with Sovereign Secure?

Sovereign Secure is a PCI SSC-approved Qualified Security Assessor (QSA) company, Qualified PIN Assessor (QPA) and Card Production Security Assessor (CPSA), and a member of the PCI SSC Global Executive Assessor Roundtable (GEAR) for 2026 to 2028. We are ISO 27001 certified, have been a UK company since 2012, and test authentication controls in our penetration testing as well as in assessments. Where we both advise and assess, the two pieces of work are kept separate, as the PCI SSC expects of a QSA company.

Want your access controls checked before the assessment?

Our PCI DSS consultancy team can review your MFA design, password settings and service accounts against Requirement 8 and show you what an assessor will test. The full requirement text is free from the PCI SSC document library. Contact us or call +44 161 523 5276.