Requirement 8: Identify Users and Authenticate Access to System Components

Requirement 8 is the largest requirement by control count after Requirement 12, and it changed more than any other in v4.0.1.

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 cannot support 12, eight is permitted only if that limitation is genuine and documented.

MFA is now required for all access into the CDE (8.4.2), not only for remote access and not only for administrators. This is the change that catches most entities on their first v4 assessment, because it extends to console access from inside the office.

8.6 addresses application and system accounts. Interactive use is constrained, and hard-coded credentials in scripts must be protected and changed periodically.

Does it apply to you?

All users and all accounts on in-scope systems, including third-party and vendor accounts.

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 no shared accounts

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 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 console 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

Official source

This page is original commentary. It cites requirement identifiers and the official requirement title, and does not reproduce the text of the standard. For the authoritative wording, including each testing procedure and the customized approach objective, download PCI DSS v4.0.1 (June 2024) 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.