AC-14 Permitted actions without identification: requirements and evidence

AC-14 permitted actions without identification: what the requirement asks

AC-14 requires you to identify the user actions your system allows without identification or authentication, tie each one to your mission and business functions, and document and justify those actions in the system security plan. If an assessor or contract asks for AC-14, the practical starting point is a written list of every action a person can take before logging in, with a reason for each. For a public website, that list might include reading published pages and downloading public documents. Anything not on the list is expected to require identification and authentication under the access control and identification families. The control is about the exceptions, so the list should be short and explicit.

The risk is that anonymous functionality accumulates without anyone deciding to allow it. A login page may expose a search endpoint, an API route may answer unauthenticated requests for convenience, or a status page may reveal more than its purpose needs. These paths are easy to skip because nobody set out to create them, and the team that built the system may assume that anything reachable without a password is intended to be. AC-14 forces that assumption into a documented decision. It stands alone in the catalog because its only numbered enhancement, AC-14(1), is withdrawn in Release 5.2.0, so the assessment rests entirely on the base control and its organization-defined parameter, which you must set for your system.

SP 800-53B selects AC-14 for the low, moderate and high baselines but not for the privacy baseline, so most systems in scope for a federal or contractual assessment will need it. Confirm your system's baseline in the security categorization and the SP 800-53B profile before you scope the work. For the assessment, expect the assessor to compare your documented list with the system's actual behavior, using the list of permitted actions and audit records as the primary evidence. Before the interview, check each listed action in a clean browser session and against the API gateway, and confirm the security plan states the justification for each one.

Which systems and actions AC-14 applies to in your environment

AC-14 is short, but its scope decides how much work it creates. The decisions below cover which systems carry the control, which interfaces may be reached anonymously, and where anonymous access must be ruled out, so the list of permitted actions stays small and defensible.

Confirm the baseline before listing actions

AC-14 is selected in the low, moderate and high baselines of SP 800-53B Release 5.2.0 but not in the privacy baseline. A system categorized as low still needs the control, so the anonymous-action list must exist for every in-scope system. Check the impact level in the security categorization, then confirm whether the system also falls under privacy baseline obligations, which do not add AC-14 but do change what data the anonymous interfaces may expose.

Public websites and status pages

A public marketing site, documentation portal or status page is the usual example of an anonymous action, such as viewing published content. Decide which pages are intentionally public and which pages only look public but load account data, internal links or draft material. Each permitted page should be named in the system security plan, with the reason it needs no identification, so an assessor can match the list to what the site actually serves.

Login pages and public APIs

Login pages, password reset forms, registration endpoints and public APIs are anonymous by design, but they are not harmless. Anonymous access to these interfaces is an action the list must name explicitly, for example submitting credentials, with the authentication control (IA-2) doing the work afterward. Confirm which API methods are open without a token, since read-only endpoints and write endpoints often carry different risks and different justifications.

Internal and partner systems with no anonymous path

Administrative consoles, internal business applications, partner data exchanges and any system holding nonpublic information should have no anonymous action at all. Record this as an explicit decision in the plan, and confirm that default pages, health endpoints and debugging interfaces do not answer unauthenticated requests. An anonymous path discovered in a partner integration is a finding even when the core application requires login.

Ownership of the anonymous action list

Someone accountable must own the list of anonymous actions and approve every change to it. In most organizations this is the system owner, with the information security function reviewing the rationale and the platform team maintaining the configuration. Ask who signs off on new public pages, who can add an unauthenticated route, and how removals are recorded, because assessors interview system administrators about this list and expect them to know it.

CDNs and third-party hosted content

Content delivered through a CDN, a hosted help desk or a third-party widget is still part of the system's public surface, even when the organization does not run those servers. Document which hosted components serve anonymous content, what the provider controls, and whether the provider's terms or configuration allow the organization to hold them to the same list. Where a provider's controls cannot be confirmed, record that gap in the plan rather than assuming it is covered.

How an assessor tests permitted actions without identification

This table walks through the three determination statements in the SP 800-53A procedure for AC-14, the examine and interview methods that support them, and the evidence an assessor typically requests. Read it as the assessor's guide to what gets tested, then compare it against your own list of anonymous actions and the rationale in your system security plan.

Assessment element	Test approach	Evidence requested	Common finding
Determination statement 1: user actions without identification or authentication are identified	Examine the list of user actions that can be performed without identification or authentication, then confirm the list matches the system's actual public-facing functions.	The written list of permitted anonymous actions, with the system's endpoint or page inventory used to build it.	An anonymous endpoint, API route or form exists in production that does not appear on the list.
Determination statement 2: the actions are consistent with mission and business functions	Compare each listed action against the organization's stated mission and business functions and ask the owner why the action must stay open.	Mission or business function references, and the owner's sign-off on each action's purpose.	Actions are listed with no business reason, or a listed action serves an internal function that should require authentication.
Determination statement 3: the actions are documented and justified in the system security plan	Examine the system security plan for AC-14 and check that the justification for each action is written there and matches the list.	The system security plan section for AC-14, the list of actions and its version history.	The plan states that only public pages are anonymous, but observed behavior shows additional anonymous actions, or the justification is generic.
Examine: list of user actions that can be performed without identification or authentication	Walk through the list action by action and test each one from an unauthenticated session to confirm it behaves as documented.	The list itself, plus test results or screenshots from an unauthenticated browser or client session.	Actions that the list describes as read-only can also submit data or trigger changes when called unauthenticated.
Examine: system audit records	Review audit records for anonymous activity to see whether the logged actions match the permitted list and whether unexpected anonymous activity appears.	Audit log extracts covering unauthenticated requests over a period the assessor selects.	Audit records show unauthenticated requests to actions that are not on the list, or anonymous activity is not logged at all.
Interview: system and network administrators	Ask administrators how anonymous access is configured, who changes it, and what happens when a new public feature is added.	Notes of the interview and any configuration records the administrators point to during it.	Administrators describe anonymous access differently from the plan, or no one can say who approved the current list.
Approval of the permitted list	Ask who approved the list and when, then look for a record that shows the approval and any later changes.	Approval record, change ticket or meeting minutes that name the approver and date.	No record exists of who approved the list, or the list was changed without updating the plan.
Reliance on this procedure	Use the procedure as the assessor's method for planning tests, then prepare evidence that answers each element above.	Evidence mapped to each determination statement, so the reader can show where each element is met.	The organization treats the procedure as a fixed checklist and does not test its own configuration against it.

Implementing AC-14 step by step, with the output of each step

This sequence turns AC-14 into a documented, approved and reviewable position: a verified list of the few actions a system allows without logon, each with a stated mission reason, recorded in the system security plan where assessors can test it.

Confirm the system baseline and boundary
The system owner confirms the system name, boundary, impact level and the SP 800-53B baseline that applies, since AC-14 is selected in the low, moderate and high baselines but not the privacy baseline. Confirm the boundary includes every internet-facing component, including web front ends, APIs, load balancers and any identity or support services. The output is a short baseline record that states the impact level, the selected baseline and the component list used in the later steps. The check is that the system owner and security lead sign off that the boundary matches the current architecture diagram.
Inventory every unauthenticated entry point
Security engineers enumerate every route, page, API method, health endpoint, static asset path and internal service that responds without a logon. Use the web server and API gateway configuration, the application's authorization rules and a request test from an unauthenticated client to confirm actual behavior rather than documented intent. Record each entry with its path or method, the component that serves it and the data it returns. The output is an anonymous action inventory, and it is complete when a second engineer can reproduce the results from the same test script.
Decide permitted actions with the mission owner
The mission or business owner reviews the inventory line by line and decides which actions must remain available without identification or authentication, such as reading a public website or retrieving a published status page. Each approved action needs a written reason tied to the mission or business function, and each action that does not have a clear reason is removed or moved behind authentication. The output is an approved list of permitted actions with a rationale column and the name of the decision owner. The check is that every entry in the approved list maps to an inventory line and no inventory line is left undecided.
Set the organization-defined parameter value
AC-14 has one organization-defined parameter, which the organization fills in when it implements the control. The security lead records the value that defines the permitted actions in the terms the assessor will read, and confirms it matches the approved list exactly. Confirm the value against the current AC-14 entry in the NIST CPRT or the OSCAL catalog, since the parameter wording is what the assessment objects refer to. The output is a parameter record in the control implementation statement. The check is that the parameter value and the approved list say the same thing.
Align the output with AC-8, IA-2 and PL-2
Three related controls share this boundary. AC-8 requires the system use notification where it applies, so the team confirms which permitted pages display the notice and that the notice text matches the system's approved wording. IA-2 governs identification and authentication, so every action not on the approved list must require authentication, and the team tests that the authentication path does not expose extra actions. PL-2 is the system security plan that holds the justification, so the approved list, the parameter value and the AC-8 and IA-2 references must use identical identifiers. The output is a cross-reference table, and the check is that a test of each entry point produces the behavior the table predicts.
Write the justification into the system security plan
The security lead drafts the AC-14 section of the system security plan with the approved actions, the mission rationale for each, the parameter value, the implementation description and references to the inventory and the cross-reference table. The system owner and the authorizing official or designated approver sign the section, and the record includes the approval date and the next review date. The output is the signed AC-14 section and a version-controlled record of its approval. Wiki and document platforms such as XWiki keep page version history and let reviewers compare versions, which supports this record. The check is that the approver can trace each approved action to its rationale and test result.
Schedule review and retain the review record
Set a recurring review of the approved list and the inventory, and trigger an earlier review after any change to routes, public content, authentication or the system boundary. Reviewers repeat the unauthenticated request tests and compare results with the approved list, then record any removed or added actions. The output is a dated review record with the test evidence, the reviewer and the decision. Confirm with the system owner and the assessment team how often the review must occur for the system's authorization, since the control text does not set a fixed interval. Where access to the documentation is governed by roles, a tool such as BookStack can scope edit and view rights per shelf, book or page for the owners involved.

Evidence that passes an AC-14 assessment

An assessor testing AC-14 wants to see one consistent story: the list of anonymous actions, the justification for each, the configuration that enforces the list, and proof that the list is reviewed and changed under control. Each artifact below should point to the others, so the same list can be traced from the security plan to the system and back.

Approved list of anonymous actions

This is the central artifact: a written list of every user action the system allows without identification or authentication, such as viewing a public website's pages. Each entry should name an accountable owner and the date the list was approved, with the approver recorded. Assessors compare this list against the system's actual behavior, so keep it specific enough to test, for example by URL path or function rather than by a general phrase like "public content." Confirm the list matches the organization-defined values your AC-14 implementation uses.

Security plan justification for each action

AC-14 requires the anonymous actions to be justified in the system security plan, tied to the mission and business functions the system supports. For every listed action, the plan should state why it must run without identification and what data it exposes. Assessors look for a rationale that would hold up if a reader asked why a login was not required. Reference the related controls in the plan, including AC-8, IA-2 and PL-2, where the design depends on them.

Access configuration enforcing the list

Exported route definitions, web server or proxy rules, API gateway policies and access control settings show whether the system enforces the list. Assessors check that every unauthenticated path is on the approved list and that no other path is reachable without a login. Capture these configurations from the running environment, not only from the deployment templates, and store them under version control so each export can be dated and compared with the approved list.

Sample logs matching the list

Audit or access log extracts show anonymous requests arriving at the system and map them to approved actions. An assessor looks for unauthenticated requests that fall outside the list, which indicates a configuration gap, and for approved actions that never appear, which may indicate the list describes behavior the system no longer has. Sample logs across more than one period and confirm that the logging itself is enabled and protected, since the sample is only as good as the record behind it.

Change records for list additions

Every addition or removal to the anonymous action list should pass through the same change process as other system changes, with a request, impact analysis, approval and a recorded implementation date. Assessors trace a sample of changes back to the configuration change that made them and check that the security plan was updated at the same time. Tie list changes to the change record rather than to informal email approvals, so the history can be audited.

Periodic review record

Review records show that someone with authority checked the list, the justifications and the configuration at a defined interval, and recorded what they found and what they changed. Set and document the review frequency yourself based on how often the system changes and what your authorization requires, then keep each review dated, signed by the reviewer and linked to any follow-up tickets. Version history in your documentation platform helps show what changed between reviews, and assessors often ask for the previous version alongside the current one.

What meeting AC-14 costs in money and effort

This table lists the cost components of documenting and evidencing AC-14, who carries each one, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for scoping a fixed-scope quote, since NIST does not estimate compliance costs and no price is supplied for this control.

Cost component	Who carries it	One-time or recurring	What drives it up or down
Deciding the permitted list of anonymous actions	Mission owner and security lead	One-time, then recurring on change	Up with the number of public interfaces and mission functions; down when the list is limited to a few read-only actions such as viewing a public website
Inventorying and configuring anonymous routes	Platform engineering and system administrators	One-time, then recurring on change	Up with the number of systems and gateways that accept unauthenticated requests; down when a single standard public-content pattern serves all anonymous traffic
Writing the SSP section and rationale	Security engineer or compliance lead	One-time, then recurring on review	Up with the number of systems covered by the low, moderate or high baseline; down when one shared template is reused across systems
Reviewing logs and audit records as evidence	Security operations staff	Recurring	Up with traffic volume and the frequency of assessor requests; down when logging is centralized and queries are saved for reuse
External review of the list before assessment	Independent assessor or outside consultant, if engaged	Optional, per assessment cycle	Up when the list is large or contested; down when the rationale is written against the mission before the assessment begins
Keeping the SSP and permitted list current	Document owner and change board	Recurring	Up with frequent changes to public-facing content or APIs; down when changes pass through a defined review step
Wiki and documentation tooling	Organization's own staff (self-hosted tools carry no license fee)	One-time setup, then recurring upkeep	Up with hosting, patching and access administration; down when version history already records who changed the list and when
Fixed-scope quote from an implementation partner	Organization, paid to the partner for agreed deliverables	One-time for the engagement	Up with the number of systems, interfaces and evidence sets in scope; ask whether the quote covers list design, configuration, SSP text, evidence packaging and retesting

Who owns AC-14: your team, a partner and the auditor

Your organization owns AC-14 from start to finish. The system owner and mission owner decide which user actions may be performed without identification or authentication, because those decisions follow from the system's mission and business functions. Security reviews the proposed list and the stated justification, and engineering enforces the approved list in the platform. Your administrators are the people an assessor will interview about how the list is applied in practice, so they need to understand it.

Decision ownership: The system owner and mission owner name each permitted action and state why it serves the mission.
Security approval: The security team checks that every permitted action is narrow, documented and consistent with the risk decisions for the system.
Engineering enforcement: Platform and application teams make sure only the approved routes respond without a session.
Documentation: Your team keeps the approved list and its rationale in the system security plan and updates both when the system changes.
Interview readiness: Administrators can explain the list, why each item exists and how changes are approved.

Before any outside help starts, confirm which of these owners are named in your own governance documents and who signs off changes to the list.

Which open-source tools can hold AC-14 evidence

A self-hosted documentation platform can keep the list of anonymous actions and its SSP section under version control, which is the part of AC-14 evidence most often lost in practice. XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page with what changed, when and by whom, and lets reviewers compare any two versions and roll back to an earlier one. That history answers an assessor's question about when the approved list changed and who approved the change, provided the approval itself is recorded in the page or in a linked decision record. Confirm that the version and any extensions you plan to run are covered by the licenses your organization accepts, since the license applies to each component you deploy.

BookStack, licensed under MIT, assigns abilities through roles and allows permissions to be overridden per role at the shelf, book, chapter or page level. That lets you restrict editing of the page that holds the approved anonymous action list to a small group of security and system owners, while the rest of the SSP stays open to the wider team. Check the current permission model against your version before relying on it, and test that a non-approver really cannot edit the list. Neither tool enforces access on public routes. Whether a visitor can reach a public website without authenticating is decided by the web application and its access configuration, and you need to verify that separately.

Before treating either platform as the system of record for the SSP, confirm three things with the vendor, your assessor and your own environment: whether the tool's audit history meets your retention and integrity expectations, whether the SSP needs export in a format your authorizing official or assessor accepts, and whether the platform's own security configuration is documented as part of the system boundary. A wiki can hold the rationale for each anonymous action, but the decision to allow it remains the organization's, and the independent assessor will test that the recorded decision matches the running system.

Where AC-14 implementations usually fall short

AC-14 is a short control on paper, but its gaps tend to hide in places the list never covered: forgotten API routes, general justifications, and documents that drift from the live system. The cards below pair each gap with a closing action an assessor can verify against the system security plan and the running configuration.

Anonymous routes nobody listed

Teams often document the public website but forget unauthenticated API endpoints, health checks, admin login pages or debug paths that answer without a session. An assessor who samples the running system will find them and ask why they are missing from the list of actions permitted without identification or authentication. Close it by enumerating every route that returns a response without a credential, using the gateway configuration and a scan from outside the boundary, and reconciling the result against the list.

Justifications written as one statement

A single sentence such as "public content is available to all" is often used to cover every anonymous action. AC-14 asks for the actions to be documented and justified in the security plan, so each action needs its own reason tied to the mission or business function it serves. Close it by writing one justification line per action, naming the function it supports and the owner who accepted the risk of allowing it.

List never approved by the mission owner

Security or platform teams sometimes compile the anonymous action list on their own and file it without the business owner's sign-off. The control ties permitted actions to mission and business functions, so a list the owner has never seen does not show that the actions are consistent with them. Close it by obtaining a dated written approval from the mission owner for the exact list, and storing it with the plan.

SSP section that disagrees with configuration

The security plan may describe an anonymous action set that differs from what the load balancer, web server or identity provider actually allows. Assessors compare the document with the system, and a mismatch is treated as a finding even when the intent was sound. Close it by tracing each listed action to the specific configuration key, rule or route that permits it, and recording the file and version checked in the plan.

No review after feature releases

A new release, a marketing form or a diagnostic endpoint can quietly add an action that works without login. Without a review step tied to change management, the list stops matching the system after the first few releases. Close it by adding a checklist item to the release process that requires the anonymous action list to be confirmed or updated before each production change is approved.

Public site treated as out of scope

Teams sometimes exclude a marketing site from the boundary because it is public, even when it runs on the same platform, cluster or content store as internal systems. An anonymous path into shared infrastructure can then reach systems that do require authentication. Close it by including the public site in the system boundary or documenting the shared components and the controls that separate them, and confirming that the anonymous actions on it appear in the list.

AC-14 questions buyers ask before hiring help

How much effort does AC-14 take for a small public website compared with a large platform?

For a small public website, AC-14 is usually a short exercise: the organization lists the few actions a visitor can take without logging in, such as reading pages, and writes down why those actions serve the business. For a large platform, the work grows with the number of anonymous surfaces, including public APIs, sign-up flows, password reset pages, status endpoints and content delivery paths. Each surface must be identified, justified and kept consistent with the security plan. The control text asks for the list and the rationale, so the effort is mostly analysis and documentation, with technical checks added where anonymous endpoints exist. Confirm the number of anonymous entry points in your own environment before estimating effort.

Can our organization implement AC-14 in-house without outside help?

Yes, in most cases. AC-14 is a documentation and justification control, so an organization with a system security plan owner and someone who knows the system's public interfaces can complete it internally. Outside help is most useful when the anonymous surfaces are spread across several cloud accounts, when the system has many public APIs, or when the team has no one to review the rationale against mission needs. Your organization owns the decision about which actions are permitted without identification or authentication. A partner can prepare the inventory, configuration evidence and documentation, but the decision and the control remain with your organization.

What does AC-14 need from our decision makers, engineers and document owners?

AC-14 needs three groups to work together. Decision makers, such as the system owner and business sponsor, must confirm which anonymous actions support the mission and accept the risk of leaving them open. Engineers must produce an accurate list of anonymous endpoints, pages and functions, and show how each is reached and what it exposes. Document owners must record the list and the rationale in the system security plan and keep it aligned with the access control policy and the identification and authentication controls. Ask your team to name one owner for each group before work starts, so approvals and evidence do not stall at the end of the project.

How long does AC-14 work take, and what sets the timing?

The timing depends mainly on the number of anonymous surfaces, how many systems share them, and how quickly decision makers approve the rationale. A system with one public website and a few documented pages moves much faster than a platform with many public interfaces across several environments. DeployOpen does not set a fixed duration for this control. A fixed-scope written plan sets the timeline: it lists the systems in scope, the deliverables and the review points before work starts. Ask for the scope, deliverables and schedule in writing, and check whether the schedule depends on approvals from your side.

Can a consulting partner sign off that our AC-14 control is met?

No. A partner can prepare the list of anonymous actions, the configuration evidence and the documentation, but it cannot sign off that the control is met. Only an independent assessor, auditor or certification body issues assessment results or reports. Your organization owns its controls and the decisions behind them. When you plan an assessment, ask your assessor which evidence they expect for AC-14, including the list of user actions and system audit records, and confirm with them how they want the rationale presented. This keeps the roles clear for your authorizing official or certifying body.

How should we ask a partner for a quote on AC-14 work?

Ask for a quote built on a written scope rather than a general estimate. DeployOpen does not publish a price list, and a quote follows from the scope agreed in writing. Your request should name the systems in scope, the number of anonymous surfaces you know about, the documents to be updated, the evidence to be produced, and who approves each step. Ask the provider to separate one-time work, such as the initial inventory and documentation, from recurring work, such as periodic review of the anonymous action list when the system changes. Also ask what your organization must provide, including access, staff time and reviewers.

How DeployOpen scopes and prepares AC-14 evidence

DeployOpen works on AC-14 as part of a written, fixed-scope engagement inside your own infrastructure. We help you identify the few unauthenticated actions your system allows, document the rationale in the system security plan, and prepare the evidence an independent assessor will examine. Your organization owns the decisions and the control; an independent assessor issues any assessment result.

How we scope

We confirm which systems fall within the AC-14 scope and their impact baseline before work starts.
We list every page, endpoint and service reachable without logon, so the action inventory is complete.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We configure the self-hosted platform so only the agreed unauthenticated actions are reachable.
We test anonymous access paths against the documented list and record any unexpected exposure.
We set up audit logging so anonymous access attempts and changes to public content can be reviewed.

How we hand over

We deliver the action inventory and the justification text for the system security plan.
We provide version-controlled documentation showing who approved each permitted action and when.
We hand over test records and configuration evidence mapped to the AC-14 determination statements.

How we support

Ongoing support is available as a retainer to review the permitted action list after platform changes.
We can re-test anonymous access paths when new public pages or APIs are released.
Your organization confirms the final control wording and assessment conclusions with its independent assessor.