Requirement 8 is where PCI DSS v4.0.1 sets specific values for passwords, lockout, sessions and MFA, so every authentication store needs checking against it, not only the main directory. This guide works through Requirement 8 sub-requirement by sub-requirement: unique IDs and account lifecycle (8.2), authentication factors and password parameters (8.3), where MFA is required (8.4), how MFA must be built (8.5), and how this fits with system and application accounts (8.6). It is written for identity engineers, PCI programme owners and internal auditors preparing evidence for a QSA or a self-assessment. Requirement wording is summarised, not quoted, because the standard itself is published as a PDF in the PCI SSC Document Library; check every value against the current standard before relying on it.
Key takeaways
- Every person gets a unique ID before touching any system component or cardholder data (8.2.1); shared and generic IDs are exceptions that need justification, approval and individual attribution (8.2.2).
- The password settings are specific: the standard sets a minimum length and letters-and-numbers composition (8.3.6), a password history (8.3.7) and a lockout threshold and duration (8.3.4); read the exact values in the current standard. A PCI SSC FAQ confirms re-authentication after 15 minutes idle (8.2.8).
- MFA covers all non-console access into the CDE (8.4.2), not only administrators (8.4.1) and remote access (8.4.3); PCI SSC FAQs say FIDO2 phishing-resistant authentication, including synced passkeys, can stand alone only for 8.4.2.
- 8.3.9 applies only to single-factor passwords: where MFA protects all in-scope access, a PCI SSC FAQ says the 90-day change or dynamic analysis requirement can be assessed as not applicable.
- MFA design is assessed too: 8.5.1 requires MFA that resists replay, cannot be bypassed (including by administrators without documented exception), uses two different factor types and needs every factor to succeed before access.
How Requirement 8 is structured
Requirement 8, "Identify Users and Authenticate Access to System Components", has six sections. Requirement 7 decides what an identity may do; Requirement 8 proves who the identity is. Section 8.6 on system and application accounts is covered in depth in the PCI DSS Requirements for Service Accounts and NHIs Guide, and the wider standard in the PCI DSS 4.0 Guide. This page focuses on 8.1 to 8.5.
| Section | Subject | Sub-requirements | What assessors usually ask for |
|---|---|---|---|
| 8.1 | Policies, procedures, roles | 8.1.1, 8.1.2 | Current documented procedures and a RACI for identity tasks |
| 8.2 | User identification and account lifecycle | 8.2.1 to 8.2.8 | Account listings, HR leaver reports, inactivity reports, session settings |
| 8.3 | Strong authentication for users and administrators | 8.3.1 to 8.3.11 | Password policy configuration per system, hashing settings, reset procedure |
| 8.4 | Where MFA is required | 8.4.1 to 8.4.3 | Network diagrams of access paths into the CDE, MFA policy coverage |
| 8.5 | How MFA systems are configured | 8.5.1 | MFA configuration, bypass and exception records, observation of a login |
| 8.6 | System and application accounts | 8.6.1 to 8.6.3 | Service account inventory, interactive-login controls, rotation evidence |
Several v4.0 additions were future-dated and became mandatory on 31 March 2025, according to the PCI SSC, including several in Requirement 8; the standard marks which ones. If your last assessment was before that date, those controls may not have been tested yet.
8.2: unique IDs and the account lifecycle
- 8.2.1 unique IDs: every user has a unique ID before access is allowed. In practice this means named accounts in the directory, named database logins rather than one application owner login used by DBAs, and named console users on network devices fed from TACACS+ or RADIUS.
- 8.2.2 shared and generic IDs: allowed only by exception, limited to the time needed, with documented business justification, management approval, and the individual's identity confirmed before access so that every action can be attributed to a person. A privileged access tool that checks out a shared root or
sacredential to a named user, with session recording, is the usual way to meet this. See the Privileged Access Management Guide. - 8.2.3 service providers only: unique authentication factors for each customer premises. One support password used across all customers fails this.
- 8.2.4 lifecycle changes: adding, deleting and modifying IDs, factors and other identifier objects is authorised and done with the approved privileges. Ticket references on account creation are the normal evidence.
- 8.2.5 leavers: access for terminated users is revoked immediately. Reconcile HR termination dates with disable timestamps, including local accounts and SaaS tools in scope. See the Joiner-Mover-Leaver Guide.
- 8.2.6 inactivity: inactive user accounts are removed or disabled within the period the standard sets.
- 8.2.7 third-party remote access: accounts used by third parties to access, support or maintain system components are enabled only for the time needed and monitored for unexpected activity.
- 8.2.8 idle sessions: a session idle for more than 15 minutes requires re-authentication. This applies to console, remote desktop, SSH and web administrative consoles, not only to workstation screen locks.
8.3: authentication factors and password parameters
8.3.1 requires all user and administrator access to be authenticated with at least one factor: something you know, something you have or something you are. The remaining items set how factors are protected and, where passwords are used, how strong they must be.
| Sub-requirement | Value or rule (v4.0.1) | Typical setting to check |
|---|---|---|
| 8.3.2 factor protection | Strong cryptography makes factors unreadable in transmission and storage | TLS on all login paths; salted, slow password hashing in custom apps |
| 8.3.3 identity before change | User identity verified before any factor is changed | Helpdesk reset procedure; self-service reset flow |
| 8.3.4 lockout | Lock out after a maximum number of invalid attempts, for a minimum period or until identity is confirmed (values in the standard) | Account lockout threshold and duration in directory and each local auth store |
| 8.3.5 first use and reset | Unique value for first use and reset, changed immediately after first use | "Must change at next logon" on temporary passwords |
| 8.3.6 length and composition | Minimum length set in the standard, with a lower fallback where a system cannot support it, and numeric and alphabetic characters | Minimum length and complexity per system, including appliances |
| 8.3.7 history | Not equal to a set number of previous passwords | Password history setting that meets the standard |
| 8.3.8 user guidance | Authentication policies and procedures documented and communicated | Published password and MFA guidance |
| 8.3.9 lifetime (single factor) | Change at least every 90 days, or analyse security posture dynamically and decide access in real time | Maximum password age, or a risk engine on the login path |
| 8.3.10 and 8.3.10.1 | Service providers: guidance to customer users, and lifetime rules where customer passwords are the only factor | Customer portal password and MFA options |
| 8.3.11 physical and logical factors | Tokens, smart cards and certificates are assigned to one user and not shared | Token assignment register; certificate issuance per user |
Two practical points. First, 8.3.6 allows a lower length where a system cannot support the standard minimum; keep the vendor documentation showing the cap. Second, 8.3.9 does not apply where MFA protects all in-scope access. The PCI SSC FAQ on 8.3.9 and 8.3.10.1 says those requirements apply only where passwords are part of single-factor authentication, and that an assessor can mark them not applicable when MFA covers all in-scope components, with the reason documented in the ROC. See the Password Policy Guide (NIST-aligned).
Reconciling PCI DSS with NIST SP 800-63B
NIST SP 800-63B (revision 4) says verifiers shall not impose composition rules or periodic password changes, requires a blocklist of common and compromised values, and sets a 15-character minimum where a password is the only factor (8 when used inside MFA). PCI DSS 8.3.6 still asks for letters and numbers, and 8.3.9 still offers a 90-day change for single-factor passwords. Our recommendation at NHI Mgmt Group: set a minimum of 15 characters for single-factor passwords, which satisfies both, keep the letters-and-numbers rule on CDE systems because PCI requires it, add a breached-password blocklist, and remove single-factor passwords from the CDE so that 8.3.9 stops applying and NIST's no-expiry guidance can be followed. See the Breached password checks guide.
8.4: where MFA is required
| Sub-requirement | Who and what | Can phishing-resistant authentication stand alone? |
|---|---|---|
| 8.4.1 | All non-console access into the CDE by personnel with administrative access | No. PCI SSC FAQ 1596 says it must be combined with another factor |
| 8.4.2 | All non-console access into the CDE, every user | Yes. The applicability note allows phishing-resistant factors alone; FAQ 1595 confirms FIDO2 synced passkeys qualify |
| 8.4.3 | All remote network access from outside the entity's network that could access or impact the CDE, including users, administrators and third parties | No. FAQ 1596 applies the same rule as 8.4.1 |
- Two layers for administrators: an administrator on the corporate network who reaches the CDE through a jump host needs MFA at the CDE boundary under 8.4.1, even if they already used MFA to sign in to the corporate network. Remote administrators may hit both 8.4.3 (into the network) and 8.4.1 (into the CDE).
- What "non-console" means: any logical access over a network interface, including SSH, RDP, web consoles and database clients. Direct physical console access is outside 8.4.1 and 8.4.2.
- Cloud consoles count: where cloud management planes can change CDE components, treat console and API access as into or impacting the CDE. See the Cloud Provider Mandatory MFA guide.
- Non-human access: the 8.4 requirements are written for people. Application and system accounts are governed by 8.6; do not create interactive accounts for scripts to avoid MFA. See the How to Find Accounts Excluded From MFA and Conditional Access guide.
8.5: building MFA that an assessor will accept
8.5.1 sets five tests for any MFA system protecting CDE access:
- Replay resistance: captured factors cannot be replayed. Static codes and reusable OTP seeds fail.
- No bypass: MFA cannot be bypassed by any user, including administrators, unless specifically documented and authorised by management on an exception basis for a limited time. Watch for "trusted IP" exclusions, legacy protocol paths and break-glass accounts. See the Break-Glass Account Guide.
- Two different factor types: a password plus a security question is two things you know and fails.
- All factors succeed before access: the PCI SSC FAQ on factor feedback (article 1584) confirms all factors must succeed before access is granted. It allows showing that one factor succeeded before the next is presented.
- Independence: access to one factor must not give access to the other. An OTP delivered to the same desktop session the password is typed into weakens this; assessors look at the delivery path.
Push approval fatigue is not named in 8.5.1, but number matching and phishing-resistant methods reduce it. See the MFA Fatigue and Bypass Guide and the Phishing-Resistant MFA Guide.
Decision guidance
| Situation | Option A | Option B | Our view |
|---|---|---|---|
| User access into the CDE (8.4.2) | Password plus OTP or push | FIDO2 passkey or smart card alone | B for staff with managed devices: it meets 8.4.2 alone and removes 8.3.9 scope; keep A for edge cases |
| Administrative access (8.4.1) | Phishing-resistant factor plus PIN or password | Password plus OTP | A: it meets FAQ 1596 and resists phishing |
| Legacy system that cannot take MFA | Front it with a jump host or PAM gateway enforcing MFA | Compensating control documented in the ROC | A where possible; B needs a documented compensating control assessment |
| Single-factor password lifetime (8.3.9) | 90-day change | Dynamic posture analysis | Prefer removing single-factor access; if not, dynamic analysis only where you can show the risk engine's decisions |
Smaller merchants on an SAQ often have few CDE access paths: a single jump host with MFA and a password manager for appliance accounts covers most of Requirement 8. Large service providers usually need an identity provider policy set per access path, a PAM tool for 8.2.2 shared credentials, and separate evidence for 8.2.3 and 8.3.10. Use the PCI DSS SAQ Types Guide to confirm which sub-requirements your SAQ includes.
How to implement Requirement 8
- Map every access path into the CDE: list each way a person or system reaches CDE components (VPN, jump hosts, cloud consoles, SaaS admin portals, database clients, out-of-band management). Use the PCI DSS Scoping and Segmentation Guide to confirm scope.
- Inventory authentication stores: directory, local OS accounts, database logins, network devices, hypervisors and SaaS tools. Record each store's password, lockout and session settings against 8.2.8 and 8.3.4 to 8.3.7.
- Fix the cheap settings first: lockout, history, minimum length, idle timeout and first-use change are configuration changes. Pilot on a test group, then roll out per store. Roll back by restoring the previous policy object.
- Close shared and generic IDs: replace them with named accounts, or vault them with check-out to named users for 8.2.2.
- Enforce MFA per path: start in report-only or audit mode where your identity provider supports it, confirm coverage, then enforce. Keep documented, time-limited exceptions with management approval for 8.5.1.
- Automate leaver and inactivity controls: drive 8.2.5 from HR events and run a scheduled job for the inactivity rule in 8.2.6, covering local accounts as well as the directory.
- Collect evidence continuously: configuration exports, MFA policy coverage reports, leaver reconciliation and exception registers, so the assessment is a review rather than a scramble.
Detection and measurement
- What to log: successful and failed authentication, lockouts, MFA challenges and failures, MFA method registration and reset, account creation, disablement and privilege change. Requirement 10 sets the required log content.
- What to alert on: spikes in lockouts across many accounts (password spraying, ATT&CK T1110.003), logins to CDE systems that did not pass MFA, use of shared IDs without a matching check-out, and third-party accounts active outside their approved window.
| Metric | Target | Requirement |
|---|---|---|
| Access paths into the CDE enforcing MFA | 100% | 8.4.1 to 8.4.3 |
| Median time from HR termination to account disable | Same day | 8.2.5 |
| Accounts past the inactivity limit still enabled | 0 | 8.2.6 |
| Authentication stores meeting length, lockout and history settings | 100% | 8.3.4 to 8.3.7 |
| Open MFA bypass exceptions past their expiry | 0 | 8.5.1 |
| Shared ID sessions without named check-out | 0 | 8.2.2 |
Framework mapping
| PCI DSS v4.0.1 | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ATT&CK technique addressed |
|---|---|---|---|
| 8.2.1, 8.2.2 unique and shared IDs | IA-2, IA-4 | PR.AA-01 | T1078 Valid Accounts |
| 8.2.5, 8.2.6 leavers and inactivity | AC-2, AC-2(3) | PR.AA-01 | T1078 Valid Accounts |
| 8.2.8 idle sessions | AC-11 | PR.AA-03 | |
| 8.3.4 lockout | AC-7 | PR.AA-03 | T1110 Brute Force |
| 8.3.5 to 8.3.7, 8.3.9 passwords | IA-5, IA-5(1) | PR.AA-01 | T1110.003 Password Spraying |
| 8.4.1 to 8.4.3, 8.5.1 MFA | IA-2(1), IA-2(2) | PR.AA-03 | T1078 Valid Accounts |
For ISO/IEC 27001 alignment, see the PCI DSS 4.0 to ISO 27001 Mapping Guide.
Common failure patterns
- MFA only at the VPN: 8.4.3 is met, but internal administrators reach CDE servers with a password alone, failing 8.4.1 and 8.4.2.
- Local accounts forgotten: the directory meets 8.3.4 and 8.3.6, but appliances, hypervisors and database logins keep vendor defaults for lockout and length.
- Exclusions that become permanent: trusted network locations or "temporary" MFA exclusions without expiry, which fail the bypass test in 8.5.1.
- Treating phishing-resistant authentication as enough everywhere: per FAQ 1596 it stands alone only for 8.4.2; administrative and remote access need a second factor.
- Service accounts used by people: engineers sign in with an application account to avoid MFA, breaking 8.2.1 attribution and 8.6.1. See the Service Account Security Guide.
- Third-party access left on: vendor support accounts enabled permanently instead of for the time needed, failing 8.2.7.
Practitioner checklist
- Map every access path into or able to impact the CDE and record the MFA control on each (8.4.1 to 8.4.3).
- Confirm every authentication store meets the standard's minimum length, history and lockout values and 15-minute idle re-authentication.
- Remove or vault shared and generic IDs with named check-out and approval (8.2.2).
- Reconcile HR leavers with account disablement and run a scheduled inactivity job (8.2.5, 8.2.6).
- Enable third-party remote access accounts only when needed and monitor them (8.2.7).
- Test MFA for replay, bypass, factor types and full success before access (8.5.1); keep a dated exception register.
- Use phishing-resistant factors for 8.4.2 and pair them with a second factor for 8.4.1 and 8.4.3.
- Decide whether single-factor passwords remain in scope; if not, document why 8.3.9 is not applicable.
Standards and references
- PCI SSC: Document Library (PCI DSS v4.0.1)
- PCI SSC FAQ 1595: Synced passkeys and Requirement 8.4.2
- PCI SSC FAQ 1596: Phishing-resistant authentication for 8.4.1 and 8.4.3
- PCI SSC FAQ: Purpose of Requirement 8.2.8 (15 minutes idle)
- PCI SSC FAQ 1590: Scope of 8.3.9 and 8.3.10.1
- PCI SSC FAQ 1584: MFA factor success feedback
- PCI SSC Blog: Requirements effective after 31 March 2025
- NIST: SP 800-63B Authentication and Authenticator Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Requirements for Service Accounts and NHIs Guide, Access Reviews Guide, MFA Guide, PCI DSS Readiness Checklist. This guide summarises PCI DSS v4.0.1 Requirement 8 and is not legal or assessment advice.