AC-9(4): Additional Logon Information

AC-9(4) requires you to notify users, after a successful logon, of defined “additional logon information” (for example, last login time, last login method, or failed login attempts), so the user can detect suspicious account activity quickly. To operationalize it, decide the exact fields (your org-defined parameters), implement the notice on every interactive login path, and retain evidence that the message is consistently displayed. ¹

Key takeaways:

• Define your org’s required “additional logon information” as an explicit standard, then apply it consistently across systems. ¹
• Implement the post-authentication notice on all applicable access paths (console, VPN, VDI, SSO app, privileged access) and treat exceptions as formal risk acceptances.
• Audit readiness depends on repeatable evidence: screenshots, configuration exports, and test scripts that prove the message appears after successful logon.

The ac-9(4): additional logon information requirement is easy to “half implement” and still fail an assessment. Teams often enable a generic login banner (that’s AC-8 territory) or assume centralized logging is enough. AC-9(4) is different: it is a user-facing notification shown upon successful logon, and it must include specific, organization-defined information elements. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat AC-9(4) like a small product requirement: define the exact message contents, identify every interactive login entry point, and confirm the notice displays after authentication. Your goal is not simply “a banner exists.” Your goal is that the right user sees the right account-activity context at the moment it matters, and you can prove it with durable evidence.

This page gives requirement-level implementation guidance you can hand to IAM, endpoint, PAM, and application owners. It also flags common audit hangups, evidence expectations, and practical ways to standardize across heterogeneous environments without creating a fragile, one-off build per system.

Regulatory text

Control statement (excerpt): “Notify the user, upon successful logon, of the following additional information: {{ insert: param, ac-09.04_odp }}.” ¹

What that means operationally:

• You must show a notification after the user successfully authenticates (not just pre-login). ¹
• The content of the notification is organization-defined parameters (the ac-09.04_odp placeholder). You must decide and document what fields you will display. ¹
• The requirement is about user awareness at logon. Centralized logs alone do not satisfy it if the user never sees the information. ¹

Plain-English interpretation

AC-9(4) expects a simple outcome: when someone logs in successfully, the system tells them key facts that help detect account misuse. If an attacker used the account last night, the legitimate user should have a chance to notice immediately and report it.

This is a “small UI” control with outsized governance impact. It forces you to answer: what do we want users to know at logon, and where do we implement it so it’s consistent across endpoints, remote access, and applications?

Who it applies to (entity and operational context)

Entities: Federal information systems and contractor systems handling federal data commonly inherit this control expectation through NIST-based programs. ¹

Operational scope (where it usually applies):

• Interactive user sessions: workstation logon, VDI, bastion/jump host access, SSH/RDP sessions, VPN portals, and web applications with direct user authentication.
• Privileged access paths: PAM checkouts, admin consoles, break-glass accounts, and emergency access workflows.
• SSO environments: systems fronted by an IdP may still need an application-level post-login message if the IdP notice is not presented to the user for that specific session context.

Where it may not apply cleanly (handle explicitly):

• Non-interactive service accounts and API tokens (no “user” to notify).
• Batch jobs and machine-to-machine authentications. Treat these as scoped-out with a written rationale and map them to other detective controls (logging, alerting) rather than forcing a meaningless banner.

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

Step 1: Define your org’s “additional logon information” fields (the ODP)

Create a short standard that lists the specific elements you will display. Keep it implementable across platforms. Common, practical fields include:

• Last successful logon date/time
• Source or method (interactive, remote, VPN, SSO)
• Count of failed logon attempts since last successful logon
• Last logon originating host/IP (where technically feasible)

Write the standard in a control procedure and make it unambiguous: “Systems must display [fields A, B, C] upon successful logon for interactive users.” This satisfies the “organization-defined parameter” concept in the control text. ¹

Step 2: Build a system inventory of interactive login paths

You cannot pass AC-9(4) by configuring one place. Build a quick matrix:

Access path	Example systems	Owner	Can display post-logon info?	Implementation method
Endpoint OS logon	Windows/macOS/Linux	Endpoint/IAM	Yes/No	OS policy / login scripts
Remote access	VPN/ZTNA	Network/SecOps	Yes/No	Portal message after auth
Privileged access	PAM / jump hosts	Security/IAM	Yes/No	PAM post-checkout notice
Web apps	Internal apps	App owners	Yes/No	App middleware/UI component
Cloud consoles	SaaS admin portals	Cloud/IAM	Varies	IdP notice / app config

The matrix becomes your execution tracker and audit evidence backbone.

Step 3: Decide the control “presentation layer”

Pick the layer that gives the best coverage with the least fragmentation:

• IdP-first (preferred where feasible): show the notice after successful authentication at the identity provider and confirm it appears for all user login flows you consider in scope.
• System-specific: for OS login, SSH, RDP, or legacy apps, implement locally.
• PAM-first for admin paths: if privileged users authenticate through PAM, configure the notice there and confirm it appears on every privileged session initiation.

Document the decision and any gaps (for example, a SaaS admin console that cannot display last login details). Gaps should route to exception handling.

Step 4: Implement per platform with testable acceptance criteria

Write acceptance criteria that an auditor can reproduce:

• “After successful logon, user is shown message containing [fields].”
• “Message is shown on first interactive session screen (not buried in a help menu).”
• “Message content is tied to the authenticating account and updates between sessions.”

Then implement using the simplest native mechanism available (OS security policy, IdP post-auth page, PAM message-of-the-day equivalent, or application middleware).

Step 5: Create an exception path that still satisfies risk intent

Some systems cannot show all fields. Define a decision rule:

• If you can show at least one meaningful element (example: last login time), implement it and document the limitation.
• If you cannot show any post-login notice, require a compensating control (example: automated alert to the user on new device login) and record a formal exception with approval.

Tie exceptions to a review cadence in your GRC workflow so they do not become permanent blind spots.

Step 6: Operationalize: monitoring, drift control, and change management

AC-9(4) breaks during upgrades, IdP migrations, and PAM reconfigurations. Add two lightweight mechanisms:

• A control test script run during IAM/SSO changes: validate the notice still appears.
• Configuration drift checks where possible (export config, compare to baseline).

If you use Daydream to map controls to owners, procedures, and recurring evidence artifacts, set AC-9(4) up as a repeatable evidence collection item rather than a one-time screenshot scramble.

Required evidence and artifacts to retain

Assessors usually want proof of three things: definition, implementation coverage, and operating effectiveness.

Keep these artifacts:

• AC-9(4) procedure stating the exact “additional logon information” fields (your ODP) and where the notice is implemented. ¹
• Scope matrix of systems/access paths and status (implemented / exception / not applicable).
• Configuration evidence per platform (policy exports, IdP settings screenshots, PAM configuration screens, application config snippets).
• Test evidence: dated screenshots or screen recordings showing successful logon followed by the notice, for representative systems in each access path category.
• Exception register entries with rationale, compensating controls, and approvals.

Common exam/audit questions and hangups

• “Show me the message after a successful login.” Auditors will ask for a live demo or a time-stamped capture. Pre-login banners do not answer the question. ¹
• “What is your organization-defined additional information?” If you cannot point to a documented list, you have not satisfied the parameter requirement. ¹
• “Is this consistent across remote access and privileged access?” Partial coverage is acceptable only if you have documented scope decisions and exceptions.
• “How do you know updates didn’t break it?” Expect questions about change control and retesting after IAM changes.

Frequent implementation mistakes and how to avoid them

1. Mistake: Implementing a generic login banner and calling it done.
   Fix: Ensure the notice is displayed after successful logon and contains account-activity information, not just warnings. ¹

2. Mistake: No explicit ODP definition.
   Fix: Publish a short standard listing the exact fields required, and map it to system requirements and testing.

3. Mistake: Inconsistent experience across SSO, VPN, and PAM.
   Fix: Use the access-path matrix and assign accountable owners per path.

4. Mistake: Evidence that doesn’t age well.
   Fix: Keep config exports and repeatable test steps, not only screenshots. Make it part of release checklists for IAM/PAM.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for AC-9(4). What matters for risk: AC-9(4) is a user-detective control. If you skip it, you remove a fast signal that can surface account compromise, especially for privileged users and remote access accounts. Assessors also treat missing ODP definition as a control design failure because the requirement explicitly expects organization-defined content. ¹

A practical 30/60/90-day execution plan

First 30 days (design + scoping)

• Assign a control owner (IAM or GRC with IAM execution) and named technical owners per access path.
• Draft the ODP standard: the exact “additional logon information” fields you will display. ¹
• Build the access-path matrix and identify top-risk systems (PAM, VPN, core admin consoles).
• Decide implementation layer (IdP vs system-specific) and document exceptions that seem likely.

By 60 days (implementation + initial evidence)

• Implement AC-9(4) on the highest-risk access paths first (privileged and remote access).
• Produce test evidence for each implemented path (successful logon → notice displayed).
• Open exception records for any systems that cannot comply natively; define compensating controls and approvals.

By 90 days (coverage + operationalization)

• Expand implementation to remaining in-scope interactive systems.
• Add a regression test step to IAM/PAM/VPN change management.
• Set up recurring evidence capture in your GRC workflow (Daydream fits well here): scope matrix refresh, config export snapshots, and periodic spot-check screenshots tied to a ticket.

Frequently Asked Questions

Does AC-9(4) require a pre-login warning banner?

No. AC-9(4) requires notification “upon successful logon” and the content is “additional information” you define. A pre-login banner may be useful for other controls, but it does not satisfy this requirement by itself. ¹

What counts as “additional logon information”?

The control text uses an organization-defined parameter placeholder, so you must define the fields in a standard or procedure. Pick fields that help a user recognize suspicious activity and that you can implement consistently. ¹

If we have centralized logging and SIEM alerts, can we skip the user notice?

Centralized logging does not meet AC-9(4) if the user is not notified after successful logon. Treat SIEM as complementary detective coverage, not a replacement for the user-facing notice. ¹

Do we need AC-9(4) for service accounts and APIs?

Usually no, because there is no interactive user to notify. Document “not applicable” scope decisions clearly and ensure other controls cover monitoring and anomalous authentication for those identities.

We use SSO. Where should the notice live: IdP or the application?

Put it where the user reliably sees it after authentication for the in-scope login flows. If the IdP cannot guarantee display for a given flow, implement at the application or access gateway for that path and document the decision.

What evidence is strongest for auditors?

A documented ODP definition, a system/access-path coverage matrix, and repeatable proof (config exports plus a dated successful-logon test capture) typically answers most assessor questions. ¹

Footnotes

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