AC-7: Unsuccessful Logon Attempts

To meet the ac-7: unsuccessful logon attempts requirement, you must configure your systems to limit consecutive invalid logon attempts within a defined time window and trigger a defined response (lockout, delay, or alert) that is consistently enforced and evidenced. Operationalize AC-7 by setting enterprise standards, implementing them across identity providers and critical applications, and retaining configuration and log evidence for audits. ¹

Key takeaways:

• AC-7 is a configuration-and-evidence control: auditors expect enforced settings plus proof they work. ¹
• Define two parameters centrally: max invalid attempts and time window, then apply them consistently across authentication stacks. ²
• The common failure mode is scope gaps (legacy apps, admin interfaces, third-party SaaS) that bypass your lockout standard.

AC-7 targets a specific, common attack path: repeated password guessing against a user account until an attacker gets in. The requirement is simple on paper, but most compliance issues come from inconsistent implementation. Your identity provider may enforce lockout, while a legacy VPN, an admin console, a database, or a third-party SaaS login page allows unlimited attempts. Examiners notice these seams quickly because they map directly to account takeover risk.

This page gives requirement-level guidance you can implement without turning it into a multi-quarter project. You will (1) pick defensible AC-7 parameters (attempt limit and time window), (2) apply them to the systems that matter, (3) document exceptions with compensating controls, and (4) retain evidence that shows enforcement. The outcome a CCO or GRC lead wants is straightforward: a control statement you can defend, a configuration baseline your IAM and platform teams can follow, and an evidence package that survives sampling.

Primary sources: NIST SP 800-53 Rev. 5 control AC-7 and its catalog representation. ³

Regulatory text

Control requirement (excerpt): “Enforce a limit of [organization-defined number] consecutive invalid logon attempts by a user during a [organization-defined time period]; and …” ²

What the operator must do:

1. Set two explicit parameters for your environment:
   • the maximum number of consecutive invalid logon attempts; and
   • the time window in which those attempts are counted. ²
2. Enforce the limit technically on in-scope systems (not only in policy).
3. Define the system response when the limit is reached (commonly lockout, throttling/delay, and/or alerting), and ensure it is consistent with your risk appetite and operational needs. AC-7’s excerpt shows the “limit” portion; your implementation should still specify the response behavior so it is testable and auditable. ¹

Plain-English interpretation

AC-7 requires you to stop unlimited password guessing. You pick a reasonable threshold for bad logons and a period of time, then configure your authentication systems so accounts cannot be hammered indefinitely. For auditors, AC-7 is “real” only when they can see settings in your IdP, OS, VPN, privileged access tooling, and key apps, plus logs showing the control triggers as designed.

Who it applies to (entity and operational context)

AC-7 is a NIST SP 800-53 control typically used for:

• Federal information systems; and
• Contractor systems handling federal data (for example, environments aligned to NIST controls through contracts and assessment requirements). ¹

Operationally, you should treat AC-7 as applicable anywhere a user (workforce, admin, contractor, third party support, or service account with interactive login) can authenticate:

• Identity providers and SSO portals
• VPNs and remote access gateways
• End-user OS login (workstations, servers)
• Admin consoles (cloud consoles, hypervisors, network gear)
• Critical business apps (ERP, finance, HR)
• DevOps tooling (code repositories, CI/CD portals) where interactive logon exists

What you actually need to do (step-by-step)

Step 1 — Set your AC-7 parameters and document the decision

Create a short standard that defines:

• Invalid attempt limit (the maximum consecutive failures).
• Time window (how long failures are counted before the counter resets).
• Response when exceeded (lockout duration vs. admin reset, throttling, alerting).
• Scope (systems/users covered; how you handle service accounts and break-glass accounts).
• Exceptions process (how a system can deviate and what compensating controls are required).

Keep it crisp. The standard is what you will hand to IAM, endpoint, infrastructure, and application owners.

Step 2 — Build an authentication surface inventory (scope map)

You cannot enforce AC-7 if you cannot name where logon happens. Build an inventory that lists:

• System/app name and owner
• Auth mechanism (IdP/SSO, local auth, LDAP, RADIUS, custom)
• Where lockout is configured (IdP policy, OS policy, app setting)
• Logging location (SIEM, native logs)
• Exception status (yes/no, with rationale)

Practical tip: start with “internet-exposed” and “admin” entry points first, then move inward.

Step 3 — Implement guardrails in the IdP and central auth services

If you run centralized identity, make it the default enforcement point:

• Configure lockout/throttling policies in the IdP for workforce users.
• Ensure policies apply to all relevant apps through conditional access or equivalent policy constructs.
• Align MFA and risk-based controls where used, but do not treat MFA as a substitute for AC-7. AC-7 still expects controls on repeated invalid logon attempts. ¹

Step 4 — Close bypass paths (local accounts, admin consoles, legacy apps)

This is where audits find gaps. Address:

• Local OS accounts: enforce account lockout policies via endpoint management/group policy or configuration management on servers and workstations.
• Privileged access: ensure PAM tooling and privileged admin portals enforce attempt limits, including for break-glass processes (with documented, controlled exceptions).
• Legacy apps: if an app cannot enforce attempt limits, front it with SSO, a reverse proxy, or an access gateway that can.
• Third-party SaaS: confirm the platform supports lockout/throttling; if not, document the risk decision and compensating controls (network restrictions, SSO-only enforcement, additional monitoring).

Step 5 — Define the operational response path

AC-7 is not only “set a number.” You need a runbook for what happens next:

• Who receives alerts for lockouts or brute-force indicators
• How the service desk verifies identity for unlocks/resets
• When to escalate to incident response (patterned failures across accounts, geolocation anomalies, admin account targeting)
• How to handle suspected credential stuffing (rate limiting, IP blocking, WAF rules where relevant)

Tie this to your incident handling process so repeated lockouts become actionable security signals.

Step 6 — Test and prove it works (sampling-based)

Pick a small set of representative systems and perform a controlled test in a non-production or approved test context:

• Attempt invalid logons until the threshold is hit.
• Capture screenshots/config exports showing the threshold and window.
• Capture logs showing the event sequence and the resulting lockout/throttling.

Auditors will often do this themselves. Doing it first reduces surprises.

Step 7 — Operationalize recurring evidence

Set a cadence for evidence collection that fits your audit cycle:

• Configuration snapshots for IdP policies, VPN policies, OS baselines, PAM settings
• Monthly (or other defined) SIEM queries for excessive failures and lockout events
• Exception register updates with approvals and compensating controls

Daydream (or a similar GRC workflow) becomes useful here because AC-7 evidence is repetitive and cross-team. The workflow you want is: control owner assignment, a standard procedure, automated evidence requests to system owners, and a single audit-ready packet.

Required evidence and artifacts to retain

Retain evidence that proves design, implementation, and operation:

Design (what you decided)

• AC-7 standard (attempt limit, time window, response, scope)
• Risk acceptance memos for exceptions (with compensating controls)
• RACI/control ownership mapping for AC-7

Implementation (how it’s configured)

• IdP policy exports or screenshots showing lockout/throttling settings
• VPN/remote access configuration showing enforcement
• OS baseline or endpoint management policy showing lockout settings
• PAM configuration for privileged interactive logons
• Application configuration evidence or SSO enforcement proof for key apps

Operation (proof it runs)

• SIEM queries and results for failed logons, lockouts, brute-force patterns
• Ticket samples for unlock/reset with identity verification steps
• Incident records where repeated failures triggered investigation (when applicable)

Common exam/audit questions and hangups

Expect questions like:

• “What are your configured values for maximum invalid attempts and the time window, and where are they documented?” ²
• “Show me enforcement for admin interfaces and remote access, not just SSO.”
• “How do you ensure SaaS apps inherit your lockout policy?”
• “Which systems are exceptions, and what compensating controls are in place?”
• “Demonstrate, via logs, that the control triggers when the threshold is exceeded.”

Hangups that slow audits:

• Teams cannot produce config exports quickly.
• Different systems have different thresholds without approved exceptions.
• Lockout is enabled, but logs are missing or not centrally searchable.

Frequent implementation mistakes and how to avoid them

1. SSO-only thinking

   • Mistake: “The IdP has lockout, so we’re done.”
   • Fix: inventory bypass paths (local auth, VPN, admin consoles) and enforce there too.

2. No defined time window

   • Mistake: setting an attempt limit but not clearly defining the counting period.
   • Fix: document the time window and verify the platform actually supports it or an equivalent behavior. ²

3. Overly aggressive lockouts that create a helpdesk DoS

   • Mistake: thresholds so strict that normal user behavior triggers lockouts, or attackers can easily lock out users.
   • Fix: pair lockout with throttling, monitoring, and service desk identity checks; document rationale.

4. Ignoring service accounts and break-glass accounts

   • Mistake: exceptions exist informally and are not governed.
   • Fix: explicitly scope account types; require compensating controls for any non-standard handling.

5. Evidence gaps

   • Mistake: configuration exists but no one can prove it during an assessment.
   • Fix: assign an AC-7 control owner and define recurring evidence artifacts (policy export, sample logs, exception register). ¹

Risk implications (why AC-7 gets scrutiny)

If AC-7 is missing or inconsistently enforced, attackers can perform brute force or credential stuffing against the weakest login surface. Even where MFA exists, attackers still target password entry points to trigger lockouts (availability impact) or to find pathways where MFA is not enforced. AC-7 reduces both likelihood (harder to guess) and dwell time (more detectable patterns in logs).

Practical execution plan (30/60/90-day)

Use this as a fast operational plan. Adjust to your environment; do not treat the timeboxes as guarantees.

First 30 days (Immediate)

• Assign a single AC-7 control owner (IAM or Security Engineering) and name supporting owners for endpoints, servers, VPN, and key apps.
• Publish an AC-7 standard with your chosen attempt limit, time window, and response behavior. ²
• Build the first-pass authentication surface inventory focused on:
  • internet-exposed logons
  • privileged/admin logons
  • remote access

By 60 days (Near-term)

• Implement or validate enforcement in:
  • IdP/SSO
  • VPN/remote access
  • endpoint/OS policy for managed fleets
  • PAM for privileged logons (where applicable)
• Stand up SIEM detections or log searches for excessive failures and lockouts.
• Create an exception register and route any gaps through formal approval.

By 90 days (Operationalize)

• Expand enforcement to remaining apps and legacy systems; front-end with SSO or compensating controls if native settings are weak.
• Run a tabletop or controlled test that demonstrates the lockout/throttling behavior and captures evidence.
• Establish recurring evidence collection (config exports + log samples) and store it in your GRC system. Daydream is a practical fit if you need templated evidence requests, owner tracking, and audit-ready packaging across many systems.

Frequently Asked Questions

Does AC-7 require account lockout, or is throttling acceptable?

AC-7 requires enforcing a limit on consecutive invalid attempts within a defined period. The control text is parameterized and does not mandate a single response mechanism in the excerpt you provided, but you should document and evidence the chosen response. ²

If we use MFA everywhere, do we still need AC-7?

Yes. AC-7 is about limiting invalid logon attempts and reducing password-guessing and lockout-based abuse. MFA strengthens authentication, but it does not automatically enforce attempt limits across every logon surface. ¹

How do we handle service accounts that might break if locked out?

Decide and document whether service accounts are allowed interactive logon. If a service account must authenticate interactively, treat it as in-scope and add compensating controls for any exception (restricted access paths, strong monitoring, controlled resets).

What evidence is strongest for auditors?

Configuration exports or screenshots from each enforcement point (IdP, VPN, OS baseline, PAM) plus centrally searchable logs showing failed logons and the lockout/throttling event. Pair that with an exceptions register and approvals.

Our legacy application can’t enforce a time window. What do we do?

Front the application with an authentication layer that can enforce the control (SSO, access gateway, reverse proxy) or document an exception with compensating controls and monitoring. Keep the exception explicit and time-bound in your governance process.

How do we keep this from becoming a constant helpdesk burden?

Tune thresholds based on observed behavior, add throttling and monitoring, and ensure the unlock process has clear identity verification steps. Also look for patterns of targeted lockouts, which may indicate an attack rather than user error.

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5 OSCAL JSON

3. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON