AC-7: Unsuccessful Logon Attempts

AC-7 requires you to set and enforce a maximum number of consecutive failed logon attempts for each user within a defined time window, then trigger a defined response (such as account lockout, delay, or administrator notification). To operationalize it fast, standardize the threshold, implement it across all authentication points, and retain proof of configuration, testing, and ongoing monitoring ¹.

Key takeaways:

• Define a single, risk-based failed-login threshold and time period, then apply it consistently across systems ¹.
• “Implemented” means enforced at the control point (IdP, OS, VPN, application), not written in policy.
• Evidence is configuration + test results + monitoring output + exceptions, tied to an owner and recurring health checks.

AC-7: Unsuccessful Logon Attempts is one of those controls auditors expect to be “boring and done,” because it’s foundational to account protection and brute-force resistance. The requirement is simple: you pick a number of invalid attempts and a time window, and you enforce a limit. The operational complexity comes from sprawl. Most organizations authenticate users through multiple paths: a primary identity provider (IdP), SaaS apps with local accounts, VPN and VDI, privileged access tools, break-glass accounts, endpoints, and service consoles. If any one of those paths lacks a limit (or is misconfigured), attackers and internal threat actors get an easy lane.

For a CCO, GRC lead, or security compliance owner, the fastest way to make AC-7 real is to treat it as an engineering-backed “requirement card” with clear decisions: the threshold and time period, the enforcement mechanism, the reset behavior, and exceptions (like service accounts and emergency access). Then you prove it works with repeatable tests and monitoring artifacts, not screenshots collected once and forgotten. This page gives you requirement-level steps, evidence expectations, and the audit questions that tend to stall teams.

Regulatory text

Requirement (excerpt): “Enforce a limit of [number] consecutive invalid logon attempts by a user during a [time period] ; and” ¹

Operator interpretation: You must (1) define a maximum count of consecutive failed logon attempts and a time window, and (2) enforce that limit at each relevant authentication point in scope. “Enforce” means the system must actually prevent continued guessing (for example, by lockout, throttling, or other configured response) once the limit is reached, not merely detect failures ¹.

What the operator must do:

• Choose the threshold and time period as explicit configuration values.
• Implement the limit consistently wherever users can log in (central IdP and any local authentication surfaces).
• Define the action taken when the limit is reached (lock, delay, deny, alert) and who can reset.
• Prove it works through testing and retain evidence that it stays in effect ¹.

Plain-English requirement (what AC-7 is really asking)

AC-7 is a brute-force control. If someone keeps guessing passwords (or guessing MFA/OTP where applicable), your systems must stop accepting unlimited attempts. You set a failure limit in a defined time window and trigger a response that reduces the chance of unauthorized access and creates an operational path to restore legitimate users.

Your key design decision is consistency: the same user should not be able to bypass the limit by switching entry points (for example, failing at the VPN, then trying the same account at an app with local auth). AC-7 becomes an access control program when you implement it centrally and aggressively remove local authentication where possible.

Who it applies to

Entity types and environments:

• Federal information systems.
• Contractor systems handling federal data ¹.

Operational context (where you must enforce AC-7):

• Workforce identity: SSO/IdP logons, desktop logon (domain), and privileged identity paths.
• Remote access: VPN, VDI, bastions, jump hosts.
• Administrative consoles: cloud provider consoles, CI/CD admin panels, database admin tools.
• Applications that still support local credentials (legacy apps, appliances, embedded systems).
• Any third-party managed environment where your users authenticate (you still need assurance and evidence).

If a system is “in scope” for your NIST 800-53 boundary, and users can authenticate to it, AC-7 should be enforced there or inherited from a central authentication service.

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

1) Create the requirement control card (owner, scope, decisions)

Write a one-page control card for AC-7 that includes:

• Control owner: named role (Identity & Access lead is typical).
• In-scope authentication surfaces: IdP, VPN, endpoints, privileged tools, key apps.
• Configured values: failed attempt limit and time period (explicit, not “reasonable”).
• Response action: lockout vs throttling vs deny with delay; reset rules.
• Exceptions: break-glass accounts, non-interactive/service accounts, vendor-maintained systems.
• Evidence bundle: exactly what you will retain each cycle. This maps directly to the “operators can’t show ownership/cadence/evidence” risk factor that often sinks audits ¹.

2) Decide enforcement pattern (centralize where possible)

Pick one of these patterns and document it in the control card:

Pattern	Where enforced	Good for	Audit risk
Central enforcement	IdP/SSO and directory (plus VPN)	Modern SSO-first stacks	Lower, if apps truly rely on IdP
Distributed enforcement	Each app/OS/VPN configured separately	Legacy environments	Higher, configuration drift risk
Hybrid	Central for most, local for exceptions	Most real environments	Medium; requires explicit exception list

Operational preference: centralize enforcement in the IdP and directory, then remove or tightly control local authentication in apps. AC-7 is easier to prove when a single system generates the authoritative lockout/throttle behavior.

3) Implement configurations across each logon surface

For each authentication surface, implement and record:

• Failure counter behavior: What counts as an invalid attempt (bad password, bad MFA, both)?
• Time window: rolling window vs fixed interval; reset after success; reset after admin action.
• Response: lock duration rules or throttling behavior; user messaging; helpdesk workflow.
• Privileged accounts: stricter handling is common, but if you do it, document it as an intentional standard.

Common systems to cover:

• IdP/Directory: sign-in risk policies, smart lockout / throttle, account lockout policies.
• VPN/Remote access: local vs directory-backed; confirm it inherits the directory policy.
• Endpoints/Servers: OS policy (domain GPO or MDM policies).
• SaaS apps: confirm SSO is enforced; if local accounts exist, configure the app’s lockout policy or disable local login.

4) Build the operational runbook (reset, exceptions, and escalation)

AC-7 fails operationally when lockouts become noise or denial-of-service. Your runbook should define:

• Who can unlock accounts and under what identity verification steps.
• When to treat lockouts as security events (patterns across accounts, high-value accounts).
• How to handle repeated lockouts (possible credential stuffing).
• Break-glass process: conditions, approval path, and post-use review.

5) Monitoring and alerting (make it observable)

Minimum monitoring expectations:

• Collect authentication logs showing failed attempts and lockout/throttle events.
• Alert on patterns: multiple accounts locked from one source, repeated lockouts on privileged users, lockouts outside business norms.
• Review a sample of events on a recurring cadence and document outcomes.

If you use Daydream to manage control operations, set AC-7 up as a recurring control with an assigned owner, evidence checklist, and remediation tracking so you can show sustained operation rather than a one-time configuration snapshot ¹.

6) Test it like an auditor would (and save the results)

Testing should be repeatable and scoped:

• Pick representative systems (IdP, VPN, one critical app, one privileged interface).
• Execute failed logons until the configured limit is reached.
• Capture evidence: timestamps, lockout/throttle event, and recovery steps.
• Repeat after a change (IdP policy change, app upgrade, VPN migration).

Required evidence and artifacts to retain

Keep evidence that proves design, implementation, and operation:

Design artifacts

• AC-7 control card (owner, threshold/time window, response, scope, exceptions).
• Standards/policy excerpt that states the organization’s AC-7 parameters.

Implementation artifacts ¹

• Configuration exports or policy objects (preferred) for IdP/directory/VPN/OS.
• Screenshots only if exports are impossible, with system name, admin path, and date.

Operational artifacts

• Test scripts and test results (what you did, where, outcome).
• Log samples showing failed attempts and lockout/throttle events.
• Ticket samples for unlock requests (showing identity verification and approval).
• Exception register entries (break-glass/local accounts) with compensating controls.

Governance artifacts

• Change records for authentication policy changes.
• Recurring control health check record and remediation tracking to closure ¹.

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers:

• “What is your configured limit and time period?” Provide the exact values and where they are enforced ¹.
• “Show me enforcement for VPN and the cloud console.” Auditors pick alternate entry points.
• “Do service accounts and break-glass accounts follow this policy?” If not, show the exception and compensating controls.
• “How do you prevent lockout abuse (DoS)?” Show throttling design, user verification, and alerting.
• “How do you know this hasn’t drifted?” Provide periodic health checks and configuration baselines.

Hangups that slow audits:

• Teams can’t list all authentication surfaces.
• Evidence is a single screenshot with no context.
• Local accounts exist in SaaS apps “just in case,” with weak lockout settings.

Frequent implementation mistakes (and how to avoid them)

1. Only configuring the IdP and ignoring local logons.
   Fix: inventory all logon surfaces, then either federate to IdP or configure local lockout.

2. Relying on policy text without technical enforcement.
   Fix: treat configuration artifacts as primary evidence. Policy supports; config proves.

3. Inconsistent settings across systems.
   Fix: publish a standard and track deviations as exceptions with owners and review dates.

4. No reset/verification process.
   Fix: write a helpdesk runbook and require identity verification before unlocking.

5. No monitoring of lockouts.
   Fix: route auth logs to your SIEM and create at least one alert for repeated lockouts on sensitive accounts.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, AC-7 gaps increase exposure to password guessing and credential stuffing. The business risk shows up as account takeover, unauthorized access to federal data, and audit findings that question baseline access control maturity.

Practical execution plan (30/60/90)

Use phases rather than day counts if your change windows are unpredictable.

First phase (Immediate): set the standard and cover the main control points

• Assign the AC-7 control owner and publish the control card ¹.
• Decide the threshold and time window and get security + IT operations sign-off.
• Implement/enforce in your primary IdP/directory and VPN.
• Run a proof test and save evidence.

Second phase (Near-term): eliminate bypass paths and formalize operations

• Inventory remaining logon surfaces (apps with local auth, appliances, admin consoles).
• Federate to SSO where feasible; configure local lockout where not.
• Implement the unlock runbook and ticket tagging for lockouts.
• Turn on monitoring and basic alerting; document review ownership.

Third phase (Ongoing): keep it healthy and auditable

• Run recurring control health checks and track remediation to closure ¹.
• Review exceptions (break-glass, vendor-managed) and reconfirm compensating controls.
• Retest after major changes (IdP migration, VPN change, app upgrades).
• Package evidence in a consistent repository so audits do not become a scavenger hunt.

Frequently Asked Questions

Do we have to use account lockout, or is throttling acceptable?

AC-7 requires you to enforce a limit within a time period and trigger a response that stops unlimited attempts ¹. Lockout is common, but throttling or delays can also enforce a limit if they effectively prevent consecutive guessing and you can prove the behavior.

What should we set as the number of attempts and time window?

NIST leaves the values as assignment parameters, so you must choose and document them ¹. Pick values your business can support operationally, then standardize them across systems and manage deviations as explicit exceptions.

Does AC-7 apply to MFA failures too?

If your systems treat incorrect MFA challenges as part of “invalid logon attempts,” include them in scope so the control blocks repeated guessing across the full authentication flow. Document exactly what counts as a failed attempt in your control card and test plan.

How do we handle service accounts that don’t “log on” interactively?

If the account can authenticate to a system, assess whether lockout could break production. Where you must exempt non-interactive accounts, document the exception and add compensating controls like tight network restrictions, credential rotation, and monitoring of auth failures.

What evidence do auditors prefer for AC-7?

Configuration exports/policy objects plus a short test record that shows the limit triggering in real conditions tend to pass fastest. Pair that with log samples and a defined unlock runbook so the control looks operational, not theoretical.

We outsource IT to a third party. Can we inherit AC-7?

You can inherit operation, but you still need assurance. Require the third party to provide configuration evidence and lockout event logs for in-scope systems, and track the requirement in your control register with an internal owner accountable for review.

Footnotes

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