IA.L2-3.5.1 Identification: requirements and evidence

What IA.L2-3.5.1 identification asks for and why assessors start with account lists

A defense contractor preparing for a Level 2 assessment has to show that every identity on a system holding CUI is known. IA.L2-3.5.1 requires the organization to identify three kinds of identity: system users, processes acting on behalf of those users, and devices that access the system. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.5.1, a basic requirement in the Identification and Authentication family. NIST SP 800-171A breaks it into three assessment objectives, one for each identity type, and an assessor tests each one separately. A system with a strong login process still fails if a service account, a scheduled job or a network appliance runs under an identity nobody can explain.

Shared and unknown accounts are the usual problem. A generic administrator login used by several people makes it impossible to tie an action in the audit logs to a person, and an account created by a former vendor with no owner on record is an identity that no one reviews. Assessors therefore begin with the account lists: the directory export of user accounts, the list of service and process identities, and the device inventory or registration records. They compare those lists against the access that is actually granted and check that each entry has an owner and a documented purpose. The lists are also the evidence that the identifiers used by the access control requirement AC.L2-3.1.1 can be trusted. Confirm with your assessor which exports they expect, in what format, and for which systems in scope.

Which systems, accounts and devices fall under IA.L2-3.5.1 scoping

IA.L2-3.5.1 applies to every identity that can reach a system holding CUI, not only the employee accounts people think of first. The cards below cover the scoping decisions that change the work, and each one ends with the question your team must answer before the assessment starts.

In-scope CUI systems

Start with the systems that store, process or transmit CUI, then include every platform that authenticates users into them, such as directories, VPN gateways, jump hosts and administrative consoles. Ask whether every path into a CUI system passes through an identity source you can list. A system left off the boundary often has local accounts that were never assessed against the requirement. Your system security plan should name each of these components so an assessor can trace identities to them.

Service and automation accounts

Backup agents, scheduled jobs, CI pipelines and integration connectors run as accounts that the requirement treats as processes acting on behalf of users. Each one needs a unique identifier and a named owner, even though no person signs in with it. Ask who owns each non-human account and which process or system it acts for. Accounts created during past projects are common findings because nobody remembers their purpose.

Shared and generic accounts

Shared logins such as a common administrator account, a help desk login or a kiosk account cannot identify one person, so they weaken the audit trail and the identity that the access control requirement relies on. Where a shared account is operationally required, document the business reason, restrict its use and confirm that some other control links each session to a responsible individual. Ask whether any shared account can be replaced with individual accounts or privileged access tooling.

Workstations, mobile and IoT devices

Device identification applies to any endpoint that connects to a CUI system, including laptops, phones, tablets, printers, scanners and building or lab equipment that sits on the network. Confirm how each device is identified before it is granted access, whether by certificate, directory object or a managed inventory record. Ask which devices can connect to the CUI network without being recorded in an inventory. Unmanaged devices and personal phones that sync mail are typical gaps.

Third-party and cloud identities

Accounts held by managed service providers, contractors, cloud tenants and software-as-a-service applications can reach CUI even when your own directory does not manage them. Each external identity should trace back to a sponsoring person and an identity source you control, and you should know which of these fall inside your assessed boundary. Ask which external identities have standing access and who approves their creation. Your contracts and flowdown terms should match the answer.

Directory and provisioning sources

The identity source that creates and removes accounts determines whether your evidence is consistent across systems. If an application keeps its own user table while the corporate directory holds the master record, two identity lists exist and they can drift apart. Ask which system is the authoritative source for each population of identities and whether the other systems are fed from it. Open-source options such as authentik, FreeIPA, Keycloak and midPoint can serve this role, and you should confirm that each one fits your environment before choosing it.

How to design an identifier scheme that an assessor can trace

An identifier is auditable when an assessor can start from any account, process or device in the system and reach one accountable owner without guessing. For IA.L2-3.5.1 Identification, that means every human user, every process acting on a user's behalf, and every device that reaches the system carries a unique identifier that maps to a named owner. Shared logins, generic accounts with no owner of record, and identifiers that point to a role instead of a person fail the trace even when the technology works. Before building anything, decide who owns the identifier for each class of identity, and record that decision in the directory, not only in a spreadsheet.

Naming conventions are a local choice, and the requirement does not prescribe a format. A workable scheme usually separates three classes: person accounts, service or process identities, and device identities, with a prefix or attribute that makes the class obvious in logs. A service account, for example, might carry a clear marker and a documented owner team, while a device record stores the asset tag and the responsible administrator. Confirm with your assessor how they expect to correlate identifiers across the directory, applications and endpoints, because a name that changes between systems breaks the trace. Keep the scheme consistent so the same person or device resolves to one identifier everywhere.

Document the scheme in the system security plan, including the identifier classes, the naming rules, who approves new identifiers, and where the authoritative record lives. The plan is where the assessor first looks to confirm that the design exists and is followed. Then pull a sample of accounts and devices and check that each one resolves to an owner and a documented class. Gaps found at this stage are cheaper to fix than gaps found during an assessment, and the account lists and audit records that later support 3.5.1 should match the scheme you documented.

How an assessor tests IA.L2-3.5.1 against the SP 800-171A objectives

This table maps the three SP 800-171A assessment objectives for IA.L2-3.5.1 to the test approach an assessor takes, the evidence requested and the findings that most often stop a requirement from being scored as MET. Read each row as one objective, and check that your evidence covers all three rows before you treat the requirement as ready.

Assessment objective	How the assessor tests it	Evidence the assessor requests	Common findings
Users of the system are identified	Compares the account list against the authorized user population, then samples accounts to confirm each one traces to a named person or approved role	Identification procedures, system account list, HR or directory extract showing the matching person, audit records of logons	Shared or generic logon accounts, accounts with no named owner, duplicate identities for one person
Processes acting on behalf of users are identified	Reviews service accounts, scheduled jobs and integration accounts, then asks who owns each one and what user action it performs	Service account inventory with owners, job or integration configuration, account list entries for non-human identities	Orphaned service accounts left after staff departures, processes running under a personal or administrator account
Devices accessing the system are identified	Compares device records (for example, directory computer objects or certificates) with observed connections and checks that unknown devices cannot join	Device inventory or directory export, enrollment records, network or authentication logs showing device identifiers	Unidentified laptops or appliances on the network, devices that connect without a registered identifier, stale device records
Procedures and mechanisms exist	Walks through how identifiers are created, approved and recorded, and tests whether the mechanism works as documented	Written identification procedure, approval records for new accounts, configuration of the identity provider or directory	Procedures that describe a process nobody follows, accounts created outside the approval path
Evidence is final and current	Checks that the evidence reflects the system at assessment time and that drafts are not presented as operating records	Dated account lists, recent audit records, signed or approved procedure versions	Account lists exported months earlier, draft procedures, screenshots with no date or system name

Implementing unique identification step by step

This sequence moves an environment from scattered accounts and devices to a single, documented identifier scheme that an assessor can trace from policy to directory to system records. Each step names the output to hand the assessor.

Inventory every identity source and device class
List every place where users, processes and devices are identified today. That includes the corporate directory, local accounts on servers and workstations, application-local user tables, cloud tenants, service accounts, CI/CD runners, network devices and any shared or generic logins. Record the owner, the system that holds each identity and whether it is in scope for the CUI environment. The output is a system-level inventory that the system security plan can reference. Confirm the scope with your own system boundary before you start, because identifiers outside that boundary do not need to meet IA.L2-3.5.1 for CUI.
Define the identifier standard
Write a short standard that sets the format for each identifier type: human users, groups, roles, processes acting on behalf of users, service accounts and devices. Specify that every identifier is unique within the system, that a person maps to exactly one primary user identifier, and that shared or generic logins are not permitted for CUI access unless they are formally identified and attributable. Assign an owner for the standard and an approval record. The output is a signed identifier standard that an assessor can read against the 3.5.1 objectives.
Consolidate identities into an authoritative directory
Choose one authoritative source for human identities, typically an existing corporate directory or an identity provider, and connect other systems to it. Where applications keep their own user tables, plan how their accounts will be linked to the directory record or retired. Use open-source identity components where they fit your environment, such as authentik, FreeIPA or Keycloak with directory federation, and confirm each product's capabilities against your own requirements before you commit. The output is a list of connected systems and the mapping from each local account to its directory identity.
Assign identifiers to process and service accounts
Give every service account, scheduled job and integration that acts on behalf of a user its own identifier, and record the named owner accountable for it. Remove anonymous or inherited credentials that run processes without an identity. Where a process acts for a user, document which user it acts for and how that link is recorded. The output is a service account register with an owner, purpose, system and review contact for each entry, which the assessor can compare against the account lists in the system.
Register devices with unique identifiers
Enumerate every device class that can reach the system, including workstations, servers, mobile devices, network equipment and specialized assets, and register each device with a unique identifier. Use device certificates, hardware-bound identifiers or an asset inventory tied to the directory, depending on what your environment supports. Confirm that devices not registered cannot authenticate to in-scope systems. The output is a device register that matches the inventory from the first step and a documented method for checking it.
Reconcile accounts and remove duplicates
Compare the account lists from each system against the authoritative directory and the service and device registers. Find orphaned accounts, duplicates, shared logins and identifiers that do not trace to an owner, then disable or merge them. Record each exception and its resolution. The output is a reconciliation report with a dated result that shows every enabled account and device maps to one identity record, which is the evidence an assessor will sample first.
Document the identification procedure and retain records
Write the procedure that staff follow to create, change and retire identifiers, including who approves each request and where the record is kept. Link it to the identifier standard, the directory design and the reconciliation process. Retain account lists, audit records and the procedure in final form so that they can be produced at assessment time. The output is an approved procedure and a set of retained records that together show the 3.5.1 objectives are met on an ongoing basis, not only on the day of the review.

How self-hosted identity platforms produce identification evidence

The evidence for IA.L2-3.5.1 is easiest to produce when one identity source defines who exists in the environment and every system takes its accounts from that source. A self-hosted identity platform can play that role inside your own infrastructure. authentik (MIT) can act as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it rather than keeping local user tables. FreeIPA (GPL-3.0-or-later) provides single sign-on for Linux and UNIX hosts through an MIT Kerberos KDC, which gives you a directory of host and user principals for that part of the estate. Your choice depends on which systems must authenticate against it, and you should confirm the supported protocols and versions for each product against your environment before you commit to a design.

Keycloak (Apache-2.0) fits when your existing directory is already the authoritative list. Its user federation connects to LDAP or Active Directory servers and synchronizes users into Keycloak, so accounts managed in the corporate directory are the ones used for application sign-in. That keeps a single identifier per person, which is what an assessor will trace when checking a user list against the systems it can reach. Confirm how federation maps directory attributes to Keycloak users, how often synchronization runs, and how disabled directory accounts are handled, because a federated user that remains active in the application after removal from the directory will show up as a gap.

midPoint (EUPL-1.2+) addresses the part that identity sources do not handle on their own: keeping accounts on connected systems aligned with changes to people and roles. It creates, updates and deletes accounts based on user changes and role assignments, and it maintains alignment through provisioning, live synchronization, scheduled reconciliation and discovery, with separately defined inbound and outbound rules. Reconciliation reports are useful evidence of an account list that matches the authorized population, and orphaned accounts found during discovery should be traced to an owner before they are removed. Ask for the synchronization and reconciliation configuration in writing and test it on a representative connected system before relying on it for assessment evidence.

Which account lists and records pass an IA.L2-3.5.1 review

An assessor testing IA.L2-3.5.1 looks for proof that every user, process acting for a user, and device has a unique, vetted identifier, and that the records match what is running. The cards below cover the artifacts that usually carry that proof, how each one stays current between assessments, and why draft versions do not count.

Identification procedures

These are the written rules for how an identifier is issued to a person, a service process or a device, who approves it, and what identity proofing happens first. Assessors compare the procedure with the accounts they sample, so the steps must describe what administrators actually do. Review the procedure at a defined interval, record the approver and date, and confirm the approved version is the one staff follow. A draft or unsigned copy will not carry weight.

Current system account lists with owners

The account list is the core artifact for this requirement. It should name every user, service account and shared or process account on each in-scope system, with an accountable owner for each entry. Export it from the system itself rather than building it by hand, then reconcile it against HR and contractor rosters. An account with no named owner is a finding waiting to happen, so resolve orphans before the assessment starts.

Device registration lists

Assessors look for a list of the devices permitted to reach the system, each tied to a unique identifier such as a hostname, certificate or hardware record. The list should show who registered each device and when. Compare it with network and endpoint inventory so that no device connects under an identifier that is missing from the register. Update it when hardware is added, reimaged or retired.

Directory exports from identity sources

Exports from Active Directory, LDAP, or the identity provider show the identities the organization actually manages and their attributes. Keep dated exports from each source of truth, because an assessor may ask what the directory held on a specific day. Confirm that application accounts trace back to a directory entry, and that disabled or deleted users are not still present in downstream systems. Store exports where they cannot be edited after the fact.

Audit records showing identities in use

Authentication and audit logs demonstrate that identifiers are used by the right people, processes and devices in practice. Assessors often sample a log entry and trace it back to a listed account. Make sure logs record the unique identifier rather than a shared generic name, and retain them long enough to cover the assessment window. Gaps in logging for a given system can undermine an otherwise complete account list.

Change records for account creation

Tickets, workflow approvals and provisioning logs show how each identifier was created, by whom and under what authority. These records connect the account list to the identification procedure. Check that each new account has an approval trail, and that changes to owners, roles or device registrations are recorded as well. Confirm that changes are logged in the system of record, not only in email or chat.

What meeting IA.L2-3.5.1 costs in tooling, engineering and evidence upkeep

This table breaks the cost of meeting IA.L2-3.5.1 into its components, showing who is paid for each, whether it is one-time or recurring, and what drives it up. Read the recurring rows as the upkeep that keeps identifier evidence current between assessments. The main takeaway is that open-source licenses are rarely the largest line item, while hosting, staff time and account review are.

Cost component	Who is paid or who spends effort	One-time or recurring	Main cost drivers
Identity platform hosting	Client cloud or data center team, or a managed hosting provider	Recurring	Number of identity sources, high availability design, and the cloud or data center footprint
Directory consolidation and cleanup	Client identity engineers, with an implementation partner if scoped	One-time, with later rework	Count of existing directories, duplicate or orphaned accounts, and naming inconsistencies
Integration of applications and devices	Client platform engineers, with an implementation partner if scoped	One-time per application, plus updates	Number of applications, protocols in use (for example SAML, OIDC, LDAP) and device count
Provisioning and deprovisioning automation	Client identity engineers or an implementation partner	One-time build, recurring maintenance	Number of connected systems, role model complexity and change volume
Periodic account reviews	Client system owners, managers and the security team	Recurring	Number of user and service accounts, review frequency set by the client's own policy, and count of privileged accounts
Evidence collection for assessors	Client compliance lead and system administrators	Recurring, peaks before an assessment	Number of identity sources to export from, log retention settings and how well account lists are maintained
External review or testing	Independent tester or assessor, engaged by the client	Recurring or per engagement	Scope of identity testing, number of applications and environments in scope, and whether testing covers the identifier process
Assessor sampling time	Independent assessor, paid by the client under its contract	Per assessment	Number of sampled accounts, number of identity sources and how quickly the client produces final-form evidence

Who owns identification, who can help, and where the assessor stops

The organization owns identification. It decides who and what gets an identifier, who approves each account, how identifiers are named and retired, and which procedures govern them. Those decisions are management and policy decisions, so they cannot be delegated to a consultant or a software vendor. The organization also has to operate the process after the assessment, which is where most identifier gaps appear.

Identifier policy: Define what counts as a user, a process acting for a user, and a device, and the naming scheme for each.
Account approval: Name who authorizes new accounts and what evidence of that approval is retained.
Account inventory: Maintain the list of system accounts that assessors will ask for, and keep it current.
Ownership: Assign a named owner for each identity source, directory and service account.
Operations: Run recurring reviews so identifiers match current staff, contractors and devices.

Before engaging anyone, confirm that your written procedures describe the process as it actually runs, because an assessor will compare the two.

Common identification gaps that fail the requirement and how to close them

Most identification failures under IA.L2-3.5.1 come from accounts and devices that exist without a clear owner or a current record. Assessors test whether every identity can be traced to a person, process or device, and these gaps break that trace. Each card below names a gap, why it matters, and the closing action to take before an assessment.

Shared generic accounts

A single login used by several staff, such as a shared administrator or a common helpdesk account, means the system cannot tell which person acted. Assessors look for an identifier that maps to one individual for each session. Close the gap by issuing named accounts to each person, moving shared access into role assignments, and retiring the generic login or restricting it to documented break-glass use with logged, reviewed access. Confirm how your platform records the named user behind any privileged action.

Service accounts with no owner

Processes that act for users or other systems often run under accounts that nobody registered or is responsible for. Without an identifier linked to an accountable owner, the process cannot be traced when it misbehaves. Build an inventory of service accounts with the team that owns each one, the purpose, and the system it touches. Assign every entry a unique identifier and remove accounts that no owner can justify. Process identities are one of the three objectives an assessor checks under 3.5.1.

Directories out of sync with applications

When an application keeps its own user list, accounts created or changed in the corporate directory may not match what the application holds. Two records for one person, or an application account with no directory source, leaves identities that cannot be vouched for. Connect applications to one authoritative source through federation or sign-in delegation, and confirm that account creation, change and removal flow from that source. Keycloak user federation and authentik providers are two open-source ways to delegate sign-in to a single directory.

Unregistered devices

Devices that access the system without a recorded identifier cannot be distinguished from unauthorized hardware. This matters for laptops, servers, network equipment and any device that joins the network under its own identity. Maintain a device inventory that gives each authorized device a unique identifier, and ensure unknown devices are refused or flagged. Ask your assessor which device evidence they will expect, since the device objective of 3.5.1 is tested separately from user identification.

Departed users still listed

Accounts for people who have left the organization, changed roles, or no longer need access remain active in many environments. Each stale account is an identity the organization cannot justify, and assessors check that current accounts match current personnel. Tie account removal to HR and contract end events, and reconcile system account lists against the personnel roster on a set schedule. Identity lifecycle tools such as midPoint can create, update and delete accounts on connected systems from user changes, which reduces manual cleanup.

Identifiers reused after deletion

When a deleted account's name is given to a new person, the new account inherits the old account's history, group memberships and audit trail. This blurs who did what and can grant unintended access. Set a rule that identifiers are not reissued for a defined period after deletion, and record the retention period in your account management procedure. Note that the reuse rule is its own requirement, IA.L2-3.5.5, so confirm the period and enforcement method with your assessor.

How long, how much effort and what help IA.L2-3.5.1 needs

How much effort does IA.L2-3.5.1 identification take?

For most organizations the effort is mainly in inventory and clean-up, not in writing new technology. You need a complete list of user accounts, service and process identities, and device identities, each with an owner and a purpose, and you need to show that every one of them is unique. The NIST SP 800-171A assessment objectives for 3.5.1 cover three checks: system users, processes acting on their behalf, and devices. Effort rises with the number of directories, legacy systems, shared logins and undocumented service accounts. The fastest way to size it is a discovery pass across your identity provider, directories and endpoint management tools, then a count of accounts that do not map to a named owner. Ask any provider to base its quote on that inventory.

Can we do IA.L2-3.5.1 in-house without outside help?

Yes, the organization owns its controls and can meet 3.5.1 with its own staff. The requirement is a policy and operating practice backed by evidence, so an internal team that understands the identity estate can do the work. Outside help is most useful for three gaps: no current account inventory, shared or orphaned identities that need redesign, and an unfamiliar identity product. An implementation partner can prepare systems and evidence, but it cannot assess you or issue a report. Only an independent assessor or certification body can do that. Decide early which parts you will keep, such as ownership decisions and sign-off, and which you will buy, such as configuration and evidence collection.

What does the team need to provide for the work?

The work needs named owners who can answer for each account class. Identity administrators must confirm how users, service accounts and devices are created and who approves them. Application owners must say which identities their systems use. Security or compliance staff must define what evidence will be kept and who reviews it. Someone with authority must accept the system security plan and the final evidence, since assessors only accept evidence in final form. Expect the directory administrator, the IT operations lead and the compliance lead to spend the most time. Ask any provider to name the internal roles it expects before the scope is signed.

How does IA.L2-3.5.1 relate to authentication and identifier reuse?

IA.L2-3.5.1 establishes who or what each identity is, and the other requirements build on that foundation. IA.L2-3.5.2 verifies that identity before access is granted. IA.L2-3.5.5 prevents identifiers from being reused, so a new account cannot inherit an old account's history. IA.L2-3.5.6 disables identifiers after a defined inactivity period. The CMMC Assessment Guide describes 3.5.1 as the vetted identity that the access control requirement AC.L2-3.1.1 relies on. In practice, one unclear identifier can weaken several requirements at once, so resolve duplicates and shared accounts before you configure authentication.

Which open-source tools help with identification?

Several self-hosted platforms can serve as the identity source your evidence draws from. authentik acts as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to it. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. Keycloak user federation connects to existing LDAP or Active Directory servers and synchronizes users, so directory accounts are used for application sign-in. midPoint creates, updates and deletes accounts on connected systems based on user changes and role assignments. Confirm each product's capabilities against its documentation and your own environment before you choose one.

What changed for certification after the Phase II suspension?

On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. A 60-day review by a CMMC Reform Task Force followed. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page indicates that implementation may only require self-assessments at Levels 1 and 2 for now, while the eCFR text of 32 CFR 170.3(e) still shows the original schedule. Confirm the current status with your contracting officer before you plan certification spending. Whatever the timing, 3.5.1 must still be MET because it cannot be placed on a POA&M.

What does a 3.5.1 assessment cost, and what drives it?

No official figure for 3.5.1 alone is supplied here, so ask for one based on your scope. The cost has a few parts: internal staff time to build the inventory, any identity product licensing or hosting, implementation services if you buy them, and the independent assessment fee if a certification assessment applies to your contracts. Recurring costs include account reviews and maintaining the inventory as people join and leave. Costs rise with the number of directories, legacy applications and undocumented service accounts. Ask any provider for a written quote that separates one-time setup from recurring operations, and that names which deliverables and evidence it includes.

How long does IA.L2-3.5.1 take to implement?

No duration is supplied here, so confirm the timeline against your environment. The main variables are how many identity sources exist, whether shared or service accounts need redesign, and how quickly your owners can confirm them. An organization with a single directory and a current inventory will move faster than one that must reconcile several directories and undocumented accounts. Build the schedule around the inventory and owner sign-off steps, since those tend to set the pace. Ask any implementation partner to show the milestones in its written scope before work starts.

How DeployOpen prepares identification evidence for your assessment

DeployOpen starts by agreeing the identity scope in writing before any work begins. The scope names the systems that hold or process CUI, the user populations (employees, contractors, service staff), the process accounts that run on their behalf, and the device types that may reach the environment. Your organization owns the identity policy and the decision on what counts as a unique identifier in its own environment. DeployOpen then implements the self-hosted identity platform inside your infrastructure, which may be a directory such as FreeIPA, an identity provider such as authentik, or federation from an existing Active Directory or LDAP source through Keycloak. The configuration is documented so an assessor can trace each application back to one authoritative source of identity.

The account lifecycle is where most identification gaps appear, so DeployOpen builds the joiner, mover and leaver steps as defined procedures. Where provisioning must reach several connected systems, midPoint can be used to create, update and disable accounts from role assignments, with inbound and outbound rules documented separately. Deliverables typically include the current account list for each in-scope system, a reconciliation report that matches accounts to named people or documented service identities, and the procedure that explains how an account is created and retired. Shared, generic or orphaned accounts are flagged for your decision rather than quietly reassigned.

DeployOpen prepares these materials for your review, but it does not issue assessment results, scores or attestations. Only an independent assessor from a C3PAO, or your own self-assessment process where that applies, reaches a finding on IA.L2-3.5.1. Before the assessment, confirm with your assessor which evidence forms they accept, how they want account lists exported and dated, and whether they will sample privileged accounts separately. Ask any implementation partner to state in the quote which systems are excluded from scope and who keeps the evidence current after handover.

IA.L2-3.5.1 Identification