Quick-reference card
| Field | Value |
|---|---|
| Control ID | AC-14 |
| Control name | Permitted Actions Without Identification or Authentication |
| Framework | NIST SP 800-53, Revision 5 |
| Control family | Access Control |
| Baselines | LOW MODERATE HIGH |
| Relevance | Organization (First Party and Third Party) |
| Risk severity | Low |
What this control requires
AC-14 requires organizations to identify, document, and justify every action users can perform without first proving their identity. That requirement means you can’t leave pre-authentication access points undefined. You need a deliberate inventory of what’s allowed before a user logs in, along with a rationale for each exception recorded in your system security plan.
In practice, this means most organizations start by cataloging their public-facing surfaces. Public websites, phone systems that receive inbound calls, and fax endpoints are common examples of legitimate unauthenticated actions. The control forces you to make a conscious decision about each one rather than inheriting defaults from legacy configurations or vendor settings.
Where this breaks down is the assumption that “no login required” equals “low risk.” The control exists because every action that operates before access control mechanisms engage sits outside identity-based protections entirely. If you haven’t formally decided which pre-authentication actions are acceptable, you’ve implicitly permitted all of them.
Why it matters
Pre-authentication surfaces are the one category of attack surface that never benefits from identity-based controls, and most organizations have never inventoried theirs. Every application feature, endpoint, or developer-mode mechanism that operates before a user authenticates represents an entry point where credential policies, multi-factor authentication (MFA), and session controls offer zero protection.
Specifically, consider the Microsoft Office “Test” registry key (ATT&CK technique T1137.002), a developer-mode mechanism that instructs Office applications to load a dynamic-link library (DLL) from a specified file path on startup. When this key is left present on production workstations from a prior deployment or misconfigured image, an attacker who gains even limited write access to the affected registry path can cause a malicious payload to load inside a trusted Office process.
The result is code execution inside a trusted application the next time a user opens Word or Excel, without any authentication step or user interaction beyond launching the program. This attack path is one instance of a broader risk class: the inventory gap around pre-authentication entry points.
In practice, organizations accumulate undocumented pre-auth surfaces over time through software updates, developer tooling left in production images, and legacy application features that predate current security baselines. Without a deliberate exercise to identify these actions and confirm they are intentionally permitted, each one becomes an unmonitored entry point.
What attackers exploit
The following threat vectors target systems where pre-authentication actions haven’t been formally inventoried and restricted:
- Developer-mode registry keys and configuration flags (such as T1137.002) left active on production endpoints, allowing pre-auth code execution inside trusted processes
- Public-facing application endpoints that accept unauthenticated input and interact with backend services, including health-check endpoints, status pages, and API discovery routes
- Legacy protocols and services enabled by default during OS or application deployment that accept connections without identity and access management controls
- Self-service password reset and account recovery flows that expose user enumeration or bypass authentication logic through predictable token generation
- Pre-boot and firmware-level interfaces accessible over the network without authentication, including baseboard management controllers (BMCs) and out-of-band management ports
How to implement
The core implementation challenge for AC-14 is shifting from implicit defaults to explicit decisions. Most environments already have unauthenticated actions running, but few organizations have documented which ones are intentional and why.
For your organization
Start by building a complete inventory of every action a user or system can perform before authentication occurs. This inventory should cover public-facing websites, inbound communication channels, application endpoints that respond without credentials, and any developer or diagnostic features that bypass login.
Specifically, walk through each system in scope and answer one question: “What can someone do here without logging in?” Document each answer in a structured format that includes the system name, the specific unauthenticated action, and the business justification for permitting it. Your system security plan is the authoritative home for this documentation.
In practice, each identified action needs an assigned owner responsible for reviewing whether that action still requires unauthenticated access. Remove or disable anything that lacks a current business justification. This review should be recurring, not one-time, because new pre-auth surfaces appear with every software update, configuration change, and deployment.
Where this breaks down most often is the assumption that network segmentation substitutes for this inventory. A segmented network reduces exposure but doesn’t satisfy the control’s requirement to identify and justify specific unauthenticated actions. Another frequent gap is treating only web applications as in scope while ignoring protocol-level services, management interfaces, and embedded device endpoints.
The result is a documentation burden that’s easier to carry as a continuous habit than a retrospective effort. Maintain the inventory as a living document, capture configuration screenshots showing disabled pre-auth features, and record the review cadence in your security plan. A NIST 800-53 compliance checklist can help you track this control alongside your broader access control family obligations.
For your vendors
When assessing vendors against AC-14, you need to verify that they’ve made deliberate decisions about pre-authentication access rather than accepting defaults. The goal is confirming that your vendor has inventoried, documented, and justified every action their systems allow before authentication.
In practice, this means requesting the vendor’s documented list of unauthenticated actions for any system that processes, stores, or transmits your data. This list should include public endpoints, API routes that respond without credentials, and any administrative or diagnostic interfaces accessible without login.
Specifically, ask whether the vendor conducts periodic reviews of pre-authentication surfaces. A vendor that performed this inventory once during initial deployment but hasn’t revisited it since is likely carrying undocumented pre-auth surfaces from subsequent updates. Request evidence of the most recent review cycle and its findings.
Where this assessment surfaces risk most clearly is in vendors who cannot produce a documented list of unauthenticated actions, whose system security plans lack a rationale for permitted pre-auth access, or who claim “everything requires authentication” without evidence of a formal review. The last response is often a sign the inventory was never performed. A compliant vendor, by contrast, can produce a dated inventory tied to specific systems, show evidence of periodic review cycles, and explain the business rationale for each permitted unauthenticated action.
In practice, reviewing the vendor’s approach to NIST SP 800-53 compliance more broadly will reveal whether their access control posture reflects deliberate design or inherited defaults.
The result is a verification step grounded in configuration evidence. Request screenshots or exports showing that developer-mode features, diagnostic endpoints, and legacy services are disabled in production environments. Then compare the vendor’s documented list of permitted unauthenticated actions against what you can observe through external reconnaissance of their public-facing infrastructure.
Evidence examples
Auditors assessing AC-14 will look for artifacts that demonstrate a deliberate inventory and ongoing review of pre-authentication actions.
| Evidence Type | Example Artifact |
|---|---|
| Access control policy | Policy document defining organizational rules for unauthenticated system access, including approval authority and review cadence |
| Pre-authentication action inventory | Maintained list of every action permitted without identification or authentication, organized by system, with business justification for each entry |
| System security plan | Security plan sections documenting the rationale for each permitted unauthenticated action and the risk acceptance decision |
| Configuration evidence | Screenshots or exports of system settings showing disabled developer-mode features, restricted diagnostic endpoints, and enforced authentication on management interfaces |
| Review records | Dated records of periodic reviews confirming the pre-authentication inventory remains current after software updates and configuration changes |
| Audit logs | System audit records capturing access attempts to endpoints designated as unauthenticated, demonstrating monitoring coverage |
Cross-framework mapping
No applicable content for this control.
Related controls
- AC-08 (System Use Notification): AC-08 governs the notification banners and consent messages displayed before or during login, which directly intersects with AC-14 because unauthenticated users may still need to see system use notifications before accessing permitted pre-auth functions.
- IA-02 (Identification and Authentication for Organizational Users): IA-02 establishes the identification and authentication requirements for organizational users, making it the complement to AC-14. Actions not covered by AC-14’s permitted exceptions must satisfy IA-02’s authentication requirements.
- PL-02 (System Security and Privacy Plans): PL-02 requires organizations to maintain system security plans, and AC-14 specifically mandates that the rationale for unauthenticated actions be documented within those plans.
Frequently asked questions
What is NIST SP 800-53 AC-14?
AC-14 is a NIST SP 800-53 access control that requires organizations to identify and document every user action permitted on a system without identification or authentication. The control applies across LOW, MODERATE, and HIGH baselines, meaning it’s required regardless of system categorization. Organizations must record each permitted unauthenticated action in their system security plan along with a supporting rationale tied to mission and business functions.
What happens if AC-14 is not implemented?
Without AC-14, organizations accumulate undocumented pre-authentication surfaces that sit outside identity-based protections and go unmonitored. Legacy developer-mode features, diagnostic endpoints, and default service configurations remain active without anyone formally deciding whether they should be. This gap directly expands the attack surface available to adversaries who haven’t yet authenticated, and it creates audit findings because assessors will look for a documented list of permitted unauthenticated actions in the system security plan and find none.
Following a NIST compliance program helps organizations close these gaps systematically.
How do you audit AC-14?
Auditing AC-14 starts by verifying that the organization maintains a current inventory of user actions that can be performed without identification or authentication. Assessors then confirm that each action on the inventory includes a documented rationale in the system security plan, and that the rationale ties back to organizational mission and business functions. The audit should also include reviewing system configuration settings to verify that only inventoried pre-auth actions are actually accessible, comparing the documented list against what the system permits in practice.
What are examples of actions permitted without authentication?
Common examples include accessing publicly available sections of an organization’s website and receiving inbound calls or fax transmissions on organizational lines. Some organizations also permit unauthenticated access to application health-check endpoints and public API documentation pages. The key requirement is that each permitted action appears on a documented list with a business justification recorded in the system security plan, and organizations can also determine that no actions are permitted without authentication by setting the control’s assignment value to “none.”