Account lockout controls stop or limit repeated failed authentication attempts and are a required safeguard under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 (AC.L2-3.1.8); this post shows practical, auditable ways to implement lockout behavior in Azure and AWS, how to document the controls, and real-world options for small businesses that lack enterprise identity infrastructure.
What the Control Requires (brief)
AC.L2-3.1.8 requires that organizations limit or block repeated authentication attempts to prevent brute-force and credential-stuffing attacks. The key objectives are: detect failed authentication attempts, apply an automated temporary block or lockout when thresholds are exceeded, log the events, notify administrators, and document the behavior in your System Security Plan (SSP) and procedures.
Implementing Lockouts in Azure AD
Azure Active Directory (Azure AD) provides built-in "Smart Lockout" and password protection settings that are the straightforward way to satisfy the control for cloud identities. Practical steps: go to the Azure portal > Azure Active Directory > Security > Authentication methods > Password protection (or Azure AD Identity Protection for risk-based policies). Configure the lockout threshold (e.g., 5 failed attempts) and the lockout duration (e.g., 15 minutes). For hybrid environments, deploy Azure AD Password Protection proxy to extend policy to on-prem AD DS accounts.
Technical details and recommended parameters (Azure)
Set Smart Lockout to a low threshold while avoiding excessive false positives: common recommended starting values are 5 failed sign-ins to trigger a lockout and a 15–30 minute lockout duration. Enable Azure AD Identity Protection sign-in risk policies to automatically block high-risk sign-ins or require MFA. Ensure auditing is enabled: collect Azure AD sign-in logs to a Log Analytics workspace or to an SIEM, retain for your required retention period, and export logs for evidence.
Evidence and compliance notes (Azure)
Document your Azure settings in the SSP: include screenshots of Password Protection/Smart Lockout settings, Conditional Access policies requiring MFA, and a retention statement for sign-in logs. Evidence for assessments: exported sign-in logs showing failed attempts and lockout events, change records for configuration, and your runbook describing how to respond to account lockouts and unlock requests.
Implementing Lockouts in AWS (workarounds and patterns)
AWS IAM does not provide an out-of-the-box, configurable "account lockout" for console or API authentication equivalent to Azure AD Smart Lockout. That said, you can meet the control by implementing a detection-and-response pattern using CloudTrail, CloudWatch Logs/Alarms, and a Lambda function (serverless automation) to disable or quarantine an account after repeated failures.
Serverless lockout workflow (practical implementation)
Architecture: enable AWS CloudTrail for management events and send events to CloudWatch Logs. Create a CloudWatch Logs metric filter that detects ConsoleLogin events with failure: filter pattern like { $.eventName = "ConsoleLogin" && $.responseElements.ConsoleLogin = "Failure" }. Use a CloudWatch alarm or CloudWatch Logs subscription to invoke a Lambda. The Lambda increments a counter in DynamoDB keyed by username+account+time window, and when the counter exceeds your threshold (e.g., 5 failures in 15 minutes) the Lambda takes action: call iam.update_login_profile(UserName=..., PasswordResetRequired=True) or iam.delete_login_profile to disable console sign-in, and call iam.update_access_key(UserName=..., AccessKeyId=..., Status='Inactive') to disable access keys.
Permissions, thresholds and recovery (AWS)
Lambda needs least-privilege IAM permissions: iam:UpdateLoginProfile, iam:DeleteLoginProfile, iam:UpdateAccessKey, iam:ListAccessKeys, iam:GetUser; plus DynamoDB PutItem/GetItem and CloudWatch/Logs invoke. Recommended threshold: 5–10 failed console logins within 15–30 minutes for small organizations. Implement an automated notification (SNS/email) to send incident alerts and include a manual verification/recovery process: an approval workflow (ticketing + multi-admin approval) to re-enable the account after password reset and MFA re-enrollment. Log every disablement with CloudTrail and keep these as assessment artifacts.
Alternative AWS options
If you use AWS IAM Identity Center (formerly AWS SSO), AWS Cognito, or a managed AD (e.g., AWS Managed Microsoft AD), evaluate their built-in lockout or adaptive authentication capabilities first—these services often provide or can be extended with lockout-like behavior. If you federate to an identity provider (Azure AD, Okta), implement lockout at the IdP layer and treat AWS as relying party; document the federation relationship in the SSP and show IdP logs as evidence.
Small-business scenario and example
Scenario: a 50-person contractor uses Microsoft 365 (Azure AD) for email and a single AWS account for development. Action plan: enable Azure AD Smart Lockout and conditional access requiring MFA for all users; set lockout to 5 attempts / 15 minutes. In AWS, enable CloudTrail and CloudWatch Logs, deploy the Lambda/DynamoDB lockout automation described above, and require all employees to authenticate to AWS via SSO federation to Azure AD where lockouts are already applied. Maintain a simple runbook for helpdesk that documents the steps to verify identity and restore access (reset password, confirm MFA) and link tickets to events in CloudTrail for audit.
Risks of not implementing lockout controls
Without lockout controls you expose accounts to credential stuffing and brute-force attacks, increasing the risk of account takeover, data exfiltration, ransomware, and loss of Controlled Unclassified Information (CUI). From a compliance standpoint, failure to implement controls or compensating controls can lead to nonconformities in an assessment, removal from contracts, or penalties. Operationally, lack of automated controls forces manual detection and slow incident response.
Compliance tips and best practices
Best practices: (1) Pair lockouts with mandatory MFA to reduce the likelihood that locking will be required frequently; (2) tune thresholds to balance security and availability (start conservative and adjust after monitoring); (3) centralize logs and retain them per your retention policy; (4) document everything in your SSP, include configuration screenshots, runbooks, and escalation procedures in your POA&M; (5) exclude service accounts only with compensating controls (keys stored in vaults, rotation, strict monitoring); (6) test the lockout and recovery process regularly and capture the test evidence for assessors.
Implementing account lockout controls in Azure and AWS is achievable for small businesses: use Azure AD Smart Lockout and Conditional Access for cloud identity, and for AWS use federation or a small serverless automation pattern (CloudTrail → CloudWatch → Lambda → disable account) to enforce lockouts, combined with MFA and logging to produce the evidence required by NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 AC.L2-3.1.8. Document your configuration, response procedures, and test results in the SSP and you will have a clear, auditable implementation that reduces risk and meets compliance expectations.
