AC-9: Previous Logon Notification

What this control requires

AC-09 requires organizations to notify users of their last successful logon date and time upon each system access. This notification gives users a verifiable checkpoint to detect unauthorized access to their accounts.

In practice, this control means your systems must capture and store successful logon timestamps, then display that information to the authenticated user at the start of each new session. The notification should be prominent enough that a user can immediately recognize whether the displayed date and time align with their actual last access. Organizations operating under the NIST SP 800-53 framework often overlook this control because it doesn’t appear in any baseline, but it remains a valuable layer of access control hygiene.

Without previous logon notification, users have no passive mechanism for spotting session hijacking or credential misuse between formal audit reviews. The control applies to both human user interfaces and system-to-system architectures where logon events occur.

Why it matters

Most organizations invest heavily in preventing unauthorized access but spend far less on helping users detect it after the fact. Previous logon notification fills that detection gap by giving every authenticated user a lightweight, self-service indicator of account activity.

Failing to implement AC-09 won’t trigger a baseline compliance finding, but it does weaken your audit posture. Assessors reviewing access control family controls may flag the absence of logon notification as a gap in your overall access monitoring strategy, particularly if your system processes sensitive data or supports privileged operations.

In practice, the real cost is operational visibility. Without last-logon timestamps displayed at session start, compromised credentials can go unnoticed for weeks or months. Users are often the first to notice something is wrong, but only if the system gives them the information to do so.

What attackers exploit

Without previous logon notification, several common attack patterns remain invisible to account holders:

• Credential stuffing and password reuse: Attackers test stolen credential pairs against target systems. Without previous logon notification, successful unauthorized logons remain invisible to the legitimate account holder.
• Session hijacking: Stolen session tokens allow attackers to authenticate as the victim. A mismatched last-logon timestamp would alert the user on their next legitimate access.
• Privilege escalation from dormant accounts: Attackers target inactive accounts where the legitimate user rarely logs in, using privilege escalation techniques that go undetected without logon visibility.
• Insider threat using shared credentials: When credentials are shared informally, previous logon notification creates an audit trail visible to the account holder, deterring misuse.

How to implement

Implementing previous logon notification sounds straightforward, but the most common failure is treating it as a display-only feature without reliable timestamp capture and storage behind it.

For your organization

Start by identifying every system and application where users authenticate. AC-09 sits within the AC family of controls and applies to human user interfaces and other architectures where logon events occur, so your scope extends beyond web portals to include command-line interfaces, API gateways with interactive authentication, and remote access services.

In practice, that means configuring your authentication infrastructure to capture and persist successful logon timestamps. Most identity providers and operating systems already record this data in audit logs, but AC-09 requires the information to be surfaced to the user, not just stored for administrators. The notification must include the date and time of the last successful logon, displayed clearly upon each new successful authentication.

Where off-the-shelf configuration isn’t available, custom applications need a logon notification banner or interstitial that queries the stored timestamp and presents it before the user proceeds to the main interface. For commercial products, check vendor documentation for built-in last-logon notification features. Many enterprise platforms support this capability through configuration rather than custom development.

That work creates a documentation requirement. Record your implementation in the system security plan, including how timestamps are captured, where they’re stored, and how the notification is rendered. Maintain configuration evidence showing the feature is enabled across all in-scope systems.

Beyond initial setup, test the notification periodically to confirm accuracy, particularly after system upgrades or authentication infrastructure changes. A silent configuration reset during an upgrade is one of the most common ways this control breaks after initial deployment.

Where implementations typically break down is in a few predictable areas. Common failures include displaying timestamps in a format users can’t interpret, storing timestamps in a timezone different from the display timezone without conversion, and failing to account for systems where multiple logon methods exist for the same account.

For your vendors

When assessing vendor compliance with AC-09, request evidence that their systems notify users of previous logon dates and times upon successful authentication. This evidence should include screenshots or recordings of the logon notification as it appears to end users, along with configuration documentation showing the feature is active.

Specifically, ask vendors whether their system displays the date and time of the user’s last successful logon upon authentication. If the vendor’s platform supports multiple authentication methods, confirm that previous logon notification functions consistently across all of them.

The answers you get will guide your document review. Inspect the vendor’s system design documentation to understand how logon timestamps are captured and stored. Red flags include systems that log authentication events but don’t surface them to users, platforms where the notification feature exists but is disabled by default, and architectures where logon data is only accessible to administrators through audit tools.

Where red flags appear, follow up with documentation requests. Ask for the vendor’s access control policy and procedures addressing previous logon notification specifically. Generic access control policies that don’t mention logon notification suggest the vendor hasn’t scoped this control into their compliance program.

The result of these findings is a contract-level gap to address. Consider requiring AC-09 notification terms in agreements with vendors processing sensitive data on your behalf. Even though AC-09 isn’t part of any NIST SP 800-53 baseline, the control strengthens your overall third-party access monitoring posture.

Evidence examples

Cross-framework mapping

Related controls

The following controls work alongside AC-09 to strengthen access monitoring and account visibility:

• AC-07 — Unsuccessful Logon Attempts: AC-07 addresses the system’s response to failed authentication attempts, while AC-09 focuses on notifying users about successful logon history, together forming complementary layers of logon visibility.
• PL-04 — Rules of Behavior: PL-04 establishes user responsibilities and acceptable use expectations, which can include the obligation to review previous logon notifications and report anomalies.
• AC-02 — Account Management: AC-02 governs the lifecycle of user accounts, and previous logon notification depends on properly managed accounts to ensure timestamps map to the correct identity.
• AC-17 — Remote Access: Remote access sessions are particularly vulnerable to credential misuse, making previous logon notification an important detection layer for users authenticating from outside the network.
• AU-02 — Event Logging: AU-02 defines which events the system must log, and successful logon timestamps captured for AC-09 notification overlap with the audit logging requirements of AU-02.
• IA-04 — Identifier Management: Identifier management ensures each account maps to a unique individual, which is a prerequisite for meaningful previous logon notification.

Frequently asked questions

What is NIST SP 800-53 AC-09?

AC-09 is a NIST SP 800-53 access control that requires systems to notify users of the date and time of their last successful logon upon each new authentication. This notification allows users to detect unauthorized access by comparing the displayed timestamp against their actual usage. The control applies to human user interfaces and other system architectures where logon events occur, covering both system notification messages and logon banners.

What happens if AC-09 is not implemented?

Without AC-09, users lose the ability to detect unauthorized access between sessions by reviewing their last logon date and time. Compromised credentials can remain active for weeks or months because no system notification message alerts the account holder to unexpected activity. Organizations that skip this control often discover credential misuse only during scheduled access reviews or after an incident, rather than at the point of the next legitimate logon.

How do you audit AC-09?

Auditing AC-09 requires verifying that system notification messages display the correct date and time of the last successful logon upon each new user authentication. Assessors review access control policy documents for previous logon notification requirements, inspect system configuration settings to confirm the feature is enabled, and test the notification by logging in and comparing the displayed timestamp against audit log entries. Procedures addressing previous logon notification should describe how timestamps are captured, stored, and presented.

Is AC-09 required for NIST 800-53 compliance?

AC-09 is not included in any NIST SP 800-53 baseline (low, moderate, or high), so it isn’t mandatory for organizations selecting controls through the baseline selection process. Organizations can still implement the control voluntarily as part of a tailored control set or when a risk assessment identifies logon visibility as a priority. Including previous logon notification strengthens your access monitoring posture even when it isn’t a baseline requirement.