AC-7: Unsuccessful Logon Attempts

Control ID: AC-07 | Control name: Unsuccessful Logon Attempts | Framework: NIST SP 800-53 Revision 5 | Control family: Access Control | Baselines: LOW MODERATE HIGH | Relevance: System-level | First Party and Third Party | Risk severity: Medium

What this control requires

AC-07 requires information systems to enforce a limit on consecutive failed logon attempts and respond automatically when that limit is exceeded. The response can include locking the account for a defined period, locking it until an administrator intervenes, delaying the next logon prompt through an algorithm, or notifying the system administrator. This control sits within the Access Control family and applies at all three baselines (LOW, MODERATE, HIGH).

In practice, that enforcement requires two organization-defined parameters: the maximum number of consecutive invalid attempts allowed and the time window in which those attempts are counted. The response action also requires a deliberate choice. Temporary lockouts are the most common approach, but the NIST SP 800-53 catalog explicitly permits delay algorithms, administrator-only unlock, CAPTCHA challenges, or IP-based restrictions as alternatives.

Where organizations frequently underestimate scope, the control applies regardless of whether logon occurs through a local console or a network connection. Operating system-level and application-level enforcement are both in scope, meaning a single system may need AC-07 configured at multiple layers to cover all authentication entry points.

Why it matters

Brute-force and credential-stuffing attacks remain among the most reliable methods for gaining unauthorized access to systems covered by the NIST SP 800-53 Access Control family. Without a threshold on failed logon attempts, attackers can submit millions of credential combinations with no friction. AC-07 directly addresses this gap by forcing systems to slow down or halt authentication after a defined number of failures.

The consequences of omitting this control extend beyond individual account compromise. Credential-stuffing attacks often target high-value applications that hold sensitive personal or financial data, and a successful attack can expose thousands of accounts before anyone notices abnormal activity.

IRS Get Transcript credential-stuffing attack

From approximately February through May 2015, attackers ran an automated campaign against the IRS’s “Get Transcript” web application, which allowed taxpayers to retrieve prior-year tax transcripts online. The attackers already possessed stolen personal data, including Social Security numbers, dates of birth, and prior-year adjusted gross income figures, sourced from unrelated breaches. Armed with that data, automated scripts submitted high-volume authentication requests and successfully answered the application’s knowledge-based authentication questions for hundreds of thousands of accounts.

The eventual scale far exceeded initial disclosures. The Tax Inspector General for Tax Administration (TIGTA) ultimately found that approximately 355,000 taxpayer accounts were accessed without authorization, up from the initially reported 100,000. Before the IRS detected the attack, an estimated 13,000 to 15,000 fraudulent tax refunds were issued, totaling between $39 million and $50 million.

That scale traced directly to a missing control. The application had no meaningful rate limiting or account lockout mechanism. A year before the breach was disclosed, TIGTA found evidence that a single user had authenticated 902 times in one day, far exceeding the IRS’s own defined thresholds for unusual activity.

The response compounded the exposure. IRS staff failed to act on those alerts. AC-07 exists to defeat exactly this category of attack by requiring systems to enforce a hard ceiling on failed attempts and automatically lock, delay, or escalate when the ceiling is breached.

What attackers exploit

• No lockout threshold configured. Systems that allow unlimited authentication attempts give credential-stuffing tools an unobstructed path to valid credentials.
• Overly generous thresholds. A lockout set at 100 attempts per hour provides negligible friction against automated tooling that can test thousands of credentials per minute.
• Application-layer gaps. Organizations that enforce lockout at the operating system level but not within web applications leave a parallel authentication path unprotected.
• Missing monitoring on lockout events. Even when lockout triggers correctly, the absence of alerting means security teams cannot detect and respond to large-scale campaigns in progress.
• Permanent lockout avoidance. Attackers deliberately spread attempts across accounts and time windows to stay below per-account thresholds, making aggregate monitoring essential.

How to implement

For your organization

The most common failure mode is configuring lockout at one layer but missing other authentication surfaces entirely. A web application with a three-attempt lockout provides no protection if the underlying API endpoint or administrative console accepts unlimited attempts.

Step 1: Inventory all authentication entry points. Document every system, application, and service that accepts user credentials. Include VPN gateways, remote desktop services, API endpoints, administrative consoles, and cloud management portals.

Step 2: Define your lockout parameters. Choose a maximum attempt threshold (commonly three to five consecutive failures) and the time window for counting (commonly 15 to 30 minutes). Select your response action. Temporary lockout with automatic release after 15 to 30 minutes is the most widely adopted approach, but delay algorithms or administrator-only unlock may be appropriate for high-sensitivity systems.

Step 3: Configure enforcement at each layer. For operating systems, use group policy (Windows) or PAM modules (Linux). For web applications, implement lockout logic in the authentication service rather than relying solely on WAF rules. For cloud environments, configure conditional access policies and identity provider settings.

Step 4: Enable alerting on lockout events. Forward lockout events to your SIEM or centralized logging platform. Set correlation rules to detect distributed attacks that trigger lockouts across many accounts simultaneously.

Step 5: Test and validate. Confirm that lockout triggers at the defined threshold across all entry points. Verify that the automatic release timer works as configured. Test that alerts fire and reach the security operations team.

Common mistakes to avoid:

• Relying on a single WAF rule instead of application-level enforcement
• Setting lockout thresholds so high (for example, 50 attempts) that automated tools can exhaust credential lists before triggering a lock
• Failing to configure lockout on service accounts and API keys
• Not testing lockout behavior after system upgrades or configuration changes

For your vendors

Third-party risk assessments should verify that vendors enforce AC-07 on every system that processes, stores, or transmits your data. The most frequent gap in vendor environments is inconsistent enforcement across multiple applications within the same vendor organization.

Step 1: Request evidence of lockout configuration. Ask vendors to provide screenshots or exports of their account lockout policy settings for each in-scope system. Look for the specific threshold, time window, and response action.

Step 2: Verify scope of enforcement. Confirm that lockout applies to all authentication methods the vendor uses, including web portals, APIs, SSH access, and database connections. A vendor that locks web portal accounts but allows unlimited SSH attempts has a material control gap.

Step 3: Review monitoring and response procedures. Request documentation showing that the vendor monitors lockout events and has a defined response process for large-scale lockout campaigns. Ask for sample alert configurations or recent incident reports.

Step 4: Assess lockout parameters against your risk tolerance. A vendor using a 30-attempt threshold with a one-minute lockout window may technically satisfy AC-07 but provides inadequate protection for high-sensitivity data. Evaluate whether the vendor’s parameters align with the sensitivity of the data they handle on your behalf.

Step 5: Include AC-07 in ongoing monitoring. Incorporate lockout policy verification into your recurring vendor assessment cycle. Configuration drift is common after vendor system upgrades, so point-in-time attestation is not sufficient.

Common mistakes to avoid:

• Accepting a vendor’s SOC 2 report as sufficient without verifying that AC-07 is specifically tested
• Not asking about API-level lockout controls, which vendors frequently omit
• Treating vendor self-attestation as equivalent to configuration evidence

Evidence examples

Cross-framework mapping

Related controls

• AC-02 — Account Management: Provides the account lifecycle context that AC-07 builds on. Lockout responses such as disabling an account or requiring administrator intervention depend on the account management processes defined under AC-02.
• AC-09 — Previous Logon Notification: Displays information about the last successful logon, helping users detect unauthorized access that may have occurred despite AC-07 protections.
• AU-02 — Event Logging: Defines which events the system must log. Failed logon attempts and lockout triggers are critical audit events that support AC-07 enforcement and investigation.
• AU-06 — Audit Record Review, Analysis, and Reporting: Requires regular review of audit logs. Without AU-06 processes, lockout events generated by AC-07 may go unnoticed, as demonstrated in the IRS Get Transcript breach.
• IA-05 — Authenticator Management: Governs password complexity, rotation, and storage. Strong authenticator management reduces the likelihood of successful credential guessing, complementing the brute-force protection that AC-07 provides.

Frequently asked questions

What is NIST SP 800-53 AC-07

AC-07 is an access control requirement that forces information systems to limit consecutive failed logon attempts and take automatic action when the limit is exceeded. The control applies at the LOW, MODERATE, and HIGH baselines, making it a baseline expectation for nearly all federal systems and any organization adopting the NIST SP 800-53 catalog. Organizations define the specific threshold, time window, and response action, such as temporary account lockout, delay algorithms, or administrator notification.

What happens if AC-07 is not implemented

Systems without AC-07 controls allow unlimited authentication attempts, giving attackers an open path to test stolen or guessed credentials at scale. Credential-stuffing attacks can compromise thousands of accounts in hours, as demonstrated when the IRS’s Get Transcript application was exploited for three months without any lockout mechanism. The resulting exposure can include unauthorized data access, fraudulent transactions, regulatory penalties, and extended incident response costs.

How do you audit AC-07

Auditing AC-07 requires verifying both the configuration and the operational effectiveness of lockout controls. Start by collecting lockout policy exports from operating systems, identity providers, and applications to confirm that the threshold, time window, and response action match your organization’s defined parameters. Then review audit log samples showing that lockout events actually trigger at the configured threshold. Validate that alerting rules forward lockout events to the security operations team and that response procedures document how administrators investigate and resolve lockout incidents.

How many failed login attempts before lockout under NIST SP 800-53

NIST SP 800-53 does not prescribe a specific number. AC-07 requires organizations to define and enforce their own threshold based on risk tolerance. Industry practice typically falls between three and five consecutive failed attempts within a 15- to 30-minute window, with temporary lockout lasting 15 to 30 minutes. High-sensitivity systems may use lower thresholds or require administrator-only unlock. The key requirement is that the threshold exists, is documented, and triggers an automatic system response.