Testing Account Lockout Controls: The Ultimate Guide (AC.L2-3.1.8)

CMMC account lockout control testing verifies that systems limit repeated unsuccessful logon attempts using a documented threshold, lockout action, and recovery process. For AC.L2-3.1.8 under NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2, an organization must define its approach, implement it across in-scope systems, and retain evidence that the setting works as intended. A strong program tests both the configuration and the real-world outcome: failed attempts trigger a lockout, authorized personnel can restore access appropriately, and exceptions do not create uncontrolled risk.

What does AC.L2-3.1.8 require?

AC.L2-3.1.8 requires the organization to limit unsuccessful logon attempts. The control is designed to reduce the likelihood of password-guessing, credential-stuffing, and brute-force attacks against accounts that access covered information systems.

The assessment objectives are straightforward:

• The means of limiting unsuccessful logon attempts is defined. The organization has documented its threshold, lockout duration or administrator-unlock process, scope, exception handling, and responsible owners.
• The defined means is implemented. The documented settings are active on the systems where users authenticate to access CUI, security administration functions, or supporting infrastructure.

The requirement does not prescribe one universal number of attempts. A threshold of three failed attempts provides more protection than ten, but an overly aggressive threshold can increase help-desk volume and create denial-of-service concerns. Your selected setting should be reasonable for the risk, documented, technically enforceable, and consistently applied.

What systems must account lockout controls cover?

As a vCISO, I advise clients to start with authentication paths rather than a narrow list of servers. Identify every place a workforce member, administrator, vendor, or privileged service provider can attempt to authenticate into the CMMC assessment scope.

Do not assume that a domain policy protects every device. Local administrator accounts, standalone systems, firewall consoles, legacy manufacturing applications, and SaaS applications can each have separate authentication controls. A system may be out of scope only when it is genuinely segregated from CUI and cannot affect the security of the CUI environment.

How should an organization define its lockout policy?

Your written policy should turn a broad requirement into settings an administrator can implement and an assessor can evaluate. Define the threshold, the lockout mechanism, how long the account remains locked, who may unlock it, how users obtain support, and how exceptions are approved and reviewed.

A practical baseline for many small and mid-sized organizations is five consecutive failed attempts, a 15-minute lockout duration, and a 15-minute counter reset period. Some organizations choose administrator-assisted unlocks for privileged accounts, while allowing standard accounts to automatically unlock after a defined interval. Either approach can meet the requirement when the decision is risk-based and consistently enforced.

For example, Northstar Circuits, a 185-person PCB manufacturer, uses Active Directory, Microsoft 365, Fortinet VPN, and several Windows systems supporting engineering release and production scheduling. Its policy sets a five-attempt threshold for standard domain accounts, a 15-minute lockout duration, and a 15-minute reset counter. Privileged IT accounts lock after three failures and require help-desk verification plus an IT administrator unlock. The company documented a separate exception for a legacy automated test station, where a noninteractive service account is protected through a vaulted password, restricted logon rights, and monitoring rather than an interactive account lockout policy.

How do you perform cmmc account lockout control testing?

Effective CMMC account-lockout testing combines document review, configuration review, and a controlled functional test. A screenshot alone may show a configured value, but it does not prove that the intended account is actually locked after the threshold is exceeded.

1. Review the documented standard. Confirm it identifies the failed-attempt threshold, lockout duration or unlock process, account types covered, and exception process.
2. Map authentication sources. List domain controllers, Entra ID, VPN gateways, Linux hosts, network appliances, and applications that authenticate in-scope users.
3. Inspect effective settings. Validate the applied policy, not merely the existence of a policy object. Check organizational unit inheritance, security filtering, local overrides, and device-level configurations.
4. Select a safe test account. Use a dedicated nonprivileged account with no operational role. Never conduct repeated failed logons against a production executive, administrator, shared production, or emergency account.
5. Perform controlled failed logons. Submit invalid credentials until the documented threshold is exceeded. Record the date, system, account, attempt count, expected result, and actual result.
6. Validate the lockout result. Confirm that a valid password is rejected while the account is locked, that relevant logs record the event, and that the configured unlock mechanism works.
7. Restore and document. Unlock the test account if necessary, retain artifacts, identify gaps, and track remediation to closure.

For Windows domain environments, the following commands provide useful evidence of the domain policy and a specific account’s state:

net accounts /domain
Get-ADUser -Identity cmmc-lockout-test -Properties LockedOut,AccountLockoutTime
Get-ADDefaultDomainPasswordPolicy | Select LockoutThreshold,LockoutDuration,LockoutObservationWindow
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 10

At Northstar Circuits, the IT manager tested a temporary domain user from a standard workstation connected to the production VLAN. After the fifth invalid password attempt, Windows rejected the correct password, Event ID 4740 appeared on the domain controller, and the account automatically unlocked after 15 minutes. The manager retained the Group Policy report, command output, event export, test worksheet, and a ticket showing that the test account was disabled after validation.

What evidence should be retained for an assessment?

Assessors generally want to see a coherent story: the organization defined the control, deployed it, and confirmed it works. Evidence should be dated, attributable to the relevant system, and current enough to represent the operating environment.

• The access control policy or security standard containing lockout requirements.
• A system inventory or authentication architecture diagram showing in-scope identity sources.
• Active Directory Group Policy reports showing effective account lockout settings.
• Microsoft Entra ID smart lockout or identity protection configuration evidence where cloud authentication is in scope.
• VPN, firewall, Linux, application, and appliance configurations for separate authentication paths.
• A completed functional test record with expected and actual results.
• Security logs showing the lockout event, such as Windows Event ID 4740.
• Approved exception records, compensating safeguards, expiration dates, and periodic reviews.

Account lockout testing should be repeated after identity-platform changes, major migrations, domain policy modifications, new remote-access deployments, or discovery of a failed control. At minimum, include it in the organization’s recurring control-validation schedule.

What is the step-by-step implementation path?

1. Assign an owner, usually the IT manager or identity administrator, with vCISO oversight.
2. Choose risk-based settings for standard, privileged, local, and service accounts.
3. Document the standard and exception process before deploying technical settings.
4. Configure Active Directory, Entra ID, VPN, Linux, appliances, and applications according to the scope map.
5. Restrict or disable legacy authentication methods that bypass centralized protections.
6. Deploy settings first to a pilot group and monitor for operational impacts.
7. Roll out broadly, confirming effective policy application on representative systems.
8. Conduct a controlled lockout test and preserve evidence.
9. Review exceptions quarterly and remove them when no longer necessary.

What should your AC.L2-3.1.8 compliance checklist include?

• ☐ A documented unsuccessful-logon-attempt threshold exists.
• ☐ The policy states lockout duration, reset period, or administrator-unlock requirements.
• ☐ Privileged account handling is defined and more restrictive where appropriate.
• ☐ Domain, cloud, VPN, local, Linux, appliance, and application authentication paths are inventoried.
• ☐ Effective settings have been verified rather than assumed from intended configurations.
• ☐ A dedicated test account has been used to validate the threshold safely.
• ☐ The test confirmed that a correct password cannot be used during lockout.
• ☐ Lockout events are logged and can be reviewed by authorized personnel.
• ☐ Exceptions are documented, approved, time-bound, and protected by compensating controls.
• ☐ Evidence is retained with dates, system names, settings, and remediation records.

What are the most common account lockout questions?

How many failed login attempts are required for CMMC AC.L2-3.1.8?

CMMC does not mandate a specific number. Five consecutive failed attempts is a common baseline, while three attempts may be appropriate for privileged accounts or high-risk access paths. The organization must define and implement a threshold that fits its risk profile.

Does automatic account unlock meet the CMMC requirement?

Yes. After the threshold is reached, an account may remain locked until an administrator unlocks it or unlock automatically after a predefined period. The chosen approach must be documented, configured, and testable.

Do service accounts need account lockout settings?

Interactive service accounts should generally be eliminated or tightly controlled because repeated authentication failures can disrupt operations. Where a noninteractive account cannot follow the standard lockout mechanism, document the exception and use compensating safeguards such as vaulting, restricted logon rights, least privilege, monitoring, and credential rotation.

What logs prove an account lockout test passed?

Useful evidence includes the failed authentication events, the account lockout event, the policy configuration, and a test record demonstrating that valid credentials were rejected during lockout. In Active Directory, Windows Security Event ID 4740 is commonly used to show that an account was locked out.

Is Microsoft Entra smart lockout enough for CMMC compliance?

It may support the control for Entra-authenticated cloud services, but it does not automatically cover on-premises Active Directory, VPN devices, local accounts, Linux systems, or separate applications. Validate each authentication path in the CUI environment.

Next step: Schedule a 30-minute evidence review with your identity owner and use this guide to test one representative authentication path before expanding validation across the environment.