AC-8 System use notification: requirements and evidence

What AC-8 system use notification requires before anyone logs on

When an assessor or a contract asks for the AC-8 banner, the team has to show exactly what a user sees before any access is granted, and prove that the same notice appears on every path into the system. AC-8 asks for a notice that tells the user the system is a U.S. Government system, that use may be monitored and audited, that unauthorized use is prohibited and subject to penalties, and that continued use means the user consents to those conditions. The notice must stay on screen until the user acknowledges it. The risk the control addresses is simple: a user who was never told about monitoring or legal exposure cannot be held to those terms, and an organization cannot rely on monitoring evidence it never disclosed. Confirm the exact wording against the control text in the NIST CPRT entry rather than relying on memory or on a template copied from another system.

What usually makes AC-8 hard is not writing the banner but controlling it. Banner text is often drafted by a system owner, never approved by legal counsel or the authorizing official, and then left unchanged through several releases. Login paths are another gap: the web console may show the notice while an SSH session, an API token flow, a VPN gateway or a service account route skips it entirely. Before an assessment, list every interactive entry point, capture the screen or prompt each one presents, and record who approved the wording and when. Keep those approval records and acknowledgement logs with the system security plan, because the assessment procedure for AC-8 looks for documented approval of the banner, user acknowledgements and the mechanisms that display the notice.

AC-8 has no control enhancements in SP 800-53 Release 5.2.0, so the work sits in one control statement with two organization-defined parameters that the organization must set. The control is selected for the low, moderate and high baselines in SP 800-53B Release 5.2.0 but not for the privacy baseline, so a system that holds only personal data under the privacy baseline still needs a decision on whether a banner applies to it. Confirm the baseline selection for your system in the system security plan. Also check the publicly accessible system conditions in the control text before you assume that a public website needs the same banner as an internal administrative console.

Which systems and access paths need the AC-8 banner

The AC-8 banner is not a single text file applied everywhere. The baseline a system is assigned, the wording its agency or contract requires, the logon paths users reach it through and the accounts that come from outside the organization each change what must be displayed and who must approve it. Work through these decisions before drafting any banner text.

Baseline selection sets the scope

SP 800-53B selects AC-8 in the low, moderate and high baselines, so any system categorized at one of those impact levels carries the control. The privacy baseline does not include AC-8, so a system that is only scoped to privacy controls does not inherit this requirement. Confirm the impact level in the security categorization before counting systems, because a system that moves from low to moderate adds the banner obligation to its existing plan.

U.S. Government wording where it applies

The control text expects a notice stating that users are on a U.S. Government system. Systems operated for a federal agency, or under a contract that requires this wording, need that statement. Systems owned by private organizations may use the organization's own legal text, provided it still covers monitoring, prohibited use, penalties and consent. Ask counsel which wording the agency, contract or regulator requires before approving the banner text.

Interactive logon paths in scope

Every interactive path that presents a logon prompt needs the banner before access is granted. Inventory the console, web applications, SSH, VPN portals and remote desktop gateways, along with any administrative consoles for hypervisors or network devices. A banner shown on the web portal but not on SSH leaves a gap an assessor will find by logging on through the unlisted path.

Publicly accessible systems follow different rules

The control sets separate conditions for publicly accessible systems, such as a public website or an open portal that lets anyone reach a page before logon. Identify any such system early, because its notice language and the point at which it appears differ from an internal logon banner. Document the boundary in the system security plan so the reviewer can see which systems fall into each group.

Contractor and third-party accounts

Accounts held by contractors, managed service providers and vendor support staff log on through the same paths and receive the same banner. Check that federated or shared logon services, and any jump hosts used by outside staff, display the notice before they pass the user to the system. Confirm with the contract owner whether the agreement requires specific wording for outside users.

Inherited and shared banners

Where a common identity provider or hosting platform displays the banner for several systems, record which component provides it and which systems inherit it. Assessors test the banner on each system's actual logon path, so inherited coverage must be shown for every system that uses that path. Keep the inheritance record with the banner approval so the evidence stays linked to the right systems.

What the logon notice must say, element by element

AC-8 asks the organization to show a notice before a user gains access, and the researched content of the control breaks that notice into four elements. The first is a statement that the user is accessing a U.S. Government system. The second is a statement that use may be monitored, recorded and audited. The third is a statement that unauthorized use is prohibited and that it can lead to penalties. The fourth is a statement that using the system means the user consents to monitoring. Engineers placing the text on a login screen should treat each element as a separate sentence they can point to in a test, so that a missing clause is visible in review rather than hidden in a longer paragraph.

The control leaves two decisions to the organization. Its organization-defined parameters, which SP 800-53A labels AC-08_ODP[01] and AC-08_ODP[02], are values the organization assigns when it implements the control. In practice these cover the exact notice wording and the conditions under which the notice is shown. Record the chosen values in the system security plan, and confirm with counsel that the wording matches the statute, agency policy or contract that applies to the system. Legal review should cover the exact characters on screen, not a summary, because a paraphrase that drops a clause can fail an assessment even when the intent is correct.

Store the approved wording in a controlled document with a version, an approver and a date, and keep the sign-off records. Assessors using SP 800-53A examine documented approval of notification messages and banners and compare them with what users actually see, so the approved text is the first thing they will request. Engineers should also keep a copy of the rendered banner from each login path, including remote access, console and web portals, since a banner that exists in the document but not on one entry point is a common finding. Confirm with the system owner which entry points are in scope before the assessment starts.

How publicly accessible systems change the banner rules

AC-8 does not treat publicly accessible systems the same way as systems that require a logon. The control sets separate conditions for them, because a visitor to a public website usually never logs on, so a banner that must stay on screen until the user acknowledges it does not fit. The first task is to decide, in writing, which of your systems count as publicly accessible for this control. Record the test you applied, the systems it covers, and who approved the decision, so the determination can be examined later.

Once a system is classed as publicly accessible, the notice belongs on the public entry point, before any restricted content or functionality is presented. Confirm with your security and legal owners how the notice is worded and where it sits, and keep the approved text under version control. Do not assume that a banner built for a logon page carries over unchanged. Check the wording against the control text itself, which you should read in the NIST CPRT or the OSCAL catalog for SP 800-53 Release 5.2.0 rather than relying on this summary, since the exact conditions for publicly accessible systems are set out there.

When an assessor reviews this part of AC-8, expect questions about the scope decision, the approved notice text, and proof that the notice appears on the public entry point before restricted pages load. Typical evidence includes the documented determination, the approved notice, dated screenshots or captures of the public pages, and the configuration that controls what is displayed. Ask your independent assessor which evidence form they accept, and agree on it before testing begins, so the artifacts you prepare match what they will examine.

How an assessor tests the AC-8 banner

This table compares the three SP 800-53A assessment methods for AC-8 System use notification, showing what the assessor does, what evidence to prepare and where banners usually fail. Read each row as a question the assessor will ask, and use the findings column to check your own logon paths before the assessment begins.

Assessment method	What the assessor does	Evidence requested	Common findings
Examine	Reads the approved banner wording and the approval record, then compares the text against the notice elements the control requires.	Documented approval of the banner text, the current banner wording, and the policy or procedure that assigns who approves changes.	Banner wording was never formally approved, or the approved text differs from what users actually see.
Examine	Reviews user acknowledgement records to confirm that users must acknowledge the notice before access is granted.	Acknowledgement logs or screen captures showing a user must act on the banner before the session continues.	Acknowledgements are not recorded, or the log cannot tie an acknowledgement to a specific user and time.
Examine	Checks system audit records and the privacy assessment documentation that relate to monitoring described in the banner.	System audit records, privacy impact assessment and privacy assessment report where monitoring touches personal data.	The banner says use is monitored, but no audit record or privacy assessment supports that statement.
Interview	Asks system and network administrators how the banner is deployed, changed and kept consistent across systems.	Named administrators able to explain the deployment method, change steps and where the banner is configured.	Administrators describe a manual process that is not written down, or cannot say which systems display the banner.
Interview	Asks legal counsel whether the banner wording matches the organization's authority and the required notice elements.	Counsel's review of the wording, or a record showing counsel approved it.	No legal review exists, or the banner was copied from another organization without adaptation.
Test	Logs on through every login path, including console, remote, web and any publicly accessible interface, and observes the banner.	Test results for each login path, with the banner displayed before access is granted.	Banner appears on the main login page but is missing from one remote, API or secondary login path.
Test	Attempts to bypass or dismiss the banner without acknowledging it and confirms the session does not proceed.	Recorded test steps showing the banner stays on screen until acknowledged.	Banner times out or closes automatically, letting the session continue without acknowledgement.
Test	Reviews the configuration of the mechanisms that display the banner, including any settings for publicly accessible systems.	Configuration exports or settings for the display mechanism, and the documented separate treatment for publicly accessible systems.	Public-facing systems use the same banner as internal systems without the separate conditions being documented or tested.

How to implement AC-8 in order

This sequence takes AC-8 from a scoped baseline decision to recorded user acknowledgements, with each step producing a document or record that an assessor can examine and test.

Confirm the baseline and systems in scope
Start by checking which SP 800-53B baseline your system is categorized under. AC-8 is selected for the low, moderate and high baselines but not for the privacy baseline, so a system categorized only against the privacy baseline does not carry this requirement. Then list every system, application, portal and remote entry point that grants access, since each one needs the notice. The output is a scoped inventory of logon paths tied to the system security plan, which the owning team confirms in writing.
Obtain counsel approval of the notice wording
Draft the notice so it states that the user is accessing a system, that use may be monitored and audited, that unauthorized use is prohibited and subject to penalties, and that use constitutes consent. Ask legal counsel to review the wording against your agency or contractual obligations, because the required content is set by policy and law and your counsel decides the exact text. While drafting, set the two organization-defined parameters the control leaves to you, and record the values chosen. The output is approved banner text and a written parameter record signed by the approver.
Document the approval and banner ownership
Put the approved text, the parameter values, the approver's name and the approval date into the access control policy and procedures or a dedicated banner standard. Name the owner responsible for changes and state which systems use the text. Assessors look for documented approval of the notification messages, so an unsigned draft in a shared folder will not satisfy them. The output is a versioned document that maps each logon path to the approved banner version.
Configure each logon path to display the notice
Apply the approved text to every interactive logon path, including console, web, SSH, VPN, remote desktop and any single sign-on prompt that precedes application access. Configure the banner so the user must see it before access is granted and must act on it to proceed. Keep the configuration in version control or a configuration baseline so changes are tracked. Confirm that the mechanism does not allow a user to bypass the banner through an alternate path. The output is a configuration baseline showing the banner setting for each path.
Hold the notice until the user acknowledges it
Configure the banner to remain on screen until the user explicitly acknowledges it, rather than dismissing automatically after a timer. Test that closing the window, pressing back or waiting does not grant access. Where a system is publicly accessible, apply the separate publicly accessible conditions the control describes, and confirm the wording and placement with counsel for those entry points. The output is a test record showing that access is blocked until acknowledgement on each path.
Verify behavior on every path, including public entry points
Test each logon path from the inventory in step one, using test accounts and a clean browser or session for each. Check that the banner text matches the approved version exactly, that it appears before authentication or access, that it holds until acknowledgement, and that the public entry points show the conditions set for publicly accessible systems. Record the date, tester, path, observed text and result. Assessors use this kind of test evidence to check the mechanism, so keep the screenshots or captured output with the results. The output is a signed test report with pass or fail per path and remediation for any failures.
Record each acknowledgement and retain the records
Decide how acknowledgements are captured. Where the platform logs them, confirm that each acknowledgement is tied to a user identity, a timestamp, the banner version and the logon path. Where it does not, add a mechanism that records this data or confirm that audit records from the platform capture it. Set how long these records are retained under your audit and retention policy. Review a sample of records periodically to confirm the banner is being acknowledged. The output is an acknowledgement record set that shows who saw which version of the notice and when.
Confirm the evidence package before assessment
Bring the approved text, the parameter record, the configuration baseline, the test report and the acknowledgement records together under the control's entry in the system security plan. Check that each piece refers to the same banner version so an assessor can trace one notice from approval through configuration to user acknowledgement. Ask your independent assessor which evidence formats they accept. The output is a single evidence set that a third party can examine, and the organization owns the conclusion drawn from it.

Evidence that passes an AC-8 assessment

AC-8 is tested on evidence from both sides: the approved wording and the banner the user actually sees, and the settings and records that prove the banner stays until acknowledged. The cards below cover the artifacts an assessor typically asks for, how to capture them, and how to keep them current between assessments.

Documented approval of banner messages

This is the written record that the banner text was reviewed and approved by the people the organization designates, typically including legal counsel. Assessors compare the approved wording against what each system displays, so the approval should quote the exact text, name each system or logon path it covers, and carry a date and version. Check that any change to the wording triggers a new approval before it goes live.

Captured output from each logon path

Screenshots or captured console output show the banner as a user sees it at every entry point: the web login, the SSH or console prompt, remote desktop, and any API or management interface that presents a logon screen. For each capture, record the system, the date, the account state used, and the tester's name. The aim is to show the banner appears before access is granted, not only on the main portal.

Configuration exports for banner settings

Export the configuration files or policy values that control the banner, such as the login banner file, the display manager setting or the SSH banner directive, and store them with the system baseline. Assessors use these exports to confirm the banner is set everywhere it should be and to detect drift. Confirm with your platform vendor which setting controls each component, because the key names differ across products.

User acknowledgement records

Acknowledgement records show that each user must accept the notice before the session continues, and that the system holds the banner until that acceptance occurs. Keep logs of acceptance events with user identifier, timestamp and system, and test that declining the notice ends the attempt. Assessors often sample these records against the user population to find gaps in coverage.

Test record for publicly accessible entry points

Where a system is publicly accessible, the test record should show how the organization handled the separate condition for public access, including the notice shown and any reliance on other controls such as AC-22 for public content. Record the entry points tested, the expected and observed behavior, and the reviewer. Confirm the public-access condition with your assessor before the test, since the applicable wording depends on your system's status.

Automated checks and current evidence

Wazuh Security Configuration Assessment checks endpoint configuration against YAML policies, and Fleet policies answer yes or no questions about devices through osquery. Confirm whether either can read the banner file or setting in your environment before relying on it, and if it can, schedule the scans and keep the results with the captures. Refresh every artifact after each banner or system change, and rerun the logon-path tests on a fixed schedule set in your continuous monitoring plan.

What meeting AC-8 costs in money and effort

This table compares the main cost components of putting an AC-8 banner in place, who is paid for each, whether it is one-time or recurring, and what drives it up. Read it as a checklist for a quote: each row should appear as its own line item, because the total follows from the number of logon paths, systems in scope and wording changes.

Cost component	One-time or recurring	What drives it	How to keep it down
Legal review of banner wording	One-time, then recurring on each change	Number of jurisdictions, contracts and user populations; whether counsel must approve each variant	Agree one master wording with counsel, then limit variants to those the law or contract requires
Engineering time to configure each logon path	One-time per path, plus recurring on upgrades	Number of web consoles, SSH and RDP entry points, VPN gateways, APIs and admin portals in scope	Inventory logon paths early and reuse one banner template across systems that share a platform
Acknowledgement mechanics and enforcement	One-time, then recurring when platforms upgrade	Whether the system can block access until the user acknowledges, or only displays text	Confirm the native capability of each platform before design, and document any gap in the system security plan
Testing of public entry points	One-time, then recurring on release	Number of publicly accessible systems, since these follow separate conditions from private systems	Test public and private paths in the same pass and keep scripted checks for the banner text
Evidence upkeep when banners change	Recurring	Frequency of wording changes, number of systems showing the banner and approval records kept per change	Store approved wording, approval dates and screenshots in one versioned repository
Tooling and licenses	One-time setup, recurring license or support fees where applicable	Choice of commercial logon or monitoring products versus self-hosted open-source components	Self-hosted open-source tools can remove license spend, but confirm their configuration and support costs before deciding
Auditor sampling time	Recurring at each assessment	Number of systems sampled, how many banner versions the auditor must trace and how quickly evidence is produced	Keep a current banner register so the assessor can sample quickly and without rework

Who does what for AC-8: your team, a partner and the auditor

Your organization owns AC-8 in full. The control is a decision about what users see before they log on, and that decision carries legal and policy weight, so it cannot be delegated to a vendor. Your team sets the two organization-defined parameters for the control, approves the exact wording of the notice, decides which logon paths and systems display it, and keeps the approval record that an assessor will ask to see.

Banner wording: Legal counsel and the security owner agree the text, covering the elements the control statement requires, and record the approval date and approver.
Scope decisions: Your team lists every interactive logon path, including consoles, remote access gateways, web portals and administrative tools, and decides where the banner applies.
Publicly accessible systems: Your team identifies which systems are publicly accessible and confirms the separate conditions that apply to them.
Ongoing ownership: Someone internal reviews the banner when the wording, legal basis or system inventory changes.
Acknowledgement records: Your team decides how user acknowledgements are captured and retained as evidence.

Confirm with counsel and your assessor which wording and parameters they expect before any configuration work starts.

Questions teams ask about AC-8 system use notification

Does AC-8 apply to every system?

No. AC-8 is selected in the SP 800-53B low, moderate and high security control baselines, so it applies wherever your system's impact level places it in one of those baselines. It is not selected in the privacy baseline. Which baseline applies is a decision made during security categorization and baseline selection, and it belongs to the organization that owns the system. Confirm the baseline in your system security and privacy plan before scoping banner work, because a system that is categorized low still needs the control. NIST does not estimate compliance costs or set timelines for this work.

What drives the effort of building a system use notification banner?

The control itself is a single notice shown before access is granted, so the technical effort is usually modest. Most of the work comes from the surrounding evidence. The main drivers are the number of logon entry points (web portals, SSH, VPN, desktop and API consoles), how many of them already show a notice, whether the same text must be applied across different platforms, and how much of the platform configuration must be tested and documented. Systems with many legacy entry points usually take the most effort to cover consistently.

How long does it take to get the banner wording approved?

NIST does not set timelines for approval, and the duration depends on your own governance. Approval typically runs through legal counsel, security leadership and the owners of each affected system. The organization-defined parameters for AC-8 must be set before the wording is final, so the first step is agreeing on the values. Ask your legal team which review cycle applies and whether the organization already has approved notice text that can be reused. Starting this review early avoids delays when the banner must go live.

Can our team implement the banner without outside help?

Often yes, if the team has administrative access to each logon entry point and someone who can write and review configuration changes. Assessors need to see the approved wording, the mechanism that displays it, and proof that users acknowledge it before access. An internal team that owns the platforms, runs its own change control and keeps its own records can usually produce that evidence. Outside help is most useful when many heterogeneous platforms must be configured consistently or when the team lacks capacity to test and document every entry point.

What does the work need from legal, platform and security staff?

Each group owns a different part of the control. Legal counsel reviews the notice text so it states that users are on a U.S. Government system, that use may be monitored and audited, that unauthorized use is prohibited and penalized, and that use means consent. Platform engineers configure the banner on each system and confirm it displays before access is granted. Security staff own the policy, approve the parameters, keep the records and test the result. Agree on a single owner for the banner content so later changes are reviewed once and applied everywhere.

What should we ask for in a fixed-scope quote for banner work?

Ask for a written scope that lists each logon entry point, the platforms and versions in each, the approved notice text, and whether each system is internal or publicly accessible, since the publicly accessible conditions in AC-8 differ. Also ask which deliverables are included: configuration changes, test results, the evidence package for each system and handover documentation. Confirm what the quote excludes, such as legal review or the assessment itself. Ask who performs the independent assessment, because DeployOpen prepares systems and evidence but independent assessors issue assessment conclusions.

How does an assessor check the banner?

An assessor reviews the documented approval of the notice, the notice text itself, the user acknowledgement records and the mechanisms that display the banner, as listed in SP 800-53A. They also interview system and network administrators and may involve legal counsel. Testing confirms the banner appears before access is granted and stays until the user acknowledges it. Prepare by keeping approved text under version control, capturing screenshots or logs from each entry point, and retaining acknowledgement records in the audit trail.

How DeployOpen prepares AC-8 banner evidence

DeployOpen prepares the systems, banner configuration and evidence that an assessor reviews for AC-8 System use notification, inside the client's own infrastructure. The organization owns the wording and the control decision, and only an independent assessor can report on whether AC-8 is met.

How we scope

The written scope lists each system, login path and interface where a use notice must appear before access is granted.
Scope records whether any system is publicly accessible, since those systems follow separate notification conditions.
Scope names the organization-defined parameter values the client must confirm for AC-8 before build work starts.

How we build

We configure the logon notice on each in-scope platform so it displays before authentication completes.
We set the banner to remain on screen until the user acknowledges it, and test that the acknowledgement is recorded.
We check the banner text against the elements the control requires, using the client's approved wording.

How we hand over

We deliver banner configuration files, screenshots and test records mapped to the AC-8 determination statements.
We document the approval trail for the banner wording so an assessor can examine who signed off the text.
We hand over acknowledgement logs and audit records showing banner display and user consent for each in-scope system.

How we support

Ongoing support is available as a retainer for banner changes, platform upgrades and periodic re-testing.
We can rerun banner tests after any change to login pages, identity providers or publicly accessible content.
Clients ask for a fixed-scope quote covering the systems, testing and documents agreed in writing before work starts.

AC-8 System use notification