AC-14: Permitted Actions Without Identification or Authentication

AC-14 requires you to explicitly identify which actions your system permits without identification or authentication, and to ensure those actions align with mission and business needs. To operationalize it, build an “unauthenticated actions allowlist,” implement technical controls that enforce it (and block everything else), and retain evidence that those exceptions are reviewed, approved, and tested. ¹

Key takeaways:

• Treat AC-14 as an allowlist requirement: name the unauthenticated actions, justify them, and enforce them. ¹
• Most audit failures come from “implicit” unauthenticated access (default pages, health endpoints, metadata, error messages) that nobody documented. ¹
• Your strongest evidence is a system-specific inventory of unauthenticated actions mapped to routes/services plus test results proving authentication is required everywhere else. ¹

AC-14: permitted actions without identification or authentication requirement is about controlling the exceptions to your normal access control model. Every production environment ends up with some: a public marketing site, a status page, a login screen, a password reset start page, a software update repository, or a pre-auth API used for device bootstrap. AC-14 forces you to name those exceptions on purpose, rather than discovering them during an incident or assessment.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate AC-14 into a short, assessable set of deliverables: (1) a documented list of permitted unauthenticated actions for each system boundary, (2) business/mission justification and explicit approval, (3) technical enforcement and monitoring, and (4) recurring review. This control pairs naturally with secure design and application security practices, but the compliance “win” comes from making the exceptions explicit, limited, and provably enforced. ²

Regulatory text

Requirement (excerpt): “Identify {{ insert: param, ac-14_odp }} that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and” ¹

What the operator must do:
You must produce an explicit, system-specific identification of actions that do not require a user or device to authenticate, and you must show that those actions are consistent with your organization’s mission and business functions. Practically, that means: define what “pre-auth” can do, document it, get it approved, implement controls so only those actions are possible without authentication, and periodically re-validate the list. ¹

Plain-English interpretation

AC-14 asks one question: “What can an unauthenticated party do in this system?” Your answer must be deliberate and constrained.

Think in terms of actions, not just “pages.” Examples of actions include:

• View a public page (read-only)
• Submit a contact form (write)
• Start a password reset flow (write)
• Call an API endpoint that returns non-sensitive metadata (read)
• Pull a software update package (read)

AC-14 does not say you must have zero unauthenticated actions. It says you must identify them and keep them aligned to business need. If an endpoint exists only because it was convenient for engineering, it usually does not survive AC-14 scrutiny. ¹

Who it applies to (entity and operational context)

AC-14 applies to:

• Federal information systems and programs implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or used for authorization. ²

Operationally, it matters most for:

• Internet-facing applications (web apps, customer portals, SaaS front doors)
• APIs and microservices (especially “public” routes and shared gateways)
• Remote access and device enrollment (bootstrap, provisioning, MDM)
• Cloud control planes and metadata surfaces (where misconfigurations create unintended pre-auth access)
• Third-party integrated services (support portals, status pages, forms, CDN buckets) where your system boundary includes externally hosted components

If you have multiple environments, define AC-14 for the production boundary first, then replicate to staging/dev with justified differences.

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

Step 1: Define the system boundary and the “no-auth” definition

1. Identify the system boundary you are assessing (application, platform, enclave, API suite).
2. Define what counts as “without identification or authentication” in your environment:
   • No session
   • No API key / client cert
   • No SSO token
   • No device identity
3. Decide whether “soft identity” signals (IP allowlists, CAPTCHA, rate limiting) count as authentication. Document your stance and apply it consistently.

Deliverable: AC-14 scope statement for the system. ¹

Step 2: Build the unauthenticated actions allowlist (the core AC-14 artifact)

Create an inventory that lists every permitted unauthenticated action, with enough specificity that engineering can enforce it and an auditor can test it.

Minimum fields that work in practice:

• System / service name
• Action name (verb + object)
• Interface (UI route, API endpoint, protocol command)
• Method (GET/POST/etc. for web)
• Data touched (none, public content, account identifiers, telemetry)
• Business justification (mission/business function)
• Compensating controls (rate limits, WAF rules, bot controls, content-type restrictions)
• Owner (service owner) and approver (risk owner)
• Logging/monitoring hooks
• Review cadence trigger (release-based, quarterly, etc. as your policy dictates)

Deliverable: “Permitted Unauthenticated Actions Register” per system. ¹

Step 3: Enforce “deny by default” for everything else

Work with engineering to ensure the architecture enforces the allowlist:

• Centralize authentication at the edge (gateway/reverse proxy) where possible.
• Require explicit annotations/config for “public” routes.
• Block unauthenticated access by default for new endpoints.
• Add automated tests that fail builds when a new unauthenticated route appears.

For legacy apps, use compensating enforcement:

• Web server rules that require auth except for enumerated paths.
• API gateway route policies.
• Service mesh authn/authz policies.

Deliverable: Technical enforcement configuration (gateway policy, web server config, service annotations) aligned to the allowlist. ²

Step 4: Validate with testing that mirrors how attackers and auditors probe

You need two kinds of evidence:

• Positive testing: pre-auth actions on the allowlist work as intended.
• Negative testing: everything not on the allowlist returns an auth challenge/deny response.

Practical tests to run and retain:

• Unauthenticated crawling of the app to enumerate reachable routes.
• API route discovery (at least for published APIs).
• Attempt access to common sensitive functions without auth (profile, admin, export, search, files).
• Confirm error messages do not expose sensitive data.

Deliverable: AC-14 test results (scan outputs, scripts, screenshots, logs) and remediation tickets for exceptions. ¹

Step 5: Put governance around changes (so AC-14 stays true)

AC-14 breaks during releases. Fix that with change controls:

• Add a release checklist item: “Any new unauthenticated actions? If yes, update register and obtain approval.”
• Require security review for any pre-auth route changes.
• Route alerts to the control owner when gateway config changes affect public routes.

Deliverable: Change-management hooks (ticket templates, CI checks, approval workflow) tied to the AC-14 register. ²

Step 6: Assign ownership and recurring evidence

Make AC-14 assessable:

• Control owner (often AppSec, IAM, or platform security)
• System owners responsible for route-level accuracy
• Evidence owner (GRC) to collect artifacts on a schedule

If you use Daydream to run control operations, map AC-14 to a named owner, a written procedure, and recurring evidence requests so audits do not depend on tribal knowledge. ¹

Required evidence and artifacts to retain

Keep artifacts system-by-system, not as a generic policy-only package.

Core evidence

• Permitted Unauthenticated Actions Register (current, approved) ¹
• Approval record for each permitted action (ticket, risk acceptance, design review notes) ¹
• Gateway/reverse proxy configuration showing allowlisted public routes ²
• Test evidence showing unauthenticated access is blocked where required ¹
• Log samples proving monitoring exists for pre-auth activity (request logs, WAF logs) ²

Supporting artifacts

• Data classification notes for any data exposed pre-auth
• Threat model excerpts for pre-auth workflows (password reset, signup, device bootstrap)
• Remediation tickets for any discovered accidental public endpoints

Common exam/audit questions and hangups

Auditors typically push on clarity and completeness:

1. “Show me what an unauthenticated user can do.” They want the allowlist and the enforcement point. ¹
2. “How do you know the list is complete?” Expect to show test methods (crawls, gateway route inventories) and change hooks. ²
3. “Who approved these exceptions?” They want risk ownership, not only engineering intent. ¹
4. “What happens when a new endpoint is added?” They want to see deny-by-default controls and CI/release checks. ²
5. “Do pre-auth endpoints expose identifiers?” Password reset and username discovery flows are common hangups because they can leak account existence.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails AC-14	How to avoid it
Documenting “public pages exist” without naming actions/endpoints	Not specific enough to test	Inventory routes/endpoints and methods in the register. 1
Relying on developers’ memory of what is public	Lists drift with releases	Generate route inventories from gateways and compare to the register. 2
Allowing broad unauthenticated read access “because it’s non-prod”	Non-prod often contains real data and pathways	Apply the same allowlist discipline, and document any environment differences explicitly.
Pre-auth endpoints return verbose errors	Can disclose internal state or identifiers	Standardize error handling and validate with negative tests.
No explicit approver	Exceptions look accidental	Require risk-owner approval for each pre-auth action. 1

Enforcement context and risk implications

No public enforcement case references were provided in the source catalog for this requirement, so this page does not list enforcement actions.

Risk-wise, AC-14 failures usually show up as:

• “Unintended public access” findings during penetration tests
• Excessive information disclosure from public endpoints
• Attack surface expansion from undocumented pre-auth services

From a governance standpoint, the risk is less about having a login page and more about having unknown unauthenticated capabilities.

Practical execution plan (30/60/90)

You asked for speed and operationalization; here is a plan structured as phases rather than dated promises.

First 30 days (Immediate containment and visibility)

• Name the control owner and evidence owner for AC-14. ¹
• Pick the highest-risk system boundary (internet-facing app/API) and create the first Permitted Unauthenticated Actions Register. ¹
• Pull a route inventory from your gateway/reverse proxy and reconcile it against what the team believes is public.
• Run a basic unauthenticated test pass and open remediation tickets for any surprises.

By 60 days (Enforcement and repeatability)

• Implement deny-by-default patterns for new endpoints (framework defaults, gateway policies).
• Add CI checks or release checklist gates tied to updates of the AC-14 register.
• Formalize approval workflow for any pre-auth action (security review + risk owner sign-off). ²

By 90 days (Scale across systems and harden evidence)

• Expand the register approach to remaining systems in scope.
• Standardize evidence capture (test outputs, config exports, approvals) so audits are routine.
• Put a recurring review on calendars and tie it to change events (major releases, new integrations, significant architecture changes).
• If you use Daydream, configure recurring evidence requests and a single source of truth for the register, approvals, and test artifacts to reduce audit scramble. ¹

Frequently Asked Questions

Does AC-14 mean we must eliminate all unauthenticated access?

No. AC-14 requires you to identify what is permitted without identification or authentication and keep it consistent with mission/business needs. The control is satisfied by a deliberate, enforced allowlist with approvals and evidence. ¹

What counts as an “action” for AC-14 in a web application?

Treat an action as a discrete capability: a route or endpoint with a method that reads or writes data or triggers a workflow. “Public site” is not granular enough; list the specific public routes and any pre-auth APIs behind them. ¹

Are health checks and status endpoints in scope?

Yes, if they can be called without authentication. Document them in the allowlist, constrain the response content, and add rate limiting/monitoring because these endpoints are commonly probed. ¹

How do we handle third-party hosted pages like a status page or support portal?

If the capability is part of your system boundary or customer experience, treat it as an unauthenticated action that must be identified and justified. Retain configuration and access evidence from the third party and link it to your register entry. ²

What evidence is most persuasive to auditors for AC-14?

A current, approved allowlist plus proof of enforcement at a central control point (gateway/proxy) and negative test results showing all other routes require authentication. Pair those with change-control records showing the list stays current. ¹

We have a legacy app with many public routes. How do we get compliant without rewriting it?

Start by inventorying and approving only what must remain public, then enforce exceptions at the edge (reverse proxy/gateway) while engineering reduces the public surface over time. Keep remediation tickets to show active risk reduction and control operation. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5