CMMC Level 2 Practice 3.5.1: Identify system users, processes acting on behalf of users, and devices

To meet CMMC Level 2 Practice 3.5.1, you must maintain a reliable way to identify every human user, every process acting for a user (service accounts, scheduled tasks, API tokens), and every device that can access systems that store, process, or transmit CUI. Operationally, this means authoritative inventories, unique identifiers, and evidence that identity records match real access paths. ¹

Key takeaways:

• Build one authoritative identity source for users, service accounts, and devices in scope for CUI access. ¹
• Tie identification to access enforcement points (SSO, VPN, MDM, EDR, NAC, cloud IAM) so “known identity” is required to connect. ¹
• Keep assessor-ready evidence: inventories, naming standards, joiner/mover/leaver records, and samples proving accounts/devices in logs map to real owners. ¹

CMMC assessments regularly expose a gap between “we have accounts in AD” and “we can prove every identity and endpoint touching CUI is known, owned, and controlled.” CMMC Level 2 Practice 3.5.1: identify system users, processes acting on behalf of users, and devices requirement is the foundational move that makes access control, least privilege, logging, incident response, and audits work in practice. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize 3.5.1 is to treat it as an authoritative identity and asset attribution requirement: every authentication event in scope must resolve to (1) a named person, (2) a managed non-human identity with an accountable owner, or (3) a managed device with a unique identifier and lifecycle status. ¹

This page gives requirement-level implementation guidance you can assign to IAM, IT Ops, Security, and system owners. It focuses on what assessors typically look for under CMMC Level 2 aligned to NIST SP 800-171 Rev. 2, and what evidence you should retain to demonstrate consistent operation. ²

Requirement overview (what 3.5.1 is really asking)

Goal: You can’t control access to CUI systems if you can’t reliably answer, “Who (or what) is this?” at the moment of access.

3.5.1 requires identification of three identity classes:

1. System users (humans): employees, contractors, admins, third parties with interactive access.
2. Processes acting on behalf of users (non-human identities): service accounts, app identities, scheduled jobs, RPA bots, API keys/tokens, integration accounts.
3. Devices: laptops, desktops, VDI endpoints, servers (on-prem and cloud), mobile devices, network gear, and specialized equipment that connects to in-scope systems.

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2 for this practice, so your implementation should be evidence-driven and consistently applied to the CUI environment and its access paths. ^{1 2}

Regulatory text

The practice is mapped to NIST SP 800-171 Rev. 2 requirement 3.5.1: “Identify system users, processes acting on behalf of users, and devices.” ¹

What the operator must do: implement and maintain identification mechanisms and records so that every account and device that can access the system is uniquely identifiable and attributable to an owner (person or function), and so that those identities can be tied to access activity (auth logs, system logs, and administrative actions). This expectation sits within the CMMC program framework in 32 CFR Part 170 and DoD’s CMMC guidance. ^{3 2 1}

Who it applies to (entity + operational context)

Applies to:

• Defense contractors and subcontractors handling CUI where CMMC Level 2 is required. ^{3 2}

Operational scope:

• Your CUI boundary: systems that store, process, or transmit CUI, plus supporting services that provide access (identity providers, endpoint management, remote access, jump boxes, admin workstations). ²
• Third party access into the boundary: managed service providers (MSPs), cloud administrators, support vendors, and consultants.

Practical scoping rule: if a user/process/device can authenticate to, administer, or reach CUI systems over the network, it must be identifiable and represented in your inventories and access control sources. ¹

Plain-English interpretation

You must be able to:

• List every human account that can access CUI systems, and tie each account to a real person and role.
• List every service account or application identity and tie it to an accountable owner, purpose, and where it runs.
• List every device that can reach CUI systems, uniquely identify it, and show whether it is authorized and managed.

If you cannot connect “an account in a log” to “a named owner + approved purpose + current status,” you will struggle to defend access decisions during assessment. ¹

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

1) Define the identification standard (write it down)

Create a short “Identification Standard” that covers:

• Unique identifiers for users (no shared accounts; naming convention).
• Non-human identity rules (service accounts must have: owner, purpose, system, rotation/secret storage approach, and approval).
• Device identification attributes (hostname standard, serial number, asset tag, MDM/EDR identifier, and ownership type).

This becomes the assessor-facing statement of how you meet 3.5.1 across the environment. ¹

2) Establish authoritative sources (one per identity class)

Pick and document the system of record for each:

• Humans: HR system + directory/IAM (AD/Azure AD/Okta).
• Non-human identities: IAM directory and a service-account register (often in ITSM/CMDB).
• Devices: CMDB/asset management plus MDM/EDR inventory for endpoints and cloud inventory for cloud assets.

Assessors want consistency. “We have three lists that don’t match” is a common finding pattern because it breaks attribution. ²

3) Inventory and reconcile (close the gaps)

Run a reconciliation cycle:

• Export all user accounts from IAM/directory and identify:
  • orphaned accounts (no owner),
  • shared/admin accounts without named assignees,
  • privileged accounts not mapped to a person,
  • external/third party accounts without sponsor.
• Export service accounts/app registrations/API tokens and identify:
  • missing owners,
  • unknown purpose,
  • credentials stored outside approved secret storage,
  • broad permissions without justification.
• Export device inventory from MDM/EDR/CMDB and identify:
  • unmanaged endpoints reaching VPN,
  • stale devices,
  • servers missing owners/environment tags,
  • “misc” hostnames that don’t map to an asset record.

Close gaps by disabling, reassigning ownership, or documenting legitimate exceptions with compensating controls. ¹

4) Bind identification to access control enforcement points

Identification must be real at the point of access. Tie your sources to:

• SSO/IAM for interactive apps.
• VPN/remote access with device checks where possible.
• MDM/EDR enrollment requirements for endpoints.
• Cloud IAM (roles bound to identities; no anonymous access paths).

Your proof is that unknown identities and unmanaged devices cannot successfully authenticate into the boundary. ^{1 2}

5) Operationalize lifecycle (JML + service account lifecycle + device lifecycle)

Document operational routines:

• Joiner/Mover/Leaver: account creation, role change, termination disablement.
• Service account lifecycle: request, approval, creation, review, and retirement.
• Device lifecycle: procurement, enrollment, assignment, decommission, secure disposal.

A control that depends on a one-time cleanup will not survive an assessment. You need repeatable operations and evidence. ²

6) Set up recurring evidence capture (assessment-ready)

Treat this as a control with a cadence:

• scheduled exports,
• reconciliation tickets,
• approvals,
• exception log,
• samples that map identities in logs to your inventories.

Daydream-style workflows (control mapped to recurring evidence capture, with owners and review checkpoints) reduce the scramble before a CMMC assessment because evidence is collected as a normal operating rhythm, not a special project. ²

Required evidence and artifacts to retain

Maintain artifacts that show both design and operation:

Design artifacts

• Identification Standard (users, service accounts, devices). ¹
• CUI boundary description and system list showing in-scope systems and access paths. ²
• Procedures for JML, service account management, device enrollment/decommission. ¹

Operational evidence (assessor-friendly)

• Current user list from IAM with owner attributes (department/manager/sponsor for third party).
• Service account register with owner, purpose, system, approval record, and current status.
• Device inventory exports (MDM/EDR/CMDB/cloud inventory) with unique identifiers and owner/custodian fields.
• Tickets/approvals for new privileged accounts and service accounts.
• Termination samples showing timely disablement (provide examples, not statistics). ²
• Sample log evidence: authentication logs showing identifiers that match inventory records (user UPN, device ID, service principal). ¹

Common exam/audit questions and hangups

Expect assessors to probe these areas (and stall if answers are vague):

• “Show me your complete list of accounts that can access the CUI enclave.” ²
• “How do you identify and control service accounts and app identities?” ¹
• “Can you map this privileged account in the logs to a named individual and an approval?” ¹
• “How do you prevent unmanaged devices from accessing CUI systems?” ¹
• “How do you handle third party access, and who sponsors it?” ²

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating AD as the only inventory.
   Fix: reconcile AD/IAM with HR, ITSM, and cloud IAM so your “truth” reflects real access paths. ¹

2. Mistake: ignoring non-human identities.
   Fix: create a service account register and require owners and approvals. Include API tokens and app registrations, not just Windows services. ¹

3. Mistake: unmanaged endpoints still have a path in.
   Fix: require managed device posture for remote access and enforce enrollment for endpoints that touch CUI. ¹

4. Mistake: shared admin accounts.
   Fix: use named admin accounts or role-based elevation tied to a person; document emergency access if you must keep it. ¹

5. Mistake: evidence is anecdotal.
   Fix: capture exports, tickets, and screenshots as routine evidence. Daydream can track control operation and prompt recurring evidence collection so you can answer assessor requests quickly. ²

Enforcement context and risk implications

Public enforcement cases were not provided in the source catalog for this requirement, so this page does not cite specific actions.

Operational risk is still clear: failure to identify users, non-human identities, and devices breaks access accountability and weakens incident response because activity cannot be reliably attributed. Under the CMMC program structure, assessment results and contractual requirements drive business impact, so missing evidence for 3.5.1 becomes a practical delivery risk for DoD work. ^{3 2}

Practical 30/60/90-day execution plan (phased, assessor-driven)

First 30 days (Immediate stabilization)

• Confirm the CUI boundary and list all systems and access methods in scope. ²
• Publish the Identification Standard (users, service accounts, devices) and assign control owners in IAM, IT Ops, and Security. ¹
• Export current accounts and device inventories and create a gap list: unknown owners, stale accounts, unmanaged devices, undocumented service accounts. ¹

Next 60 days (Control operation and cleanup)

• Remediate the gap list: disable or assign owners; document business-justified exceptions. ¹
• Implement a service account request/approval workflow and start a service account register tied to ITSM/CMDB. ¹
• Tighten access points: ensure SSO/VPN/cloud IAM require identifiable identities; reduce anonymous or shared pathways. ¹

Next 90 days (Evidence maturity and assessment readiness)

• Run a repeat reconciliation cycle and retain evidence as a “control packet” (exports, tickets, samples, approvals). ²
• Prove attribution with sampled logs: pick representative systems and show user/service/device identifiers map to your authoritative sources. ¹
• Put the control on a recurring review schedule in your GRC tooling; Daydream can manage mapping, assignments, and recurring evidence reminders so the control stays current between assessments. ²

Frequently Asked Questions

Does 3.5.1 require unique user IDs, or is an email address enough?

The requirement is to identify users, processes, and devices in a way that supports accountability. Email/UPN often works as a unique identifier if it is enforced consistently in IAM and shows up in authentication logs. ¹

Are service accounts and API keys in scope for “processes acting on behalf of users”?

Yes. Treat service accounts, application identities, and tokens as non-human identities with a named owner, defined purpose, and lifecycle controls. ¹

Do personal (BYOD) phones or home computers have to be inventoried?

If a device can access the CUI boundary, it must be identifiable and controlled. Many organizations meet this by blocking BYOD from direct access and requiring managed devices for CUI work. ¹

What counts as “device identification” for cloud systems?

For cloud workloads, “devices” includes compute instances and managed services that connect to or host in-scope functions. Keep cloud inventory records with unique instance/resource identifiers and ownership tags that map to a responsible team. ¹

How do we handle third party access under 3.5.1?

Ensure third party accounts are uniquely identifiable, tied to a sponsor/owner, and removed when access ends. Your evidence should show the access path (VPN/SSO) and the identity record that approves and tracks the third party account. ²

What is the fastest way to make 3.5.1 assessor-ready?

Build three exports (users, service accounts, devices), reconcile them to owners and access paths, and retain a repeatable evidence packet. Daydream helps by mapping the requirement to control steps and prompting recurring evidence capture so you can produce the packet on demand. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170