AC.L2-3.1.8 in the Compliance Framework (NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2) requires organizations to limit unsuccessful logon attempts — an essential control to prevent credential-stuffing, brute-force attacks, and account takeover; this post explains how to combine multi-factor authentication (MFA), rate limiting, and adaptive authentication to meet the control with practical steps, example configurations, and small-business scenarios.
Understanding the control and the risk of non‑compliance
At its core, AC.L2-3.1.8 is about reducing repeated failed authentication attempts that indicate automated attacks or credential abuse. Failure to implement effective mitigations increases the risk of unauthorized access to Controlled Unclassified Information (CUI), potential data exfiltration, operational disruption, and loss of DoD contracting eligibility. Regulators and assessors expect documented technical controls (e.g., lockouts, throttling, step-up auth) combined with monitoring and policy evidence.
MFA as the first and most effective layer
MFA should be mandatory for all users with access to CUI and administrative accounts. Implementations that meet the Compliance Framework requirement include time‑based one‑time passwords (TOTP), push notifications, FIDO2/WebAuthn keys, or hardware tokens. For small businesses: enable MFA at the identity provider (IdP) level (Azure AD, Okta, Duo, or Keycloak) and enforce it through SSO so all applications inherit the protection without per-app configuration.
Practical MFA setup for small businesses
Example: In Azure AD, require MFA via Conditional Access for all privileged roles and for interactive sign-ins from outside the corporate network; set "Require multi-factor authentication" for groups handling CUI. In Okta, create an MFA policy that requires a stronger factor (FIDO2 or Duo Push) for administrative groups and step-up to MFA when sign-in risk is medium or higher. Document the policy, enrollment process, and backup options (e.g., hardware tokens stored securely) as compliance evidence.
Rate limiting and account lockout strategies
Rate limiting stops mass automated attempts while account lockouts prevent repeated guessing against a single account. Recommended practical settings: implement IP-based throttling (e.g., block or slow requests after 100 requests/min), account-based soft lockouts after 5 failed attempts within 15 minutes with exponential backoff, and progressive penalties (temporary lock, CAPTCHA, or require password reset + MFA). Avoid permanent lockouts that can be used for denial-of-service; prefer temporary lockouts (e.g., 15–30 minutes) with admin override logs.
Technical examples of rate limits and lockouts
Webserver/WAF: Use nginx limit_req with a burst setting and AWS WAF rate-based rules to block sources that exceed e.g., 300 requests/5 minutes. Application: implement server-side throttling middleware that tracks failed attempts per account and per source IP in a fast datastore (Redis) and enforces progressive delays of 1s, 5s, 30s. Host-level: deploy fail2ban with a jail that bans IPs after X failed SSH or custom application auth attempts. For WordPress or vendor apps, use vendor-provided login limit plugins combined with Cloudflare rate-limiting rules.
Adaptive authentication for targeted risk-based defenses
Adaptive authentication applies contextual signals (geolocation, device fingerprint, time of day, IP reputation, sign-in velocity, and known compromised credentials) to dynamically require stronger controls. Implement adaptive rules in your IdP or PAM: e.g., require step-up MFA for a login from a new device or high-risk country, restrict access when sign-in velocity indicates automation, and enforce device-managed status for access to sensitive systems.
Real-world adaptive policies and integrations
Example: configure Azure AD Conditional Access to require MFA for sign-ins from unfamiliar locations or when the sign-in risk is medium/high as reported by Microsoft Identity Protection. With Okta, create rules that force device compliance checks and require FIDO2 for high-risk sign-ins. For a small business using Keycloak, enable the "Risk-based authentication" plugin or implement a custom authenticator that checks GeoIP and triggers OTP when heuristics indicate risk. Log each step-up event to the SIEM for auditability.
Logging, monitoring, and evidence for assessors
To satisfy compliance reviewers, produce logs showing failed attempts, lockouts, rate-limiting actions, MFA challenge events, and administrative overrides. Forward auth logs to a SIEM or centralized logging (Splunk, Elastic Stack, or a managed logging service). Create daily or weekly alerts for high failure rates (e.g., >500 failed logins in 24 hours) and retain logs for the period required by your organization’s retention policy. Include sample runbooks for incident response to credential stuffing and account takeover attempts.
Compliance tips and best practices
Document policies and baseline configurations: lockout thresholds, rate limits, adaptive rules, MFA enforcement, exception handling, and the rationale tied to AC.L2-3.1.8. Test controls with red-team or automated tools (e.g., password spray simulations) and record test evidence. Train helpdesk staff on safe unlock procedures and maintain an auditable approval workflow for account reinstatements. Regularly review and tune thresholds to reduce false positives that may disrupt legitimate users.
In summary, meeting AC.L2-3.1.8 is best achieved by combining mandatory MFA, intelligent rate limiting, and adaptive authentication policies that respond to contextual risk—backed by centralized logging, documented procedures, and periodic testing. For small businesses this can be implemented affordably by leveraging cloud IdPs (Azure AD, Okta, Duo), WAF/rate-limiting on the edge (Cloudflare, AWS WAF), and simple server-side throttling (Redis + middleware or fail2ban), all of which provide the technical evidence and operational effectiveness assessors expect under the Compliance Framework.
