CMMC Level 2 Practice 3.5.2: Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to

CMMC Level 2 Practice 3.5.2 requires you to authenticate (verify) the identity of every user, process, and device before you allow access to systems that store, process, or transmit CUI. To operationalize it fast, standardize identity sources (IdP/AD), enforce strong authentication at every access point, and retain assessor-ready evidence that authentication is required and works as designed. ¹

Key takeaways:

• Require identity verification before any access decision for users, services, and devices in the CUI environment. ²
• “Processes” and “devices” are in-scope; service accounts, APIs, and endpoints must authenticate, not just humans. ²
• Evidence wins assessments: configs, logs, diagrams, and account inventories must show authentication is enforced and monitored. ³

CMMC Level 2 assessments frequently expose a gap between “we have logins” and “we can prove identity is verified before access, everywhere it matters.” Practice 3.5.2 closes that gap by making authentication a prerequisite to access for users, processes, and devices, not an optional feature you enable in a few places. ²

For a CCO, GRC lead, or compliance officer, the fastest path is to treat 3.5.2 as an access “gate” requirement: no interactive access, no remote access, no API call, no service-to-service traffic, and no endpoint connection to the CUI enclave happens without an authenticated identity bound to that action. Then you collect evidence that a third party assessor can validate without reading your mind.

This page gives requirement-level implementation guidance you can hand to IT and security owners: what scope to set, what to configure, what to document, and what artifacts to retain so you can demonstrate compliance during a CMMC Level 2 assessment. Program context comes from the CMMC program rule and guidance and the mapped security requirement in NIST SP 800-171 Rev. 2. ⁴

Requirement: CMMC Level 2 Practice 3.5.2 (identity authentication prerequisite)

Plain-English interpretation

You must verify “who or what” is requesting access before you allow that access. “Who” includes employees, admins, and third-party users. “What” includes non-human identities such as service accounts, scheduled jobs, applications, containers, and API clients. “What device” includes laptops, servers, mobile devices, and network-attached endpoints that connect to the CUI environment. ²

Practical translation: if your environment makes an access decision based on an identity (account, certificate, token, key), the identity must be authenticated first, and you must be able to show the mechanism and the results (policy + configuration + logs). ²

Regulatory text

Regulatory excerpt (mapped control text): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.5.2 (Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to).” ¹

What the operator must do: implement authentication controls so that access to systems handling CUI is gated by verified identities for (1) humans, (2) processes/service accounts, and (3) devices; then document and retain proof the gate exists and is enforced. Assessment expectations and program context come through the CMMC program requirements and DoD program guidance. ⁴

Who it applies to (entity and operational context)

Applies to defense contractors and other federal contractors handling CUI in non-federal systems, specifically the CUI “enclave” or boundary where CUI is stored, processed, or transmitted, plus supporting identity and access infrastructure that controls entry to that boundary (IdP/AD, SSO, VPN, VDI, PAM, MDM, certificate services). ⁵

Include:

• Workforce users (employee, contractor, privileged admins).
• Third-party users with any access path (support portals, remote tools, jump boxes).
• Non-human identities (service accounts, CI/CD runners, integration accounts, bots).
• Endpoints and servers that connect to CUI systems. ²

What you actually need to do (step-by-step)

1) Define the “authentication boundary” for CUI access

• Inventory all entry points to the CUI environment: workstation logon, VPN, VDI, SSH/RDP, cloud consoles, web apps, file shares, APIs, and admin tools.
• Map each entry point to an authentication authority: AD, cloud IdP, application native auth, certificate-based auth, or managed key/token system.
• Write down the rule: “No access without authentication,” and list exceptions you will not allow (shared accounts, anonymous services) unless explicitly justified and controlled. ²

Deliverable: a one-page “CUI Access Paths & Authentication Map” diagram/table that an assessor can follow.

2) Standardize identities (humans)

• Centralize human authentication through a managed identity provider (AD/IdP) where feasible.
• Enforce unique user IDs; eliminate shared accounts for interactive use.
• Require authentication at every hop (for example: VPN authentication plus host authentication, not “VPN only”). ²

Practical tip: if you must keep local accounts (lab gear, appliances), put compensating controls around them (vaulted credentials, restricted network paths, documented ownership).

3) Control non-human identities (processes/service accounts)

This is where 3.5.2 often fails in real environments.

Minimum expectations:

• Create an inventory of service accounts and application identities that touch CUI systems.
• Ensure each process authenticates using a managed method (certificates, scoped tokens, key pairs stored in a secrets manager, or domain-managed service accounts).
• Prohibit hardcoded credentials in scripts, images, repos, and build logs; implement scanning and code review checks where possible.
• Bind non-human identity to least privilege and a known owner; document “who approves changes.” ²

Evidence focus: assessors will ask how you know “this process is really that process.” Your answer is: controlled credential issuance + protected storage + rotation + logs.

4) Authenticate devices before granting access (device trust)

For devices that connect to CUI systems:

• Enroll endpoints in device management (MDM/endpoint management) and enforce that only managed devices can connect.
• Use device certificates or equivalent device identity where supported (Wi‑Fi/EAP-TLS, VPN cert auth, machine accounts).
• Block unknown devices at the network and application layers (conditional access, NAC where applicable). ²

The goal is clear: a laptop is not “trusted” because it’s on your Wi‑Fi; it is trusted because it presents a verifiable device identity tied to management and policy.

5) Make authentication a prerequisite in technical policy (configuration)

Implement and document control points:

• OS logon: domain auth, local admin restrictions.
• Remote access: VPN/VDI requires authenticated user; admin access requires authenticated user and controlled admin tooling.
• Applications: SSO or strong app auth; disable anonymous access; remove default accounts; enforce session controls.
• APIs/services: require authenticated tokens/keys; reject unauthenticated requests; log auth outcomes. ²

6) Monitor and prove it works (recurring evidence)

• Enable authentication logging on identity providers, VPN, critical apps, and key infrastructure.
• Review failed logins, impossible travel, unusual service-account use, and device enrollment anomalies.
• Capture recurring evidence on a schedule so you can show consistent operation, not a one-time screenshot. This aligns with the practical expectation to map the practice to documented operation and ongoing evidence capture. ⁶

Where Daydream fits naturally: use Daydream to map CMMC Level 2 Practice 3.5.2 to owners, systems, and evidence tasks, then collect time-stamped artifacts (configs, exports, tickets) on a recurring cadence so assessment prep is not a spreadsheet scramble. ³

Required evidence and artifacts to retain

Keep evidence that answers: “Where is authentication required?” and “Show me it happened.”

Suggested artifacts (pick what matches your stack):

• CUI boundary diagram + “access paths & auth map” (network/app/remote access).
• Identity architecture documentation (AD/IdP design, trust relationships, SSO flows).
• Access control policies and standards that state authentication is required for users, processes, and devices. ²
• Account inventories:
  • User account list (including privileged users and third-party accounts).
  • Service account list with owner, purpose, auth method, privilege level.
  • Managed device inventory for endpoints accessing CUI.
• Configuration evidence (screenshots/exports):
  • Conditional access policies, VPN auth settings, SSO settings, device compliance rules.
  • Application settings disabling anonymous access and default credentials.
• Logs and reports:
  • Authentication logs (success/failure), VPN logs, IdP sign-in logs.
  • Samples showing service account authentication events.
• Change records and approvals:
  • Tickets for creating service accounts, issuing certificates, granting access.
• Periodic review evidence:
  • Access reviews for privileged accounts and third-party access paths.
  • Exception register (if any) with justification and compensating controls. ²

Common exam/audit questions and hangups

Expect assessors to probe these:

• “Show me every way a user can reach CUI and where they authenticate.” ²
• “Which systems authenticate devices, and what happens to unmanaged devices?”
• “List all service accounts touching CUI and prove their credentials are controlled.”
• “Do any applications have local users outside the IdP? How do you manage them?”
• “Where are authentication logs stored, and who reviews them?” ²

Hangups:

• Teams show MFA evidence for humans but ignore process and device authentication.
• Teams can describe the control but cannot produce exports/logs fast.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails 3.5.2	Fix
Relying on network location (“inside the office”) instead of authentication	Access can occur without verified identity	Require auth at each access point; treat internal network as untrusted for CUI paths. 2
Shared admin/service accounts	No attributable identity; weak auditability	Convert to unique admin accounts; use managed service identities; document ownership.
Hardcoded credentials in scripts	Process identity cannot be trusted	Move secrets to a managed store; enforce repo scanning; rotate and log access.
Device access without device identity	Unknown endpoints can connect	Enforce device enrollment and device-based authentication where supported.
Evidence is ad hoc	Hard to demonstrate operation	Define an evidence list and collect on a recurring cadence mapped to the practice. 3

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. ⁵

Operational risk still matters: weak authentication is a common precursor to unauthorized access, lateral movement, and inability to attribute actions to a specific identity. For CMMC Level 2, the direct business risk is failed assessment readiness and loss of eligibility for contracts that require certification under the CMMC program framework. ⁷

Practical 30/60/90-day execution plan

You asked for speed; use this plan as a control rollout and evidence sprint. The day markers are sequencing guidance, not a claim about how long your environment will take.

First 30 days (stabilize scope and gates)

• Confirm CUI boundary and list all access paths.
• Select system-of-record for identities (IdP/AD) and document the architecture.
• Inventory privileged users, third-party accounts, and service accounts that touch CUI.
• Turn on logging for IdP/VPN/core systems; define where logs are stored and who reviews them.
• Draft the evidence checklist for 3.5.2 and assign owners.

By 60 days (close the biggest gaps)

• Eliminate or tightly control shared accounts for interactive use.
• Migrate key applications to SSO or enforce strong app authentication.
• Implement managed secrets for service accounts; remove hardcoded credentials from repos where found.
• Enforce managed-device access controls for endpoints used to access CUI (conditional access / MDM compliance).

By 90 days (prove operation and harden)

• Run an internal mini-assessment: pick each access path and demonstrate the authentication prerequisite end-to-end with screenshots/log samples.
• Complete service account governance: owner, purpose, auth method, rotation approach, approvals.
• Formalize recurring reviews (failed auth patterns, dormant accounts, unmanaged device attempts).
• Store all evidence in a single assessment-ready repository (Daydream or your GRC system) with clear naming and dates. ³

Frequently Asked Questions

Does 3.5.2 require MFA everywhere?

3.5.2 requires authentication as a prerequisite to access; it does not, by itself, specify MFA in the excerpted text. Assessors will still expect strong, consistent authentication controls appropriate to risk and scope. ²

What counts as a “process” that must be authenticated?

Any non-human identity that accesses CUI systems counts, including service accounts, applications, scheduled tasks, API clients, and integration jobs. You need a controlled authentication method (token, certificate, key) tied to that identity and logged. ²

Are devices in scope if they never store CUI locally?

If a device can access systems that store, process, or transmit CUI, it is part of the access path and you should treat it as in scope for device identity verification. Document the rule and enforce it through device management and access controls. ²

We have legacy apps with local users. Can we still pass?

Yes, if you can show those local identities are authenticated before access and are governed (unique accounts, controlled provisioning, logging, and timely removal). Document why SSO is not feasible and keep compensating controls and evidence. ²

What evidence is most persuasive in a CMMC Level 2 assessment for 3.5.2?

A clean access-path map plus configuration exports and logs that show authentication is required and enforced across users, service accounts, and devices. Pair that with inventories and change tickets that prove governance. ⁶

How do we operationalize recurring evidence capture without burning the team out?

Define a fixed evidence list per system (IdP, VPN, key apps, device management) and collect exports/log samples on a regular cadence into a single repository with owners and due dates. Tools like Daydream help by mapping the practice to evidence tasks and keeping time-stamped artifacts assessor-ready. ³

Footnotes

1. NIST SP 800-171 Rev. 2; DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. DoD CMMC Program Guidance

4. 32 CFR Part 170; DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

5. DoD CMMC Program Guidance; 32 CFR Part 170; NIST SP 800-171 Rev. 2

6. DoD CMMC Program Guidance; NIST SP 800-171 Rev. 2

7. 32 CFR Part 170; DoD CMMC Program Guidance