The easiest way to fail this requirement is to have your IT team all using the same admin account. The second easiest way is to have service accounts with no documented owner. The assessor doesn’t care that everyone in IT knows who actually did the work. The log entry needs to say it.
What the assessor is actually evaluating
The NIST language says “ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.” On the ground, this means:
No shared user accounts on systems in the CUI boundary. That’s the core requirement. Every account on a CUI system should be associated with one person. If two people log in as “admin,” you fail. If your team shares “it@company.com” to do administrative work, you fail. If there’s a generic service account running backups with no documented owner, that’s a problem. The assessor will ask who that account belongs to, and “nobody, it’s just for backups” is not a satisfactory answer.
Audit logs must show individual user identification, not roles or groups. When someone accesses a CUI file, the log should show their username, not “administrators” or “backup_service.” The log needs to identify the person. That’s what creates accountability.
Service accounts and shared functions need a documented owner. Service accounts are legitimate. Your backup software needs to run as something. But that “something” needs a named owner and documented privileges. “Backup service account, owned and monitored by [name], has read access to file shares and write access to backup storage.” Even though the service account isn’t used by a person directly, there’s still one person responsible for managing it and justifying its use.
Break-glass accounts need documentation too. If you have an emergency Global Admin account for “in case everything goes wrong” scenarios, it needs to be documented: what it is, why it exists, when it would be used, and why it isn’t used for day-to-day operations. This hasn’t been a major pain point in assessments, but the assessor may ask about it, and having clear documentation prevents it from becoming a finding.
Named admin accounts per person. If you have three IT staff members, each one gets their own admin account. The naming convention varies, but a common pattern is a prefix or suffix that distinguishes the admin account from the regular account: la.jsmith@company.com (local admin), adm.jsmith@company.com, or jsmith.admin@company.com. Not admin@company.com shared among them. This applies to domain admins, local admins if they exist, and any highly privileged accounts.
In the assessment room
The assessor is checking three things:
Are shared accounts gone? They’ll ask to see your account inventory for systems in the CUI boundary. They’ll look for accounts assigned to multiple people, generic role-based accounts, or accounts with no documented owner. If you have “admin” on a server and three people know the password, that’s a finding.
Can you show them a log with a specific user account? They’ll pull up audit logs from a system in the CUI boundary and point to an action, like a file access or a configuration change. The log entry should show the name of the user who did it. “DOMAIN\jsmith” not “DOMAIN\administrators.” “adm.jsmith@company.com” not “admin account.” The log has to identify the person.
Are you actually using unique identifiers? This is different from “you have a policy.” It means the logs are configured to capture the user ID of the account performing the action. On Windows, that’s the username in the Security Event Log. In Azure or Microsoft 365, that’s the sign-in logs showing a specific user identity. In SSH logs on Linux systems, the username of the account that logged in.
SSP language that works
[Organization Name] eliminates shared user accounts from all systems within the CUI boundary. Each user who requires access to CUI systems receives a unique user account associated with that individual. Administrators who require elevated privileges are provisioned with named administrative accounts using a prefix or suffix convention (e.g., la.jsmith@company.com or adm.jsmith@company.com, not a generic admin account).
Service accounts used for automated functions (backups, scheduled reports, application services) are assigned to named individuals who are responsible for monitoring and justifying their use. A service account inventory listing each service account, its purpose, the system it runs on, and the responsible owner is maintained and reviewed at least quarterly.
Audit logs for all CUI boundary systems are configured to capture the individual user account performing each action. User identification is recorded in all system logs, including authentication logs, file access logs, configuration change logs, and privilege escalation logs. Local administrator accounts do not exist on domain-joined systems in the CUI boundary; all administrative work is performed through named domain administrative accounts.
Notice what this covers: no shared accounts, named admin accounts per person, service account documentation with an owner, and logs that record individual user identification.
How to present your evidence
When the assessor reaches AU.L2-3.3.2, have these items ready:
A user account inventory for CUI boundary systems. List every user account on systems in your CUI boundary, what it’s for, and who it belongs to. This needs to cover active directory user accounts, local accounts on servers, application accounts, service accounts, everything. If you can’t produce this list without looking, you’re not ready.
Audit log samples showing user identification. Pull up logs from at least one CUI boundary system showing specific actions (file access, logon, config change) with the user account clearly identified. Windows Event Viewer, Azure sign-in logs, SIEM dashboards, whatever your system uses. The log needs to show “DOMAIN\jsmith” or “adm.jsmith@company.com” not “admin” or “backup_service.”
Evidence that shared accounts have been eliminated. If you’ve recently gotten rid of shared admin passwords, show what replaced them. Named individual admin accounts, mfa enforcement, updated documentation, whatever your solution is.
Service account inventory. A document listing each service account in your CUI boundary, what it does, which system it runs on, and the name of the person responsible for it.
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.
Common failures
Shared admin account. Multiple IT staff members use "admin@company.com" or a local "Administrator" account with a password everyone knows. If two different people used it in the past week, you fail. The assessor will ask who did what and won't accept "we think it was one of three people."
Service accounts with no documented owner. You have a "backup_user" or "app_service" account that's been running for years. When the assessor asks who owns it, nobody in the room knows for sure. There's no documentation linking it to a person. Service accounts need named owners even though they're not login accounts for individuals.
Logs don't show user identification. The assessor pulls up a file access log and it shows "admin" or "local system" instead of a specific username. The audit trail exists but it doesn't identify the individual. That's the whole point of this requirement.
Can't produce a user account inventory. The assessor asks for a list of who has access to CUI systems and you have to dig through active directory, ask IT staff, check multiple servers. A current inventory should be ready to go.
A current user account inventory for CUI boundary systems with no shared accounts. Named administrative accounts per person. Service accounts with documented owners. Audit logs showing specific user identification for actions in the CUI boundary. Live log samples the organization can pull up and walk through. When the assessor asks "who did this action," the answer is in the logs with a name attached to it, and that's what they want to see.
If you use an MSP/MSSP
If your MSP manages systems or accounts in your CUI boundary, this requirement still applies to you. Your MSP shouldn’t be using shared admin accounts any more than your staff should.
Here’s what usually matters:
You control the access policy, the MSP implements it. You define that no shared accounts are allowed. You maintain the user account inventory (at least at a high level, listing who has what access where). The MSP handles the technical implementation: creating named accounts, configuring audit logging, monitoring those accounts.
Service accounts on your CUI systems need a documented owner even if your MSP manages them. If the MSP runs a monitoring agent on your file server, that agent needs to run under a service account. You should know what that account is, what it does, and ideally there should be a named owner at your organization or the MSP who’s responsible for it.
You need to see the logs. Your MSP is operating your systems, but you need visibility into the audit trail. That doesn’t mean you review raw logs yourself. But you need to be able to say “here’s what our CUI systems are logging, here’s an example of how we identify individual users” if the assessor asks.
Make sure the MSP understands the requirement. If they’re used to shared admin accounts for efficiency, that doesn’t work for CMMC. Named accounts per person. Service accounts with owners. Logs that identify individuals. Brief them before the assessment.
This page covers AU.L2-3.3.2 from NIST SP 800-171 Rev 2 (3.3.2). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.