PCI DSS 8.3.4: Invalid authentication attempts are limited
PCI DSS v4.0.1 control 8.3.4: 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
Invalid authentication attempts are limited by:
- Locking out the user ID after not more than 10 attempts.
- Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed.
Summary
Lock an account after no more than ten failed attempts, for at least thirty minutes or until identity is confirmed.
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.4.a | Examine system configuration settings to verify that authentication parameters are set to require that user accounts be locked out after not more than 10 invalid logon attempts. |
| 8.3.4.b | Examine system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until the user’s identity is confirmed. |
The most precisely numbered control in Requirement 8, which makes it one of the easiest to verify and to fail: not more than 10 attempts, minimum 30 minutes or confirmed identity. The numbers are the requirement, so a policy of 15 attempts fails on inspection regardless of other protections. Worth pairing with 8.3.6 on password strength: lockout limits online guessing, complexity limits offline cracking, and neither substitutes for the other. The practical tension is denial of service: an attacker can lock out a known username on purpose: which is an argument for confirmed-identity unlock rather than for a longer threshold.
What to prepare
- Configuration evidence per system showing the threshold and the duration.
- The unlock procedure where identity confirmation is used instead of a timed unlock.
- Coverage across every authentication point, not only the main application.
How to implement it
1. Set it in the identity provider. One place to configure and one place to evidence, rather than per application, which is where the inconsistencies appear.
2. Prefer identity-confirmed unlock. It answers the lockout-as-denial-of-service problem and is explicitly permitted as an alternative to waiting.
3. Check the paths that bypass the front door. An API, a legacy endpoint or a database login often has no lockout at all, and this control is not limited to interactive web login.
4. Rate-limit as well as lock. Lockout is the requirement; rate limiting reduces how often it fires and is what keeps a lockout policy from becoming an outage.
Where this commonly fails
- A threshold above ten, which fails the number outright.
- A lockout duration under thirty minutes with no identity-confirmation alternative.
- The policy set centrally while local accounts on individual components are unaffected.
- API authentication with no lockout, because the control was read as being about login screens.
Related controls
Others in section 8.3:
| Control | What it requires |
|---|---|
| 8.3.1 | All user access to system components for users and administrators is authenticated via at least… |
| 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.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.3.3 · All controls · 8.3.5 →
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.