Quick-reference card
| Field | Value |
|---|---|
| Control ID | SC-11 |
| Control name | Trusted Path |
| Framework | NIST SP 800-53 Revision 5 |
| Control family | System and Communications Protection |
| Baselines | None |
| Relevance | System (First Party and Third Party) |
| Risk severity | Medium |
What this control requires
SC-11 requires you to establish an isolated communication channel that users can trust when interacting with security-critical functions like authentication. This control exists because attackers routinely target the space between a user and a system’s security mechanisms, injecting themselves into login flows, session handoffs, and credential prompts. Without a verified trusted path, users have no way to confirm they’re communicating with a legitimate security function rather than a spoofed interface.
In practice, this control has two parts. First, your system must provide a physically or logically isolated communication path between the user and the system’s trusted components. Second, users must be able to invoke that path themselves whenever they need to interact with security functions, with authentication and re-authentication as the baseline minimum. The isolation requirement means the path can’t share resources with untrusted applications that could modify or observe the communication.
The reason this matters operationally is that trusted paths enforce a boundary that most organizations assume exists but rarely verify. Credential harvesting, session hijacking, and phishing attacks all exploit the absence of a guaranteed channel between the user and the system’s security functions. If you can’t assure users that their login prompt is genuine, every other authentication control you’ve built sits on an unreliable foundation.
Why it matters
Organizations that skip SC-11 create a gap that auditors and assessors will flag during any NIST SP 800-53 control review. Because trusted path mechanisms touch authentication directly, their absence raises questions about the integrity of your entire access control chain. Assessors evaluating your system authorization package will look for evidence that users can invoke an isolated channel, and missing documentation here can stall or block authorization decisions.
The compliance risk compounds when you consider that SC-11 underpins trust in your authentication mechanisms. If an attacker can intercept or spoof the communication between a user and the system’s authentication function, the integrity of every session that follows is compromised. Governance frameworks treat this control as a signal of how seriously an organization treats its security architecture.
Beyond audit findings, failing to implement trusted paths exposes your organization to a class of attacks that bypass application-level defenses entirely. These attacks target the communication layer itself rather than the application logic, making them invisible to most monitoring tools.
The risk is compounded in environments with shared infrastructure, remote access, and multi-tenant systems. In these settings, the absence of a trusted path gives attackers more opportunities to position themselves between users and security functions.
What attackers exploit
- Spoofed login prompts that mimic legitimate authentication interfaces, harvesting credentials before the user reaches the real security function
- Man-in-the-middle positioning on shared or unprotected communication channels between the user’s input device and the system’s trusted components
- Malicious applications that intercept keystrokes or screen content during authentication, capturing credentials in transit
- Session hijacking during re-authentication events where the communication path lacks isolation from untrusted processes
- Social engineering attacks that redirect users to fraudulent security prompts because no trusted path mechanism exists to validate the prompt’s origin
How to implement
Most organizations struggle with SC-11 because the concept of a “trusted path” feels abstract until you map it to specific platform capabilities and architectural decisions. The implementation challenge is translating the control’s isolation requirement into concrete technical configurations that auditors can verify.
For your organization
Start by identifying every point where users interact with security functions in your environment. Authentication and re-authentication are the minimum scope, but your implementation should also cover any security function where user input determines access decisions.
Map each interaction point to a specific trusted path mechanism. On workstation operating systems, the secure attention sequence (commonly Ctrl+Alt+Del on Windows systems) provides a hardware-level interrupt that untrusted applications can’t intercept or suppress. This key combination triggers a trusted path to the operating system’s logon interface, ensuring the user communicates directly with the authentication component. Document which platform-specific mechanism you rely on and confirm that it can’t be overridden by user-space applications.
For web-based and remote access systems, implement transport layer security (TLS) with mutual authentication to create a logically isolated channel. Ensure that certificate validation is enforced end-to-end and that users can verify the authenticity of the connection before entering credentials. Consider implementing certificate pinning for critical authentication endpoints to prevent man-in-the-middle attacks using fraudulently issued certificates.
Verify that your trusted path implementation aligns with the reference monitor concept, which requires that the security enforcement mechanism is tamperproof, always invoked, and small enough to be subjected to analysis and testing. Your system and communications protection architecture should document how the trusted path mechanism meets these three properties.
Test your implementation by attempting to intercept or spoof the trusted path from an unprivileged application context. If a user-space application can present a fake login prompt that is indistinguishable from the genuine authentication interface, your trusted path implementation doesn’t meet the control’s requirements. Document the test results and remediation steps as part of your assessment evidence.
For your vendors
When evaluating vendor compliance with SC-11, focus your assessment on whether the vendor’s system architecture includes a documented trusted path mechanism and whether users of that system can invoke it during authentication.
Request the vendor’s system design documentation and security plan to verify that a trusted path is defined for user-to-security-function communications. Look for specifics about how the path is isolated, whether physically through dedicated hardware channels or logically through software-enforced separation. Vague references to “secure login” or “encrypted authentication” don’t satisfy this control.
Ask vendors to describe how their trusted path implementation prevents untrusted applications from modifying or observing communications on the path. The vendor should be able to explain the technical mechanism, not just assert that the path is secure. Request independent assessment results that validate the isolation properties.
Include these questions in your vendor security assessment questionnaire: Does your system provide a physically or logically isolated trusted communication path for user authentication? Can users invoke the trusted path mechanism themselves? How do you prevent untrusted applications from intercepting communications on the trusted path? What independent testing has validated your trusted path implementation?
Review the vendor’s audit records and assessment results from independent testing organizations. These records should demonstrate that independent testers validated the trusted path mechanism and confirmed its isolation properties. Red flags include the absence of any trusted path documentation, reliance on application-layer controls alone without underlying platform support, and the inability to describe how the path prevents interception by untrusted processes.
Evidence examples
| Evidence type | Example artifact |
|---|---|
| Policy documentation | System and communications protection policy defining requirements for trusted communication paths, including scope of security functions covered and isolation standards |
| Trusted path procedures | Procedures addressing how trusted communication paths are established, invoked by users, and maintained, including platform-specific secure attention sequences |
| System design documentation | Architecture diagrams and design documents showing how the trusted path is physically or logically isolated from untrusted application processes |
| Configuration evidence | System configuration settings demonstrating that trusted path mechanisms are enabled, enforced, and cannot be overridden by user-space applications |
| Security plan | System security plan sections documenting the trusted path implementation approach, reference monitor alignment, and security function coverage |
| Independent assessment results | Assessment results from independent testing organizations validating that the trusted path provides the claimed isolation properties |
| Audit records | System audit records capturing trusted path invocations, authentication events over the trusted channel, and any failed attempts to bypass the mechanism |
Cross-framework mapping
No cross-framework mappings are currently configured for SC-11.
Related controls
- AC-16 — Security and Privacy Attributes: Defines how security attributes are associated with information and used in access decisions, which trusted paths help protect during attribute-based authentication exchanges.
- AC-25 — Reference Monitor: Establishes the foundational concept that SC-11 implements, requiring tamperproof, always-invoked, and analyzable security enforcement mechanisms for the trusted path.
- SC-12 — Cryptographic Key Establishment and Management: Governs the cryptographic infrastructure that logically isolated trusted paths rely on for channel integrity and confidentiality during authentication.
- SC-23 — Session Authenticity: Protects session integrity after the trusted path establishes the initial authenticated connection, ensuring that subsequent communications maintain the trust established during login.
Frequently asked questions
What is NIST SP 800-53 SC-11
SC-11 is the NIST SP 800-53 control that requires organizations to provide an isolated trusted communication path between users and a system’s security functions, including authentication and re-authentication at a minimum. The control mandates that users can invoke this path themselves, ensuring they communicate directly with trusted components rather than potentially spoofed interfaces. It addresses a fundamental security architecture requirement by preventing untrusted applications from modifying or observing security-critical communications.
What happens if SC-11 is not implemented
Without SC-11, your system lacks a verified channel between users and security functions like authentication, leaving credential exchanges vulnerable to interception and spoofing by untrusted applications. Assessors reviewing your system authorization package will flag the missing trusted communication path as a gap in your system and communications protection controls. The absence of this control undermines the integrity of every access decision that depends on authentication, since there is no assurance that the user’s credentials reached the legitimate security function.
How do you audit SC-11
Auditing SC-11 starts with reviewing the system design documentation and security plan to verify that a trusted communication path is defined and that it covers authentication and re-authentication at minimum. Assessors then examine configuration settings and independent assessment results to confirm that the path is physically or logically isolated from untrusted processes. The audit also checks system audit records for evidence that users can invoke the trusted path and that the mechanism operates consistently across all entry points where security functions are accessed.
What is an example of a trusted path
The most recognized example of a trusted path is the secure attention sequence on desktop operating systems, where a specific key combination triggers a hardware-level interrupt that untrusted applications can’t intercept or simulate. On Windows systems, the Ctrl+Alt+Del key combination invokes the operating system’s login interface through a path that bypasses all user-space applications. In network environments, mutually authenticated TLS connections provide a logically isolated trusted path between a user’s browser and a server’s authentication endpoint, ensuring that credentials travel over a verified channel.