AC-9: Previous Logon Notification

To meet the ac-9: previous logon notification requirement, configure each in-scope system to display the user’s last successful logon date and time immediately after the next successful logon, and retain evidence that the notice is consistently shown. Operationalize it by defining scope, implementing a standard banner/notification pattern, testing coverage, and collecting screenshots and configuration proof for audits.

Key takeaways:

• AC-9 requires a user-facing notification after successful logon that shows last logon date/time. ¹
• Auditors look for consistent behavior across access paths (SSO, VPN, RDP, console, privileged sessions), plus durable evidence.
• Treat AC-9 as a detective user control that helps surface account takeover and shared credential misuse.

AC-9 is deceptively small, and it still fails in real programs because teams treat it as “a banner” instead of a measurable, testable control behavior. The requirement is narrow: on successful logon, the system must notify the user of the date and time of the last logon. ¹ That means (1) the system must track last successful logon per user (and ideally per account context), and (2) the user must see that information at the moment they authenticate.

For a CCO, GRC lead, or compliance officer, the fastest path is to operationalize AC-9 as a control with clear scope boundaries, an implementation standard you can apply across platforms, and recurring evidence that proves it works. You should also decide how AC-9 interacts with your incident response process: if a user sees an unexpected last-logon timestamp, what is the required action, and how do you capture the report?

This page gives requirement-level guidance you can hand to IAM, endpoint, and platform owners, then audit against with repeatable tests and artifacts. Primary references: NIST SP 800-53 Rev. 5 control catalog and overview materials. ²

Regulatory text

Requirement (verbatim): “Notify the user, upon successful logon to the system, of the date and time of the last logon.” ¹

What the operator must do:

• Ensure the system records the last successful logon date/time for each user account.
• Ensure the system displays that last successful logon date/time to the user immediately after the user successfully authenticates.
• Ensure the behavior is consistent across the system’s supported logon methods (for example, local console, remote access, SSO-backed web login, privileged session entry), to the extent those are in scope for your authorization boundary.

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

AC-9 is a “self-detection” control. If an attacker uses valid credentials, the system may not block the logon. AC-9 gives the legitimate user a simple signal: “someone logged in before you at time X.” The control is satisfied only if the user can actually see the last-logon timestamp after a successful logon, not merely if the system logs it silently.

AC-9 does not require you to show failed logons, source IP, device details, geolocation, or session history. Those can be valuable enhancements, but the requirement text is specifically “date and time of the last logon.” ¹

Who it applies to (entity + operational context)

Entities / programs most commonly scoped to AC-9

• Federal information systems and systems assessed against NIST SP 800-53. ³
• Contractor systems handling federal data where NIST 800-53 controls are flowed down by contract, ATO expectations, or customer security requirements.

Operational contexts where AC-9 matters most

• Systems with interactive user authentication, including workforce identity (employees/contractors) and privileged administrators.
• Environments where SSO abstracts the logon. Even if authentication is delegated, the relying application often still has a “post-authentication landing page” where you can present the last-logon notice.
• Remote/admin access paths (jump hosts, bastions, VDI, RDP/SSH gateways) where attackers commonly replay credentials.

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

1) Define control scope and ownership (make it auditable)

Create a simple AC-9 scope statement for your control narrative:

• In-scope systems: list the applications, OS platforms, and access gateways within your authorization boundary that have interactive logon.
• Out-of-scope rationale: for service accounts, batch accounts, non-interactive APIs, and system-to-system identities, document why AC-9 is not applicable (no “user” to notify).
• Control owner: typically IAM for standard, platform security for OS baselines, and application engineering for custom apps.

Daydream practice that helps: map AC-9 to a named owner, a short procedure, and the evidence artifacts you will produce every cycle so you don’t rebuild proof during an assessment.

2) Select an implementation pattern per platform

Use one of these patterns, depending on where authentication happens:

Pattern A: OS / interactive shell notice

• Use native OS capabilities or session initialization scripts to display: “Last successful logon: ”.
• Confirm it triggers on successful authentication for all login vectors you allow (console, remote, privilege escalation session entry where applicable).

Pattern B: Web application notice (SSO or local auth)

• After authentication, display the timestamp on the first page the user sees (dashboard, profile area, or a dismissible notification).
• Store last successful logon per user in your application database or identity store attribute, and update it on successful authentication.

Pattern C: Access gateway / bastion notice

• For VPN portals, VDI brokers, bastions, and remote access gateways, configure the portal UI to show the last successful logon timestamp where supported.
• If the gateway cannot display it, push the requirement down to the first interactive system the user reaches, and document the boundary decision.

3) Define the “last logon” data rule (avoid ambiguity)

Write a one-paragraph standard and get it approved by the system owner:

• “Last logon” means last successful authentication event for that account within the system boundary.
• Display time in a consistent time zone (commonly UTC or the user’s local time). Pick one and document it.
• Decide what you show on first-ever logon (“No previous logon recorded” is acceptable operationally; keep the message consistent and testable).

4) Build or configure it, then test like an assessor

Your test procedure should be short and repeatable:

• Log on as a test user, capture the shown last-logon timestamp.
• Log off and log on again, verify the last-logon timestamp updates and shows the prior session time.
• Repeat using alternate access paths that are in scope (SSO vs direct, remote vs local, privileged vs standard) until you have confidence the user-facing notice appears consistently.

5) Wire it into user reporting and incident handling

AC-9 has more value when users know what to do:

• Update your security awareness or acceptable use guidance: if the last-logon time is unexpected, the user must report it to the service desk or SOC.
• Create a simple ticket category (“Suspicious previous logon notification”) so reports are searchable and triage is consistent.

6) Evidence collection and cadence (don’t scramble at audit time)

Collect evidence that proves two things: configuration exists, and behavior works.

Required evidence and artifacts to retain

Keep these artifacts per in-scope system or per standardized baseline:

Design / governance

• Control narrative for AC-9: previous logon notification requirement mapped to system scope and owner.
• Applicability notes for non-interactive accounts (service accounts) and boundary decisions.

Implementation proof

• Configuration screenshots or exported settings showing the feature is enabled (where supported).
• Application code/config snippet (or design doc) describing how last successful logon is stored and displayed (for custom apps).

Operational evidence

• Test scripts and results showing the banner/notice appears after logon and updates correctly.
• Screenshots from at least one successful logon path per platform, with timestamps visible.
• Change records for any updates to the logon workflow that could impact the notice.

Assessment readiness tip: keep a single “AC-9 Evidence Packet” folder per system with the same file naming convention each cycle. Daydream-style control mapping helps here because it forces consistent artifacts and ownership across systems.

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me the notification after you log in. Where is it displayed?”
• “Does it work through SSO and through your remote access path?”
• “What is the system of record for last successful logon?”
• “How do you handle first-time logon or newly provisioned accounts?”
• “How do you know this didn’t break after a UI change or IAM change?”

Common hangup: teams show a system log entry for last logon, but the user never sees it. AC-9 requires user notification upon successful logon. ¹

Frequent implementation mistakes (and how to avoid them)

1. Only implementing on one entry point
   Fix: inventory logon methods and test each in scope (portal, thick client, admin jump host, console).

2. Showing “current logon” instead of “previous logon”
   Fix: display the stored “last successful logon” value, then update it after displaying.

3. Confusing failed-logon messaging with AC-9
   Fix: failed-logon alerts are useful, but AC-9 is specifically previous successful logon date/time. ¹

4. No evidence, only statements
   Fix: keep screenshots, test runs, and config exports in a recurring evidence packet.

5. Breaking the notice during UX redesigns
   Fix: add AC-9 to the release checklist for authentication and landing-page changes.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AC-9. Treat AC-9 as an assessment and authorization readiness control: failure usually shows up as a control deficiency during audits, system security reviews, or customer due diligence.

Risk-wise, the absence of AC-9 removes a simple detection signal for users after credential compromise. That increases dwell time when credentials are reused, especially for shared workstations and privileged accounts.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign a control owner and publish a one-page AC-9 standard: definition of “last logon,” time zone rule, and what appears on first logon.
• Build the in-scope inventory: systems with interactive logon within the boundary.
• Identify your implementation pattern per system (OS notice, web app notice, gateway notice).

By 60 days (Near-term)

• Implement AC-9 on the highest-risk access paths first: admin entry points, remote access gateways, core workforce apps.
• Create and run a standard test script per platform; store evidence in a consistent folder structure.
• Update user guidance and create a ticket category for suspicious previous-logon reports.

By 90 days (Operationalize)

• Expand coverage to remaining in-scope systems and close any gaps for alternate logon paths.
• Add AC-9 checks to change management for authentication, SSO configuration, and landing-page changes.
• Establish a recurring evidence routine aligned to your audit cycle (collect fresh screenshots/test results and configuration exports).

Frequently Asked Questions

Does AC-9 apply to service accounts or API tokens?

Usually no, because AC-9 requires notifying a “user” upon successful logon. Document service accounts as non-interactive identities and keep them out of AC-9 scope unless humans directly log in with them. ¹

We use SSO. Who is responsible for the notification, the IdP or the application?

Either can satisfy the requirement if the user is notified upon successful logon, but pick one pattern and document it per system boundary. In practice, many teams implement it in the relying application because it controls the post-authentication UI. ¹

What should the message say on a user’s first login?

Use a consistent “no previous logon recorded” message (or equivalent) and verify it behaves predictably in tests. The key is that subsequent logons show an actual previous date/time. ¹

Do we need to show the last logon location or IP address?

AC-9 only calls for date and time of the last logon. Extra context can help security operations, but it is not required by the control text. ¹

How do auditors typically validate AC-9?

They will request a live demonstration or screenshots showing the notice after logon, plus configuration evidence and a short narrative describing scope and responsibility. Expect follow-up questions about alternate logon paths and privileged access.

How can Daydream help with AC-9 without turning it into a paperwork exercise?

Use Daydream to map AC-9 to a named owner, a standard implementation procedure per platform, and a recurring evidence checklist. That keeps your screenshots, configs, and tests in one place and reduces back-and-forth during assessments.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5