03.05.05: Identifier Management

To meet the 03.05.05: identifier management requirement, you must implement a controlled lifecycle for all identifiers that access systems processing CUI: how identifiers are created, issued, used, changed, disabled, and audited. Operationalize it by standardizing naming rules, preventing shared IDs, integrating HR/offboarding with IAM, and retaining evidence that identifiers remain unique, authorized, and traceable. (NIST SP 800-171 Rev. 3)

Key takeaways:

• Treat identifiers as controlled assets with an end-to-end lifecycle: request → approval → issuance → monitoring → termination. (NIST SP 800-171 Rev. 3)
• Enforce uniqueness and traceability: no shared IDs, no orphaned accounts, and consistent naming across systems. (NIST SP 800-171 Rev. 3)
• Evidence wins audits: your IAM records, joiner/mover/leaver tickets, and account review outputs must tie back to policy. (NIST SP 800-171 Rev. 3)

03.05.05: Identifier Management sits in the access control family of expectations for nonfederal organizations that handle Controlled Unclassified Information (CUI). The requirement is easy to “technically” satisfy in one system and still fail in an assessment because most environments have more identifiers than they think: Windows/Entra IDs, local admin accounts, service accounts, database users, SaaS users, API keys mapped to “users,” break-glass accounts, and third-party support logins.

Assessors generally look for two things: (1) a consistent rule set for identifiers (uniqueness, naming, ownership, authorization), and (2) proof that your process works across the scope of your CUI environment, not just in your primary directory. Your fastest path is to define an identifier standard, map every in-scope system to an authoritative identity source, and implement joiner/mover/leaver workflows that reliably disable access when people change roles or leave. (NIST SP 800-171 Rev. 3)

This page translates the 03.05.05: identifier management requirement into concrete steps, evidence artifacts, and audit-ready checks you can run without turning it into a multi-quarter IAM program. (NIST SP 800-171 Rev. 3)

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.05.05 (Identifier Management).” (NIST SP 800-171 Rev. 3)

Operator meaning: You must manage identifiers deliberately, not casually. That means you define how identifiers are formed and assigned, ensure they are unique and attributable to a specific user or process, control exceptions (service accounts, shared operational accounts), and maintain records that show identifiers are issued and removed under authority. Your controls should prevent “mystery accounts,” make ownership clear, and make it possible to trace actions in logs back to a responsible party. (NIST SP 800-171 Rev. 3)

Plain-English interpretation (what the requirement expects)

For every system in scope for CUI, you need to be able to answer, quickly and consistently:

• What is the identifier? (format, naming convention, type)
• Who or what owns it? (person, service, integration, third-party support)
• Who approved it and why? (role/need-to-know basis)
• Where can it be used? (systems, environments, network zones)
• When does it expire or get disabled? (termination, role change, end of contract)
• How do you review it? (periodic verification, exception handling)

A clean implementation ties identifier records to HR or contract records for humans, and to a system owner plus documented purpose for non-human IDs. (NIST SP 800-171 Rev. 3)

Who it applies to (entity and operational context)

Applies to:

• Federal contractors and subcontractors operating nonfederal systems that process, store, or transmit CUI. (NIST SP 800-171 Rev. 3)

Operationally, this touches:

• Corporate directory/IAM (e.g., AD/Entra ID) and any separate identity stores
• Workstations and servers with local accounts
• Network devices, security tooling, and jump hosts
• SaaS applications used for CUI work (ticketing, engineering tools, collaboration)
• Databases, CI/CD tools, code repos
• Service accounts, automation identities, API identities
• Third-party identities used for support or managed services (NIST SP 800-171 Rev. 3)

If it can authenticate and touch CUI workflows, it is in scope for identifier management expectations. (NIST SP 800-171 Rev. 3)

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

1) Define identifier standards (policy + technical rules)

Create a short, enforceable standard that covers:

• Uniqueness: one identifier per human; no shared user IDs
• Naming convention: human-readable pattern; separate patterns for admins and services
• Identifier types: human, privileged, service/integration, break-glass, third-party
• Prohibited identifiers: generic accounts without ownership; reused IDs
• Exception process: who approves, how it’s time-bounded, how it’s reviewed (NIST SP 800-171 Rev. 3)

Practical tip: keep the standard implementable. If your naming scheme is too complex, teams will route around it with local accounts. (NIST SP 800-171 Rev. 3)

2) Build an in-scope identifier inventory

You cannot manage what you cannot enumerate. Produce an inventory that includes:

• Identity repository (system of record)
• Identifier name
• Identifier type (human/service/admin/etc.)
• Owner (person or system owner)
• Approval reference (ticket/change record)
• Systems where it exists
• Last login / last used (if available)
• Status (active/disabled) (NIST SP 800-171 Rev. 3)

Minimum viable approach: start with your directory export plus high-risk systems (VPN, jump box, email/collaboration, source control, ticketing, endpoint management). (NIST SP 800-171 Rev. 3)

3) Implement joiner/mover/leaver (JML) controls tied to identifiers

Operationalize workflows so identifiers are created and removed consistently:

• Joiner: request → manager approval → provisioning → role assignment
• Mover: role change triggers access change; admin identifiers revalidated
• Leaver: disable directory account; revoke sessions/tokens; disable local and app accounts; document completion (NIST SP 800-171 Rev. 3)

Key control behavior: offboarding must reach non-directory accounts too (local server accounts, app-local users, database users). This is where most programs fail. (NIST SP 800-171 Rev. 3)

4) Control non-human identifiers (service/integration accounts)

Service accounts create audit pain because they are easy to proliferate and hard to attribute. Require:

• Documented purpose and owning team
• Approved scope of permissions
• Credential storage method (managed secrets vault if you have one; otherwise documented secure storage approach)
• Rotation/maintenance process and a decommission trigger when the service is retired
• Logging that links activity to the service identifier and the owning system (NIST SP 800-171 Rev. 3)

5) Restrict and document privileged identifiers

Most environments need separate identifiers for admin functions. Your implementation should:

• Distinguish admin identifiers in naming and inventory
• Require explicit approval and role justification
• Ensure admins still have a normal user identifier for email and web browsing
• Track assignment and removal as a change-controlled activity (NIST SP 800-171 Rev. 3)

6) Prevent “identifier sprawl” from third parties

For third-party access:

• Require named individuals (no “VendorSupport” shared accounts)
• Time-bound access with an end date
• Maintain sponsor/owner inside your organization
• Disable access when the statement of work ends or personnel rotate (NIST SP 800-171 Rev. 3)

7) Run recurring reviews and close findings

Do periodic checks (cadence is your choice, but it must be consistent and evidenced):

• Orphaned accounts (no owner, no ticket, no HR record)
• Dormant identifiers
• Shared accounts and exceptions expiring
• Privileged identifiers still justified
• Accounts outside the directory that were missed by JML (NIST SP 800-171 Rev. 3)

If you use Daydream for third-party risk and control operations, treat identifier management evidence like any other recurring control: map the requirement to owners, create an evidence request schedule, and store exports/tickets in a single control record to reduce scramble during assessments. (NIST SP 800-171 Rev. 3)

Required evidence and artifacts to retain

Assessors want artifacts that show design and operation. Retain:

Governance

• Access control / identity policy section that defines identifier rules (NIST SP 800-171 Rev. 3)
• Identifier naming standard (humans, admins, services)
• Exception procedure for shared/operational accounts (if allowed)

Operational records

• IAM/directory exports showing active identifiers and attributes (owner, status)
• JML tickets or HR-to-IAM workflow logs (provisioning and deprovisioning)
• Service account register with owner, purpose, approval, and permissions summary
• Third-party access approvals and termination evidence (disablement records)
• Periodic access/identifier review results and remediation tickets (NIST SP 800-171 Rev. 3)

Technical proof

• Screenshots or configuration exports demonstrating naming constraints where enforced
• Logs that demonstrate traceability from identifier to action (sample audit trail) (NIST SP 800-171 Rev. 3)

Common exam/audit questions and hangups

Expect these questions, and prepare concise evidence-backed answers:

1. “Show me your identifier naming convention and where it’s enforced.”
   Hangup: policy exists but systems allow free-form creation. Provide config evidence or procedural controls. (NIST SP 800-171 Rev. 3)

2. “Do you have shared accounts? If yes, show approval and compensating controls.”
   Hangup: shared accounts exist for convenience with no owner. Assign ownership, restrict scope, and time-bound exceptions. (NIST SP 800-171 Rev. 3)

3. “How do you ensure offboarding disables access everywhere?”
   Hangup: you disable Entra/AD but forget SaaS, local admins, databases. Show a deprovision checklist and completion evidence. (NIST SP 800-171 Rev. 3)

4. “How do you manage service accounts and ensure accountability?”
   Hangup: service accounts are unmanaged and over-permissioned. Maintain a register and approvals. (NIST SP 800-171 Rev. 3)

5. “Can you tie a log entry back to an individual?”
   Hangup: generic IDs prevent attribution. This becomes a security and compliance risk because investigations stall. (NIST SP 800-171 Rev. 3)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix that assessors accept
Only managing identifiers in the main directory	Many systems keep local users or separate identity stores	Build an inventory by system and reconcile it to the directory/HR feed. (NIST SP 800-171 Rev. 3)
Allowing shared accounts “temporarily”	Temporary becomes permanent; no accountability	Create an exception register with an owner, business reason, and planned removal. (NIST SP 800-171 Rev. 3)
Treating service accounts as “IT-only”	They often hold powerful permissions	Require ownership, approval, and lifecycle controls like human accounts. (NIST SP 800-171 Rev. 3)
Offboarding that stops at email/VPN	Access persists in apps and infrastructure	Use a leaver checklist that enumerates all in-scope systems and records completion. (NIST SP 800-171 Rev. 3)
No retained evidence	Controls may operate but can’t be proven	Store exports, tickets, and review results in a control evidence folder with dates and owners. (NIST SP 800-171 Rev. 3)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, the risk shows up as assessment failures and as incident response gaps: if identifiers are shared or orphaned, you cannot reliably attribute actions, and you will struggle to scope a compromise, prove containment, or show that only authorized individuals accessed CUI. (NIST SP 800-171 Rev. 3)

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and rules)

• Publish identifier standards (humans/admins/services/third parties) and the exception process. (NIST SP 800-171 Rev. 3)
• Identify in-scope systems for CUI and list their identity stores.
• Export current identifiers from the directory and top critical systems; start an inventory.
• Put an immediate stop to new shared accounts without written approval.

By 60 days (operationalize lifecycle)

• Implement or formalize JML workflows with clear owners (HR, IT, app owners). (NIST SP 800-171 Rev. 3)
• Create a service account register and require ownership + approval for each entry.
• Build an offboarding checklist that includes SaaS and local accounts; require completion evidence.
• Start a recurring identifier review (orphaned/dormant/privileged/third-party).

By 90 days (prove operation and close gaps)

• Complete the first full review cycle and track remediation to closure. (NIST SP 800-171 Rev. 3)
• Reduce or eliminate shared accounts; document remaining exceptions with compensating controls.
• Validate that logs and investigations can map activity to identifiers and owners.
• Centralize evidence collection (policy, exports, tickets, review results) so audit response is a retrieval task, not a reconstruction exercise. (NIST SP 800-171 Rev. 3)

Frequently Asked Questions

Does 03.05.05 require unique IDs for every person, even contractors and third-party support?

Yes in practice, because traceability depends on unique identifiers tied to a specific individual or accountable owner. If you allow any shared third-party IDs, treat them as documented exceptions with strong limits. (NIST SP 800-171 Rev. 3)

Are service accounts part of identifier management?

They should be. Service and integration identifiers often have broad access and long lifetimes, so you need ownership, approval, and a decommission trigger like you do for people. (NIST SP 800-171 Rev. 3)

We can’t technically enforce naming conventions everywhere. Will a documented process pass?

Often yes if the process is specific, consistently followed, and you can prove it with tickets, exports, and review results. Weak processes fail when exceptions are undocumented or reviews don’t happen. (NIST SP 800-171 Rev. 3)

How do we handle break-glass accounts under this requirement?

Treat them as privileged identifiers with named owners, strict access conditions, and periodic verification that they remain disabled or controlled outside emergencies. Retain evidence of checks and any emergency use. (NIST SP 800-171 Rev. 3)

What evidence is most persuasive to an assessor?

A current identifier inventory, completed JML tickets (including offboarding), a service account register, and the last completed review with remediation proof. Pair each artifact to the written standard. (NIST SP 800-171 Rev. 3)

How does this map to our vendor/third-party due diligence program?

Third-party access should follow the same identifier rules: named individuals, sponsor ownership, time-bounded access, and termination evidence. Manage third-party identifiers as part of access governance, then track evidence in your GRC workflow. (NIST SP 800-171 Rev. 3)