Permitted Actions Without Identification or Authentication

To meet the permitted actions without identification or authentication requirement, you must explicitly define which actions (if any) an unauthenticated user can take in your system, document the business justification, and implement technical controls that restrict everything else. Your goal is a short, approved “anonymous actions allowlist” that is enforced, tested, and auditable. (NIST Special Publication 800-53 Revision 5)

Key takeaways:

• Create an explicit allowlist of unauthenticated actions; “none” is an acceptable outcome if it fits mission needs. (NIST Special Publication 800-53 Revision 5)
• Enforce the allowlist technically (routing, APIs, WAF, IAM defaults) and verify it through testing and evidence. (NIST Special Publication 800-53 Revision 5)
• Auditors look for alignment between documentation, system behavior, and user experience across web, API, and support channels. (NIST Special Publication 800-53 Revision 5)

AC-14 is easy to misunderstand because it does not tell you to “allow anonymous access.” It tells you to decide, deliberately, what actions can happen before a user proves who they are, and to keep that decision consistent with mission and business functions. (NIST Special Publication 800-53 Revision 5)

For FedRAMP Moderate environments, this control often shows up in practical places: public landing pages, status pages, documentation portals, download endpoints, password reset flows, “contact us” forms, product trials, API health checks, and inbound integrations that start “unauthenticated” and only later bind to an identity. Each of those entry points can quietly become a path to sensitive data exposure, account enumeration, or service abuse if you do not set boundaries and implement them consistently.

Operationalizing AC-14 means treating unauthenticated capabilities as a governed surface area. You define the allowlist, map each allowed action to system components, harden the controls that make the allowlist real, then retain evidence that proves unauthenticated users cannot do anything else. The fastest path is to centralize the decision, bake it into architecture patterns, and test it like any other security requirement. (NIST Special Publication 800-53 Revision 5)

Regulatory text

Requirement (AC-14): “Identify organization-defined user actions that can be performed on the system without identification or authentication consistent with organizational mission and business functions.” (NIST Special Publication 800-53 Revision 5)

What the operator must do:
You must (1) identify the specific actions your system permits before identification or authentication, (2) ensure those actions are consistent with mission/business needs, and (3) make that identification concrete enough that engineering can enforce it and assessors can test it. The control does not require that you permit unauthenticated actions; it requires that you define them. (NIST Special Publication 800-53 Revision 5)

Plain-English interpretation

AC-14 requires an explicit, documented decision about what an anonymous user can do. If you do allow something, keep it narrow, low-risk, and measurable. If you allow nothing, document that and make sure the system actually behaves that way.

Think “allowlist,” not “best effort.” If an endpoint, UI path, or integration can be hit without a valid identity, it is an unauthenticated action, even if it feels harmless (for example, “check order status,” “validate email,” “download client,” or “submit support ticket”).

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers operating in a FedRAMP Moderate context. (NIST Special Publication 800-53 Revision 5)
• Federal Agencies operating systems under the same baseline. (NIST Special Publication 800-53 Revision 5)

Operational contexts where AC-14 is commonly assessed:

• Public web properties tied to the boundary (marketing site hosted inside boundary, doc site, status page).
• Any application “pre-auth” flows: login page, SSO initiation, password reset, email verification, invite acceptance.
• Public APIs: health endpoints, token endpoints, API discovery, documentation, OpenAPI specs.
• Upload/download and link-sharing features: presigned URLs, public share links, “view-only” links.
• Support and onboarding: ticket submission, chat widgets, trial request forms, knowledge base search.
• Third-party entry points: inbound webhooks, connectors, and integrations that can trigger processing prior to user authentication.

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

1) Build the “unauthenticated actions inventory”

Create a list of every path an unauthenticated user can reach:

• Web routes (including static assets served from the same origin).
• API endpoints (REST/GraphQL), including versioned paths and “internal” endpoints exposed through gateways.
• Authentication-adjacent services (IdP callbacks, OAuth/OIDC endpoints, SAML ACS endpoints).
• Public object storage access patterns (CDN, bucket policies, signed URL generators).
• Embedded third-party widgets that proxy into your backend.

Practical tip: do not rely on app team memory. Pull from API gateway route tables, WAF logs, ingress controller configs, and service mesh policies.

2) Define an allowlist with business justification

For each unauthenticated action you intend to permit, document:

• Action name (plain language).
• Component(s) involved (service, route, endpoint).
• Data touched (none, metadata, public content, user-provided content).
• Risk notes (abuse, enumeration, injection, scraping).
• Business justification (what mission or function requires it). (NIST Special Publication 800-53 Revision 5)
• Decision: allowed / disallowed.

If you choose “none,” write it explicitly: “No user actions are permitted without identification or authentication,” then list exceptions if any exist (for example, “serving a static login page” is still an unauthenticated action, but it should not process sensitive data).

3) Translate the allowlist into enforceable technical rules

Make the allowlist real across layers:

At the edge (preferred):

• API gateway: default-deny routes; explicit unauthenticated route group.
• WAF/CDN: restrict methods (GET only where feasible), apply bot controls, block high-risk patterns on public endpoints.
• Rate limiting and request size limits on any anonymous POST/PUT endpoints (for example, contact forms).

In the app:

• Require authentication by default in middleware; carve out explicit exceptions mapped to the allowlist.
• Prevent data leakage in error messages (avoid “user not found” style responses that enable enumeration).
• Enforce CSRF protections where browser sessions exist, even for pre-auth flows.

In storage and messaging:

• Ensure public objects truly contain public content only.
• Avoid unauthenticated triggers that enqueue privileged jobs.

4) Add guardrails for the allowed anonymous actions

For each allowed action, implement safeguards proportionate to abuse risk:

• Input validation and content-type constraints for forms and uploads.
• CAPTCHA or equivalent friction where abuse is likely (document why you chose it).
• Logging and alerting for spikes, repeated failures, and suspicious patterns.
• Clear separation of “public content” from tenant or customer content.

5) Test like an assessor

Prove that unauthenticated users can only do what you said:

• Perform route discovery tests for unauthenticated sessions.
• Attempt method switching (GET to POST), parameter tampering, and ID guessing.
• Validate that unauthenticated requests cannot access tenant-specific resources.
• Confirm consistent behavior across environments and alternate hostnames.

6) Operationalize governance (change control)

Unauthenticated surface area changes all the time. Put a gate in place:

• New public endpoints require security review and an update to the AC-14 allowlist.
• Release checklists include a question: “Does this change add or modify unauthenticated actions?”
• Periodic review aligned to your SDLC and architecture review cadence.

Where Daydream fits naturally: teams lose time chasing where unauthenticated access exists across services and third parties. A control-centric system like Daydream helps you keep the allowlist, owners, test evidence, and change approvals in one place so AC-14 stays current through releases.

Required evidence and artifacts to retain

Keep artifacts that connect policy intent to system behavior:

1. AC-14 “Permitted Actions Without Identification or Authentication” statement (one page is enough): allowlist, business rationale, scope notes. (NIST Special Publication 800-53 Revision 5)
2. Architecture evidence: gateway route tables, ingress configs, WAF policies showing default-deny with explicit exceptions.
3. Application configuration: middleware rules, authorization policy snippets, feature flags that control anonymous paths.
4. Test evidence: dated screenshots, curl commands, automated test outputs demonstrating anonymous access is restricted to the allowlist.
5. Change approvals: tickets/PRs showing review and approval when anonymous actions were added or modified.
6. Logging evidence: sample logs for unauthenticated events and any alert rules tied to abuse patterns.

Common exam/audit questions and hangups

Expect assessors to ask:

• “Show me the list of actions allowed without authentication.” (NIST Special Publication 800-53 Revision 5)
• “Where is it implemented in the system?” (point to gateway + app middleware)
• “How do you ensure developers don’t add new anonymous endpoints?” (SDLC gate)
• “Do public endpoints process or return customer data?” (data-flow answer)
• “How do you prevent account enumeration in password reset and login?” (design + test proof)
• “Are status pages, docs, and CDNs inside the authorization boundary?” (scope clarity)

Hangups that slow teams down:

• Treating “static pages” as exempt and forgetting the backend calls they trigger.
• Assuming SSO initiation endpoints are “safe” without validating redirect URIs and error handling.
• Missing alternate interfaces (mobile API base URL, legacy endpoints, admin subdomains).

Frequent implementation mistakes and how to avoid them

Mistake: “We don’t allow anonymous access” with no proof.
Fix: document “none” as the allowlist decision and show default-deny configs and test results.

Mistake: Allowing unauthenticated endpoints to return detailed errors.
Fix: standardize generic responses and log details server-side.

Mistake: Pre-auth endpoints share code paths with authenticated operations.
Fix: split handlers and enforce strict checks before calling privileged services.

Mistake: Public object storage contains tenant artifacts.
Fix: separate buckets/accounts, add scanning, and require signed access for anything non-public.

Mistake: No owner for the allowlist.
Fix: assign a single control owner (often AppSec or GRC) with engineering accountable for implementation.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat risk context as a security and audit exposure discussion rather than enforcement-driven precedent.

Risk implications are straightforward: the unauthenticated surface area is where you are most exposed to opportunistic abuse (scraping, credential stuffing enablers, form spam, denial of service) and accidental data leakage (public endpoints returning sensitive metadata). AC-14 forces you to define and constrain this surface area so you can defend it and prove it. (NIST Special Publication 800-53 Revision 5)

A practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Assign a control owner and confirm system boundary scope.
• Inventory unauthenticated routes/endpoints from gateways, WAF, and code.
• Draft the AC-14 allowlist with business justifications and owners. (NIST Special Publication 800-53 Revision 5)
• Implement quick wins: default-deny in gateways where missing; remove accidental public endpoints.

By 60 days (enforce and test)

• Map each allowed action to an enforcement point (gateway policy + app middleware).
• Add abuse controls to permitted anonymous actions (rate limits, input constraints, logging).
• Create repeatable test scripts (manual or automated) and store evidence outputs.
• Add SDLC change gates for new/modified anonymous actions.

By 90 days (operationalize and make it audit-ready)

• Run a full control walk-through: document to config to observed behavior.
• Complete evidence pack: allowlist, configs, test results, approvals, logs.
• Establish a recurring review tied to architecture review or release governance.
• Track exceptions formally, with expiry criteria and compensating controls.

Frequently Asked Questions

Do we have to allow any actions without authentication to satisfy AC-14?

No. AC-14 requires that you identify which actions can be performed without identification or authentication; “none” can be a valid identified set if it matches mission and business needs. (NIST Special Publication 800-53 Revision 5)

Are “view the login page” and “load static assets” considered permitted actions?

Yes, they are actions performed without authentication, even if they are low risk. Document them in scope terms and ensure they do not trigger backend data access beyond what you intend.

How should we handle password reset flows under this requirement?

Treat password reset as a permitted unauthenticated action with strict constraints: generic responses, anti-enumeration behavior, throttling, and logging. Document exactly which endpoints are allowed and what they return.

What evidence is strongest for auditors?

A short allowlist document plus technical proof: gateway/ingress configs showing default-deny, app middleware exceptions aligned to the allowlist, and test outputs showing unauthenticated requests fail for everything else. (NIST Special Publication 800-53 Revision 5)

We have a public status page. Does AC-14 apply?

If the status page is part of the in-scope system boundary, then yes: it is an unauthenticated action and must be covered by your allowlist decision. If it is out of scope, document that boundary decision clearly.

How do we keep this current as teams ship new endpoints?

Add a release or architecture gate that flags new public routes and requires an update to the allowlist and test suite before deployment. A centralized system of record (for example, Daydream) helps keep approvals and evidence tied to the control.