AC-9 Previous logon notification: requirements and evidence

What AC-9 previous logon notification asks for and why it is often missed

AC-9 requires the system to show a user, after a successful logon, the date and time of that user's last logon, so the user can recognize access that was not theirs. An organization that tailors or audits against SP 800-53 may find AC-9 in its catalog but in none of the SP 800-53B baselines, which means nothing in the baseline selection will put it in scope. The control is only in play when someone decides to select it, either by tailoring a baseline or through an overlay, and then documents how the system meets it. The catalog names AC-7 and PL-4 as related controls, which is a useful starting point for the people who will write the implementation statement.

The risk AC-9 addresses is quiet misuse of a valid account, such as a stolen password used between a user's own sessions. The four current enhancements, AC-9(1) to AC-9(4), extend the idea to failed logon attempts and to changes in account details, so the notice can show what happened while the user was away. Confirm with your own assessor which enhancements you will select, because SP 800-53B selects none of them for any baseline, and each selected enhancement needs its own evidence.

Teams often miss AC-9 for two reasons. First, sign-in is rarely a single path: users log on through an identity provider, through directory-backed single sign-on, and then through individual applications that may keep their own logon records, so the last-logon value must be generated and displayed on every path that counts. Open-source identity components such as authentik, which delegates sign-in to applications through protocols like OpenID Connect and SAML, or FreeIPA, which provides single sign-on for Linux and UNIX environments, can help centralize the record, but you must confirm which layer actually displays the notice. Second, because the control sits outside the baselines, no team owns it by default, so assign it to a named owner before assessment begins.

Which logon paths and systems AC-9 applies to once you tailor it in

AC-9 is not selected in any SP 800-53B baseline, so the organization decides whether it applies at all, and to which systems and users. The cards below cover the scoping choices that change the work, and each one should be recorded in the system security plan with its rationale.

Systems that need the notice

Start by deciding which systems hold information where an unnoticed logon would matter, such as systems with personal data, payment data or privileged administrative functions. Because AC-9 is outside the baselines, a system inherits it only when the organization tailors it in. Record the decision per system or per system type, and note which systems are excluded and why. Assessors will ask whether the scope matches the system inventory.

Interactive user logons

Interactive logons through a web portal, desktop or console are the most direct case for AC-9. The control asks the system to show the date and time of the previous successful logon after the user signs in. Confirm the application can display that value, that the value comes from a trusted source, and that users see it on every successful logon. Check the behavior after a password reset or first logon, where no prior value may exist.

Administrator and privileged accounts

Decide whether administrator and privileged sessions are in scope. These accounts often carry the highest risk of misuse, so many organizations include them even when the rest of a system is out of scope. Confirm whether privileged access runs through a jump host, a bastion or a separate console, since the notice may appear in only one of those paths. Document any path where the notice cannot be shown.

Service and API access

Service accounts and API keys do not have a person who reads a notice, so AC-9 usually does not fit those paths in a literal sense. Record that position explicitly, and identify any compensating evidence, such as credential rotation records or logs of service authentication, that the organization relies on instead. Ask the assessor how they will treat non-interactive access before the assessment begins.

SSO and identity provider logons

When applications delegate sign-in to an identity provider, the logon event may happen at the provider rather than in the application. authentik, for example, acts as an identity provider for applications through protocols such as OpenID Connect and SAML, and FreeIPA provides single sign-on for Linux and UNIX environments. Decide whether the notice is shown by the identity provider, the application, or both, and confirm that the value shown reflects the successful logon the user actually performed.

Documenting the decision in the SSP

The system security plan should state whether AC-9 is selected, which systems and paths it covers, where it is implemented, and what is excluded with its rationale. Link the decision to the owner who approved it and to the review cycle. Assessors examine the plan and the access control policy for this, so an undocumented exclusion is a finding risk even when the technical behavior is sound. Also confirm that AC-9 is cross-referenced to related controls AC-7 and PL-4.

How an assessor tests AC-9 with examine, interview and test methods

This table lists each SP 800-53A assessment method used for AC-9, the objects an assessor reviews under it, and the findings that commonly appear. SP 800-53A gives AC-9 one determination statement, so every method feeds one question: does the system notify users of their previous successful logon, and can the organization show it. Read the rows as a checklist to prepare evidence before the assessor arrives.

Method	Objects or activities the assessor reviews	Common findings
Examine	Access control policy and procedures addressing previous logon notification, system design documentation, system configuration settings and associated documentation, system notification messages, system security plan	No documented decision for AC-9 when it is outside the organization's selected baseline; procedures that never mention the notice; configuration documents that omit the setting
Interview	System and network administrators who configure logon behavior; system developers who build or customize the login flow	Administrators unsure whether the notice is enabled; developers unaware of the requirement; answers that differ from the configuration files
Test	Mechanisms implementing the previous logon notice, including local logon, directory-backed logon and single sign-on flows, checked with sample accounts	Notice shows the wrong timestamp or time zone; notice missing after SSO logons; notice shown after failed logons when the design says otherwise; no record of the prior logon to display
Examine (system security plan)	Whether the SSP states the AC-9 decision, the mechanism that provides the notice, and the owner of the configuration	Plan describes AC-9 as implemented while the configuration shows otherwise; ownership of inherited or identity-provider settings is unclear
Test (identity provider)	Whether the identity provider or application returns and displays the last successful logon, including applications that delegate sign-in	Each application handles the notice differently; the identity provider stores the event but the application never shows it

Evidence that passes AC-9 and how to keep it current

AC-9 is assessed with a single determination statement, so the evidence set is small but must be exact. The cards below cover the decision record, the policy text, the notice configuration, the timestamp tests and the upgrade history that together show the notice is selected, implemented and still working.

Tailoring decision in the security plan

Because SP 800-53B does not select AC-9 for any baseline, the assessor first needs a written decision that adds it. Record the tailoring choice in the system security plan, name the reason (for example, a customer requirement or an internal risk finding), and state which logon paths it covers. Re-check the entry at each assessment and whenever the system boundary or authentication design changes, so the plan still matches what runs.

Policy and procedures on previous logon notification

The access control policy and its procedures should name previous logon notification explicitly, including who owns the setting, what the notice shows and how exceptions are approved. Assessors examine this document against the one determination statement. Review it on the schedule set in AC-1 and confirm that the procedure text still names the current identity provider and the applications that display the notice.

Notice configuration for each logon path

Export the relevant settings from each path a user can log on through, such as the identity provider, the application login and any administrative console, and keep the files under version control. Where a setting only exists in a user interface, keep a dated screenshot with the configuration name visible. Repeat the capture at each assessment so the evidence reflects the running configuration, not an earlier design.

Timestamp test against audit records

Run a scripted test with a known account: log on successfully, confirm the displayed last logon date and time, then compare that value with the authentication event in the audit log. Save the test steps, inputs, outputs and the matching log entry. Repeat the test after clock or time source changes, because a notice that shows the wrong time undermines the purpose of the control.

Change log across upgrades

Platform upgrades, identity provider updates and changes to authentication flows can silently remove or alter the notice. Keep a change log that records each upgrade, the release reviewed and the result of re-running the logon test. Note any affected setting so the assessor can see the control was checked after change, not only at initial deployment.

How to implement previous logon notification step by step

This sequence takes AC-9 from a documented tailoring decision to a tested, evidenced procedure that shows users their last successful logon time. Each step names the artifact it produces so an assessor can follow the trail from scope to test results.

Confirm scope and document the tailoring decision
Start by confirming which systems fall inside the authorization boundary and whether AC-9 applies to them. SP 800-53B Release 5.2.0 does not select AC-9 for the low, moderate, high or privacy baselines, so the organization must record why it adds the control, either by tailoring its baseline or through an overlay. The control owner, the system security officer and the risk owner should sign off on that decision. The step is complete when the system security plan lists AC-9, its implementation statement and the tailoring rationale. Ask your assessor early whether they expect the control in scope for your system.
Define successful logon and the timestamp to display
Write down what counts as a successful logon for each account type, such as interactive console sessions, web application sign-in, API token issuance and administrative elevation. Decide which timestamp the user sees, the time of the previous successful logon, and how the system handles the first logon of a new account when no prior record exists. Set the time source and time zone display rules, and align them with the organization's time synchronization requirements. The output is a short logon definition and display specification that the identity and application owners approve. Confirm that failed attempts are excluded from the displayed value unless you intend to implement the failed-logon enhancement.
Configure the identity provider or application
Configure the identity provider or application so it records each successful logon and returns the previous value at the next sign-in. Where sign-in is delegated, such as through an OpenID Connect or SAML provider, confirm whether the identity provider or the relying application stores the value, and document the configuration in the system design documentation. Restrict who can read or change the stored records, and keep configuration files under change control. The step is done when a test account shows the expected prior logon on its second successful sign-in. Confirm the exact capabilities of your chosen product in its current documentation rather than assuming them.
Test every logon path including SSO and administrative access
Test each path a user can take to reach the system: direct application login, single sign-on, federated sign-in, command line or console access, remote administrative sessions and break-glass accounts. For each path, run a successful logon, verify the displayed previous logon time matches the audit log, and confirm that a failed attempt does not overwrite the stored value. Record the test cases, expected results, actual results, tester and date. Include one case where a session is established through a path that bypasses the normal user interface, since assessors often ask about those routes. Any path that does not display the value needs a documented exception or a fix.
Write the procedure and retain the test evidence
Write a procedure that tells administrators how the notification is configured, how it is verified after upgrades or changes, and who reviews failures. Link the procedure to the access control policy and procedures addressed under AC-1, and to the change control records for any configuration change. Store the signed tailoring decision, the logon definition, configuration exports, the test records and the audit log samples together in the evidence repository. The step is complete when an assessor could reproduce your test from the written procedure and find the same results. Re-run the tests after material changes to the identity provider or application.

Using authentik and FreeIPA to support AC-9 evidence

Previous logon notification depends on where logon happens. When an identity provider or single sign-on service handles authentication, its records and configuration become the starting point for showing the last logon to the user. The two open-source tools below cover different parts of that chain, and each needs confirmation before it is counted as evidence.

authentik as the sign-in provider

authentik (MIT) is an identity provider that applications delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Because the logon event happens in authentik rather than in each application, its logon records can be the source for a previous logon notice. Confirm whether authentik natively displays the previous logon time to the user, or whether the application must read and show it. Check the provider configuration for each connected application, since an application that uses local passwords would fall outside this record.

FreeIPA for Linux and UNIX logon

FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. It is relevant where operating system and host logons authenticate against a central directory, so the logon history held by the directory can support the notice for those sessions. Confirm whether a previous logon notice is a native feature for the hosts and services in your environment or needs work on each system. Kerberos ticket issuance and host login records are not the same as a message shown to the user, so test what the user actually sees.

Mapping logon sources to systems

Before choosing a tool, list every system that accepts logons and record which identity source it uses. Some applications will use authentik, some hosts will use FreeIPA, and some will keep local accounts. Assessors examining AC-9 will ask whether the notice applies to every logon path that grants access to the system. A gap in this inventory is the most common reason a notice passes for some users and not others.

Evidence the assessor will request

Collect configuration exports showing the previous logon setting, screenshots or recorded test logons showing the notice text and timestamp, and the logon records that the timestamp is drawn from. The SP 800-53A procedure for AC-9 examines the access control policy, procedures, system design documentation, configuration settings and notification messages, and tests the mechanisms. Keep the tool version and configuration under change control so the evidence still matches the system at assessment time.

Testing failed logon and account change notices

The AC-9 enhancements extend the notice to failed logon attempts and to changes made to the account. Identity providers often record failures and credential changes in the same log as successful logons, so check whether each event type can be surfaced and whether it reaches the user. Test a failed logon, a password change and a profile change in a non-production tenant, and document which events produce a notice and which do not.

What meeting AC-9 costs in money and effort

This table lists each cost component of putting AC-9 in place, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since NIST does not estimate compliance costs and no figures for AC-9 are published in the supplied sources.

Cost component	One-time or recurring	What drives it up	How to keep it down
Engineering time to configure the notice	One-time, with later changes	Number of identity providers and admin consoles that must show the last logon time, and whether the notice is custom code or a built-in setting	Use the identity provider's existing logon notification features where they meet the requirement, and confirm the exact behavior with the vendor first
Identity provider or application changes	One-time, then recurring with upgrades	Custom applications that handle their own sign-in, legacy systems that cannot pass the last logon data, and proxy or SAML integrations that need extra attributes	Route sign-in through one self-hosted identity provider such as authentik or FreeIPA so the notice is set in one place, after confirming which logon paths each product supports
Testing across logon paths	One-time per path, then recurring after changes	Count of logon paths (web, SSH, VPN, console, API tokens), failed and successful logons, and account change events covered by AC-9(1) to AC-9(4)	Write a short list of logon paths in the system security plan, test each path once, and retest only the paths touched by a change
Evidence upkeep	Recurring	Number of systems in the authorization boundary, frequency of configuration changes, and how many screenshots, configuration exports and test records must be refreshed for each assessment	Export settings from configuration management and keep test results in a single evidence location so each assessment reuses them
External testing or review	Recurring, usually per engagement	Scope of the independent review, number of logon paths sampled, and whether the reviewer also checks AC-7 and AC-8 at the same time	Agree the scope in writing before work starts and bundle AC-9 with related logon controls such as AC-7 and AC-8
Auditor sampling time	Recurring, per assessment cycle	Number of systems and logon paths sampled, and how quickly the organization can produce the requested records	Keep the configuration, test records and sample logon outputs ready so the assessor can test without follow-up requests
Tailoring and documentation	One-time, then recurring at review	Decision to add AC-9 to a baseline by tailoring or overlay, since SP 800-53B does not select it for any baseline	Record the tailoring decision and rationale once, and reference the same standard configuration across systems

Who owns AC-9 and what a partner can take on

Your organization owns AC-9 in full. Because SP 800-53B does not select AC-9 for any baseline, the first decision is whether the control belongs in your system at all, and that decision must be recorded as part of tailoring the baseline or as an overlay. Your team then sets the policy, names who approves it and signs off on the final implementation before an assessment begins.

Tailoring decision: Decide whether AC-9 applies to the system, record the rationale in the system security plan and state which enhancements you adopt.
Policy owner: Name the person who owns the access control policy and procedures that cover the logon notice and its review cycle.
Final sign-off: Approve the configured behavior, including what users see after a successful logon and how failed logon information is handled.
Exception handling: Document any systems where the notice cannot be shown, such as headless service accounts, and the compensating measures you accept.
Ownership of results: Keep the authority to accept or reject partner work products and to answer the assessor.

Confirm with your assessor early which tailoring decisions they expect to see documented before testing starts.

Where AC-9 implementations usually fall short

AC-9 sits outside the SP 800-53B baselines, so it is often never decided on at all, and when it is built, it tends to cover only one logon path. The cards below cover the gaps that assessors most often find, each with a concrete check the organization can run before its assessment.

No tailoring decision on record

Because SP 800-53B does not select AC-9 for the low, moderate, high or privacy baselines, many systems never mention it. Assessors then ask why the control is absent from the system security plan. Record an explicit decision either way: add AC-9 through tailoring or an overlay, or document why the organization does not select it and which risk it accepts. Confirm the decision with the authorizing official and your assessor before the assessment starts.

Notice built for password logons only

Teams often add the last logon message to the local login screen and miss the paths users take most. Single sign-on, API token flows and service sessions may never display the notice, or they show a timestamp from the identity provider's cache. Inventory every logon method that reaches the system, then test each one with a known account. Identity providers such as authentik, which delegates sign-in to applications over OAuth2, OpenID Connect and SAML, need the notice handled at the application or at the provider.

Timestamp drawn from the wrong event

A common defect records the last attempted logon rather than the last successful one. A failed password guess then appears as the user's last access, which hides the signal AC-9 exists to provide. Check how the timestamp is written, which event it reads, and whether a failed logon updates the same field. Run a test where the user fails once and then succeeds, and confirm the notice shows the successful time.

Enhancements selected but not built

AC-9 has four enhancements, AC-9(1) to AC-9(4), which address notifying users of unsuccessful logon attempts and of changes to security-related account information. Selecting them in the plan without building them creates a gap that assessors test directly. Decide for each enhancement whether it applies to the system, document the mechanism, and test the notice with a failed logon and an account change. Confirm each enhancement's exact text in the catalog before writing the test plan.

Evidence captured once, never refreshed

Screenshots of the notice taken during initial deployment often go stale after an upgrade, a change to the login page or a new identity integration. Assessors reviewing the system later find evidence that no longer matches the running configuration. Schedule a repeat test after each significant change, store the output with the date and build version, and link it to the test objects listed in SP 800-53A. Ask your implementation partner to include this retest in the handover runbook.

Notice logic not in the design documents

Assessors examine system design documentation and configuration settings for AC-9, and a notice that exists only in code or in one administrator's memory fails that examination. Document where the last logon value is stored, which component writes it, how it reaches the user, and who owns the setting. Keep this entry in the system security plan so that the examine evidence matches the test results.

Deciding whether the AC-9 enhancements belong in your scope

AC-9 has four control enhancements in SP 800-53 Release 5.2.0, none of them withdrawn, and SP 800-53B selects none of them for the low, moderate, high or privacy baseline. That means the team must decide whether to select only the base control, which is also outside every baseline, or to tailor in some or all of AC-9(1) to AC-9(4). Nothing in the baselines forces the choice, so it has to come from your own risk assessment, your system's logon paths and any contractual or regulatory language that names logon history or account changes. Record the decision and its rationale in the system security plan so an assessor can trace why each item is in or out.

The choice changes the evidence. A base-control-only scope needs a documented requirement that successful logons show the previous logon date and time, the configuration that does this in each logon path, and a test showing a user sees it. Adding enhancements means you also need evidence for the failed logon notification and account change notification behavior that each selected enhancement covers. Confirm the exact wording of each enhancement in the official catalog before you write test cases, because this page does not restate that text. Scope every login path, including SSO, administrative consoles and any application that handles its own sign-in, since the notification has to work where users actually log on.

Review AC-7 and PL-4 alongside AC-9 before you finalize the scope. AC-7 governs unsuccessful logon attempts, so the failed logon behavior you choose to notify users about depends on the lockout and counting settings already in place under that control. PL-4 covers rules of behavior, which is where you can state what users should do when the last logon time looks wrong, such as reporting it to the security team. If your identity provider handles sign-in for several applications, confirm with the vendor and in your own environment which component writes the logon history and which applications display it, since that decides who must produce the configuration and test evidence.

What buyers ask about AC-9 cost, effort and outside help

What drives the effort of implementing AC-9 previous logon notification?

The effort depends on how many systems show a logon notice, how many identity sources sit behind them, and how much of the logon path the organization controls. AC-9 asks that a successful logon show the user the date and time of their last logon, so the work starts with an inventory of every login surface: the identity provider, each application that signs users in directly, administrative consoles, and any remote or legacy systems. Each surface needs a way to store the last successful logon time and display it on the next successful sign-in. Where a central identity provider already records sign-in events, the work is mostly configuration and testing. Where each application keeps its own user table, each one needs separate changes. Effort also rises with the enhancements you select, because AC-9(1) to AC-9(4) add requirements for failed logons and account changes, each of which requires its own mechanism and evidence. Ask any provider to break the estimate down by system and by enhancement.

Can our team implement AC-9 without outside help?

Yes, an internal team can implement AC-9 if it has engineers who can change the logon path of each system and the time to test it. The control itself is not complex, but the evidence has to be right. Your team needs to confirm that the notice appears only after a successful logon, shows the correct timestamp, and that the stored value is protected from users who could alter it. Outside help is most useful when many systems are involved, when identity infrastructure is split across cloud accounts or data centers, or when the team has no capacity to prepare the system security plan entries and test records an assessor will examine. An implementation partner can prepare configurations, test accounts and evidence, but it cannot decide whether your organization meets the control. That decision belongs to your own risk owners and to the independent assessor.

How long does AC-9 implementation take?

No fixed duration applies, because the timeline is set by the systems in scope and the way they authenticate users. The main drivers are the number of logon surfaces, whether a central identity provider can be used, the change process for production authentication systems, and the testing cycle needed to confirm behavior after failed and successful logons. Organizations that already run a central identity provider for most applications usually have a shorter path than those with many standalone applications. Change approval windows, regression testing for login flows and the need to update the system security plan can each add time. Ask any provider to tie its schedule to a written scope that lists each system, each enhancement and each deliverable, since a timeline without that scope cannot be checked against the work.

What does our organization need to provide for AC-9 work?

The work needs three groups of people and access. Identity owners must confirm how sign-in is configured, approve changes to authentication flows and provide access to the identity provider or directory. Application owners must confirm which applications display logon information, accept changes to their login pages or session handling, and approve test plans. Test accounts are essential: you need accounts with known logon histories, accounts for failed logon tests, and accounts that can be used to simulate account changes so that the enhancements can be shown to work. Your team should also provide the existing access control policy, procedures and system security plan so that new AC-9 evidence matches documents an assessor will already examine. Ask for a list of these inputs in any written scope before work begins.

Is AC-9 required in an SP 800-53B baseline?

No. AC-9 is not selected in the SP 800-53B low, moderate or high baselines, and it is not selected in the privacy baseline. None of its four current enhancements is selected in those baselines either. An organization can still adopt AC-9 by tailoring a baseline, which means choosing controls beyond the baseline to meet its own risk, or by applying an overlay that adds it for a specific system type. The decision should be recorded in the system security plan with a reason, so that an assessor can see why the control is in scope. Contracts or customers sometimes require controls that the baseline omits, so check the contract text before deciding whether AC-9 is a voluntary addition or a requirement you must meet.

Who issues the AC-9 assessment result?

An independent assessor issues the assessment result, not the implementation partner. NIST's SP 800-53A gives the assessment procedure for AC-9, with one determination statement and examine, interview and test methods. Assessors review documents such as the access control policy and system configuration settings, interview system administrators and developers, and test the mechanisms that show previous logon notification working. An implementation partner, including DeployOpen, prepares systems, controls and evidence so that the assessor has material to examine. It does not issue audit reports, attestations or certifications. Your organization owns the control and its determination, and the assessor's report is the document a regulator, customer or authorizing official will rely on. Ask any prospective assessor to confirm its independence and the scope of its report before you engage it.

How DeployOpen scopes and prepares AC-9 evidence

DeployOpen works on AC-9 Previous logon notification as part of a written scope inside your own infrastructure. We prepare the logon notification behavior, its configuration and the evidence an assessor would examine, while your organization keeps ownership of the control and any independent assessor issues conclusions.

How we scope

Confirm which systems, applications and identity providers must show the last successful logon date and time to users.
Record in the written scope whether AC-9 is selected by a tailored baseline or an overlay, since SP 800-53B does not select it.
Agree which AC-9 enhancements for failed logons and account changes are in scope before any configuration work begins.

How we build

Configure the previous logon notification behavior in the identity layer, such as authentik providers or FreeIPA single sign-on, where the platform supports it.
Confirm the displayed timestamp and failed logon messaging against your written requirement in a controlled test environment.
Test the mechanisms with the examine, interview and test methods that SP 800-53A describes for AC-9 before handover.

How we hand over

Deliver configuration settings, design notes and test results mapped to the AC-9 determination statement and its assessment objects.
Provide a procedure document covering how users see the notice, how exceptions are recorded and who reviews them.
Document open items and the items your own assessor or auditor will need to examine, so responsibility for conclusions stays clear.

How we support

Support the AC-9 configuration through upgrades of the identity platform, since logon behavior can change between versions.
Review the AC-9 evidence set when the system security plan, identity architecture or related controls such as AC-7 change.
Ongoing support, upgrades and continuous testing are available as a retainer, priced separately from the fixed-scope engagement.