03.05.05 Identifier management: requirements and evidence

What 03.05.05 identifier management requires for CUI systems

Requirement 03.05.05 asks the organization to authorize identifiers before they are assigned, select and assign them uniquely to individuals, groups, roles, services and devices, stop identifiers from being reused for a defined period, and mark each individual's status, such as contractor or foreign national. For a compliance lead with an assessment coming, the first task is to recognize that no single team owns all of that. HR knows who has started, moved or left, IT creates the accounts, and system owners decide which applications and roles a person needs. The identifier process runs across those three groups, and an assessor will ask whether they follow one documented path.

The risk is simple to state. A shared or orphaned account hides who touched CUI. If a contractor's login outlives the contract, or two people use the same service account, the audit trail in 03.03 cannot tell you who acted. The requirement has two organization-defined parameters that you must set yourself: the time period for preventing identifier reuse, and the characteristic that marks each individual's status. NIST's discussion names contractors, foreign nationals and non-organizational users as examples of status characteristics. Pick the values, write them into the identification and authentication policy, and confirm with your legal or export compliance lead that the status marking matches how your organization already classifies people.

Do not treat a Rev. 2 control as the finish line. NIST's change analysis traces 03.05.05 to Rev. 2 requirement 3.5.5 but classifies the change as significant, because Rev. 3 asks for more detail and foundational tasks. If your evidence is a list of accounts from an earlier assessment, expect to add the authorization records, reuse-period settings and status fields that the assessment procedure in SP 800-171A Rev. 3 examines. Confirm the exact determination statements with the NIST SP 800-171A Rev. 3 assessment procedure before you size the work, and ask any implementation partner to map each statement to a named artifact in your environment.

Which identifiers and systems fall under 03.05.05

03.05.05 applies to every identifier that lets a person, group, role, service or device act on a system that handles CUI. The cards below cover the identifier types, the directories that issue them, and the scoping choices that change how much work the requirement creates. Organizations set the ODP values for reuse periods and status characteristics, and those values must be written down.

Individual user identifiers

Each person who reaches a CUI system needs a unique identifier that is assigned only after an authorized person or role approves it. Check whether employees, contractors, subcontractor staff and non-organizational users each receive a named identifier, and whether shared logins exist anywhere in the enclave. Confirm who holds the authority to approve each assignment and keep that approval on record.

Group and role identifiers

Groups and roles collect individuals for access decisions, so each one needs its own unique identifier and a named owner. Inventory every group that grants access to CUI repositories, administrative consoles or ticketing systems, and record who may add members. Role accounts used by automation should be tied to a documented owner so that an orphaned role cannot persist unnoticed.

Service and device identifiers

Service accounts, API clients and machine identities also count as identifiers under 03.05.05, even though no person signs in with them. Build an inventory that names the owner, purpose and target system for each one. Device identifiers that are managed by 03.05.02 should be reconciled against the same inventory so that a retired host does not keep a valid identity.

Authoritative directories and identity providers

Identifiers are usually issued by a central directory, such as an LDAP-based store, and then passed to applications through single sign-on or provisioning. Open-source options include FreeIPA, which stores users, groups and hosts in 389 Directory Server, and Keycloak, which brokers logins for applications. Identify which system is the source of truth for each identifier type, because an application that creates local accounts outside that source breaks the unique-assignment rule.

Contractors and foreign nationals in the same directory

03.05.05 requires individuals to be marked with a characteristic that shows their status, such as contractor, foreign national or non-organizational user. Decide whether these people live in the same directory as employees, with a status attribute, or in a separate one. A single directory simplifies reporting, but only if the status attribute is mandatory and enforced at creation. Confirm which characteristic your federal agency or your own policy expects you to use.

Separate CUI enclave identity stores

If the CUI enclave runs its own identity store, its identifiers are a separate population that must still meet the reuse, uniqueness and status rules. Ask whether enclave accounts are provisioned from the corporate directory, typed in by hand, or copied from another system. Synchronization gaps are a common source of duplicate or stale identifiers, so document the provisioning path and the reconciliation schedule.

How an assessor tests identifier management

This table maps each assessment method in SP 800-171A Rev. 3 to the evidence an assessor examines, the people they interview, and the mechanisms they test for 03.05.05. Use it to prepare the artifacts and walkthroughs before the assessment begins, since the same gaps tend to appear across organizations.

Assessment element	What the assessor does	Evidence to have ready	Common finding
Examine: policy and procedures	Reads the identification and authentication policy and the identifier management procedures for authorization, uniqueness, reuse and status rules	Dated, approved policy and procedure documents that name the reuse period and status attribute	Procedures exist but omit the defined reuse period
Examine: account management procedures	Checks how identifiers are requested, approved and assigned for people, groups, roles, services and devices	Account request and approval records tied to the named authorizing role	Identifiers assigned by administrators without a recorded authorization
Examine: system design documentation	Confirms how the directory or identity platform enforces unique identifiers and records individual status	Architecture diagrams and directory schema showing the status attribute	No documented design for how status is stored or enforced
Examine: list of system accounts	Samples the account list and matches each identifier to a person, group, role, service or device	Exported account inventory with owner, type and status fields	Shared or generic accounts with no owner, and stale service accounts
Interview: identifier management personnel	Asks who authorizes identifiers, how reuse is blocked and how status changes are handled	Named owners and a walkthrough of a recent identifier request	Staff describe a practice that the written procedure does not require
Interview: security and system developers	Confirms how application and platform identifiers are created and retired	Developer notes on service identifiers and their lifecycle	Developers create service identifiers outside the managed process
Test: identifier assignment mechanisms	Creates or requests a test identifier and checks that authorization, uniqueness and status are enforced	Test records showing a rejected duplicate and a status value on each account	Duplicate identifiers accepted, or status is optional
Test: reuse prevention	Checks that a retired identifier cannot be reissued within the defined period	Configuration showing the reuse window and a test of reissue	Reuse period defined in policy but not enforced by the system
ODP check: reuse period and status characteristic	Confirms both organization-defined parameters have values, a period for reuse and a characteristic for status such as contractor or foreign national	Signed values for the reuse period and the status characteristic, referenced in the system security plan	One or both parameters left blank, so the requirement is not fully met

How to implement identifier management in order

This sequence turns 03.05.05 into a working process: the two organization-defined values are settled first, then authorization, naming, status marking and reuse prevention are built on top of them, and the procedures are written down last so they describe what actually runs.

Settle the two organization-defined parameters
Before anything is configured, decide the time period for preventing reuse of identifiers and the characteristic that marks each individual's status. Ask the federal agency that holds your contract whether it specifies values, and check DoW CIO guidance if your contract or the proposed FAR overhaul applies. Where no value is specified, your organization must assign it to complete the requirement. The output is a signed ODP decision record that names both values, the reason for each and the approver, and that every later step cites.
Define the authorization step before assignment
Write down who may request and approve a new identifier for an individual, group, role, service or device. The requirement expects authorization from organizational personnel or roles before any identifier is assigned, so the approver should be a role separate from the person doing the provisioning where your staffing allows. Confirm the approval path in your identity system's request or ticket workflow, then test it by attempting an assignment without approval. The output is an approval matrix and a tested workflow record.
Establish unique naming and identifier formats
Set one naming standard for each identifier type: individuals, groups, roles, services and devices. Each format should make an identifier unique within the system and recognizable by type, so an audit can tell a person's account from a service account at a glance. Tie individual identifiers to a single authoritative source, such as an HR or directory record, so one person cannot receive two identities. The output is an identifier naming standard reviewed by the identity owner and filed with the system security plan.
Configure status attributes for individuals
Add the characteristic chosen in your ODP record to every individual identity as a required attribute. NIST's discussion gives contractors, foreign nationals and non-organizational users as examples of status characteristics, so confirm which categories your contracts and access rules need. In the directory or identity provider, make the attribute mandatory at creation and restrict who can change it. The output is a configuration export or screenshot showing the attribute on sampled accounts, plus a list of attribute values in use.
Implement reuse prevention for identifiers
Configure the directory or identity provider so a retired identifier cannot be assigned to another person for the period set in your ODP record. Many platforms reuse deleted names by default, so check this setting explicitly. Where the platform cannot block reuse, record a documented procedure and an automated check that flags any new identifier matching a retired one. The output is a tested reuse block, with a test case showing that a retired identifier is rejected during the defined period.
Connect lifecycle events to identifier changes
Link the identifier lifecycle to the events that change access, so disabling, renaming or retiring an identifier happens when an individual leaves, changes status or stops needing a service or device. In a self-hosted stack, this is often done by provisioning connectors that push creations, changes and deletions to downstream applications. Confirm which systems receive these changes and how deletions propagate. The output is a connector map and a sample lifecycle run showing one identifier moving from creation through retirement.
Document the identifier management procedures
Write the procedures that operators follow: request and approval, naming, status marking, reuse blocking, retirement and exception handling. Map each step to the ODP decision record and the naming standard so an assessor can trace one requirement to one procedure. Have the identity owner and the security lead sign off, and set a review point in the system security plan. The output is an approved identifier management procedure, cross-referenced to the policy and procedures documents for the Identification and Authentication family.

Evidence that passes a 03.05.05 review

An assessor testing 03.05.05 looks for a written policy, a working procedure, and records showing that identifiers are authorized, unique, retired on schedule, and tagged with each person's status. The cards below cover the artifacts most often requested and how to keep each one current between assessments, since a stale export or an undated procedure weakens an otherwise sound process.

Identification and authentication policy

The organization-owned policy sets out who may authorize a new identifier, which identifier types exist (individuals, groups, roles, services and devices), and the rules for reuse and status marking. Assessors read it first and compare it with the procedure and system behavior. Check that the policy names an owner, a version, an approval date and a review cycle, and that the reuse period and status characteristic appear in it as defined values rather than blanks.

Identifier management procedure

The procedure is the step-by-step record of how identifiers are requested, approved, created, changed and retired, and who performs each step. Interviews with personnel who manage identifiers test whether they follow it. Keep it tied to the directory or identity provider in use, name the system roles that perform each action, and record the review date so it can be shown to match current tooling.

Approval records for new identifiers

For each identifier created, the assessor expects evidence that an authorized person or role approved it before assignment. A ticket, workflow approval or signed request that links the requester, the approver and the identifier is enough. Sample a range of new accounts, service identities and device identities, then confirm each one has a matching approval. Gaps in this trail are among the most common findings under this requirement.

Directory exports with unique IDs and status

A dated export from the directory, such as FreeIPA's user and group records or the user store behind Keycloak, shows that each identifier is unique and that each individual carries the status attribute chosen as the ODP value, such as contractor or foreign national. Scheduling the export monthly and retaining prior copies lets you show the state at any past date. Confirm the export includes disabled and retired accounts, not only active ones.

Reuse-prevention settings and retirement records

Show the configured period during which a retired identifier cannot be reissued, along with the system setting or procedure that enforces it. Retirement records should list each deactivated identifier, the date it was retired, and the date it became eligible for reuse, if at all. The period is an organization-defined parameter, so the assessor will check that a value was set and is applied consistently across directories and connected applications.

System account list and design documentation

The list of system accounts is a point-in-time inventory of every account, group, role, service and device identity across the in-scope system. Design documentation shows how the identity provider, directory and provisioning connectors fit together, including how a status change propagates to target applications. Review both together each quarter, because an account list that omits service identities or a diagram that predates a connector will raise questions during testing.

How identity sources feed application access

For 03.05.05, the identifier decisions are made once, in the place that holds the identity record, and then pushed outward. A central directory such as FreeIPA, or an identity broker such as Keycloak or Zitadel, becomes the authoritative store for each person's identifier, group and role memberships, and the status characteristic the organization has chosen to mark individuals with, such as contractor or foreign national. The authorization step the requirement describes should happen before a record is created there, and the approval should be traceable to the person or role that gave it. Keycloak and Zitadel mainly handle sign-in, so confirm which system is the source of truth for identifiers before you map any downstream account to it.

Provisioning is the mechanism that carries those decisions to applications. In the authentik SCIM provider, user and group creations, changes and deletions are pushed to target applications over SCIM 2.0, with a full sync every hour, and users are deprovisioned from the target when they lose access. Ask each application owner whether it accepts SCIM or another automated feed, and whether deletion is a hard delete or a deactivation. Deactivation keeps the identifier occupied, which may be what you want for the reuse period, but it must be recorded and checked. The time period for preventing reuse is an organization-defined parameter, so set it in policy before you configure any sync job.

Deprovisioning is where reuse and retirement decisions take effect in practice. A policy that says an identifier cannot be reissued for a defined period means nothing if an application still holds a stale account that a new hire can claim. Every application that keeps a local account store, including appliances, legacy databases and administrative consoles that do not accept federated sign-in, is a separate place where 03.05.05 must still be shown. Inventory those stores, record how each one is created and removed, and plan for manual evidence where no automated path exists. Illustrative example: a contractor whose status is recorded in the directory is deactivated centrally, but a local admin account on a build server remains active, and that gap is the finding an assessor would look for.

Open-source options for identifier management

authentik's SCIM provider addresses the lifecycle side of 03.05.05. It pushes user and group creations, changes and deletions to target applications over SCIM 2.0, so an identifier assigned in the source directory is created in downstream systems and removed from them when access ends. This gives an assessor a traceable path from an authorized request to an account in each application. The provider runs a full synchronization every hour and deprovisions users from the target when they lose access, which supports the requirement that identifiers are not left active after a person's role ends.

Provisioning trail: Creations, changes and deletions are logged at the provider, which can be exported as evidence of when each identifier was assigned or removed.
Hourly full sync: A scheduled full sync corrects drift caused by missed events, and the sync configuration is part of the evidence for periodic reconciliation.
Deprovisioning on access loss: Removal from the target when access ends supports the reuse controls you define, but only if target applications honor SCIM delete operations.
Status attributes: authentik does not decide which characteristic marks a contractor or foreign national. Your organization must map that status into a field the provider reads.
License: authentik is released under the MIT license, which permits self-hosted use without a commercial subscription.

Confirm in your own version which attributes are synchronized, how the reuse period is enforced outside the provider, and whether each target application supports SCIM 2.0 deletes.

What 03.05.05 costs in money and effort

This table breaks down the cost components of meeting 03.05.05 Identifier management, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to shape a written scope and quote, since no supplied figures establish prices or durations. The main takeaway is that self-hosted open-source directories carry no license spend, so most of the cost sits in engineering, the ODP decisions and evidence upkeep.

Cost component	Who is paid	One-time or recurring	What drives it
Directory and identity tooling	Infrastructure provider and internal platform team (open-source licenses carry no fee)	One-time build, then recurring hosting and patching	Number of identity sources and directories in scope
Engineering to model status and provisioning	Implementation partner or internal identity engineers	One-time, with recurring changes when roles change	Number of individual status types such as contractor or foreign national
ODP decisions (reuse period and status characteristic)	Organization leadership, compliance lead and a implementation partner for drafting	One-time, revisited at each review cycle	Number of federal agencies or contracts that set or confirm values
Integration of applications with local accounts	Application owners and platform engineers	One-time per application, plus recurring for new apps	Count of applications that keep local accounts outside central identity
Evidence upkeep (logs, provisioning records, account reviews)	Internal compliance and security operations staff	Recurring	Frequency of joiner, mover and leaver events and retention settings
Contractor and non-organizational user onboarding	HR, sponsoring managers and identity administrators	Recurring	Contractor volume and turnover, and how often status changes
External review or readiness check	Independent assessor or consultant, as scoped	Periodic, tied to assessment cycle	Scope size, documentation quality and number of sampled identities
Assessor sampling and interviews	Assessor (fee set by the assessing body and agreed contract)	Periodic, per assessment	Number of identifiers sampled and quality of the examine evidence

Where identifier management usually fails review

Assessors reviewing 03.05.05 tend to test whether identifier rules exist in a working system, not only in a policy document. The gaps below cluster around undefined parameters, ownerless accounts, missing status markers, disconnected applications and unenforced reuse rules, and each one shows up quickly when an examiner compares the directory with the procedures.

ODP values never defined

03.05.05 has two organization-defined parameters: the period for preventing identifier reuse and the characteristic that marks each individual's status. Many organizations never write either value down, so the requirement cannot be assessed as complete. Ask who set each value, when it was approved and where it is recorded in the system security plan. Confirm that the same values appear in the identity provider configuration and the procedures an interviewed administrator describes.

Shared accounts without owners

Generic logins such as shared service mailboxes, break-glass accounts or a common administrator user often have no named owner in the directory. An assessor who asks who used an identifier on a given date gets no answer, which breaks the requirement to assign identifiers to a specific individual, group, role, service or device. Each shared or service identifier should carry a named accountable owner, an assignment record and a documented authorization.

No status characteristic for contractors

The requirement expects each individual's status to be marked with a defined characteristic, such as contractor, foreign national or non-organizational user. Many directories only distinguish employees from everyone else, so contractors look like staff in reports and access reviews. Check whether a status attribute exists on every account, whether it is populated at creation, and whether reports can filter by it. Without that marker, the organization cannot show that status-based controls were applied.

Orphaned application accounts

Applications that keep local user tables, or that were connected to the directory only for login, often retain identifiers after the person leaves. These orphaned accounts remain assigned and may be reused or dormant. Compare application user lists against the directory export at regular intervals. Where a connector exists, such as the SCIM provisioning that authentik documents for pushing user and group deletions to target applications, confirm that deprovisioning runs and test it with a sample account.

Reuse rules that exist only in policy

A policy may forbid reusing an identifier for a defined period, yet the directory allows an administrator to recreate a deleted username immediately. Assessors test the mechanism as well as the document, so they look for a configured retention rule, a tombstone or a blocked-name list, and an audit record of the attempt. Confirm which directory or identity platform enforces the period, how the value is set, and what happens when an identifier is requested inside that window.

Questions about 03.05.05 cost, effort and ownership

Who sets the reuse period and the status characteristic for 03.05.05?

The organization sets both values, because 03.05.05 has two organization-defined parameters: the time period for preventing identifier reuse, and the characteristic that marks each individual's status, such as contractor or foreign national. NIST does not assign these values. If the contracting agency specifies them, use those values; if it does not, the organization must choose and document its own. Confirm with the contracting officer or the program office whether the agency has published values or expects a particular reuse period. Record the chosen values in the system security plan so an assessor can check that the implementation matches the documented parameters.

Does 03.05.05 require one central directory?

No. The requirement describes outcomes: authorized assignment, unique identifiers, no reuse for the defined period, and a status marker for each individual. It does not name a product or a directory design. Many environments meet it with a single identity provider or directory, but the organization can also meet it with several systems if each one enforces the same rules and the assessor can trace identifiers across them. A central directory usually makes the evidence easier to produce, because one set of records answers the questions about assignment, reuse and status.

How much effort does assessment preparation for 03.05.05 usually take?

No supplied figure gives an effort estimate for this requirement, so confirm the scope with your assessor or the contracting agency before planning. Effort is driven mostly by the number of identifier sources, how many systems issue or consume identifiers, whether the processes are documented, and whether records of past assignments exist. An organization with one directory and written procedures needs less preparation than one with local accounts on many systems. Ask for an effort breakdown in any quote, separated into inventory, procedure writing, configuration changes, and evidence collection.

Can our own team implement and document 03.05.05 without outside help?

Yes, if your team has the skills to configure identity systems and the time to document decisions. The organization owns the control, so internal staff can define the parameters, configure the directory and write the procedures. Outside help is most useful when the environment is fragmented, when there is no documented identifier lifecycle, or when the team lacks capacity to collect evidence. Whatever you decide, the independent assessor must still review the work, and the assessment result belongs to the organization and the assessing body, not to any consultant.

What does a partner handle for 03.05.05 and what stays internal?

A partner can prepare the systems and evidence: reviewing identity configurations, setting up identifier workflows in the chosen platform, documenting procedures, and assembling records that show assignment, reuse prevention and status marking. DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's infrastructure, and most engagements are fixed-scope with the scope agreed in writing first. Decisions that stay internal include the parameter values, who is authorized to request identifiers, the personnel status categories, and accountability for the control. Only an independent assessor can issue findings, and DeployOpen does not issue reports or certifications.

How do the Rev. 2 and Rev. 3 versions change the evidence for identifier management?

The core expectations are similar, but Rev. 3 is more detailed. NIST's change analysis traces 03.05.05 to Rev. 2 requirement 3.5.5 and classifies the change as significant, with more detail and foundational tasks. Rev. 3 also makes the two organization-defined parameters explicit, so the evidence must show the chosen values. Contracts may still reference Rev. 2. Confirm with the contracting agency which revision applies, since CMMC Level 2 assesses the Rev. 2 requirement as IA.L2-3.5.5 and that scoring depends on the revision in the contract.

What evidence should we prepare to show identifier management works?

Prepare the documents and records that an assessor would examine and test. Typical items include:

Identification and authentication policy and identifier management procedures
Account management procedures and the list of system accounts
System design documentation showing how identifiers are created and stored
Records of identifier requests, approvals and assignments
Configuration exports showing reuse restrictions and status attributes

Confirm the exact evidence list with your assessor, since the method used for each item may differ.

Who owns identifier management and who can help

The organization owns 03.05.05 Identifier management, including the decisions it cannot hand off: who may receive an identifier, how long a retired identifier stays blocked from reuse, and which characteristic marks each person's status, such as contractor or foreign national. NIST treats these as organization-defined parameters (ODPs), and if the federal agency that holds the contract does not supply values, the nonfederal organization must assign them itself to complete the requirement. Those values should be written into the system security plan and approved by the people accountable for the CUI environment before anyone configures a directory. An implementation partner can help draft the options, but the choices and their justification must be the organization's.

An implementation partner can do the technical work that produces the evidence. That typically means configuring the directory and identity sources, setting up provisioning so identifiers are created only after an approval step, adding status attributes to user records, and turning on the logging that shows when an identifier was issued, changed or disabled. Self-hosted open-source platforms such as FreeIPA, Keycloak and authentik can support this work inside the organization's own infrastructure, but the partner should confirm each capability against the version in use rather than assume it. DeployOpen prepares systems, controls and evidence in this way. It does not issue assessment results, attestations or certifications.

Only an independent assessor can issue the assessment result that a contract or the Supplier Performance Risk System relies on, and the assessment is tested against the version of SP 800-171 the contract names. Before engaging anyone, confirm with the contracting officer which revision applies, because the answer changes which assessment procedure the assessor follows for 03.05.05. Ask any partner to show the approval workflow, the reuse-prevention period and the status attribute as configured in your environment, and to hand over the evidence in a form an assessor can examine and interview against. That written scope and evidence list, agreed before work starts, is the document that tells you whether outside help has done its job.

03.05.05 Identifier management