Limit unsuccessful logon attempts
📖 What This Means
This practice requires organizations to set a limit on the number of unsuccessful login attempts a user can make before their account is locked or temporarily disabled. This helps prevent unauthorized access through brute force attacks, where attackers try multiple password combinations to gain entry. For example, if a user enters the wrong password five times in a row, their account will be locked for a specified period or until an administrator resets it. This control ensures that attackers cannot endlessly guess passwords, protecting sensitive systems and data. Think of it like a security guard stopping someone after too many failed attempts to unlock a door.
🎯 Why It Matters
Unlimited login attempts make systems vulnerable to brute force attacks, where attackers systematically guess passwords until they find the correct one. For instance, in 2019, a brute force attack on a major retailer’s remote access system led to a data breach affecting millions of customers. Such breaches can result in significant financial losses, reputational damage, and regulatory penalties. From a DoD/CMMC perspective, limiting login attempts is critical to safeguarding Controlled Unclassified Information (CUI) and ensuring compliance with cybersecurity standards. This practice mitigates the risk of unauthorized access, protecting sensitive data from exploitation.
✅ How to Implement
- For AWS: Use IAM policies to configure account lockout thresholds in AWS Organizations.
- For Azure: Set account lockout policies in Azure Active Directory under Password Reset settings.
- For GCP: Configure account lockout thresholds using Identity and Access Management (IAM) settings.
- Enable Multi-Factor Authentication (MFA) to add an extra layer of security.
- Monitor login attempts using cloud-native logging tools like AWS CloudTrail or Azure Monitor.
- Automate account lockout notifications to administrators using cloud-native alerting systems.
- Regularly review and update lockout policies to align with organizational security requirements.
📋 Evidence Examples
Account Lockout Policy Document
Configuration Screenshots
Failed Login Attempt Logs
Testing Results
Training Records
📝 SSP Guidance
Use this guidance when writing the System Security Plan (SSP) narrative for this control.
How to Write the SSP Narrative
For AC.L2-3.1.8 ("Limit unsuccessful logon attempts"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how access to CUI systems is controlled, including the specific IAM tools, policies, and processes used. Reference your Access Control Policy and identify the systems in scope. Be specific -- name your actual products, settings, and responsible personnel.
Example SSP Narratives
"AC.L2-3.1.8 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to limit unsuccessful logon attempts. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."
"AC.L2-3.1.8 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to limit unsuccessful logon attempts. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."
"AC.L2-3.1.8 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."
System Boundary Considerations
- • Identify all access points to CUI systems (VPN, direct network, cloud portals)
- • Document which IAM system manages access (Azure AD, AWS IAM, on-prem AD)
- • Map user roles to system access levels
- • Ensure this control covers all systems within your defined CUI boundary where limit unsuccessful logon attempts applies
- • Document any systems where this control is not applicable and explain why
Key Documentation to Reference in SSP
- 📄 Access Control Policy
- 📄 IAM configuration documentation
- 📄 Access request and approval records
- 📄 Evidence artifacts specific to AC.L2-3.1.8
- 📄 POA&M entry if control is not fully implemented
What the Assessor Looks For
The assessor will verify that access controls are implemented as described, test whether unauthorized users are blocked, and review access logs for evidence of enforcement.
💬 Self-Assessment Questions
Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.
Question 1: Have you configured account lockout thresholds in your systems?
Question 2: Are failed login attempts logged and monitored?
Question 3: Is MFA enabled for sensitive accounts?
Question 4: Are lockout policies reviewed and updated regularly?
Question 5: Are employees trained to recognize suspicious login activity?
⚠️ Common Mistakes (What Auditors Flag)
1. Not setting lockout thresholds.
2. Failing to monitor failed login attempts.
3. Not implementing MFA.
4. Inconsistent lockout policies across systems.
5. Inadequate documentation.
📚 Parent Policy
This practice is governed by the Access Control Policy