Unsuccessful Logon Attempts

To meet the unsuccessful logon attempts requirement (NIST SP 800-53 Rev. 5 AC-7), you must define a threshold for consecutive invalid logons within a defined time window and enforce it system-wide by locking the account or delaying further prompts. Then you must prove it works through configuration evidence, logs, and tested exceptions. ¹

Key takeaways:

• You must choose and document both the attempt limit and the time period, then implement consistent technical enforcement across all in-scope authentication paths.
• “Lock or delay” must be automatic and measurable; compensating controls and exceptions need formal approval and testing evidence.
• Auditors will focus on coverage gaps (SSO, VPN, admin consoles, APIs) and whether logs prove enforcement in the FedRAMP boundary.

Unsuccessful logon attempt controls are one of the fastest ways to reduce exposure to password guessing and credential stuffing, but they also fail audits for a predictable reason: inconsistent enforcement across identity providers, applications, and administrative interfaces. AC-7 is explicit that your organization must define the number of consecutive invalid attempts, define the time period, and enforce an automatic lockout or a delay of the next logon prompt. ¹

For a Compliance Officer, CCO, or GRC lead supporting FedRAMP Moderate, the operational goal is straightforward: make lockout/delay behavior a standard, testable configuration requirement wherever a user can authenticate inside the authorization boundary, and maintain evidence that it remains in place over time. You are not only writing a policy statement; you are validating that each authentication stack (IdP, OS, SaaS admin console, bastion, VPN, PAM, and any customer-facing login) behaves as specified, logs the events, and supports support-desk unlock workflows without creating new security gaps.

This page gives requirement-level implementation guidance you can hand to IAM, SecOps, and system owners, plus the evidence package assessors typically request during FedRAMP assessment and ongoing continuous monitoring. ²

Regulatory text

Requirement (AC-7): “Enforce a limit of organization-defined number of consecutive invalid logon attempts by a user during an organization-defined time period; and automatically lock the account or delay the next logon prompt.” ¹

What the operator must do (in one paragraph)

You must (1) pick and document the attempt threshold and the measurement window, (2) implement technical controls that count failed attempts and trigger an automatic account lock or login delay, and (3) ensure the control is applied to all in-scope systems and authentication entry points in your FedRAMP boundary, with audit-ready evidence. ³

Plain-English interpretation

• “Organization-defined” is not optional. You must explicitly decide the maximum failed attempts and the time window those attempts are measured in, and record that decision in your policy/standard and SSP-level control description. ¹
• “Consecutive invalid logon attempts” means the counter tracks repeated failures for the same account (or identity), not just overall failures on a system. Your design should prevent an attacker from making unlimited guesses. ³
• “Automatically lock the account or delay the next logon prompt” means a human cannot be required to intervene for enforcement. Manual monitoring plus later action does not satisfy the control on its own. ¹

Who it applies to

Entities

• Cloud Service Providers (CSPs) operating a FedRAMP-authorized cloud service offering.
• Federal Agencies responsible for maintaining controls in the authorized boundary, including configurations they manage (for example, agency-managed IdP integrations or client access paths). ¹

Operational context (what’s in scope)

Apply AC-7 anywhere authentication occurs within (or controlling access into) the FedRAMP authorization boundary, including:

• Identity provider and SSO authentication flows (interactive and privileged)
• OS and directory authentication (Windows/Linux, LDAP/AD) where used
• VPN, bastion hosts, PAM jump boxes
• Cloud admin consoles and management planes
• Application logins (customer-facing and internal)
• API authentication where applicable (especially if it supports password-based grants or interactive prompts)

Your audit exposure usually comes from “forgotten” paths: legacy admin portals, break-glass accounts, local OS accounts on appliances, and non-SSO logins that bypass the central IdP.

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

Step 1: Set the control parameters (policy + standard)

1. Define the threshold and time window (example format: “X consecutive invalid attempts within Y minutes”). Record the chosen values in:
   • Access Control Policy / IAM Standard
   • System Security Plan (SSP) control implementation statement for AC-7 ²
2. Choose lockout vs delay per authentication stack:
   • Lockout is common for directory/IdP accounts.
   • Delay/backoff is often better for customer-facing apps to reduce helpdesk load, but it must be automatic and enforced. ¹
3. Define unlock/reset workflow:
   • Who can unlock
   • Required identity verification steps (at least two independent checks is common practice, but document what you use)
   • Logging requirements for unlock events (ticket number, approver, timestamp)

Deliverable: a one-page “AC-7 configuration standard” that system owners can implement without interpretation.

Step 2: Build an authentication entry-point inventory (coverage map)

Create an inventory of every logon entry point in the boundary and map it to the enforcing mechanism:

• Enforced by IdP policy (preferred)
• Enforced by directory/OS policy
• Enforced by application logic
• Enforced by a gateway/WAF/auth proxy

A simple table works:

Entry point	Auth mechanism	AC-7 enforcement location	Lock/delay behavior	Owner
VPN	RADIUS to IdP	IdP sign-in policy	Lock or delay	Network/IAM
Admin console	SSO	IdP	Lock or delay	Platform
Legacy app	Local accounts	App config	Lock or delay	App owner

Auditors like this artifact because it proves you understand your own boundary and didn’t assume SSO covers everything. ²

Step 3: Configure enforcement in each stack (do the engineering work)

Implementation actions you should require from each owner:

1. Configure failed-attempt counting ¹ and the defined time window.
2. Set the automated response to lock or delay.
3. Prevent bypass:
   • Ensure local accounts are disabled where feasible or held to the same standard.
   • Apply the same rules to admin and service portals.
4. Align privileged access:
   • For break-glass accounts, either enforce the same lock/delay controls or document an exception with compensating controls (for example, stronger MFA, limited network access, monitored use) and test results. ¹

Step 4: Centralize logging and monitoring (make it provable)

You need logs that show:

• Failed logon events
• Lockout events or delay/backoff triggers
• Unlock/reset actions (who, when, why)

Route these logs to your central logging/SIEM pipeline in the FedRAMP boundary, and ensure retention and access controls follow your broader logging program. ³

Step 5: Test it like an assessor (and keep the evidence)

For each entry point, run a repeatable test:

• Attempt invalid logons until the threshold is reached.
• Capture screenshots or exported config showing the threshold/time window.
• Capture log entries proving lock/delay occurred.
• Validate unlock workflow and capture the ticket + audit trail.

Store the test script and results as an “AC-7 validation packet” so you can re-run it for continuous monitoring and after IAM changes.

Step 6: Exceptions and third parties (control the blast radius)

When you cannot enforce AC-7 (common scenarios: some SaaS admin consoles, specialized appliances, or third-party-managed components):

• Document the exception, scope, and business reason.
• Add compensating controls (strong MFA, IP allowlisting, network segmentation, enhanced alerting, stricter monitoring).
• Define an exit plan (replacement, integration with IdP, or architecture change).
• Re-approve exceptions on a defined cadence, and re-test compensating controls. ¹

Practical note: This is where tools like Daydream help. Teams often lose time chasing screenshots and change records across multiple owners. A requirement-centric evidence workflow keeps the AC-7 packet current and ties exceptions to approvals and retesting, which reduces scramble during assessor requests. ²

Required evidence and artifacts to retain

Keep evidence in a form that a third-party assessor can review quickly:

Governance artifacts

• AC-7 policy/standard statement with your defined attempt limit and time period ¹
• SSP control implementation narrative for AC-7 ²
• Exceptions register entries (scope, compensating controls, approvals, expiration)

Technical artifacts ¹

• Configuration screenshots/exports from IdP, directory, OS baseline, VPN policy, application settings
• System diagrams or the coverage map table showing all entry points and where enforcement occurs
• Sample logs demonstrating:
  • failed logon events
  • lockout/delay events
  • unlock events with operator identity

Operational artifacts

• Test procedure and test results (date, tester, systems tested, outcome)
• Change management records for AC-7-related config changes
• Access requests/approvals where they affect lockout configuration or exceptions ²

Common exam/audit questions and hangups

Expect these questions in FedRAMP assessment and continuous monitoring:

1. “What are your organization-defined values for attempts and time period?” If the answer is “it depends,” you will get a finding. ¹
2. “Show me it’s enforced everywhere users can log in.” Assessors will pick odd paths: break-glass, local admin, old portals, API tokens, remote access. Your coverage map is the fastest response. ²
3. “Does your lockout create denial-of-service risk?” You need a rationale for lockout vs delay, plus monitoring for abuse. ³
4. “How do you handle service accounts?” Service accounts should not be used for interactive logon; if they are, you need explicit restrictions and monitoring.
5. “Prove it with logs.” Screenshots alone rarely satisfy; pair config evidence with event evidence.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid
Only configuring the corporate IdP	Apps with local auth bypass AC-7	Inventory all entry points and disable local auth where possible
Setting thresholds but not defining the time window	AC-7 requires both	Write the standard as “attempts within time period” and reflect it in config
Lockout works, but unlocks aren’t logged	Breaks audit trail	Require ticketing + identity verification steps + log capture
Excluding privileged accounts quietly	Creates high-impact gap	Treat exceptions as formal risk acceptances with compensating controls
No recurring validation after IAM changes	Drift is common	Add AC-7 tests to release/change checklists and periodic control testing 2

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page focuses on authorization and assessment risk.

AC-7 gaps commonly become FedRAMP findings because they are easy to test: an assessor can attempt repeated failed logons and see whether lockout/delay triggers, then verify the evidence trail. Poor design also creates operational risk: weak or inconsistent enforcement increases exposure to password guessing, while overly aggressive lockout without monitoring can enable account lockout abuse. ¹

Practical execution plan (30/60/90 days)

To avoid unsourced numeric timelines, use phases. Adapt the pacing to your change windows and IAM complexity.

Immediate (start now)

• Assign a single owner for AC-7 across IAM + platform + app teams.
• Draft the AC-7 configuration standard: attempt limit, time period, and lock vs delay decision criteria. ¹
• Build the authentication entry-point inventory and mark unknowns.

Near-term (after the standard is approved)

• Implement IdP/directory policies first (highest coverage, fastest win).
• Remediate bypass paths: local accounts, legacy app logins, admin consoles not federated.
• Turn on central logging for failures, lockouts/delays, and unlocks; validate log fields support investigations.

Ongoing (operate and evidence)

• Add AC-7 checks to onboarding for new systems in the boundary.
• Run periodic control tests and keep the AC-7 validation packet current for continuous monitoring submissions. ²
• Review exceptions and compensating controls; retire exceptions as systems modernize.

Frequently Asked Questions

Do we have to use account lockout, or can we use login delay/backoff?

AC-7 allows either account lockout or delaying the next logon prompt, as long as it is automatic and enforced after the defined number of invalid attempts within the defined time period. Document which method applies to each entry point and keep evidence. ¹

Does AC-7 apply to SSO if the application itself doesn’t handle passwords?

Yes, because the authentication still occurs. If SSO is the only entry point, you can satisfy AC-7 at the IdP, but you still need to prove there is no bypass path (local app auth, admin backdoor). ³

What about service accounts and non-human identities?

AC-7 is written for user logon attempts, but assessors will still look for misuse paths. Prevent interactive logon for service accounts, monitor failed authentications, and document how the system behaves if a service credential is repeatedly rejected. ¹

How do we handle customers or external users where lockout causes support burden?

Many teams choose delay/backoff for public-facing logins and reserve hard lockouts for workforce identities. The key is that the delay is automatic, measurable, and consistently applied, with logs that prove it triggered. ¹

What evidence is fastest to produce during an assessment?

A coverage map of all authentication entry points, paired with (1) config exports/screenshots for each, and (2) log excerpts showing failed attempts and lockout/delay events. Keep the test script and results with the evidence bundle. ²

We can’t configure lockout on a third-party-managed admin console. Is that an automatic fail?

Not necessarily, but you need a documented exception with compensating controls, an approval, and proof the compensating controls operate. Also document an exit plan to reduce reliance on the exception. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates

3. NIST SP 800-53 Rev. 5 PDF