1Overview
IA.L2-3.5.1 opens the Identification and Authentication family and is one of its five-point requirements. It requires that the organization identify its system users, the processes acting on their behalf, and the devices that access its systems, so that every actor in the environment has a distinct identity. It is a five-point requirement that cannot be deferred on a plan of action.
Identification is the first half of the question every access decision depends on: who is this. Before a system can authenticate anyone or enforce any access rule, it has to be able to name the users, processes, and devices acting within it. This control establishes that naming, the individual identities that the whole access control and accountability structure rests on. Without distinct identification, there is no way to authenticate individuals, trace actions to them, or apply access rules by identity, which is why this control anchors the family and carries a five-point weight.
Identify system users, processes acting on behalf of users, and devices.
The requirement names three kinds of actor. Users are the people; processes acting on behalf of users are the automated actions that run under a user's identity; and devices are the machines that access the system. Each has to be identified, which for users means individual accounts, for processes means the identities they run under, and for devices means a way to recognize them. This identification is the foundation the authentication of 3.5.2 then verifies, and the accountability of the audit family then relies on.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.5.1 into three objectives, one for each kind of actor: users, processes, and devices.
System users are identified. Each user has a distinct identity in the system.
Processes acting on behalf of users are identified. Automated actions running under a user carry an identity.
Devices accessing the system are identified. The machines that access the system can be recognized.
The three objectives cover the three kinds of actor. The common gap is at objective [a] wherever shared accounts persist, since a shared account identifies a group rather than an individual, and at objective [c] where devices are not identified at all. The assessor looks for distinct identities across users, processes, and devices.
3Failure Patterns
The failures are about shared or missing identities across the three kinds of actor.
Shared user accounts
A shared account identifies a group, not a person, so it fails to identify individual users. Individual accounts are the foundation of identification, and shared logins undermine it as well as the accountability that depends on it.
Unidentified devices
Where any device can connect without being identified, the device dimension of the control is unmet, and there is no basis for device-level access decisions. Identifying devices, through domain membership or a device record, closes this gap.
Anonymous processes
Automated processes running under anonymous or generic identities cannot be attributed, which fails objective [b]. Processes should act under identified accounts so their actions are traceable.
Generic accounts for people
Where people use generic or role accounts rather than individual ones, identification collapses to the role, not the person. Individual identity is what the control requires for users.
4Ownership
This is an IT-owned technical control, delivered through the directory and device management that assign identities.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Assigns individual identities to users, ensures processes run under identified accounts, and identifies devices. Owns the technical evidence. |
| Security or compliance lead | Confirms identification is individual and covers users, processes, and devices, with no shared accounts. |
| Program lead | Reviews identities as people and devices change and retains the evidence. |
5Tooling
The control is delivered by the directory that holds user and process identities and by device identification.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Directory with individual user accounts | Distinct identities for each user. |
| [b] | Service and process account management | Identified accounts under which processes act. |
| [c] | Domain membership, device records or certificates | Identification of the devices that access the system. |
The caveat is that identification is only as good as its individuality. A directory full of shared accounts identifies groups, not people, so the real work is ensuring identities are individual across users, processes, and devices. The assessor examines whether each actor is distinctly identified, so shared and anonymous identities have to be replaced.
6Evidence
The satisfied version of 3.5.1 shows distinct identities for users, processes, and devices.
| Evidence | What it demonstrates |
|---|---|
| User account listing | Objective [a]. Individual identities for users. |
| Process and service account records | Objective [b]. Identified accounts for processes. |
| Device identification | Objective [c]. Recognition of devices accessing the system. |
The evidence should show that users, processes, and devices each carry distinct identities, resting on individual accounts. The account and device records demonstrating individual identification are the clearest demonstration, and because this control cannot sit on a plan of action, the identification has to be real at the time of assessment.
Every access decision begins with who
Before a system can authenticate anyone or enforce any rule, it has to name the users, processes, and devices acting within it, and this five-point control establishes that naming. Assigning distinct identities and eliminating shared accounts is part of the onsite readiness work this practice does, and it is one of the controls that must be met rather than deferred.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.5.1. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.5.1[a] through 3.5.1[c]. csrc.nist.gov
- 32 CFR 170.24, CMMC Scoring Methodology, listing IA.L2-3.5.1 among the five-point basic security requirements. ecfr.gov