DKDavid Koran& Associates
Home The CMMC Guide Part III · Identification and Authentication IA.L2-3.5.2
The CMMC Guide · Identification and Authentication Family

IA.L2-3.5.2  Authenticate Identities

Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.

Family
Identification and AuthenticationIA, 11 requirements
Point Value
5Highest weight in the methodology
POA&M Eligible
NoCannot remain open at assessment
Objectives
ThreePer NIST SP 800-171A

1Overview

IA.L2-3.5.2 is the second five-point requirement in the family and the other half of the identity question. It requires that the organization authenticate, or verify, the identities of users, processes, and devices before allowing them access, so that a claimed identity is proven rather than simply asserted. It is a five-point requirement that cannot be deferred on a plan of action.

Identification names who someone claims to be; authentication proves it. Anyone can claim an identity, so before access is granted the claim has to be verified, through a password, a certificate, a token, or another mechanism, so that only the genuine holder of an identity gains its access. This control requires that verification as a prerequisite to access for all three kinds of actor. It is what turns the identities established in 3.5.1 into a real gate, and its five-point weight reflects that authentication is the boundary between the identified and the admitted.

The requirement · NIST SP 800-171 Rev 2, 3.5.2

Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.

The phrase "as a prerequisite to allowing access" is the operative constraint: authentication has to happen before access, not after. Each user, process, and device must have its claimed identity verified before it is admitted, so that access always follows proof. The mechanisms differ by actor, passwords or stronger factors for users, credentials for processes, certificates or keys for devices, but the principle is the same across all three, and it is the gate the rest of access control depends on.

2The Assessment Objectives

NIST SP 800-171A decomposes 3.5.2 into three objectives, one for each actor, each requiring authentication as a prerequisite to access.

[a]

The identity of each user is authenticated or verified as a prerequisite to system access. Users prove their identity before access.

MeetsUsers authenticate, for example with a password and additional factor, before gaining access.
FailsAccess is granted without verifying the user's identity.
[b]

The identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access. Processes prove their identity before access.

MeetsProcesses authenticate with credentials before accessing resources.
FailsProcesses access resources without authenticating.
[c]

The identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access. Devices prove their identity before access.

MeetsDevices authenticate, for example through certificates or domain authentication, before connecting.
FailsAny device can connect without authenticating.

The three objectives require authentication for each actor before access. The common gap is at objective [c], device authentication, where users authenticate but devices connect without verification, so an unauthenticated machine can reach the system. The assessor looks for authentication as a genuine prerequisite across all three actors.

3Failure Patterns

The failures are about access without verification and unauthenticated devices.

Devices connecting without authentication

Where users authenticate but any device can connect unverified, the device half of the control is unmet, and an unauthenticated machine can reach the environment. Device authentication, through certificates or domain membership, closes this gap.

Weak or absent user authentication

Access granted without verifying the user, or verified only weakly, fails objective [a]. Authentication has to actually prove the user's identity before access.

Processes with unmanaged credentials

Processes that access resources without authenticating, or with credentials that are not managed, fail objective [b]. Process identities have to be verified like any other.

Authentication after access

Any arrangement where access precedes verification defeats the prerequisite requirement. Authentication has to be the gate before access, not a check applied afterward.

The common root
This control fails when a claimed identity is trusted without proof. Identification without authentication is just an assertion, and the gap most often appears with devices, which are allowed to connect without the verification demanded of users. Authentication before access, for every actor, is what makes identity real.

4Ownership

This is an IT-owned technical control, delivered through the authentication mechanisms for users, processes, and devices.

RoleResponsibility for this control
IT and system administratorConfigures authentication for users, processes, and devices as a prerequisite to access. Owns the technical evidence.
Security or compliance leadConfirms authentication is required before access for all three actors, including devices.
Program leadReviews authentication coverage and retains the evidence.
See also: This control verifies the identities established by IA.L2-3.5.1, is strengthened by the multifactor authentication of IA.L2-3.5.3, and is the gate the access control family relies on.

5Tooling

The control is delivered by the authentication services for each kind of actor.

ObjectivesToolingWhat it provides
[a]Directory authentication, MFAVerification of user identity before access.
[b]Managed process and service credentialsVerification of process identity before access.
[c]Device certificates, domain authenticationVerification of device identity before connection.

The caveat is that authentication has to cover devices as well as users and precede access in every case. User authentication alone leaves the device objective unmet, and any path where access comes before verification defeats the prerequisite. The assessor examines whether every actor is authenticated before access, so device authentication in particular has to be present.

6Evidence

The satisfied version of 3.5.2 shows authentication required before access for all three actors.

EvidenceWhat it demonstrates
User authentication configurationObjective [a]. Users verified before access.
Process credential managementObjective [b]. Processes verified before access.
Device authentication configurationObjective [c]. Devices verified before connection.

The evidence should show authentication as a genuine prerequisite to access for users, processes, and devices. The configuration demonstrating verification before access across all three actors is the clearest demonstration, and because this control cannot sit on a plan of action, it has to be real at the time of assessment.

A claimed identity means nothing until it is proven

Identification names who someone claims to be, and this five-point control requires proving it before access, for devices as much as for users. Configuring authentication as a prerequisite across every actor 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-2662

7Sources

  1. NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.5.2. csrc.nist.gov
  2. NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.5.2[a] through 3.5.2[c]. csrc.nist.gov
  3. 32 CFR 170.24, CMMC Scoring Methodology, listing IA.L2-3.5.2 among the five-point basic security requirements. ecfr.gov
← Previous in Identification and Authentication
IA.L2-3.5.1 · Identify Users and Devices
Next in Identification and Authentication →
IA.L2-3.5.3 · Multifactor Authentication
About the Author
David W. Koran is a CyberAB Registered Practitioner Advanced and the author of The CMMC Decision, now in its second edition. He works onsite with defense contractors and their counsel, from the first leadership briefing through the pre-assessment review. Reach him at 802-335-2662 or dkoran@davidkoran.com.
Entry IA.L2-3.5.2 · Edition 2026.1 · Last reviewed July 12, 2026