PCI DSS 8.3.1: All user access to system components for users and administrators is authenticated via at least
PCI DSS v4.0.1 control 8.3.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 8.3.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.3
All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
- Something you know, such as a password or passphrase.
- Something you have, such as a token device or smart card.
- Something you are, such as a biometric element.
Summary
Every user and every administrator authenticates with at least one real factor: something they know, have, or are.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 8.3.1.a | Examine documentation describing the authentication factor(s) used to verify that user access to system components is authenticated via at least one authentication factor specified in this requirement. |
| 8.3.1.b | For each type of authentication factor used with each type of system component, observe an authentication to verify that authentication is functioning consistently with documented authentication factor(s). |
The base of Requirement 8 and the assumption behind the rest of it: multi-factor, password strength and lockout all presuppose that authentication happens at all. 8.3.1.a examines documentation of the authentication factors in use; 8.3.1.b observes authentication to verify it matches. The gap this control finds is rarely the main application. It is the service account with no password, the legacy admin interface on an internal network, the shared terminal login, or the database reachable without credentials because it sits behind a firewall. "All user access to system components" includes those.
What to prepare
- Documentation of the authentication factors used for each system component and each class of user.
- Evidence from observation, not just configuration: someone logging in.
- The list of accounts that are not interactive users, and how each authenticates.
How to implement it
1. Inventory the components before the accounts. The failures are systems nobody listed, not users nobody knows. Anything in scope that accepts a login is in scope for this control.
2. Treat network position as not being a factor. "It is only reachable internally" is a control, and a useful one, but it is not something you know, have or are.
3. Give service accounts a real factor and record it. Keys, certificates or managed identities all qualify; a blank password or an implicit trust does not, and these accounts usually hold more privilege than the humans.
4. Retire shared logins deliberately. Where a shared account genuinely cannot be removed, know that it also puts 8.3.6 and the uniqueness requirements in play, and document the compensating position.
Where this commonly fails
- Administrative interfaces on internal networks left unauthenticated because they are not exposed externally.
- Service and integration accounts excluded from the review because they are not people.
- A documented factor that observation contradicts, which is the difference between 8.3.1.a and 8.3.1.b.
- Consoles, out-of-band management and hypervisor access forgotten, though they reach every system component at once.
Related controls
Others in section 8.3:
| Control | What it requires |
|---|---|
| 8.3.2 | Strong cryptography is used to render all authentication factors unreadable during transmission… |
| 8.3.3 | User identity is verified before modifying any authentication factor |
| 8.3.4 | Invalid authentication attempts are limited… |
| 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… |
| 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… |
| 8.3.7 | Individuals are not allowed to submit a new password/passphrase that is the same as any… |
| 8.3.8 | Authentication policies and procedures are documented and communicated to all users… |
| 8.3.9 | If passwords/passphrases are used as the only authentication factor for user access… |
| 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… |
| 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… |
| 8.3.11 | Where authentication factors such as physical or logical security tokens, smart cards… |
← 8.2.8 · All controls · 8.3.2 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it 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. Nothing here is a substitute for advice from a Qualified Security Assessor.