What Is This CMMC Control?
Organizations must configure systems to limit how many times a user can fail to log in before the account is locked or delayed. This prevents attackers from repeatedly guessing passwords and protects against brute-force attacks. The lockout or delay should be temporary and automatically release after a set time period.
Control Intent
Prevent unauthorized access through brute-force password attacks by limiting the number of consecutive failed login attempts before implementing protective measures such as account lockout or enforced delays.
Who This Control Applies To
- •All systems that authenticate users with passwords or credentials
- •Operating systems (Windows, Linux, macOS)
- •Applications with user authentication (web apps, databases, SaaS platforms)
- •Network devices (firewalls, switches, routers, VPNs)
- •Remote access systems (VPN, RDP, SSH)
- •Cloud identity providers and SSO systems
- •Mobile device management systems
- •Privileged access management systems
Not Applicable When
- •Systems that use only certificate-based authentication without password fallback
- •Systems that use only hardware token authentication without password fallback
- •Systems that do not have user accounts or authentication mechanisms
- •Read-only systems with no interactive logon capability
- •Systems that are completely isolated with no user access
Key Objectives
- 1Prevent brute-force and password guessing attacks by limiting consecutive failed authentication attempts
- 2Implement temporary account lockouts or delays that balance security protection with availability requirements
- 3Apply failed logon attempt limits consistently across all authentication points including local and network-based logons
Sample Self-Assessment Questions (Partial)
How many failed login attempts are allowed before an account is locked or delayed?
How long does an account lockout or delay last after failed attempts?
Implementation Approaches (High-Level)
Active Directory Group Policy Lockout
Configure account lockout policy through Active Directory Group Policy to enforce failed logon attempt limits across all domain-joined Windows systems
Local Account Lockout Policy
Configure account lockout settings directly on standalone systems or for local accounts using local security policy or system-specific configuration
Application-Level Authentication Controls
Configure failed logon attempt limits within applications, databases, and web-based systems that maintain their own user authentication
Cloud Identity Provider Lockout
Configure account lockout and authentication policies through cloud identity providers such as Azure AD, Okta, Google Workspace, or AWS IAM
Network Device Authentication Controls
Configure authentication failure limits and lockout on network infrastructure devices including firewalls, switches, routers, and VPN concentrators
Privileged Access Management (PAM) System
Enforce failed logon attempt limits through a centralized privileged access management solution that controls access to privileged accounts and systems
Delay Algorithm Implementation
Implement progressive delay or exponential backoff instead of hard lockout to balance security with availability, particularly for systems where lockout could cause denial of service
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If lockout is not currently configured, prioritize implementation on systems with highest risk exposure (internet-facing, remote access, privileged accounts) For systems where lockout could cause operational disruption, document risk acceptance and implement compensating controls such as enhanced monitoring, MFA, or delay algorithms If service accounts cannot be subject to lockout, document justification and implement compensating controls such as complex passwords, password rotation, and enhanced monitoring For legacy systems that do not support lockout configuration, consider network-level controls, enhanced monitoring, or system replacement/upgrade timeline If lockout threshold is too high or duration too short, create remediation plan to adjust to acceptable levels (typically 3-10 attempts, 15-30 minute lockout) For inconsistent lockout configuration across systems, develop standardized baseline and use configuration management tools to enforce consistency If application-level lockout is missing, work with application owners to implement or document compensating controls For cloud systems without lockout, enable available security features and consider conditional access or risk-based authentication Document any accounts exempted from lockout with clear business justification and specific compensating controls Include testing and validation activities in POA&M to ensure lockout functions as intended without causing operational issues
Frequently Asked Questions
What is an acceptable threshold for failed logon attempts before lockout?
CMMC and NIST do not specify an exact number, but industry best practice and most assessors accept 3-10 failed attempts as reasonable. Organizations should balance security (lower threshold) with operational needs (higher threshold). Common configurations are 5 attempts for standard users and 3 attempts for privileged accounts. The key is having a documented, risk-based decision and consistent enforcement.
How long should account lockout last?
Typical lockout durations range from 15-30 minutes, which is long enough to significantly slow brute-force attacks while not causing excessive user frustration. Some organizations use longer durations (1-2 hours) for privileged accounts. Alternatively, organizations can require administrator intervention to unlock accounts, though this may create help desk burden. The duration should be documented in policy and consistently configured.
Do service accounts need to be subject to lockout policies?
Service accounts present a challenge because lockout could cause application or system failures. Best practice is to apply lockout to service accounts but implement compensating controls such as complex passwords, regular password rotation, restricted network access, and enhanced monitoring. If lockout cannot be applied due to operational risk, this must be documented with clear justification and specific compensating controls. Some organizations use managed service accounts or group managed service accounts that have enhanced security features.
What is the difference between account lockout and delay algorithms?
Account lockout completely prevents authentication attempts after the threshold is reached until the lockout period expires or an administrator unlocks the account. Delay algorithms implement progressive delays between authentication attempts, making each subsequent failed attempt take longer without completely blocking access. Delay algorithms can be preferable for high-availability systems where lockout could cause denial of service, but they must still provide meaningful protection against brute-force attacks through sufficient delay periods.
Does this control apply to multi-factor authentication (MFA)?
Yes, failed logon attempt limits should apply to all authentication mechanisms including MFA. However, the implementation may differ - some systems count failed MFA attempts separately from password attempts, while others count them together. The key is that an attacker cannot make unlimited attempts to bypass MFA. Organizations using MFA should document how failed attempt limits apply to each authentication factor and ensure the combined approach provides adequate protection.
How should we handle lockouts for privileged or emergency access accounts?
Privileged accounts should generally be subject to more restrictive lockout policies (lower threshold, longer duration) due to their higher risk. However, organizations need break-glass or emergency access procedures for situations where normal privileged accounts are unavailable. These emergency accounts should have strong compensating controls such as physical security requirements, multiple-person authorization, enhanced logging and monitoring, and immediate security team notification when used. The existence and use of emergency accounts must be documented and regularly reviewed.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.