IA.L2-3.5.5 Identifier reuse: requirements and evidence

IA.L2-3.5.5 identifier reuse: what a CMMC assessor expects you to prove

IA.L2-3.5.5 requires you to define a period during which user, group, role and device identifiers cannot be reused, and to prevent reuse inside that period. If you are preparing a Level 2 self-assessment or a certification assessment, the question an assessor will ask is simple: what is your reuse window, where is it written down, and how do you know no identifier was recycled inside it? The risk behind the rule is concrete. When a new hire or a re-created account receives the same username, the same group memberships or the same role assignments as a former account, it can inherit access that was never reviewed for the new person, and audit logs may attribute new activity to an old identity. Both problems undermine the traceability that other Level 2 controls depend on.

The rule is easy to state and hard to show consistently because identifiers live in many places at once: the directory, the HR system, cloud tenants, the ticketing system, VPN and remote access tools, application databases, and device inventories. Each system may generate and delete identifiers on its own schedule. A practical starting point is to write one identifier management procedure that names the authoritative source for each identifier type, sets the reuse period, and states who approves exceptions. Then confirm that the directory or identity provider enforces that procedure, and that the downstream applications do not quietly reissue names. A reasonable evidence set for this requirement includes the written procedure, the list of system accounts and identifiers the assessor can compare against your records, and test results showing a deleted identifier was not reissued within the defined period (illustrative: a leaver's username is re-requested during the window and the provisioning workflow rejects it). Confirm with your assessor which specific artifacts they will accept for your environment, and check the assessment objectives in NIST SP 800-171A before you collect anything.

Which systems and identifiers fall under the reuse rule

IA.L2-3.5.5 applies wherever the assessed environment creates or stores identifiers that can grant access to CUI. The scoping questions below decide which directories, accounts and devices your assessor will expect you to cover, and each one changes the amount of work.

CUI systems and their directories

Start with the systems inside the CUI boundary, then identify the directory that issues identities for them. If several applications authenticate against one central directory, that directory is usually where the reuse rule is tested. Confirm whether a second local user store exists on any in-scope server or appliance, because assessors check each identifier store separately. Document the directory's reuse period and the procedure that enforces it.

User, group and role identifiers

Every user account, group and role that can reach CUI falls within scope, including accounts created for contractors and temporary staff. Groups and roles matter because a recycled group name can silently reattach old permissions to a new team. Ask your administrators to show how a deleted user, group or role is retired and how its name is blocked for the defined period.

Device identifiers

Device identifiers cover workstations, servers, laptops and network-attached equipment that authenticate to in-scope systems. A reimaged or replaced device that reuses a hostname or machine identifier may inherit trust, logging history or policy assignments it should not have. Confirm how device records are removed from the directory when hardware is retired, and whether the same name can return within the reuse period.

Service and process accounts

Service accounts, scheduled tasks and integration accounts often survive staff changes and are easy to overlook. An assessor will expect them on the list of system accounts if they can access CUI. Identify the owner of each account, decide whether it is an identifier for reuse purposes, and record when it is removed so a replacement cannot pick up its old rights.

Physical access control identifiers

Badges, key fobs and access control panels issue identifiers that can be tied to people and to the systems they reach. NIST SP 800-171A names the list of identifiers generated from physical access control devices as a potential assessment object for 3.5.5. Check whether badge numbers are ever reissued, and whether the access control system and the IT directory retire the same person's identifiers together.

Third-party SaaS and managed service providers

A SaaS application or managed service provider that stores or processes CUI can bring its own identifier store into scope. Your contract and the provider's system security documentation should say whether that provider reuses identifiers and for how long. Ask for the provider's identifier management procedure and the evidence it produces, and confirm which party is responsible for each step.

How an assessor tests identifier reuse

NIST SP 800-171A breaks requirement 3.5.5 into two assessment objectives. The first is that the organization has defined the period within which identifiers cannot be reused. An assessor starts by reading the identifier and account management procedures to find that period stated as a value, not as a phrase such as "for a reasonable time." The second objective, preventing reuse within that period, depends on the first, because a test cannot pass against a period nobody wrote down. The assessor checks that the procedure names the identifier types it covers, including user, group, role and device identifiers, and that the period is the one the system actually enforces.

Written value: The procedure states the reuse period as a defined duration that the assessor can compare against configuration.
Scope of identifiers: The procedure covers user, group, role and device identifiers, not only user accounts.
Ownership: The document names the role responsible for approving the period and for changing it.
Consistency: The period matches the directory, identity provider and any ticketing workflow used for provisioning.
Final form: The assessor reviews an approved, dated version. A draft or an unsigned revision does not count toward MET.

Before the assessment, confirm that the defined period appears in the approved document and matches what the identity platform enforces.

Implementing identifier reuse prevention step by step

This sequence turns IA.L2-3.5.5 from a written intent into a configured, tested and documented control, so an assessor can see that a retired user, group, role or device identifier cannot be handed to a new account during the defined period.

Inventory every identifier store in scope
Start by listing each place where user, group, role or device identifiers are created: the directory, the identity provider, local accounts on servers and workstations, application databases, and any physical access control system that issues identifiers. The system security plan boundary tells you which stores count. The owner of each store is responsible for confirming it is complete. The output is a dated identifier inventory with a named owner and the creation method for each store, which becomes the first assessment object an assessor will request.
Set and document the reuse period
The organization decides the period during which a retired identifier may not be issued again, then writes it into the identifier management procedure. NIST SP 800-171A treats defining that period as its own assessment objective, so the value must be explicit, not implied by tool defaults. Ask the security owner and the system owner to approve it and record the approval date. The output is a signed procedure that states the period, the identifier types it covers, and who may request an exception.
Configure the directory or identity provider to refuse reuse
Configure the central directory or identity provider so that a deleted or retired identifier stays reserved for the defined period. Where the platform does not enforce reuse by default, add a check in the provisioning workflow that rejects a new account matching a reserved identifier. For self-hosted directories such as FreeIPA, and identity brokers such as authentik, confirm the exact behavior in the product documentation for your version before relying on it. The output is a saved configuration export and a written note of which setting or workflow enforces the rule.
Extend the rule to groups, roles and devices
Apply the same reservation logic to group names, role names and device identifiers, not only to user accounts. Device identifiers often come from asset tools, certificates or hostname schemes that bypass the directory, so the owner of each source must be included. Where an application keeps its own role table, the rule must be enforced there too. The output is an updated identifier inventory that marks, for each store, whether reuse is blocked by the platform, by a workflow check or by a manual procedure.
Test with a deliberate reuse attempt
Test the control the way an assessor will. Create a test identifier, retire it through the normal offboarding path, then attempt to create a new account, group, role and device with the same identifier inside the reuse period. Repeat the attempt after the period has passed to confirm the rule expires as documented. Run the test in a non-production or test tenant where possible, and record who ran it. The output is a test script with expected and actual results for each identifier type.
Record results and retain evidence
Record each test result, any failure, the corrective change and the retest that confirmed it. Keep the procedure, configuration exports, inventory, test records and change tickets in final form, since assessors accept final evidence rather than drafts. Schedule a review of the inventory and the reuse period at the interval the organization sets in its procedure, and log each review. The output is a complete evidence package that maps each of the two assessment objectives to a named artifact, which the independent assessor can sample during a Level 2 assessment.

Where identifier reuse actually happens

The most common way identifier reuse occurs is not a deliberate decision but a side effect of how accounts are deleted and recreated. An administrator removes a departed employee's account, and weeks later a new hire receives the same username because the naming convention produces it. If the new account inherits group memberships, mailbox references, or entries in application-side permission tables keyed on the old name, the newcomer silently gets the predecessor's access. The same pattern appears with service accounts and role names that teams reuse for convenience. Testing for this path means comparing the account lifecycle log against creation events: any new identifier that matches a deleted one inside the defined period is a finding, and assessors will ask for the period definition itself, which the organization must set and document.

A second path sits inside the directory. Many directories delete an object and release its unique identifier immediately, such as a numeric UID, SID-like value, or object GUID that a downstream system may still reference. A new object can then be created that the target system treats as the old one. Confirm how your directory assigns and retires identifiers, whether deleted objects are retained as tombstones for a period, and whether any application caches identifiers longer than the directory does. Testing combines a directory export with a deletion-and-recreation exercise in a non-production tenant, recording whether the new object receives a fresh identifier. The third and fourth paths involve identities that are matched on attributes rather than identifiers. A cloud tenant or SaaS application that links accounts by email address will attach a new user to a dormant profile when the address is reissued, which is why provisioning connectors should match on an immutable identifier. Manual account creation outside the directory is the last risk: a local application admin creates an account by hand and bypasses the lifecycle entirely, so no deletion record exists to block reuse. Testing here means reconciling application user lists against the directory and flagging accounts with no directory counterpart. Ask your provisioning and identity platform owners which attribute drives matching in each connected system before the assessment begins.

Evidence that satisfies the reuse requirement

IA.L2-3.5.5 is tested by looking at both the rule and the proof that the rule runs. Assessors want a written procedure with a defined period, lists of accounts and identifiers, directory configuration, and records showing reuse was actually blocked. Each artifact below should be kept current between assessments and held in final form.

Identifier management procedure

The written procedure must state the period during which a user, group, role or device identifier cannot be reused, who owns the rule, and how exceptions are approved. This document answers the first assessment objective directly. Check that the defined period in the procedure matches the value configured in the directory or identity provider, because a mismatch is a common finding. Record the version and approval date so the reviewer can see it was current during the assessment window.

Account and identifier lists

Assessors compare the list of system accounts and the list of identifiers against the procedure. Export the list with creation dates, disable dates and deletion dates, and include groups, roles and device objects, not only human users. Gaps in these lists, such as identifiers that disappear without a deletion record, weaken the case that reuse is prevented. Generate the export from the system of record on a fixed schedule and keep the timestamp on the file.

Directory and IdP configuration exports

Export the settings that control identifier retention from the directory or identity provider, such as the deletion behavior for users and groups and any tombstone or retention parameter. Where a self-hosted platform such as FreeIPA runs the directory, its configuration and the 389 Directory Server settings are the artifacts to retain. Where authentik provisions to downstream applications, export the SCIM provider configuration so the reviewer can see that deletions propagate. Confirm each setting with the vendor documentation for the version you run.

Creation and deprovisioning logs

Logs of account creation, change and deletion show that identifiers move through the lifecycle as the procedure describes. Keep the log entries that record who made each change and when, and make sure the logs are protected from edits. An auditor will sample entries and trace each one back to an approved request. Missing logs for deletions are a high-risk gap because they make the reuse window impossible to verify.

Reuse attempt test records

Test records show that the control works, not only that it is written down. Run a documented test in which an identifier inside the defined period is requested again and confirm the system refuses it. Record the test steps, the account used, the expected result, the actual result and the tester. Illustrative example: an administrator tries to recreate a deleted user name inside the period, and the directory rejects the request with an error that is captured in the test record.

Current evidence between audits

Evidence goes stale quickly, so assign an owner to each artifact and a recurring review date. Collect the exports and test records on a schedule, store them in a repository with version control, and note any configuration change that affects the reuse window. Ask your assessor which format and retention period they expect. Evidence must be in final form, so drafts, unsigned procedures and unrecorded test runs will not count as MET.

What meeting IA.L2-3.5.5 costs in money and effort

This table breaks the cost of meeting IA.L2-3.5.5 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no fixed price or duration applies to every environment. The main takeaway is that open-source licenses remove software spend but not the engineering and evidence work.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Identifier reuse policy and procedure	Internal policy owner or consultant	One-time, then reviewed periodically	Number of identifier types in scope (users, groups, roles, devices) and whether existing account standards already exist
Directory and lifecycle configuration	Platform engineer or implementation partner	One-time build, with change work later	Number of directories, whether an identity provider and FreeIPA or similar are already in use, and how many target applications need provisioning
Engineering time to test non-reuse	Internal engineers or implementation partner	One-time for test design, recurring when systems change	Complexity of account deletion and recreation workflows, and whether reuse is blocked by the platform or by procedure alone
Evidence collection and upkeep	Internal compliance or IT staff	Recurring	How often accounts are created and retired, and whether logs and account lists are exported automatically or by hand
Assessor sampling and assessment support	Independent assessor (for certification) and internal staff	Recurring per assessment cycle	Number of identifiers and account events the assessor samples, and how quickly staff can produce final-form records
Software licenses	Vendor or none for open-source components	Recurring if commercial tools are used	Open-source licenses such as MIT or GPL carry no license fee, but support contracts and hosting still cost money
Remediation if a gap is found	Internal team or implementation partner	One-time per finding	Whether the gap is a missing procedure (cheap to fix) or a platform that cannot block reuse (more engineering)

Who owns identifier reuse work and who should be paid for it

Your organization owns IA.L2-3.5.5 because the requirement is a rule about how your organization manages identifiers, not a product setting. Assessors look for a written identifier management procedure that names the period during which a retired user, group, role or device identifier cannot be reissued, and for evidence that people follow it. Your security and HR or IT administration leads should make those decisions and sign the procedure.

Defined period: Set the reuse-prohibition period in policy, justify it, and record who approved it and when.
Account lifecycle rules: Document how joiners, movers and leavers trigger identifier retirement, and who can request an exception.
Periodic account reviews: Run and record reviews of the account and identifier lists, with reviewer names, dates and actions taken.
Exception handling: Keep a log of any reissue approved early, with the reason and the approver.
Budget for ownership: Staff time for policy, reviews and exception handling recurs every year and is usually larger than the one-time configuration work.

Before you engage anyone, confirm that your own policy names the period, your review cadence and an accountable owner. Partners and assessors cannot supply those decisions for you.

Common gaps that fail the reuse objective

Most failures against IA.L2-3.5.5 are not missing technology. They are gaps in written definitions, in how accounts are created, and in the proof that reuse is actually blocked. Each card below names one gap, why an assessor will notice it, and how to close it before the assessment.

No defined reuse period in writing

The first assessment objective requires the organization to define the period within which identifiers cannot be reused. If the identifier management procedure says only that reuse is prohibited, with no number, the assessor has nothing to test against. Write the period into the identifier management procedure, state which identifier types it covers (users, groups, roles and devices), and make sure the system configuration reflects the same value. A period that exists only in a policy and not in the system is the gap most often found.

Reuse permitted for groups or devices

Teams often lock down user accounts and forget that group names, role names and device identifiers can be recycled just as easily. A new group called after a retired project can silently inherit its permissions and membership history. Check every directory object type in scope, including service roles and asset records tied to physical access devices, and confirm that deletion does not free the identifier for immediate reassignment.

SaaS applications keyed on email address

Many cloud applications link a user to a record by email address. When an employee leaves and a new hire receives the same address, the new person can land in the old account with its data and access. Confirm with each application owner how the application stores its user key and whether it reuses deleted identities. Where the application keys on an email address, document the compensating control, such as an identifier from the central directory and a rule that retired addresses are not reissued during the defined period.

Manual account creation outside the directory

When administrators create accounts by hand in each system, nothing enforces the reuse period, and the records of who held an identifier before are easy to lose. Provisioning from a central source, such as an identity provider that pushes creations and deletions to target applications, gives one place where the reuse rule can be enforced and logged. Ask which accounts are still created manually and whether those exceptions are listed, justified and reviewed.

No test showing the system refuses reuse

A configuration screenshot does not show that reuse is blocked. The second assessment objective is about prevention within the period, so the assessor expects a test. Create an identifier, delete it, and attempt to create the same identifier again inside the defined period, recording the refusal. Repeat for each identifier type in scope and keep the output with the test date and the tester's name. Without this record, the requirement is hard to show as met.

Draft evidence in the assessment package

Assessors accept evidence only in final form, so a procedure marked as a draft, or a test log from a lab run that was never approved, will not count toward a MET result. Before the assessment, freeze the identifier management procedure, the account lists, and the reuse test results with version numbers and approval dates. Check that the system security plan points to the final versions, because a mismatch between the plan and the evidence is a common reason an objective is marked not met.

Questions buyers ask about identifier reuse

How much effort does preventing identifier reuse take?

The effort is usually modest once the identity directory is the single source of account creation, because the control is mostly a setting and a procedure rather than a project. The organization must first define the period during which an identifier cannot be reused, then configure the directory or identity platform so deleted user, group, role and device identifiers are not reissued inside that period. The larger share of effort is documentation and proof: a written identifier management procedure, a list of accounts and identifiers, and test records showing a new account cannot take over an old identifier. Ask any partner to size the work against your actual number of directories and systems, since that is what moves the estimate most.

Can we implement identifier reuse controls in-house?

Yes, an internal team can implement IA.L2-3.5.5 if it has administrators who understand the directory, the identity lifecycle and the evidence an assessor will request. The control has two assessment objectives in NIST SP 800-171A: defining the reuse period and preventing reuse within it. Internal teams often handle the configuration well but struggle to produce evidence in final form, such as a procedure approved by the right owner and screenshots or exports dated within the assessment window. Many organizations keep ownership in-house and bring in an outside party to review the configuration and evidence before an assessor sees it.

What does identifier reuse require from IT and HR?

The control depends on a joiner, mover and leaver process that both IT and HR run. HR must trigger account creation and deletion through a recorded event, so IT can tie each identifier to a person and a termination date. IT owns the directory settings, the reuse period, the list of system accounts and identifiers, and the logs proving that deleted identifiers were not reissued. Where provisioning is automated, for example through a SCIM provider that pushes user and group creations, changes and deletions to target applications, the IT team must confirm that deletions propagate and that the target systems are included in the account lists assessors check.

Does identifier reuse count as a POA&M item?

It can. IA.L2-3.5.5 is worth 1 point under 32 CFR 170.24 and is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it may be placed on a plan of action and milestones when the organization is otherwise scoring well. Conditional Level 2 status requires a score of at least 88 of 110, which the rule expresses as 0.8. Treat a POA&M as a bridge, not a plan to skip the control: the organization must still document the gap, the planned remediation and the owner. Confirm the current status of CMMC phases and assessment rules with the Department of War before relying on any POA&M approach in a contract.

How long does POA&M closeout take under the rule?

Under the CMMC rule, a POA&M item for a Conditional Level 2 status must be closed out within 180 days. That clock matters for IA.L2-3.5.5 because the remediation often depends on directory configuration, provisioning integrations and a process change, all of which need owner sign-off before the item can be marked closed. Plan the work backward from the 180-day deadline, and collect the closeout evidence as you go rather than at the end, so the assessor sees a final configuration, a finished procedure and test results rather than drafts. Confirm how the deadline applies to your own contract and assessment type.

What should a partner's scope include for identifier reuse?

A fixed-scope agreement should list each directory, identity provider and target application in the boundary, the reuse period to be defined and approved, the configuration changes to be made, and the documents to be produced. It should also name the evidence the partner will prepare, such as the identifier management procedure, the account and identifier lists, and test records, and state who signs off on each one. DeployOpen plans, configures and documents self-hosted identity platforms such as authentik and FreeIPA inside your own infrastructure and prepares evidence for assessment. It does not issue assessment reports or certifications, and an independent assessor makes that determination. Ask for the scope, deliverables and timeline in writing before work starts.

How DeployOpen prepares identifier reuse evidence

DeployOpen plans, implements and documents the identifier lifecycle that IA.L2-3.5.5 Identifier reuse asks for, inside your own infrastructure. We prepare the systems and evidence an assessor will examine, while your organization owns the control and an independent assessor makes the determination.

How we scope

Agree in writing which identity systems, directories and applications fall within the identifier reuse requirement.
Define with your team the no-reuse period your organization will adopt and record it in the scope document.
Confirm which identifiers are covered: user, group, role and device identifiers, with the owner of each decision named.

How we build

Configure the directory or identity provider so newly created identifiers cannot reuse a retired value during the defined period.
Connect target applications through provisioning so creations, changes and deletions flow from one authoritative source.
Test reuse attempts in a non-production environment and keep the results for the assessor.

How we hand over

Deliver the identifier management procedure, configuration records and the account and identifier lists an assessor reviews.
Document test steps, expected results and actual results so each assessment objective can be traced to evidence.
Provide a handover session so your administrators can run and explain the controls without DeployOpen present.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer if your organization wants help between assessments.
Review configuration drift and identifier records after platform upgrades so the control keeps working as designed.
Agree the scope of any follow-on work in writing before it starts, as with the original engagement.