AC-7 Unsuccessful logon attempts: requirements and evidence

What AC-7 unsuccessful logon attempts requires in plain terms

When an assessor or customer asks for lockout evidence under AC-7, they want two things shown: the organization has defined a limit on failed logons within a set period, and the system responds automatically when that limit is exceeded. AC-7 requires both parts, and the organization, not the platform, decides the values. The control is selected in the SP 800-53B low, moderate and high baselines but not in the privacy baseline, so any system in scope for those baselines needs a documented setting and proof that it runs. The first part is the organization-defined limit on consecutive invalid logon attempts and the period in which those attempts are counted. The second part is the automatic response: locking the account or node, delaying the next logon prompt, notifying an administrator or taking another action the organization defines. Many teams configure a lockout and stop there. Assessors also look for the response being written down in the system security plan, applied to every logon path, and survivable by an authorized administrator who needs to unlock an account. Confirm with your assessor whether they accept a delay in place of a lockout, and record the chosen response for each system.

The control exists because password guessing and credential stuffing, where attackers replay leaked username and password pairs, depend on unlimited attempts. Limits make those attacks slow and noisy. The hard part is consistency. Identity providers, local operating system accounts, databases and network devices often each carry their own lockout settings, and a user may be locked out in one place but not another, or an attacker may find a path with no limit at all. Lockouts also create denial-of-service risk: an attacker who deliberately fails logons can lock out real users. Plan the response to avoid that, for example with delays or alerts rather than permanent locks on high-value accounts, and document the trade-off in your risk decisions.

Which systems, accounts and teams does AC-7 cover?

AC-7 applies wherever a logon is accepted inside the authorization boundary, so scoping starts with an inventory of every interface that takes a password, token or key. The cards below cover the systems, account types and inherited settings that most often change the work, and the decisions to record in the system security plan before an assessor arrives.

Identity providers and directory services

Central identity providers and directories such as FreeIPA are the most common place where the lockout threshold is set for many applications at once. Confirm whether the threshold lives in the directory, in the identity provider or in each application, because a single setting can cover dozens of logon paths. Record which component enforces the limit and what happens when it trips, since an assessor will test that component directly. Document the enforcing component for every logon path.

Applications that delegate sign-in

Applications that hand sign-in to a central provider, such as authentik acting as an OAuth2, OpenID Connect, SAML, LDAP or proxy provider, may have no local logon form at all. In that case AC-7 is largely satisfied by the provider, but the application must still be checked for any local fallback login, API key or admin bypass. List each application, its sign-in path and whether a local password path remains.

Infrastructure access: SSH, consoles and network devices

SSH daemons, hypervisor and out-of-band consoles, firewalls, switches and VPN gateways often keep local accounts that bypass central identity. Each one accepts logons and must be covered by the limit or be explicitly justified. Check whether the device supports a failed-attempt threshold and a lockout or delay, and where it does not, record a compensating mechanism such as an alert on repeated failures.

Local, break-glass and emergency accounts

Break-glass accounts exist to work when central identity fails, which makes them a likely target and a likely lockout risk at the same time. Decide in advance whether these accounts lock automatically, delay the next prompt or only alert, and who can unlock them without reopening the same risk. Store their credentials under documented control and test the emergency unlock path, because an assessor will ask how a legitimate administrator recovers access.

Service accounts that cannot be locked

Service and automation accounts often authenticate programmatically, and a lockout can stop a batch job, a backup or an integration. Where a lockout would cause an outage, document the exception, the reason the account cannot be locked and the alternative control, such as strong credentials, restricted source addresses and monitoring for repeated failures. Confirm the exception with the risk owner and keep it in the plan of action and milestones until it is closed.

Third-party SaaS and inherited provider settings

For SaaS platforms, the organization often cannot change the lockout threshold and can only inherit the provider's setting. Request the provider's documented logon controls and any independent assessment reports covering them, then record which settings are inherited and which are configured by the organization, such as single sign-on enforcement. Confirm these details with each vendor in writing, since the organization owns the control's outcome even when the provider controls the mechanism.

How an assessor tests the lockout setting

This table pairs each SP 800-53A assessment method for AC-7 with the objects an assessor examines, interviews or tests, the evidence to prepare and the findings that commonly appear. Read it as a preparation checklist: the two determination statements define what must be shown, and each row shows where that proof usually comes from. The main takeaway is that a policy value alone rarely passes; assessors look for the same limit applied on every logon path and a documented response when it is exceeded.

Method and objects	Evidence to prepare	Common findings
Examine: access control policy and procedures addressing unsuccessful logon attempts	Approved access control policy and procedure text naming the failed-logon limit, the time window and the response, with review dates	Policy states a limit but gives no time window, or procedures do not name who reviews the setting
Examine: system design documentation and system security plan	Design notes showing where logon is enforced (directory, identity provider, application) and the parameters the organization set for AC-7	Design documents describe lockout only for one application while other login paths are not covered
Examine: system configuration settings and associated documentation	Exported configuration showing the attempt limit, time window, lockout duration or delay and alert setting for each enforcing component	Settings differ between the directory and an application, or the values in the export do not match the policy
Examine: system audit records	Sample of failed-logon and lockout events showing that the response fired at the defined threshold	No lockout or alert events exist for the period, so the assessor cannot confirm the control operates
Interview: system developers	Named developers who can explain how lockout is implemented in custom or configured applications	Developers are unaware of lockout behavior in an application added after the initial design
Interview: system and network administrators	Administrators who can describe how they receive alerts, how locked accounts are released and how exceptions are approved	Administrators say release is done by hand with no record, or alerts go to a mailbox nobody monitors
Test: mechanisms implementing the access control policy for unsuccessful logon attempts	Test scripts and results that submit repeated invalid credentials on each login path and record the outcome	The limit is enforced on the web console but not on API, SSH or directory bind paths
Test: lockout response and alert delivery	Test record showing the account or node locks, the delay applies or the administrator is notified as the policy defines	No documented response when the limit is exceeded, or the response fires only after a manual check

How to implement AC-7 step by step

This sequence turns the AC-7 requirement into settings that each logon path enforces, with a signed parameter decision, configuration records and test results that an assessor can follow from policy to system behavior.

Inventory every logon path
List every way a user, administrator, service or device can attempt to log on to the system boundary. Include the web console, SSH or RDP access, database logons, API token exchanges, VPN and remote access gateways, and any local accounts kept for emergencies. Record which identity source or local store validates each path. The owner of the system security plan should review the list with the system administrators, because local or legacy logon paths are the ones most often missed. The output is a path inventory showing each path, its authenticator store and its owner. The step is complete when every path in the inventory has a named enforcement point.
Define the limit, window and response
Have the organization decide the number of consecutive invalid logon attempts it will allow, the period over which those attempts are counted, and the automatic response when the limit is exceeded. Responses include locking the account or node, delaying the next logon prompt, notifying an administrator or taking another defined action. Record the rationale, the risk owner and any differences between user classes, such as administrators and standard users. The output is a signed parameter decision approved under the access control policy. Confirm the values with your own risk assessment and any applicable contract or regulator requirement rather than adopting a default from a vendor.
Write the policy and procedure references
Update the access control policy and the procedures that address unsuccessful logon attempts so they cite the approved parameters, the systems in scope and the response owner. Include what happens when a locked account is reported, who may verify the user's identity and how the event is recorded. Link this text to the related controls for account management, audit and authenticator management so the dependencies are visible to assessors. The output is a versioned policy and procedure document with an approval record. The step is complete when the parameter decision is traceable from the policy to each procedure.
Configure each system or identity provider
Apply the approved limit, window and response to each enforcement point from the inventory. Where applications delegate sign-in to a central identity provider, such as authentik acting through OAuth2, OpenID Connect, SAML, LDAP or proxy providers, confirm the setting at the provider and check that each application does not add its own weaker logon behavior. Where a system authenticates locally, such as a Linux host or a database, configure the native lockout or delay mechanism and document the exact keys or policy objects used. Export the configuration from each component. The output is a set of configuration exports, one per path, with the date and the person who applied the change. Confirm the exact setting names with each vendor's current documentation.
Decide how locked accounts are unlocked
Define who may unlock an account or node, what verification they must perform before doing so, and whether unlocking can be automated after a defined period. Consider the effect on service accounts, emergency administrator access and remote users who may be locked out while traveling. Document the approval path and the audit record created for each unlock. Where a central identity provider or directory manages the account, specify whether the unlock happens there or in each application. The output is a written unlock procedure and a role assignment list that names the people allowed to unlock accounts. The step is complete when the procedure has been tested by the same administrators who will use it.
Route failure events to monitoring
Confirm that failed logons and the lockout or delay response are written to the system audit records and sent to the place where administrators review them. Log sources may include the identity provider, the operating system, the database and the remote access gateway. A security analytics platform such as OpenSearch Security Analytics, which uses Sigma rules to match ingested logs and raise alerts, or Wazuh, which compares events against its ruleset and writes alerts, can be used to create detections for repeated failures and lockouts. Confirm that each detection is tested against the log format actually produced by the system. The output is a detection rule export and a sample alert showing a lockout event reaching the review channel.
Test each path with controlled failed logons
Run controlled failed logon attempts against each path in the inventory, using test accounts that are approved for the purpose. Confirm that the account or node locks after the defined number of consecutive failures within the defined window, that the response occurs as specified, that the unlock procedure works, and that the event appears in the audit records and alerts. Repeat the test for each user class in the parameter decision. Record the timestamp, path, test account, observed behavior and any deviation. Retain the results for the assessor. The output is a dated test record for each path, with failures investigated and retested before the step closes.
Document the settings in the system security plan
Record the approved parameters, the enforcement point for each logon path, the unlock role assignments, the monitoring detections and the test results in the system security plan for AC-7. Reference the configuration exports and test records by version so an assessor can locate them. Note any path that uses inherited settings from a common control provider and confirm the inheritance is documented in the agreement. Ask the independent assessor which evidence format they expect before finalizing the plan. The output is an updated system security plan section for AC-7 that matches the live configuration, and the step closes when a second reviewer has reconciled the plan against the exports and the test record.

Which evidence passes an AC-7 assessment and how to keep it current

An assessor testing AC-7 looks for proof that the limit, window and response are defined, configured and working, and that they stay that way. The cards below cover the artifacts that carry that proof and how to refresh each one between assessments so the evidence does not go stale.

Access control policy and failed-logon procedures

The policy and procedures should name the organization-defined limit on consecutive invalid logon attempts, the period over which attempts are counted, and the automatic response when the limit is exceeded. Assessors examine this text first, so each value must match what the systems actually enforce. Review the section whenever a platform changes or a new identity provider is added, and record the review date and approver in the document history.

Identity provider configuration exports

Export the lockout or throttling settings from every identity provider and directory that authenticates users, including the limit, window, lockout duration and any delay. Store the exports with a timestamp and hash them so they can be compared over time. Schedule the export at a fixed interval and also after any change ticket touching authentication, then diff the output against the approved baseline. Confirm with each vendor which lockout options the product actually exposes, since settings differ between identity providers, directories and proxy layers.

Failed-logon and lockout audit records

Audit records of failed logons and lockout events show the control operating in production, not only in design. Confirm that each system writes failed attempts and lockouts with user, source, timestamp and outcome, and that the records are retained for the period your policy sets. Pull a sample of lockouts each quarter and check that each one corresponds to a real failed-attempt sequence. Gaps in the log stream are findings in their own right, so monitor for log silence from each source.

Controlled failed-logon test records

Run a scripted failed-logon exercise against a non-production or designated test account on each in-scope system, and record the attempts, the moment the limit is hit, the response observed and the time to unlock or resume. Keep the test plan, the account used, the expected result and the actual result side by side. Repeat the test after any change to authentication, identity provider upgrades or policy edits. Have the test run by someone other than the administrator who owns the configuration to strengthen the evidence.

Alert rules and sample administrator alerts

Where the response includes an administrator alert, keep the rule that generates it and examples of alerts it has sent. Open-source tools such as Wazuh and OpenSearch Security Analytics can collect failed-logon events, match them against rules and send alerts to channels such as email or Slack. Confirm each tool's detection and alerting options for your log sources before relying on them, then test the rule with a controlled exercise and file a dated sample alert. Review the rule set when log formats or sources change.

System security plan entries

The system security plan should describe how AC-7 is implemented for each system, including which component enforces the limit, the values chosen, any inherited settings from a shared identity service and the owner responsible. Assessors compare these entries with the configuration exports and test results, so mismatches are a common finding. Update the entries through the change process whenever a limit or component changes, and reconcile the plan against the latest export at each review cycle.

What meeting AC-7 costs in money and effort

This table lists each cost component of meeting AC-7, who typically carries it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a request for a fixed-scope written quote, since no prices or durations are published here.

Cost component	One-time or recurring	What drives it up	How to keep it down
Policy and procedure drafting for logon limits	One-time, then reviewed periodically	Number of system types with different lockout rules and approval steps	Write one account lockout standard that covers all logon paths, with system-specific exceptions listed
Engineering time to configure each logon path	One-time per path, plus changes	Number of logon paths, such as web, SSH, VPN, database and API, and number of identity providers	Consolidate sign-in on one identity provider such as authentik or FreeIPA so limits are set in fewer places
Legacy or unsupported system adaptation	One-time, often the largest single item	Applications that cannot enforce lockout natively and need a proxy, wrapper or compensating control	Retire or front legacy logons with a supported identity provider before scoping the work
Test effort to prove lockout behavior	One-time, then repeated after changes	Number of paths and thresholds to exercise, plus evidence needed for each run	Reuse one scripted test that checks threshold, time window, lockout or delay and alert in each environment
Log collection and alerting setup	One-time build, recurring tuning	Number of log sources feeding the detector and number of alert channels	Forward failed-logon events from the identity provider to one SIEM, such as Wazuh or OpenSearch Security Analytics, and tune rules once
Recurring evidence upkeep	Recurring	Frequency of assessments, configuration drift and staff turnover	Store configuration exports and alert samples in one evidence location and regenerate them on a schedule
External testing or review	Recurring or per engagement	Scope size, number of applications and whether testing is combined with other controls	Agree scope in writing and include AC-7 checks in an existing testing plan
Auditor or assessor sampling	Per assessment	Number of systems in scope and how many lockout events the assessor asks to see	Keep a clear inventory of logon paths and documented settings so sampling is quick
Open-source licensing	No license fee for listed components, verify terms	Not applicable to licensing; operating effort still applies	Budget for hosting, patching, integration and staff time, which remain even when licenses are free

Who does what: your team, an implementation partner and the auditor

Your organization owns AC-7. It is the only party that can decide what the limit and time window should be, what happens after the limit is exceeded, and how a locked user regains access. Those choices belong in the access control policy and in the system security plan, because an assessor will test the system against what the organization says it does. Your team also owns the risk acceptance when a setting differs from a stricter expectation, for example when a legacy application cannot enforce the same lockout behavior as the rest of the estate.

Policy decision: Set the consecutive failure limit, the window and the response (account lockout, node lockout, delay or administrator alert) and record the rationale.
Unlock process: Define who may unlock accounts, how the requester is verified and how unlock events are logged.
Risk acceptance: Document each exception, its compensating control, its owner and its review date.
Coverage scope: Decide which systems, identity providers and privileged interfaces fall under AC-7 and which are explicitly excluded.
Evidence ownership: Keep the current configuration exports, change records and alert review records in your own repository.

Check that the policy, the configured values and the system security plan say the same thing before an assessment begins.

Where AC-7 usually fails and how to close each gap

Most AC-7 findings are not about the lockout threshold itself. They appear where the limit is missing from one login path, where it was never exercised, or where the response to a lockout has no owner. Each card below names a gap, the fix, and the evidence an assessor would expect to see once it is closed.

Limit missing from one login path

A lockout threshold is often set on the main identity provider while a legacy admin console, a local database login or the SSH daemon still accepts unlimited guesses. Inventory every path that accepts a password, including break-glass accounts, and confirm each one enforces the organization-defined limit. For SSH, check the PAM or daemon settings on each host rather than assuming the directory policy applies. Evidence is a per-path table of configured limits with the configuration file or setting that enforces each one.

Lockout configured but never tested

A threshold that exists only in a configuration file proves nothing about enforcement. Test each login path with deliberate failed attempts from a non-production account and record whether the account or node locks, the delay applies and the administrator alert fires. Repeat the test after every change to identity settings, since upgrades and policy edits can reset values. Evidence is a dated test log showing the attempts made, the observed result and the person who ran the test.

No documented response to lockout

AC-7 requires an automatic response, but the organization must also define what happens next: who is notified, how a locked user is verified before reset and when an event is escalated as a possible attack. Without a written response, lockouts become help-desk tickets with no security review. Write the response into the access control procedures, assign an owner and set the alert destination. Evidence is the approved procedure, the alert rule that routes lockout events, and a sample of closed tickets showing the steps were followed.

Lockouts that disable service accounts

Applying the same lockout threshold to service and automation accounts can stop batch jobs, integrations and monitoring agents whenever a stored password changes. Teams then disable the lockout for those accounts, which removes the control for some of the most privileged non-human identities. Separate service accounts into their own policy, rotate their credentials through a managed process and document the compensating controls, such as restricted source addresses and alerting on repeated failures. Evidence is the account inventory with the policy assigned to each account type and the approved exception record.

Failed logons not forwarded to monitoring

A lockout that no one sees does not meet the alerting intent of AC-7. Failed authentication events often stay on the host or identity provider and never reach the log platform, so no detector can correlate them. Confirm that authentication failures from every login path are forwarded, parsed and matched by a rule that raises an alert. Open-source options such as Wazuh and OpenSearch Security Analytics can match ingested logs against rules and route alerts to a channel. Evidence is a log source inventory, a sample failed-logon event with its ingestion record, and an alert fired by a test event.

What buyers ask before bringing in help for AC-7

How much effort does AC-7 take in a small environment compared with a large one?

AC-7 is one of the lighter access control items, so the effort is driven less by the control itself and more by how many places accept logons. A small environment with one identity provider and a handful of applications usually has one lockout policy to define, one set of settings to verify and a short list of systems to test. A large environment may have directories, VPN gateways, cloud consoles, databases, service portals and legacy applications, each with its own failed logon behavior. Every additional authentication point needs its own configuration evidence and test result. Ask any partner to list the systems in scope before quoting, because the written scope is what sets the effort.

Can our own staff meet AC-7 without outside help?

Often yes, if the team already runs its identity systems and can document them. The organization owns the control, so it must define the invalid logon limit, the time window and the response, then show that the systems enforce them. Internal staff who know the directory, the identity provider and the applications can usually do this work. Outside help tends to add value when the team lacks time to prepare evidence, when several identity sources must be reconciled, or when an assessor expects a clear test record. Whichever route you choose, the decision and the accountability stay with your organization.

What skills and staff time does AC-7 need from our team?

The work needs people who can read identity and access configuration and who can explain it to an assessor. Typically this means an identity administrator who can export lockout settings, a security lead who can write the policy statement, and an application owner who can confirm how each application handles failed logons. Some applications rely on the identity provider, while others keep their own login pages and counters, so someone must check each one. Plan time for testing too, since a lockout test may lock out a real test account and must be coordinated with the service desk.

How long does AC-7 take to implement and document?

Timing depends on scope, and a written scope sets it. The main variables are the number of systems that accept logons, how many identity sources exist, whether settings are already documented and how quickly testing can be scheduled around production changes. Ask any provider to state the phases, the systems covered, the evidence to be delivered and the dependencies on your staff in the written scope. Avoid planning around a generic duration, because it will not reflect your environment.

Can an auditor test AC-7 before every system is configured?

An assessor can examine and test the systems that are already configured, and report the gaps for the rest. The SP 800-53A procedure for AC-7 uses examine, interview and test methods, so an assessor will read the policy and procedures, review configuration settings and audit records, interview administrators and observe test results. Partial readiness is useful because it shows which systems are ready and which need work. Whether an assessment is run now, and how findings are recorded, is a decision for the assessor and your sponsor. Confirm the assessment approach with them before you schedule work.

Does AC-7 apply at the privacy baseline?

No. According to SP 800-53B Release 5.2.0, AC-7 is selected for the low, moderate and high security control baselines but not for the privacy baseline. If your obligations are privacy-only, AC-7 is not a required selection under that baseline. Confirm which baseline your system is categorized under, because a contract or agency may still require AC-7 through a security baseline or a local overlay.

Can a partner make the auditor's decision on AC-7?

No. An implementation partner can configure systems, prepare settings and evidence, and test lockout behavior, but only an independent auditor or assessor issues findings or reports. Your organization remains responsible for its own control decisions, including the invalid logon limit and the response it selects. DeployOpen works this way: it prepares systems and evidence for assessment and does not issue audit reports, attestations or certifications. Ask any provider to state in writing which outputs are theirs and which belong to the assessor.

How DeployOpen scopes and prepares AC-7 evidence

DeployOpen works on AC-7 as a fixed-scope piece of implementation work inside your own infrastructure. We configure the lockout behavior of the systems you own, prepare the settings and logs an assessor will examine, and hand over documentation, while your organization keeps ownership of the control and the independent assessor issues any conclusion.

How we scope

We agree in writing which systems, applications and identity flows fall under the AC-7 logon limit.
The scope names the defined attempt limit, time window and response your organization selects for each system.
Engagements are fixed-scope, and ongoing support for lockout settings is available as a retainer.

How we build

We configure lockout, delay or administrator alert settings in identity providers such as authentik or FreeIPA where they apply.
We route failed logon events from hosts and applications into OpenSearch Security Analytics or Wazuh for alerting and review.
We test lockout behavior against the settings in scope and record the results so an assessor can repeat the test.

How we hand over

We deliver configuration exports, the settings baseline and a mapping of each system to its documented limit and response.
We provide sample failed-logon alerts and audit records showing the response fired as designed.
We document open items and the tests your organization or assessor should repeat before relying on the evidence.

How we support

We help your team keep lockout settings aligned with the documented limit when systems or identity providers change.
We can rerun lockout tests after upgrades, using the same test steps recorded at handover.
We do not issue audit reports or certifications. Independent assessors make that determination based on the evidence.