1Overview
AC.L2-3.1.8 is one of the most mechanical requirements in the framework: limit the number of times someone can fail a logon before the account is locked out. Its purpose is to blunt password guessing, the patient automated attempts that try one password after another until one works, by making the account stop responding after a defined number of failures.
The control is simple to satisfy and simple to verify, which is why it is worth doing correctly and early. A locked account after a handful of wrong passwords turns an unlimited guessing problem into a slow and noisy one, and combined with the logging of those failures it also produces a signal that an attack is underway. The requirement does not prescribe exact numbers; it requires that the organization define a limit and that the system enforce it, so a defensible configuration paired with evidence that it is applied is the whole of the control.
Limit unsuccessful logon attempts.
The requirement names no threshold, because the appropriate limit depends on the environment and its risk tolerance. Common practice, and the direction the related federal baselines point, is a small number of permitted failures followed by a lockout that lasts for a set period or until an administrator intervenes. What the assessment expects is a defined limit, an enforced lockout, and a defined action once the limit is reached.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.1.8 into two objectives: define the means of limiting failed logons (the threshold and the resulting action), and implement it.
The means of limiting unsuccessful logon attempts is defined. The organization has set both the number of consecutive failed attempts permitted before action is taken and the action that follows, such as locking the account for a set duration or until an administrator resets it.
The defined means of limiting unsuccessful logon attempts is implemented. The system actually applies the lockout when the threshold is reached, across the systems that handle CUI, including the standalone machines and local accounts a domain policy does not reach.
The two objectives are a definition and an implementation. Defining the threshold and the lockout action is a policy decision; enforcing it everywhere an account can be attacked is the technical reality, and the common gap is between them: a lockout policy defined in the domain that never reaches the standalone machines or local accounts fails objective [b] even though [a] is complete.
3Failure Patterns
The failures are less about the concept, which is universally understood, than about coverage and about the standalone systems that domain policy does not touch.
The standalone machine outside the policy
A domain lockout policy applies cleanly to domain-joined systems, but the workgroup machine on the shop floor, the standalone controller, or the local administrator account on an isolated system may never receive it. These are exactly the systems most likely to be overlooked and, on a manufacturing floor, most likely to exist, so objective [b] fails on the edges of the environment rather than at its center.
The service and application accounts
Lockout applied bluntly to service accounts can create its own problem, because a service repeatedly presenting a stale password can lock itself out and interrupt operations. This is a real tension rather than an excuse to exempt them, and it is resolved by fixing the underlying credential and monitoring rather than by removing the protection, but shops sometimes disable lockout entirely to stop the disruption, which fails the control.
Counting without consequence
Some configurations record failed attempts but never act on them, satisfying the appearance of the control without its substance. Objective [a] requires that exceeding the limit produce a defined action, and a threshold with no lockout is a counter, not a control.
Cloud and remote surfaces left unprotected
The lockout that protects the internal domain may not extend to the cloud identity used for email and remote access, which is often the more exposed surface. Where CUI or the accounts that reach it live in a cloud service, the equivalent protection has to be configured there as well, and a strong on-premises lockout paired with an unprotected cloud sign-in leaves the easier door open.
4Ownership
This is an IT-owned technical control with little organizational complexity, its main demand being thoroughness across every system and identity surface rather than a decision that leadership must make.
| Role | Responsibility for this control |
|---|---|
| IT lead or system administrator | Defines the lockout threshold and action, enforces them through Group Policy and cloud identity settings, and ensures coverage of standalone machines, local accounts, and remote surfaces. Owns the configuration evidence. |
| Security or compliance lead | Confirms the defined threshold is defensible and that the enforcement reaches every system that handles CUI, including the ones outside the domain. |
| Program lead | Includes lockout coverage in periodic configuration review, since new machines and new cloud services can arrive without the policy, and retains the record. |
5Tooling
The control is enforced with native account-policy settings, and the only real work is applying them consistently everywhere accounts exist.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a], [b] | Group Policy account lockout policy | The lockout threshold, duration, and reset-counter settings that define the limit and the action for domain accounts, recorded as configuration. |
| [b] domain | Group Policy applied to all domain-joined systems | Enforcement across the domain, confirmed to apply on office and shop-floor systems that are domain members. |
| [b] standalone | Local security policy, configuration management, or scripted baselines | The same lockout settings applied to workgroup machines and local accounts that Group Policy does not reach, which is where coverage usually needs deliberate attention. |
| [b] cloud and remote | Entra ID smart lockout, remote access lockout settings | The equivalent protection for cloud identities and remote access surfaces, so the exposed sign-in is covered as thoroughly as the internal one. |
The caveat is coverage rather than capability. Every platform can enforce lockout, and the control fails where a system was missed, so the useful question is not whether lockout is configured but whether it is configured everywhere an account can be attacked. The assessor tests objective [b] by attempting failed logons against representative systems, including the ones off the domain, and watching whether the lockout actually applies.
6Evidence
The satisfied version of 3.1.8 shows the defined limit and action and demonstrates enforcement across the full range of systems and identities.
| Evidence | What it demonstrates |
|---|---|
| Account lockout policy configuration | Objectives [a], [b]. The defined threshold, lockout duration, and reset settings. |
| Group Policy enforcement report | Objective [b]. The lockout policy applied across domain-joined systems. |
| Standalone and local account configuration | Objective [b]. Evidence the same settings reach workgroup machines and local accounts. |
| Cloud and remote lockout configuration | Objective [b]. The equivalent protection on cloud identities and remote access. |
| Lockout event records | Objective [b]. Log entries showing lockouts occurring when the threshold is exceeded, which also feed the audit trail. |
The evidence should demonstrate coverage, not just a single policy screen, because the control is satisfied only where it is actually enforced, and the assessor will probe the systems most likely to have been missed. Because lockouts generate log events, this control also contributes to the audit record, and the failed-attempt entries it produces are among the more useful early signals that credentials are being attacked.
The gaps are on the edges of the network
Account lockout is easy to set in the domain and easy to miss on the standalone shop-floor machine, the local account, and the cloud sign-in. Making sure the protection reaches every system and identity that touches CUI, including the ones outside the domain, is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.1.8. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.1.8[a] and 3.1.8[b]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov