SC-11, Trusted Path, asks the organization to provide an isolated trusted communications path between the user and the trusted components of the system, and to let users invoke that path when talking to security functions, at a minimum authentication and re-authentication. The type of isolation and the list of functions are organization defined.
800-53 binds US federal systems, and others through contract. For small and mid size companies it is a reference, and one of the more specialized controls in the set.
What it means in practice
The guidance describes a trusted path as a way for users to talk directly to security functions with enough assurance to support security policy. Only the user or the security function can activate it. Responses entered through it are protected from modification by, and disclosure to, untrusted applications.
The history in the record is useful. Early implementations used an out of band signal such as the break key, which sends no characters and so cannot be spoofed. Later ones used key combinations such as control, alt and delete, which are platform specific and cannot always be trusted either. The point is that a fake login screen should not be able to capture a password.
The enhancement is SC-11.1 Irrefutable Communications Path.
For most commercial teams the practical question is: when a user types a password, can you show it goes to the real authentication function and not to something an attacker could place in front of it? Operating system secure attention sequences, hardware backed prompts, origin bound credentials such as passkeys, and OS level credential dialogs all serve this purpose.
Evidence to collect
- The list of security functions covered, starting with authentication and re-authentication.
- Documentation of the mechanism, such as the secure attention sequence or origin bound login.
- Configuration showing it is enabled on managed devices.
- A test record showing the path cannot be mimicked by an ordinary application.
Common gaps
Custom login forms embedded in places where a lookalike page could replace them.
Password entry inside remote sessions with no way for the user to tell whether the prompt is local or remote.
No statement of which functions the path covers.
How to implement it
- Use the platform login mechanism instead of building your own prompt wherever possible.
- Prefer origin bound authentication such as passkeys, since they refuse to work on a lookalike site.
- Enable the secure attention sequence on managed machines.
- Write down the covered functions and the mechanism for each.
- Test with a spoof attempt and keep the result.
What an auditor may ask
- Which security functions does your trusted path cover?
- How would a user know a login prompt is genuine?
- Show the configuration on a managed device.
Write the answers down once, and attach the screenshots or exports you collected.
Quick check
Which functions must the trusted path support at a minimum?
Authentication and re-authentication.
