Requirement 8: Identify Users and Authenticate Access to System Components

PCI DSS v4.0.1 Requirement 8: unique IDs, the 12-character password rule, and where multi-factor authentication is now mandatory.

PCIComplianceHubLast updated Last reviewed against PCI DSS v4.0.1

Requirement 8 is one of the largest requirements by control count. Several of its controls were new or strengthened in v4.0 and have been mandatory since 31 March 2025, including the 12-character password minimum and MFA for all non-console access into the CDE.

PCI DSS v4.0.1 breaks this requirement into 6 sections containing 29 individual controls.

What this requirement is actually asking

Passwords moved to a minimum of 12 characters (8.3.6), up from seven. Where a system does not support 12 characters, the minimum is eight, and passwords contain both letters and numbers. The rule does not cover application and system accounts, which fall under 8.6, or point-of-sale accounts that can reach only one card number at a time.

MFA is now required for all non-console access into the CDE (8.4.2), not only for remote access and not only for administrators. Non-console means access over a network interface, so it covers staff who connect to the CDE from inside the office. It does not apply to direct physical console access, to application or system accounts performing automated functions, to point-of-sale accounts that can reach only one card number at a time, or to user accounts that authenticate only with phishing-resistant factors.

8.6 addresses application and system accounts. Interactive login is prevented except for an exceptional circumstance (8.6.1). Passwords for accounts that can log in interactively are not hard coded in scripts, configuration files or custom source code (8.6.2). Passwords for all these accounts are changed at the frequency set in a targeted risk analysis, and on suspicion or confirmation of compromise (8.6.3).

Does it apply to you?

All users and all accounts on in-scope systems, including administrator, point-of-sale, application and system accounts, and third-party and vendor accounts. Accounts used by consumers (cardholders) are out of scope, and some controls exclude point-of-sale accounts that can reach only one card number at a time.

The controls

Requirement 8 contains 29 controls across 6 sections. Each links to its own page with the requirement in full and the testing procedures an assessor uses to verify it.

8.1: Governance for identification and authentication

Control What it requires Guidance
8.1.1 All security policies and operational procedures that are identified in Requirement 8… Yes
8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned… Yes

8.2: Unique IDs, account lifecycle, and shared IDs only by exception

Control What it requires Guidance
8.2.1 All users are assigned a unique ID before access to system components or cardholder data… Yes
8.2.2 Group, shared, or generic IDs, or other shared authentication credentials are only used… Yes
8.2.3 Service providers with remote access to customer premises use unique authentication factors… Yes
8.2.4 Addition, deletion, and modification of user IDs, authentication factors… Yes
8.2.5 Access for terminated users is immediately revoked Yes
8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity Yes
8.2.7 Accounts used by third parties to access, support… Yes
8.2.8 If a user session has been idle for more than 15 minutes… Yes

8.3: Authentication factor strength, including the 12-character rule

Control What it requires Guidance
8.3.1 All user access to system components for users and administrators is authenticated via at least… Yes
8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission… Yes
8.3.3 User identity is verified before modifying any authentication factor Yes
8.3.4 Invalid authentication attempts are limited… Yes
8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user… Yes
8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity… Yes
8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any… Yes
8.3.8 Authentication policies and procedures are documented and communicated to all users… Yes
8.3.9 If passwords/passphrases are used as the only authentication factor for user access… Yes
8.3.10 Service providers: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users… Yes
8.3.10.1 Service providers: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either… Yes
8.3.11 Where authentication factors such as physical or logical security tokens, smart cards… Yes

8.4: Where MFA is required. Now all non-console CDE access

Control What it requires Guidance
8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative… Yes
8.4.2 MFA is implemented for all non-console access into the CDE Yes
8.4.3 MFA is implemented for all remote access originating from outside the entity’s network… Yes

8.5: MFA implemented so it cannot be bypassed or replayed

Control What it requires Guidance
8.5.1 MFA systems… Yes

8.6: Application and system accounts, and embedded credentials

Control What it requires Guidance
8.6.1 If accounts used by systems or applications can be used for interactive login, they… Yes
8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive… Yes
8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse… Yes

Evidence your assessor will ask for

  • Password policy configuration exported from the identity provider, not a policy document
  • MFA enforcement evidence per access path, including cloud consoles, web-based access and jump hosts
  • Account inventory showing every account maps to an individual, with shared accounts justified under 8.2.2
  • Records of credential rotation for application accounts

Where this commonly fails

  • MFA on the VPN but not on the cloud console, which is a separate path into the same CDE
  • Service accounts with interactive login still enabled
  • Hard-coded credentials in deployment scripts or CI configuration

Terms

Glossary entries that name a control in this requirement:

Official source

The commentary on this page is our own. The requirement title, and the control text in the tables above (shortened where it ends in an ellipsis), are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. Each control's own page carries its requirement text in full. For the authoritative wording, including each testing procedure and the customized approach objective, download the standard from the PCI Security Standards Council document library.

PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site.