AC-9(1): Unsuccessful Logons

To meet the ac-9(1): unsuccessful logons requirement, configure each in-scope system to show users, after a successful logon, how many failed logon attempts occurred since their last successful logon. Then document scope, ownership, configuration, and test evidence so an assessor can verify the notification is generated reliably across user entry points. ¹

Key takeaways:

• The requirement is a user-facing notification after successful authentication, not just logging failed attempts. ¹
• You need consistent behavior across all logon paths (interactive, VPN, SSO, privileged access) that you define as in scope.
• Audits commonly fail this control due to missing evidence: no screenshots, no test cases, no system mapping, or inconsistent enforcement.

AC-9(1) is a small requirement with outsized operational impact because it sits directly in the user authentication flow. The requirement is narrow: after a successful logon, the system must inform the user how many unsuccessful logon attempts occurred since the user last logged in successfully. ¹ This creates an immediate “something might be wrong” signal for account takeover attempts, password-spraying, or mis-typed credentials that may indicate compromised user behavior.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing AC-9(1) is to treat it as an identity and access system configuration control with clear scope boundaries. Decide which authentication experiences are “logon” for your environment (for example, workstation sign-in, web app sign-in, VPN, and privileged access tools), identify where the “last successful logon” state is stored, and confirm the user can see the count at the right moment. Then retain simple, high-quality evidence: configuration excerpts, test results, and screenshots that match the defined scope.

This page provides requirement-level guidance you can hand to IAM, IT, and application owners and then assess quickly.

Regulatory text

Requirement (verbatim): “Notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.” ¹

What an operator must do:

1. Track unsuccessful logon attempts per user in a way that survives across sessions until the next successful logon resets the counter (or equivalently, the system can calculate “since last successful logon”). ¹
2. On the next successful logon, present the count of unsuccessful logon attempts to the user as part of the logon experience (banner, modal, post-auth message, or equivalent user-visible notification). ¹
3. Ensure the experience is implemented consistently for the logon methods you designate as in scope (for example, local login vs. SSO vs. VPN), and record evidence that the behavior works as designed.

Plain-English interpretation (what AC-9(1) is really asking)

AC-9(1) requires a user-facing “heads up” after they sign in: “Since the last time you successfully logged in, there were X failed attempts.” ¹ If X is higher than expected, the user can report suspicious activity or change credentials.

This control is not satisfied by:

• Only logging failed attempts in SIEM.
• Locking accounts after too many failures (useful, but different).
• Showing “last login time” without the number of unsuccessful attempts.

Who it applies to (entity and operational context)

Applies to:

• Federal information systems and contractor systems handling federal data where NIST SP 800-53 is in scope for the system boundary. ¹

Operationally, you should expect AC-9(1) to be evaluated on:

• Interactive logons (workstations, jump boxes, VDI).
• Web application logons (direct username/password).
• SSO flows (IdP-mediated logon that still results in an authenticated session).
• Remote access logons (VPN, ZTNA portals).
• Privileged access logons (PAM tools, admin consoles).

Scoping tip (make it assessable): Document which authentication surfaces are “logon” events for this requirement in your system security plan (SSP) or control narrative, and map each to an enforcing component (IdP, OS, application, VPN concentrator). If you do not define scope, assessors will.

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

1) Assign ownership and define scope

• Control owner: typically IAM lead (technical) with GRC accountable for evidence completeness.
• System scope statement: list systems and authentication methods in scope (for example: “Okta SSO for internal apps; Windows interactive logon for endpoints; VPN login for remote access”).
• RACI check: decide who updates configurations and who tests evidence each release.

Deliverable: one-page AC-9(1) control implementation statement tied to system boundary and auth flows.

2) Choose the enforcement point (where to implement)

Pick the component that can both:

• Observe unsuccessful attempts; and
• Display a notification at successful logon.

Common patterns:

• Identity provider (IdP): best when most apps rely on SSO. The IdP becomes the enforcement point for the user-facing message.
• Operating system: for local interactive logons.
• Application layer: if the app owns authentication and does not rely on central identity.

Decision rule: if users authenticate in more than one place, centralize the control at the IdP when feasible, then handle edge cases (local logons, break-glass accounts) separately.

3) Confirm data semantics: “unsuccessful” and “since last successful”

Make these definitions explicit in your procedure:

• Unsuccessful logon attempt: failed authentication attempt for that user identifier (bad password, invalid MFA, unknown user, etc.), as captured by the enforcing system.
• Since last successful logon: attempts after the timestamp (or event ID) of the most recent successful logon event for that user.

Document edge cases:

• Password resets.
• Account unlocks.
• Username enumeration protections (some systems don’t want to confirm a username exists; your approach must still meet the requirement for valid users post-login).

4) Implement the user notification

Implementation criteria to validate:

• Notification appears after successful logon and is visible to the authenticated user. ¹
• Message contains the number of unsuccessful attempts since last successful logon. ¹
• It is delivered for each in-scope logon method, or you have a documented exception with compensating controls and explicit scope limitation.

Example acceptance statement (write this into your control narrative): “Upon successful authentication, the system displays ‘Failed sign-in attempts since last login: X’ to the user before they proceed to the application landing page.”

5) Test it like an assessor

Build a repeatable test case:

1. Pick a test user in scope.
2. Perform a known number of failed logons (record timestamps).
3. Log on successfully.
4. Capture evidence that the screen shows the expected count.
5. Repeat for each in-scope logon path (IdP portal, VPN, workstation, admin console), based on your scope statement.

Testing pitfall: If you only test one path (for example, web app login) but users also authenticate via SSO or VPN, your evidence will not match operational reality.

6) Operationalize: change control + drift monitoring

• Tie configuration changes to standard change control (ticket references in evidence).
• Add a lightweight quarterly (or release-based) control check: confirm the banner/notification still appears after auth UI updates.
• For third-party hosted identity services, keep vendor release notes (if available) attached to your test record for the period assessed.

7) Put it in your control management system (Daydream-ready)

In Daydream, treat AC-9(1) as a control with:

• Owner
• Implementation procedure
• Recurring evidence artifacts (screenshots, config exports, test logs) This is the simplest way to avoid the most common AC-9(1) failure: “implemented, but not provable.”

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Design evidence (static):

• Control narrative for AC-9(1) mapping each in-scope system/auth flow to an enforcement point. ²
• Configuration standard/procedure describing how the notification is enabled and maintained.
• Architecture snippet or diagram showing where authentication occurs (IdP, OS, app).

Operational evidence (recurring):

• Screenshots (or session recordings) of post-login notification showing the failed-attempt count.
• Test script and results (date, tester, user account, expected/actual).
• System configuration export or admin console screenshot showing the setting enabled.
• Change tickets/approvals for any changes affecting authentication UI or policy.

Retention approach (practical): Store evidence by system and by assessment period, with consistent naming (system, control, date). Assessors care more about traceability than volume.

Common exam/audit questions and hangups

Expect these:

• “Show me where the user is notified after successful logon.” ¹
• “How does the system determine ‘since last successful logon’?”
• “Does this apply to SSO logons, VPN logons, and privileged access? What’s your scope statement?”
• “Prove it works for a real user account, not only in documentation.”
• “What happens if the user authenticates through multiple channels? Are counts consistent or fragmented?”

Common hangup: teams confuse AC-9(1) with “lockout after N attempts” or “alert admins on failures.” Those may exist elsewhere, but AC-9(1) is specifically a user notification after success. ¹

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Logging without notifying.
   Fix: add a post-auth banner or message that pulls the failed-attempt count and displays it to the user. ¹

2. Mistake: Only works for one logon path.
   Fix: inventory all logon entry points; either implement across all, or explicitly scope out what you do not control and document compensating controls.

3. Mistake: Counter resets incorrectly (or never resets).
   Fix: test “failed, failed, success” and “success, failed, success” sequences and confirm correct math relative to the last successful logon.

4. Mistake: Evidence doesn’t match scope.
   Fix: keep a system list and a per-system evidence checklist. Daydream control pages help by standardizing required artifacts across systems.

5. Mistake: Break-glass and service accounts ignored.
   Fix: define account types in scope. If certain non-human accounts cannot receive notifications, document them as out of scope with rationale, and ensure they do not have interactive logon rights.

Risk implications (why auditors care)

AC-9(1) reduces the time between an attack pattern (credential stuffing, guessing, MFA fatigue attempts) and user awareness. If an attacker is probing credentials but hasn’t succeeded yet, the user sees the signal at the next successful logon. ¹

Operational risk if you skip it:

• Users remain unaware of repeated failed attempts against their accounts.
• Incident response loses a potential early-warning channel.
• In an assessment, the control often fails on “not implemented” or “not consistently implemented,” even if your monitoring detects failures elsewhere.

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

Use time phases rather than calendar promises; move faster or slower based on system complexity and auth architecture.

First 30 days (Immediate)

• Confirm system boundary and in-scope auth flows.
• Assign owner(s) and write the control narrative.
• Identify enforcement points (IdP, OS, app, VPN).
• Run a pilot implementation on one high-coverage entry point (often IdP).

By 60 days (Near-term)

• Expand implementation to remaining in-scope systems.
• Write and run standard test cases for each logon path.
• Centralize evidence collection (screenshots, config exports, test records) in your GRC repository or Daydream.

By 90 days (Operationalize)

• Add release/change triggers: authentication UI changes require re-test of AC-9(1).
• Add periodic control checks aligned to your access control review cadence.
• Confirm exceptions are documented (scope exclusions, technical constraints) and approved.

Frequently Asked Questions

Does AC-9(1) require alerting administrators or only the user?

The text requires notifying the user upon successful logon with the count of unsuccessful attempts since the last successful logon. ¹ Admin alerting can be a separate control, but it does not replace the user notification.

If we use SSO, where should the notification live?

Put it at the point of successful authentication that the user experiences consistently, typically the identity provider login or post-auth landing page. Your evidence should show the message appears after successful SSO authentication. ¹

What counts as an “unsuccessful logon attempt”?

Treat it as a failed authentication attempt for that user identifier in the enforcing system (wrong password, failed MFA, denied policy). Document your definition so assessors can reconcile it with your logs and user notification.

Do we have to show the exact number, or is “there were failed attempts” enough?

AC-9(1) explicitly requires the number of unsuccessful attempts since the last successful logon. ¹ A generic warning without a count does not meet the text.

What about service accounts or API tokens that don’t have an interactive UI?

Scope AC-9(1) to interactive logons where a user can be notified. For non-interactive accounts, remove interactive logon rights where possible, and document the scope decision and rationale in your control narrative.

How do we prove this control in an audit without giving auditors real user credentials?

Use a dedicated test account with representative policy settings, run the failed-then-success sequence, and capture screenshots plus timestamps. Keep the test procedure and results as evidence tied to the in-scope systems.

Footnotes

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

2. NIST SP 800-53 Rev. 5