Skip to content

3.5.1 — Prove Who You Are

Identify system users, processes acting on behalf of users, and devices.

This is the identity foundation that everything else builds on. Three things need unique identifiers:

  1. Every person — unique username per individual. Not team accounts, not shared logins, not generic “admin” accounts.
  2. Every automated process — service accounts, scheduled tasks, API connections. Each one has a unique identifier tied to a documented owner.
  3. Every device — workstations, servers, phones, printers. Each one tracked with a unique ID through MDM or asset management.

The assessor will test this by pointing at a random log entry and asking “who or what did this?” If the answer is “we’re not sure because three people use that account,” you fail.

This requirement is the identity layer that access control (3.1.1) depends on. Without unique identification, you can’t enforce access rules, trace actions, or hold anyone accountable.


Your assessor needs a “yes” to every row:

#QuestionWhat “yes” looks like
1Are system users uniquely identified?Every person has their own username — no shared accounts
2Are processes acting on behalf of users identified?Service accounts documented with unique IDs and owners
3Are devices authorized to connect identified?Device inventory with unique identifiers from MDM or asset management

Documents they’ll review: Identification and authentication policy; procedures addressing user identification; system security plan; system design documentation; system configuration settings; list of system accounts; list of identifiers generated from organizational information system components

People they’ll talk to: Personnel with system operations responsibilities; personnel with account management responsibilities; personnel with information security responsibilities; system or network administrators; system developers

Live demos they’ll ask for: Mechanisms supporting or implementing identification of system users, processes, and devices


These are the actual questions. Have answers ready.

  • “Can you uniquely identify every user on your CUI systems right now?”
  • “Show me a service account — who owns it and what does it do?”
  • “How do you identify devices connecting to your network? Show me the inventory.”
  • “Are there any shared or generic accounts in your environment? Show me.”
  • “How do you ensure new devices get unique identifiers before connecting?”

Shared accounts.[email protected]” used by three people. The assessor asks who performed a specific action logged under that account, and you can’t answer. Every person gets their own account.

Orphan service accounts. That SQL service account from 2019 that nobody remembers creating. Every automated process needs a documented owner who reviews it annually.

Unidentified devices. Personal phones connecting to Wi-Fi, printers nobody inventoried. If it connects to the CUI environment, it needs a unique ID in your inventory.

Generic accounts on appliances. Network devices with factory ‘admin’ accounts. Each appliance needs unique credentials — even if only two people access it.



RequirementWhy it matters here
3.1.1 — Who Gets InUses identities from this requirement to control access
3.3.2 — Trace Every ActionDepends on unique IDs to attribute actions to individuals
3.5.2 — Verify Before EntryAuthenticates the identities established here
3.5.6 — Disable Dormant AccountsDisables identifiers that go unused

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

CMMC Practice ID: IA.L2-3.5.1 | SPRS Weight: 5 points | POA&M Eligible: No