- Record the thresholds you chose, then verify each identity store enforces them — directory, cloud tenant, VPN, and application-local logins each have their own settings.
- Prefer lockout or throttling behavior that resists deliberate lockout-as-denial-of-service against known usernames.
- Test the behavior: a policy screenshot proves configuration, a locked test account proves operation.
03.01.08OFFICIAL TITLEPENDING NIST SME REVIEW
03.01.08 — Unsuccessful Logon Attempts
03.01 Access Control · NIST SP 800-171 Rev. 3
Independent summary of the official requirement
Requires enforcing a limit of an organization-defined number of consecutive invalid logon attempts by a user within an organization-defined time period, and automatically taking organization-defined actions — such as locking the account or node for a defined period or until administrator release, or delaying the next logon prompt — when the limit is exceeded (aligned to SP 800-53 AC-7).
Rev. 3 requirement text is multi-part and parameterized with organization-defined values, so this site summarizes rather than reproduces it. The summary is independent — read the official publication for the binding wording.
NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems ↗NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI ↗Independent interpretation
What this requirement is after
Password guessing has to hit a wall: after a defined number of misses in a defined window, the account locks or delays kick in. Cloud identity platforms ship this by default; the gaps are the systems outside them — VPN appliances, local accounts, line-of-business applications with their own logins — where unlimited guessing quietly survives.
Mapped practices
Brilliant at the Basics practices that support this requirement
No practice maps to this requirement — deliberately.
The campaign’s twenty practices are a priority list, not a control catalog, and none of them works this requirement’s substance directly. It still applies to you if it is in your contract’s scope: address it through your own implementation and the related artifacts below, and treat the absence of a mapping here as honesty, not permission to skip it.
Doing the work
Implementation considerations and evidence
- Lockout or throttle configuration exports per identity store, with the defined parameters
- Log samples showing lockouts triggered and cleared
Artifacts
Templates and worksheets with a mapped relationship
No artifact in the library names this requirement yet. The library index groups everything by category and practice.
The other revision
Where this came from in Rev. 2
Provenance
Sources and review status
| Primary sources | NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems · NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI |
|---|---|
| Review status | Pending NIST SME review |
| Content version | 1.0 |
| Updated |