Requirement
AC.L2-3.1.8 – Limit unsuccessful logon attempts.
This control comes from NIST SP 800-171 REV.2 / CMMC 2.0 Level 2.
Understanding the Requirement
This control requires you to define and enforce a method to stop repeated failed sign-in attempts, which helps prevent brute-force attacks. Practically, you set a threshold (e.g., three to five failed attempts) that triggers an account lockout, and you decide how the account is restored—either automatically after a short period (e.g., 5–15 minutes) or by an administrator. Meeting the objectives means both documenting the lockout approach and implementing it consistently across systems where users authenticate.
Policies and Procedures Needed
Establish an Access Control Policy and an Account Lockout Standard that specify the failed-attempt threshold, lockout duration, counter reset time, scope (workstations, servers, VPN, email, SaaS), and exceptions (e.g., non-interactive service accounts). Create procedures for help desk unlocks, identity verification, documenting exceptions, and monitoring alerts. Ensure onboarding/offboarding workflows apply the standard to all new accounts and remove access promptly. Include periodic access reviews, password/MFA requirements, and device management coverage for Windows, macOS, Linux, and remote endpoints.
Technical Implementation
- Define enterprise lockout settings: threshold of 3–5 failed attempts, lockout duration of 10–30 minutes, and a counter reset time (e.g., 5 minutes). Apply the policy to interactive logons and remote access (VPN, RDP, SSH), administrator portals, email, and key SaaS apps. Document any justified deviations.
- Windows (Active Directory): Use Group Policy at Computer Configuration → Windows Settings → Security Settings → Account Policies → Account Lockout Policy. Set Account lockout threshold (e.g., 5), Account lockout duration (e.g., 15 minutes), and Reset account lockout counter after (e.g., 5 minutes). Apply to domain-joined PCs, servers, and RDP hosts. For Windows devices managed by Microsoft Endpoint Manager, deploy the same settings via security baselines or configuration profiles.
- Microsoft Entra ID (Azure AD) and cloud IdPs: Enable and tune smart lockout or brute-force protections. Set a conservative threshold for failed sign-ins and a lockout duration that throttles attacks without hampering users. Ensure protections are enforced for critical apps (email, admin portals, VPN) and that admin accounts have stricter policies and MFA.
- macOS and Linux endpoints: For macOS via MDM, configure maximum failed attempts and auto-unlock timing in a security/privacy profile; ensure FileVault-enabled devices also enforce sensible limits. For Linux, enable pam_faillock (or pam_tally2 on older systems) with deny (e.g., 3–5) and unlock_time (e.g., 900 seconds) and ensure SSH respects the same limits.
- Service and non-interactive accounts: Do not allow interactive login where unnecessary. If an exception to lockout is required to prevent outages, mitigate with long, random secrets, MFA for any interactive use, IP allowlists, and a privileged access management process. Review exceptions at least quarterly.
- Monitoring and response: Forward lockout events to your SIEM or logging platform and alert on spikes in lockouts (e.g., multiple accounts in a short window or repeated lockouts of one account). Create a help desk runbook for verifying user identity, assessing potential attack activity, and unlocking or waiting for auto-unlock. Track metrics (number of lockouts, false positives) and tune thresholds as needed.
Example in a Small or Medium Business
A 60-person accounting firm standardizes on a threshold of five failed attempts, a 15-minute lockout, and a five-minute reset. The IT admin configures the policy in Active Directory via Group Policy for all Windows machines and servers, enforces smart lockout in Microsoft Entra ID for Microsoft 365, and sets equivalent limits on their VPN. Macs used by partners receive an MDM profile that applies the same rule, and Linux file servers use pam_faillock with a 15-minute unlock time. A written procedure tells the help desk to verify identity before unlocking accounts and to check SIEM alerts for suspicious patterns. One afternoon, a bot tries passwords against several mailboxes; three users get temporarily locked, an alert triggers, and IT tightens firewall geoblocking. Users automatically regain access after 15 minutes, and none of the accounts are compromised. The security team documents the incident, confirms settings are consistent across systems, and adds an automated report for repeated lockouts on the same user. Leadership reviews the monthly lockout trend and leaves thresholds in place because user impact is minimal and security is improved.
Summary
By clearly defining how many failed logon attempts trigger a lockout, how long the lockout lasts, and where the rule applies—and then enforcing it across endpoints, servers, cloud identity, and remote access—you blunt brute-force attacks without excessively disrupting users. Supporting procedures for exceptions, help desk unlocks, and monitoring ensure that legitimate users can recover quickly while suspicious activity is detected and investigated. Together, these policy and technical measures fulfill AC.L2-3.1.8’s intent: limiting unsuccessful logon attempts in a consistent, auditable, and practical way for SMB environments.
