AC-9(2): Successful and Unsuccessful Logons

The ac-9(2): successful and unsuccessful logons requirement is a narrow control enhancement, but it forces coordination across identity, logging, and user experience. You are not just “logging auth events.” You are committing to a specific user notification at a specific moment (post-successful logon) that depends on accurate, queryable records of prior failed attempts tied to that same user identity.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat AC-9(2) as a requirement with two explicit operator-defined decisions: (1) what constitutes an “unsuccessful logon” in your environment (bad password, MFA failure, blocked by conditional access, etc.), and (2) what time window you will report (since last successful logon, last 24 hours, last 7 days, etc.). Those decisions become your control statement, configuration targets, and testing criteria.

This page gives you requirement-level implementation guidance you can hand to IAM and platform teams, plus the evidence set you should retain so an assessor can verify design and operating effectiveness without guesswork. The control text comes from NIST SP 800-53 Rev. 5. ¹

Regulatory text

Requirement (verbatim excerpt): “Notify the user, upon successful logon, of the number of {{ insert: param, ac-09.02_odp.01 }} during {{ insert: param, ac-09.02_odp.02 }}.” ²

What the operator must do

You must implement a post-authentication message that tells the user: how many unsuccessful logon attempts occurred within a defined period. The bracketed items are parameters you must set in your implementation:

• ac-09.02_odp.01: what category of “unsuccessful logons” you count (your definition).
• ac-09.02_odp.02: the time period you look back over (your definition).
  ²

This requirement is not satisfied by a SOC-only dashboard, SIEM-only alerting, or back-end audit logs alone. The user must be notified upon successful logon.

Plain-English interpretation

AC-9(2) means: “Each time a user signs in successfully, show them how many times someone failed to sign in as them recently.” This supports early detection of account guessing, credential stuffing, misrouted SSO attempts, or other suspicious activity that a user can recognize and report.

From an operational standpoint, there are three moving parts:

1. Counting logic: your system can reliably count failed attempts associated with the user.
2. Time window logic: your system knows which failures fall inside your chosen lookback period.
3. Presentation: your application, SSO portal, VDI banner, or workstation logon UI displays the number after success.

Who it applies to (entity and operational context)

This control is most relevant where you claim alignment with NIST SP 800-53 Rev. 5 for:

• Federal information systems, where NIST SP 800-53 is the baseline security control framework. ¹
• Contractor systems handling federal data, where NIST-based controls are commonly flowed down via contracts, SSPs, or agency security requirements. ¹

Operationally, it applies wherever users authenticate:

• Enterprise IdP login pages (SSO portals)
• SaaS applications with local authentication
• Privileged access systems (bastions, PAM portals)
• VDI/workstation interactive logon, where you can present banners/notifications
• Remote access gateways (VPN/Zero Trust access), where a post-login message is possible

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

Step 1: Set the two AC-9(2) parameters (policy + technical spec)

Create a short control definition that nails down:

• Unsuccessful logon definition (examples you may choose from):
  • Incorrect password / invalid credential
  • MFA challenge failed or timed out
  • Authentication denied due to disabled/locked account
  • Conditional access denial (if you decide to count it)
• Lookback period:
  • “Since the last successful logon” (common and intuitive)
  • “Within the past day/week” (easier if your platform queries by time)

Write these choices into:

• Your access control standard (control narrative)
• An engineering implementation ticket with acceptance criteria tied to the exact message and count rules
  ²

Step 2: Confirm event sources and identity matching

Your count is only as good as your event data. For each authentication surface, identify:

• Where failed logons are recorded (IdP logs, application logs, OS logs)
• How you map an event to a user (username, immutable user ID, email, subject claim)
• How you handle edge cases (renamed accounts, federated identities, shared admin accounts)

Practical decision: if you have multiple auth planes (IdP + app local logons), decide whether AC-9(2) is implemented centrally (IdP notice) or per system (each app shows its own count). Document the scope.

Step 3: Implement the post-logon notice in the user experience

Decide the delivery mechanism:

• IdP-based: A post-auth landing page widget/modal that displays: “Unsuccessful sign-in attempts since [period]: X”.
• Application-based: A banner/toast on first page load after session creation.
• OS/VDI-based: A logon message that appears immediately after interactive login.

Minimum operational acceptance criteria you can test:

• The message displays after every successful logon (or at least after interactive logon if that’s your defined scope).
• The number matches the count from the authoritative log source.
• The message is tied to the authenticated user, not device-wide state.
  ²

Step 4: Define how the count resets (or doesn’t)

Your parameter choice drives this:

• If “since last successful logon,” the system must store a “last successful logon timestamp” per user and query failures after that timestamp.
• If “in the past [time window],” the system queries failures within that time window.

Write it down. Assessors will ask, and engineers will implement inconsistent behaviors if you don’t.

Step 5: Add operational response hooks (optional but high-value)

AC-9(2) does not require a workflow, but you should decide what you want users to do with the information:

• Link to “Report suspicious activity” or “Reset password”
• Guidance: “If you did not attempt these logons, contact the service desk.”

Keep it simple. Avoid training users to ignore the notice.

Step 6: Test and document operating effectiveness

Build a repeatable test:

• Generate failed logons for a test user (in a non-production environment if possible).
• Perform a successful logon.
• Capture evidence showing the notice and the correct count for the defined lookback window.

Store the test procedure and a sample result as part of your control evidence package.

Required evidence and artifacts to retain

Use an evidence bundle that an assessor can validate without reverse-engineering your system:

1. Control narrative for AC-9(2)

   • Your definitions for “unsuccessful logon” and “time period”
     ²

2. Configuration and design evidence (pick what fits your stack)

   • Screenshot of the post-logon notice (with date/time and user context if possible)
   • UI spec or implementation PR/commit reference showing the feature requirement
   • IdP/app configuration exports showing logging and the notice feature enabled

3. Authoritative log evidence

   • Sample authentication log entries showing failed attempts and the eventual success
   • A query or report output demonstrating the same count used by the notice

4. Test record / control operating procedure

   • Step-by-step test script
   • Result screenshots and log extracts for the same user/time window

5. Control ownership and cadence

   • Named control owner (IAM or platform), backup owner, and how changes are reviewed

Daydream tip (earned, not ornamental): if you manage multiple systems with different login paths, Daydream can track AC-9(2) as a requirement with explicit parameters, assign an owner, and schedule recurring evidence requests so the “notice still appears” doesn’t degrade after UI redesigns.

Common exam/audit questions and hangups

Assessors commonly get stuck on these points:

• “What exactly do you count as unsuccessful?” Show your definition and where it’s implemented. The control text is parameterized, so your choice must be explicit. ²
• “What period is ‘during’?” Provide the lookback period and explain reset behavior. ²
• “Where does the number come from?” Identify the authoritative event source and show a reproducible query.
• “Does every system do this?” Clarify scope: IdP-only, high-impact apps, privileged access systems, or all interactive logons.
• “Is the notice user-visible?” Provide screenshots and a test record showing it appears after successful logon.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Counting only “bad password,” ignoring other failed auth states you said you count	Your implementation drifts from your defined parameter	Write a precise definition and map each failure code/state to “counted vs not counted”
Implementing in the SIEM but not notifying the user	AC-9(2) is explicitly a user notification	Put the notice in the IdP/app/OS logon UX, not just monitoring
Showing “last login time” instead of failed attempts count	Different control objective	Ensure the message contains the number of unsuccessful logons and your defined period 2
Count is inaccurate due to missing logs or multiple identity keys	Assessor will test and find mismatch	Standardize on immutable user IDs; confirm log retention and collection for auth events
UX changes remove the banner silently	Control stops operating	Add a control check to release gates for auth UI changes and a recurring evidence capture

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk as indirect: AC-9(2) is typically assessed as part of a broader access control and auditability posture rather than penalized as a standalone failure. The practical risk is real: if attackers guess passwords or abuse a leaked credential, this notice can be an early signal to users that something is wrong, especially when monitoring is delayed or noisy.

Practical 30/60/90-day execution plan

First 30 days (get to a signed-off spec)

• Assign a control owner (IAM/platform) and a GRC reviewer.
• Decide and document the two parameters (unsuccessful logon definition, lookback period). ²
• Inventory authentication entry points and pick implementation scope (IdP vs app-by-app).
• Draft test steps and evidence checklist.

Days 31–60 (build + prove it works)

• Implement the notice in the chosen logon UX.
• Validate authoritative logs record failed attempts consistently.
• Run a controlled test that generates failures then a success; capture screenshots and log extracts.
• Update control narrative with “how it works” and “what’s in scope.”

Days 61–90 (operationalize and keep it from regressing)

• Add a recurring control check (quarterly or release-based) to confirm the notice still appears after changes.
• Add change management triggers: any change to IdP sign-in policies, MFA flows, or login UI requires AC-9(2) regression testing.
• Centralize evidence collection in Daydream (or your GRC system) with an owner, evidence due dates, and a single source of truth for the parameter choices.

Frequently Asked Questions

Does AC-9(2) require notifying users of successful logons too?

AC-9(2) specifically requires notifying the user upon successful logon about the number of unsuccessful logons during a defined period. It does not add a separate requirement to notify about successful logons beyond that trigger. ²

Can the notice be in an email instead of on-screen after login?

The control text says “upon successful logon,” which assessors commonly interpret as an immediate post-login notification in the session context. If you use email, document why it still meets “upon” and be ready for a gap assessment. ²

What should we pick for the “time period” parameter?

Pick a period your systems can implement consistently and your users can understand, then document it as the control parameter. Assessors care more about clarity, consistency, and evidence than any specific period. ²

Do we need to include failed MFA attempts in the count?

Only if you define “unsuccessful logon” to include them. Write the definition, map it to event types, and implement the same mapping in your counting logic. ²

If we use SSO, is implementing this at the IdP enough?

Often yes, if the IdP is the primary authentication point and you document that scope. If users can also authenticate directly to high-risk systems outside SSO, you may need additional implementations or a scope exception with rationale.

How do we evidence this control without giving auditors user PII?

Use a dedicated test account and capture the notice plus the supporting auth logs for that test identity. Redact identifiers in screenshots if needed, but keep enough context to prove the notice is tied to the correct user and time window.

Footnotes

1. NIST SP 800-53 Rev. 5

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