IA.L2-3.5.1

IA.L2-3.5.1: Identification

Identify system users, processes, and devices on your network and maintain a record of who or what has access.

Identification sounds simple until you sit in the assessment room. The assessor asks a straightforward question: “Who has access to your CUI systems and how do you prove it?” And then you realize your inventory is scattered across email, a spreadsheet from 2024, and someone’s institutional knowledge. IA.L2-3.5.1 means you define who and what has access, document it, and keep that documentation current.

This overlaps heavily with your access control (AC) work. Once you have identification nailed down, AC practices become a formality. If you can’t clearly identify your users and devices, you can’t explain access control to the assessor. AC.L2-3.1.1 and AC.L2-3.1.2 both depend on having clear user and device identification in place.

Family Identification and Authentication
Practice IA.L2-3.5.1
Difficulty Medium
Key evidence User/device inventory, directory service records, device management records

What the assessor is actually evaluating

The assessor isn’t checking if you have a perfect inventory. They’re checking if you know who’s in your environment and if that knowledge is current. When they ask “who has administrative access,” you should be able to pull up a document and show them a list with names, account purposes, and a review date. Not a guess. Not “let me ask the network guy.” A document.

Most small contractors mix users across multiple systems: on-premises Active Directory, Microsoft 365, local machine accounts, cloud accounts, service accounts. The assessor needs to understand you’ve mapped all of that. You don’t have to use a single system for identity management (though that’s ideal), but you do have to maintain a unified view of who exists across all your systems.

For devices, same principle. You need to know what’s on your network and what’s authorized. This is where your asset inventory ties in. The device inventory doesn’t live in a vacuum. It connects to your CUI boundary definition, your access control matrix, your patch management, and your change management processes. Your device identification feeds directly into authentication requirements (see IA.L2-3.5.2) and audit logging (see AU.L2-3.3.1).

What a realistic SSP definition looks like

Example SSP Language: IA.L2-3.5.1

Practice IA.L2-3.5.1: Identification of Users, Processes, and Devices

We maintain current identification records for all individuals, processes, and devices with access to systems containing CUI. This includes:

  • Users: All employees and contractors are provisioned in Active Directory with unique user accounts. Accounts are created using a ticket-based process documented in our Access Control policy. Each account includes the user’s legal name, title, department, and manager name. Department managers review all active accounts in their area quarterly via the AD account review ticket. The most recent review was completed on [date].

  • Processes and Service Accounts: Non-interactive service accounts are documented in a separate registry with account name, purpose, and systems accessed. This registry is reviewed by the IT manager quarterly. Service account purposes are tied to documented business functions (backup, monitoring, scheduled maintenance). The registry is stored in [shared location] and reviewed on [date].

  • Devices: All desktop, laptop, and server devices deployed in the organization are tracked in our device inventory. Devices are registered at provisioning and decommissioned when taken out of service. Device records include hostname, serial number, hardware type, OS, owner/assigned user, and deployment date. The current inventory contains [number] authorized devices and is updated monthly by the network administrator.

All identification records are reviewed for accuracy and current status every [quarter/semi-annual]. Accounts for terminated employees are disabled within one business day of separation per the Termination SOP. Devices are decommissioned when they reach end-of-life or are no longer authorized.

Notice the specific language: account review is quarterly, service accounts are documented with purpose, devices include an owner. This matters. The assessor reads this and knows exactly what to ask for and what to check. Vague SSP language leads to follow-up questions. Clear language gets you through faster.

How to present your evidence

Evidence checklist
  • Current user inventory or Active Directory listing with titles/purposes
  • Device inventory with device names, types, OS, owners, and status
  • Service account registry documenting purpose and access
  • Evidence of periodic review (tickets, sign-offs, audit dates)

You need three artifacts ready:

  1. Current user inventory or directory listing. Pull from Active Directory. Show user accounts, their job titles/purposes, and the date the report was generated. Include service accounts with their descriptions.

  2. Device inventory. A spreadsheet or asset management tool export showing device name, device type, OS, owner, and current status. The date matters. If the last update was six months ago, expect questions.

  3. Evidence of review process. A ticket, meeting notes, or sign-off document showing that someone reviewed the user and device list on the schedule you documented. Don’t overthink this. A quarterly ticket that says “AD account review completed, verified 47 active accounts, 0 anomalies” is enough.

Assessment room tips

Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.

Q: "How do you know who has access to your systems?"
Pull up your current user list from AD. "Here's every account in the directory. Sales, engineering, IT, contractors. Each one has a unique identifier and is tied to a specific person or business function." That's the answer. Don't describe it. Show it.
Q: "What about service accounts or accounts that aren't tied to a person?"
Pull up your service account registry. "These are the non-interactive accounts. Backup service, monitoring agent, scheduled maintenance script. Each one is documented with what it's for and what systems it accesses."
Q: "How often do you review this list to make sure it's accurate?"
Pull up your most recent review ticket or sign-off. "Quarterly. Last review was [date]. The manager reviewed all accounts in their department, verified that everyone is still active and in the right roles."

Common failures

Inventory exists but doesn't get updated. You created a list 18 months ago. Three people have left and two have joined. The inventory still shows the old people. When the assessor asks about current state, you can't reconcile the data. This is a common finding. The inventory itself is fine. The process to keep it current is the failure.
Users live in multiple places and nobody's mapped them. Some folks are in Active Directory, some are in the cloud tenant, some are in a separate HR system. You don't have a unified view. When the assessor asks "how many active users do you have," you have to piece together an answer from three different systems. Do that mapping work before the assessment.
You have a simple quarterly user review process backed by tickets. Manager gets a ticket every quarter saying "review these 12 accounts." Manager confirms that all 12 are still active, in the right department, on the right teams. Ticket gets closed with a comment. Done. Assessor asks if the list is current. You say "yes, reviewed last quarter" and pull up the ticket. That's it.
Your device inventory is integrated with your asset management or IT ticketing system. New device gets a ticket, gets added to inventory at provisioning. Device goes out of service, ticket decommissions it. The inventory is always current because it's tied to the process you already run.
Get assessment room tips in your inbox

Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.

If you use an MSP or MSSP

Your MSP or MSSP should be maintaining your directory services and device management. They own the day-to-day. This doesn’t mean they own identification in the compliance sense. You own the process definition in your SSP and you own the review.

What that means operationally: your MSSP manages your Active Directory and device inventory. They push updates. You do the quarterly review. Your SSP documents what you review and when. The MSSP can speak to the technical side (how accounts are provisioned, how devices are registered) in the assessment. You speak to the business side and the review process.

If your MSSP also handles your compliance program management, they’ll be preparing the review artifacts and probably running the review itself. Either way, the MSSP should be able to walk the assessor through their account provisioning process and show logs of user and device changes if asked.

Make sure your MSSP has a documented process for handling new hires, terminations, and device decommissioning. Not just a verbal thing. A documented SOP. That SOP is your evidence that identification is happening reliably, not ad hoc. The MSSP hands it to you, you reference it in your SSP, and you put it in your evidence package.

This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.

New practice breakdowns and assessment tips every week. Follow on Substack to stay current as the November 2026 deadline gets closer.

← IA.L2-3.5.2: Device & User Authentication All Practices CM.L2-3.4.9: User-Installed Software →