Identification & authentication.
Proving an identity is what it claims to be, before Access Control decides what it may do.
Identification & Authentication is 11 of Level 2’s 110 requirements: identifying users, processes, and devices, then authenticating them — passwords, multifactor, replay resistance — before anything is granted access. IA and Access Control (AC) are a matched pair: IA answers “is this really who it claims to be,” and AC answers “what is this identity allowed to do now that we know.” This page covers what IA specifically requires.
This page explains the family. It does not replace the requirement text or assessment objectives.
01What this family protects
IA protects the moment a user, a process acting on a user’s behalf, or a device claims an identity and is let in on the strength of that claim. Weak identification or authentication undermines every other family at once: an access-control policy (AC) is only as strong as the login it’s guarding, and an audit log (AU) that records the wrong identity because a credential was shared or guessed is not a useful record of anything.
02The rule says
All 11 requirements, condensed to their operative sentence. NIST SP 800-171 Rev. 2 §3.5 has the full text and discussion for each.
| § | Requirement |
|---|---|
| 3.5.1 | Identify system users, processes acting on behalf of users, and devices. |
| 3.5.2 | Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems. |
| 3.5.3 | Use multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts. |
| 3.5.4 | Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts. |
| 3.5.5 | Prevent reuse of identifiers for a defined period. |
| 3.5.6 | Disable identifiers after a defined period of inactivity. |
| 3.5.7 | Enforce a minimum password complexity and change of characters when new passwords are created. |
| 3.5.8 | Prohibit password reuse for a specified number of generations. |
| 3.5.9 | Allow temporary password use for system logons with an immediate change to a permanent password. |
| 3.5.10 | Store and transmit only cryptographically-protected passwords. |
| 3.5.11 | Obscure feedback of authentication information. |
03In practice
Identify, then authenticate (3.5.1–3.5.2). Every user, service account, and device that can reach a system touching CUI needs its own identifier — no shared logins standing in for a person — and a way to prove that identifier is genuine before access is granted.
Multifactor authentication (3.5.3–3.5.4) is the family’s highest-profile requirement, and the one most readers have already heard of by name. It applies to privileged accounts for any access, local or network, and to non-privileged accounts specifically for network access — a distinction worth reading carefully, since it means MFA reaches further than “just the admins.” Replay resistance (3.5.4) means the authentication method can’t be defeated by recording and replaying a login exchange — time-based codes and challenge-response tokens qualify; a reused static code sent by SMS is weaker ground.
Identifier and password mechanics (3.5.5–3.5.11) are mostly configuration, not new tooling: don’t reissue an old username to a new person, disable accounts nobody has used in a defined window, require a real password-complexity policy, don’t let old passwords come back, force a change off of any temporary password immediately, store and transmit passwords only in hashed or otherwise cryptographically protected form, and don’t show a password in plain text while it’s being typed.
04Where it fails
The recurring gap is partial MFA: it’s enabled on the email platform because the vendor made it easy, and nowhere else — not on the VPN, not on the remote-access tool an MSP uses, not on the CAD/CAM system itself. An assessor reading 3.5.3 literally checks all the access paths the requirement actually names, not just the one that was simplest to turn on.
A second recurring gap is service accounts: a backup job, a monitoring agent, or an integration between two systems authenticates with a static password that was set up years ago, never rotated, and excluded from the same discipline applied to human users — even though 3.5.1 and 3.5.2 apply to “processes acting on behalf of users” too.
05What evidence may look like
MFA enrollment reports from the identity provider or VPN concentrator; a password policy document matching what’s actually configured in Active Directory or the equivalent system; account-disable logs or a ticket trail showing inactive identifiers get turned off; and a short inventory of service accounts with a note on how each authenticates. The goal is showing the configuration matches the stated policy, not producing a longer policy document.
06At the shop
Blanchard Tool & Machining is the desk’s fictional composite (any resemblance to an actual company is coincidental). Blanchard rolled out an authenticator-app MFA requirement in two passes: first on the VPN the MSP uses for remote monitoring, then on the CAD/CAM login itself once the engineering lead confirmed the software supported it. Machinists on the shop floor, who only touch drawings through the local network, authenticate with a strong password rotated on a defined schedule rather than MFA — a reasonable reading of 3.5.3 for accounts with no network access path, documented as such in the SSP rather than left unexplained.
07Commonly confused with
Access Control (AC). IA confirms who someone is; AC decides what they’re allowed to do once confirmed. A login screen usually represents both families working in sequence, not one. See Access Control.
System & Communications Protection (SC). IA’s password-protection requirements (3.5.10) and SC’s cryptography requirements (3.13.8, 3.13.11) both involve encryption, but they protect different things: IA protects credentials at rest and in transit; SC protects CUI itself and the sessions carrying it. See System & Communications Protection.
08Cross-desk links
Multifactor authentication and replay-resistant login are core topics on the lab’s Privacy & Identity pages, covered there independent of any one compliance program. That material is useful background for understanding how MFA actually works; it does not itself satisfy 3.5.3, and nothing on those pages is a CMMC requirement.
09Sources
| Document | What it’s for |
|---|---|
| NIST SP 800-171 Rev. 2, §3.5 | Full requirement text and discussion for all 11 IA requirements. |
| NIST SP 800-171A | Assessment objectives for each IA requirement. |
| CMMC Level 2 Assessment Guide | How an assessor examines, interviews, and tests IA practices in the field. |
| 32 CFR 170.4 | Defines “CMMC Level 2 security requirement” and ties the 800-171 R2 families to the CMMC Program. |