PCI DSS Requirement 8: identity and authentication
By Sam Rivera, Founder, SentinelPanda · August 6, 2026 · 3 min read · PCI DSS
Two v4.0 changes here have caught more organisations than anything else in the standard: 12-character passwords, and MFA for all access into the cardholder data environment.
Unique identification
Requirement 8.2.1 requires that all users are assigned a unique ID before access is granted. Requirement 8.2.2 prohibits shared, group, and generic accounts unless they are necessary on an exception basis, managed, with individual accountability maintained and use documented.
The point is attribution: if three administrators share a root account, your Requirement 10 audit logs cannot tell you who made a change. This is why unique IDs sit upstream of logging — one requirement quietly determines whether another is achievable.
Requirement 8.2.4 and 8.2.5 cover the lifecycle: additions, deletions, and modifications managed through a formal process, and access for terminated users revoked immediately. Requirement 8.2.6 requires inactive accounts to be removed or disabled within 90 days.
The password changes in v4.0
- Minimum length of 12 characters — up from 7 — containing both numeric and alphabetic characters (8.3.6). Where a system cannot technically support 12, the minimum is 8, but you need to demonstrate the technical constraint.
- Passwords changed at least every 90 days (8.3.9) — unless you take the alternative: dynamically analysing account security posture and granting access in real time accordingly. Organisations that have moved to modern risk-based authentication can use this route.
- Passwords must not match any of the previous four used (8.3.7).
- Passwords protected with strong cryptography during transmission and storage (8.3.2).
- Requirement 8.6 covers application and system accounts, including restrictions on interactive login and management of their credentials.
The MFA expansion
This is the change with the largest engineering impact. Under v3.2.1, MFA was required for administrative access to the CDE and for remote network access originating outside the entity's network. v4.0 kept both (8.4.1, 8.4.3) and added 8.4.2: MFA for all access into the CDE.
The word "all" is doing real work. Non-administrative users accessing systems in the cardholder data environment now need MFA too, including from inside the corporate network. For organisations that treated the internal network as trusted, this is a genuine architectural change rather than a configuration tweak.
Requirement 8.5.1 sets the quality bar for MFA systems: not susceptible to replay attacks, not bypassable by any user including administrators unless specifically documented and authorised for a limited time, at least two different factor types, and access granted only after all factors succeed. That last clause rules out implementations that grant partial access after the first factor.
Practical sequencing
If you are moving from v3.2.1 to v4.0.1, address 8.4.2 first — it is the change most likely to require new infrastructure, identity provider work, or network redesign, and it is the one least amenable to being solved the week before an assessment. The password length change is comparatively simple policy and configuration work.