CMMC Level 2 Practice 3.5.5: Prevent reuse of identifiers for a defined period

The cmmc level 2 practice 3.5.5: prevent reuse of identifiers for a defined period requirement is easy to misunderstand because it sounds like “password history.” It is not. This practice is about account identifiers (the username or unique account handle) and the risk created when identifiers get recycled. Reuse can break attribution, confuse audit logs, misroute access approvals, and increase the odds that old permissions or workflow bindings get applied to the wrong person.

For most CMMC Level 2 organizations, the operational work is concentrated in identity platforms such as Microsoft Entra ID/Azure AD, on-prem Active Directory, HRIS-to-IAM provisioning, and any application with its own local user directory. Your goal is straightforward: when someone leaves and an account is disabled or removed, the identifier stays “burned” (or reserved) for long enough that old log trails, group memberships, MFA bindings, and approvals cannot be mistaken for a new user.

The fastest path to implementation is: define the identifier types you care about, set a clear waiting period, implement a “disable then retain” lifecycle, and collect evidence on a recurring cadence so you can answer assessor questions without scrambling. ¹

Regulatory text

Excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.5.5 (Prevent reuse of identifiers for a defined period).” ²

What the operator must do:

• Decide what identifiers are in scope (for example: network username, UPN, email alias, application-specific user ID).
• Define a waiting period during which an identifier cannot be reassigned to another person.
• Implement technical and procedural controls that actually prevent reassignment.
• Retain evidence that the control is configured and operating across in-scope systems used to process, store, or transmit CUI under CMMC Level 2. ²

Plain-English interpretation

If “jsmith” leaves, you cannot give “jsmith” to a new hire right away (or at all, depending on your policy). The identifier must remain unavailable for a defined period so security logs, approvals, and system bindings remain trustworthy. The assessor will expect that your definition of “identifier” matches how identity really works in your environment, not how you wish it worked.

Who it applies to

Entities

• Defense industrial base and other organizations seeking CMMC Level 2 certification for environments that handle CUI. ³

Operational context (where this shows up in practice)

• Central identity: Active Directory, Microsoft Entra ID, Okta, other IdPs.
• Provisioning flows: HRIS → IAM, IAM → SaaS apps, automated joiner/mover/leaver workflows.
• Privileged identity: admin accounts, break-glass accounts, shared service accounts (where permitted).
• Application directories: engineering tools, ticketing systems, file transfer platforms, collaboration tools that can create local usernames.

If any in-scope system allows an admin to delete a user and recreate the same username for someone else, that system is in scope for your 3.5.5 implementation.

What you actually need to do (step-by-step)

Step 1: Define “identifier” for your environment (and document it)

Create a short standard that lists identifier types you will prevent from reuse, such as:

• AD sAMAccountName / username
• UPN
• Primary email address and aliases (if used as a login)
• Employee ID (if used for access or correlation)
• Application-specific usernames for systems that do not federate to your IdP

Write a rule that states which attribute is the authoritative identifier for audit correlation (often UPN or immutable object ID in cloud IdPs) and which ones must not be reassigned.

Artifact: “Identifier Reuse Standard” (1–2 pages) mapped to CMMC Level 2 Practice 3.5.5. ²

Step 2: Set the defined period (and tie it to lifecycle reality)

Pick a waiting period that matches:

• Your log retention and investigation needs
• HR offboarding timing
• How long downstream systems retain user references (shared folders, workflow approvals, signatures)

The requirement is “defined period,” so the key is that it is explicit, approved, and consistently applied.

Artifact: Policy language in Access Control / IAM standard stating the waiting period and scope. ²

Step 3: Engineer the control in identity systems (technical enforcement)

Implement controls that make reuse hard or impossible:

For AD / Entra / common IAM patterns

• Disable, don’t immediately delete: Offboarding should disable accounts and remove access, while preserving the identifier record for correlation.
• Block rename/recreate to a reserved name: Use guardrails so admins cannot rename a new user to an old username during the waiting period.
• Preserve immutable identifiers: Ensure your logging and SIEM correlation uses immutable IDs where possible, then enforce non-reuse of the human-readable login names to reduce confusion.
• Email address handling: If email aliases are used for login in any system, treat them as identifiers. Ensure aliases of leavers are not reassigned during the waiting period.

For apps with local accounts

• Prefer SSO federation to your IdP for in-scope apps.
• If local accounts must exist, require the app owner to implement a “reserved identifiers” list or keep the account record disabled until the waiting period expires.

Evidence to plan for: screenshots or exports of IAM settings, and administrative process controls showing that deletion/recreation is restricted. ¹

Step 4: Build an operational workflow for joiner/mover/leaver (JML)

Create an offboarding runbook that includes:

1. Disable user account(s)
2. Remove active sessions and tokens
3. Remove group memberships / roles
4. Transfer ownership of assets (mailbox, files, repos)
5. Mark identifier as “reserved” until the defined period expires
6. After expiry, decide whether to delete, archive, or keep permanently reserved based on your standard

Put the “identifier reserved until” field somewhere operationally real: a ticketing task, IAM workflow attribute, or HRIS termination record referenced by IAM.

Artifact: JML Runbook + ticket template that includes an identifier-reservation step. ²

Step 5: Prove it works (recurring evidence capture)

Assessors commonly fail organizations for “we do this” controls that are not evidenced. Build a light, repeatable evidence pack:

• Sample of terminated users with timestamps
• Proof that usernames were not reassigned within the defined period
• Change management records for any exception

Daydream-style operationalization: map 3.5.5 to a control statement, then schedule recurring evidence capture so you always have a current sample set and don’t have to reconstruct history right before assessment. ¹

Required evidence and artifacts to retain

Maintain an evidence folder that an assessor can review quickly:

Evidence item	What it shows	Example artifacts
Identifier Reuse Standard	Defined period + identifier scope	Approved standard, control mapping to 3.5.5
IAM/JML procedure	Operational steps	Offboarding SOP/runbook, ticket template
System configuration evidence	Technical enforcement	Screenshots/exports of IAM settings; admin role restrictions
Offboarding tickets	Execution	Closed tickets showing disablement and reservation step completed
Audit/log evidence	No reuse	Directory audit logs, SIEM queries, app audit events
Exceptions log	Governance	Approved exceptions with compensating controls

Keep evidence aligned to the in-scope boundary for CMMC Level 2 environments that handle CUI. ³

Common exam/audit questions and hangups

Expect these questions, and prep the exact artifacts:

1. “What identifiers are covered?”
   They want a clear scope statement, not “usernames generally.” Show your standard.

2. “What is your defined period, and where is it documented?”
   Point to the policy/standard section and the workflow step.

3. “Show me you prevented reuse.”
   Provide a sample set: terminated users and proof no new accounts used those identifiers within the waiting period.

4. “What about email addresses and aliases?”
   Many environments reuse email aliases. If aliases are used as login identifiers anywhere, treat them as in scope or document why they are not.

5. “Do you delete accounts?”
   Deletion is not prohibited, but you must still prevent identifier reuse. If you delete, you need a separate reservation mechanism.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Confusing identifier reuse with password reuse.
  Fix: Put explicit wording in your standard: “identifier = username/login handle,” and cross-reference password controls separately. ²

• Mistake: Relying on “we never do that” without a technical block.
  Fix: Restrict who can create/rename accounts, require tickets, and review audit logs for rename/recreate events.

• Mistake: Reassigning email aliases for convenience.
  Fix: Treat aliases as identifiers if any system authenticates on email. If business insists on reuse, require a risk exception and compensating controls (tight audit review, forced re-registration of MFA, verification steps).

• Mistake: Deleting accounts immediately, losing the ability to prove non-reuse.
  Fix: Keep a “tombstone” record in IAM or ticketing that reserves the identifier through the defined period.

• Mistake: Ignoring local accounts in niche tools.
  Fix: Inventory in-scope applications and explicitly declare whether they authenticate via SSO. If not, assign an app control owner and enforce the same non-reuse rule.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice, so you should treat assessment risk as the primary driver: 3.5.5 is typically evaluated through documentation plus technical demonstration and sampling during a CMMC Level 2 assessment. ¹

Operational risk is practical and immediate: identifier reuse can compromise auditability, confuse investigations, and cause authorization errors when systems or administrators assume a “known” username belongs to the prior employee.

Practical 30/60/90-day execution plan

You asked for something you can operationalize quickly. Use this plan as a checklist and adapt it to your identity stack.

First 30 days (design + scoping)

• Identify in-scope identity sources (IdP, AD, HRIS, key apps) tied to CUI environments. ⁴
• Draft and approve the Identifier Reuse Standard: identifier types + defined period + exception process. ²
• Update offboarding runbook and ticket templates to include “reserve identifier until” as a required step.

Days 31–60 (technical enforcement + workflow rollout)

• Implement technical controls: disable/retain approach, restrict rename/recreate privileges, and standardize account deletion rules.
• For top in-scope apps, move to SSO where feasible; otherwise document the app-level non-reuse mechanism and owner.
• Build evidence queries: how you will show that a terminated identifier was not reused.

Days 61–90 (evidence + assessment readiness)

• Run a sample-based internal check: pick recent terminations and verify identifiers remain reserved per policy.
• Create a recurring evidence capture routine: monthly snapshots, ticket samples, and config exports.
• Load your control narrative and evidence index into your GRC system so assessors can follow the thread end-to-end; Daydream can help maintain the mapping and recurring evidence cadence so your 3.5.5 proof stays current. ¹

Frequently Asked Questions

Does 3.5.5 apply to passwords or only usernames?

3.5.5 is about identifiers (usernames or login handles), not passwords. Treat password reuse and password history under separate authentication controls. ²

What identifier types should we include in scope?

Include any attribute that functions as a login identifier or a unique account handle in logs, such as AD username, UPN, and email address if it is used to authenticate. Document the list so your evidence matches your definition. ²

We delete accounts immediately for licensing reasons. Can we still comply?

Yes, if you still prevent the deleted identifier from being reassigned during your defined period. That usually requires a reservation list or a tombstone record outside the deleted account object. ²

Does this apply to service accounts and shared accounts?

If a service account identifier could be reassigned to another purpose or person, control it the same way. If you prohibit shared accounts, document that stance and ensure exceptions follow a controlled process. ²

How do we prove “non-reuse” to an assessor?

Provide (1) your documented defined period, (2) a population or sample of offboarded accounts, and (3) directory/app audit evidence showing the identifiers were not recreated or reassigned within that period. Pair the evidence to tickets for the same users. ¹

What if our HR rehires someone and wants the same username back?

Treat a rehire as a special case in your standard: either keep the original identity object and reactivate it, or require an exception workflow that proves the reactivated account belongs to the same person and that access is re-provisioned cleanly. Document the decision and keep the ticket trail. ²

Footnotes

1. DoD CMMC Program Guidance

2. NIST SP 800-171 Rev. 2

3. 32 CFR Part 170; DoD CMMC Program Guidance

4. 32 CFR Part 170