Authentication Feedback is one of the simplest requirements in the Identification and Authentication (03.05) family. It requires that the feedback a system shows during authentication does not reveal information an attacker could use. Authentication Feedback (03.05.11) is the requirement behind the familiar behavior of showing asterisks or dots instead of the characters of a password as it is typed. Per the NIST discussion, authentication feedback should not provide information that would let unauthorized individuals compromise authentication mechanisms, the classic threat is shoulder surfing, and obscuring feedback includes displaying asterisks as users type or showing feedback for a limited time before fully obscuring it.
A common difficulty with this requirement is not stumbling much at all, because most modern systems obscure password entry by default. The care is in confirming it holds everywhere, including custom applications, kiosks, and any interface where authentication input might be echoed to the screen. The threat model varies by device, so the means of obscuring feedback is chosen accordingly.
Where things stand for companies facing the transition from NIST 800-171 R2 to R3:
The following is reproduced verbatim from NIST 800-171 R3, requirement 03.05.11 Authentication Feedback. Only the formatting has been adjusted for readability. This is a single statement with no lettered parts:
The source control is IA-06 from NIST 800-53. There are no Organization-Defined Parameters (ODPs). Per the NIST discussion, the threat is significant on desktop or notebook systems with large monitors and less significant on mobile devices with small displays, where it is balanced against the increased likelihood of input errors, so the means of obscuring feedback is selected accordingly. You can read the requirement directly at NIST 800-171 R3, 03.05.11 (p. 37).
None (0). Requirement 03.05.11 contains no bracketed assignment, so there is no organization-defined value to select and nothing for the DoD to specify. The requirement applies as written.
Your System Security Plan (SSP) narrative for 03.05.11 therefore records how the requirement is implemented rather than a parameter you chose.
NIST 800-171A R3 breaks 03.05.11 into one (1) determination statement, and it has no Organization-Defined Parameters (ODPs). The AO is:
The single objective is that authentication feedback is obscured. An assessor will look at the actual authentication interfaces to confirm it. The full guidance on assessment methods and objects, is in NIST 800-171A R3, 03.05.11 (p. 47).
Examine: identification and authentication policy and procedures; procedures for authenticator feedback; system design documentation; system configuration settings; system audit records; system security plan.
Interview: personnel with information security responsibilities; system developers; system administrators.
Test: mechanisms for supporting or implementing the obscuring of feedback of authentication information during authentication.
03.05.11 maps from NIST 800-171 R2 requirement 3.5.11 (obscure feedback of authentication information):
Mapped against the one (1) AO, it is direct (minimal effort), with no net-new AOs and none with no mapping. This is a clean carry-forward. The concept, the wording, and the source control (IA-06) are effectively unchanged. If you satisfied R2 3.5.11, you are satisfying 03.05.11, provided the behavior holds across all your authentication interfaces.
Source Control in NIST 800-53 R5:
Secure Controls Framework (SCF) Crosswalk
Organizations running a single control set across multiple frameworks can satisfy 03.05.11 through the following SCF controls:
The crosswalks from NIST 800-171 R3 and NIST 800-171A R3 to the SCF are available at no cost through the SCF Set Theory Relationship Mapping (STRM): https://securecontrolsframework.com/start-here/set-theory-relationship-mapping-strm. The STRM also carries the relationship type for each mapping (Equal, Subset Of, Intersects With), which tells you whether an SCF control fully satisfies the requirement or only part of it. Mapping above taken from SCF 2026.3.
The following are issues teams may encounter rather than certainties. They are about coverage, each of which needs documented evidence of due diligence and due care such as policies, standards, procedures, and configuration screenshots:
Reasonable objective evidence for an assessment is often subjective. The following examples of evidence to address NIST 800-171 R3 03.05.11 are sourced from the SCF Evidence Request List (ERL), available at https://securecontrolsframework.com/free-content/scf-download. These ERL artifacts are mapped to NIST 800-171 R3 03.05.11 through SCF controls. They establish a starting point for discussions on what an organization needs to have for evidence of due diligence and due care to withstand external scrutiny by an assessor or regulator.
The SCF controls that carry this requirement have no dedicated ERL artifact, so evidence rests on the configuration and records that demonstrate the objectives directly.
Alongside these, keep the System Security Plan (SSP) narrative for 03.05.11.
With the single AO mapping directly, 03.05.11 is one of the quickest requirements to satisfy. A realistic sequence:
How many assessment objectives does NIST 800-171 R3 03.05.11 have? NIST 800-171A R3 breaks 03.05.11 into one (1) assessment objectives. An assessor works through each one separately, so each needs its own evidence.
Which NIST 800-53 R5 control does NIST 800-171 R3 03.05.11 come from? IA-06.
How many Organization-Defined Parameters (ODPs) does NIST 800-171 R3 03.05.11 have? None (0). The requirement contains no bracketed assignment, so there is no organization-defined value and nothing for the DoD to specify.
Where does NIST 800-171 R3 03.05.11 sit in the NIST 800-171 R3 Kill Chain? Phase 12, Secure Baseline Configurations (SBC). The Kill Chain is a phased model for sequencing R3 implementation, and it assigns this requirement to that phase.
03.05.11 Authentication Feedback requires that authentication feedback is obscured so it cannot be used to compromise authentication. It maps directly from R2 3.5.11 as a single objective, so there is no net-new work. The trap, if any, is a non-standard interface that echoes input. Confirm obscured feedback across all authentication interfaces and keep screen shots as evidence.
Authoritative sources:
Authoritative sources:
This guide reproduces U.S. Government text from NIST 800-171 R3 and NIST 800-171A R3. It is educational, not legal or assessment advice. Last reviewed: 2026-09-22.
