Security requirement
- a.Uniquely identify and authenticate system users, and associate that unique identification with processes acting on behalf of those users.
- b.Re-authenticate users when [Organization-defined: circumstances or situations] .
Discussion
System users include individuals (or system processes acting on behalf of individuals) who are authorized to access a system. Typically, individual identifiers are the usernames associated with the system accounts assigned to those individuals. Since system processes execute on behalf of groups and roles, organizations may require the unique identification of individuals in group accounts or the accountability of individual activity. The unique identification and authentication of users apply to all system accesses. Organizations use passwords, physical authenticators, biometrics, or some combination thereof to authenticate user identities. Organizations may re-authenticate individuals in certain situations, including when roles, authenticators, or credentials change; when the execution of privileged functions occurs; after a fixed time period; or periodically.
Tailoring decisions required
Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.
Implementation perspective
Treat User Identification and Authentication as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to identity proofing, authentication strength, authenticator lifecycle, and resistance to credential compromise.
- Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
- Resolve every organization-defined parameter through an approved governance and tailoring process.
- Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
- Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
- Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.
Questions to ask
- Which CUI assets, data flows, users, and services are protected by this requirement?
- Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
- Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
- What change, incident, or threshold should trigger reassessment?
Evidence and validation
- identity proofing records
- authenticator issuance and revocation logs
- MFA and federation configuration
- credential inventories and rotation evidence
Common failure patterns
- MFA applied only to interactive users
- service credentials without ownership or rotation
- weak recovery paths that bypass strong authentication
- federated trust not reviewed after partner changes
Assessment objectives and methods
Assessment objectives (4)
- a.
system users are uniquely identified.
- a.
system users are authenticated.
- a.
processes acting on behalf of users are associated with uniquely identified and authenticated system users.
- b.
users are reauthenticated when [Organization-defined: circumstances or situations] .
Examine
- identification and authentication policy and procedures
- list of circumstances or situations requiring re-authentication
- system design documentation
- system configuration settings
- system audit records
- list of system accounts
- system security plan
- other relevant documents or records
Interview
- personnel with identification and authentication responsibilities
- personnel with system operations responsibilities
- personnel with account management responsibilities
- system developers
- personnel with information security responsibilities
- system administrators
Test
- processes for uniquely identifying and authenticating users
- mechanisms for supporting or implementing identification and authentication capabilities
Source NIST SP 800-53 controls
These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.
Authoritative sources
- NIST SP 800-171 Revision 3 official publication ↗
- NIST SP 800-171A Revision 3 official publication ↗
- NIST OSCAL Content release used for this import ↗
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.