Identifier management is about having a process and sticking to it. New hire comes on. You create an account. You document it. They leave. You disable it. You can show both the creation and the deactivation. This is the practice that prevents “I forgot we had that account” from being a compliance gap.
Most small contractors do this informally and successfully. The problem arises when informality means nobody can explain it to the assessor. You know how it works. Your IT person knows how it works. But when you sit in front of the assessor, you can’t produce a ticket showing the request, approval, and completion. That’s when it becomes a finding.
What the assessor is actually evaluating
The assessor is checking that accounts don’t appear or disappear randomly. They want evidence of a process. When they ask “walk me through how a new account gets created,” you should be able to describe the request, approval, provisioning, and documentation steps. When they ask “how do you know an account still needs to exist,” you should be able to show a list of active accounts and evidence of periodic review.
They’re also checking for abandoned accounts. Accounts that were created but never deactivated, so they still exist even though nobody uses them. These are security problems because they’re orphaned and hard to track. The process prevents this by ensuring accounts are reviewed and deactivated when people leave or roles change.
This ties directly to access control. Once you have identifier management documented, the access control people can show who has what access because accounts are tracked from creation through removal. See AC.L2-3.1.1 and AC.L2-3.1.2 for how this feeds into access decisions.
What a realistic SSP definition looks like
Practice IA.L2-3.5.5: Identifier and Authentication Method Management
We maintain a documented process for provisioning, managing, and deactivating user and system identifiers throughout their lifecycle.
Account Provisioning Process: New employees and contractors are added to our systems through a documented request process. The hiring manager submits an access request ticket that specifies: the employee’s name, job title, start date, and required systems/applications. The IT manager reviews and approves the request based on job requirements and least privilege. Once approved, the ticket is sent to our MSSP (or IT team) to provision the account in Active Directory and required applications. The ticket is closed once provisioning is confirmed, and the employee receives credentials. All provisioning is documented in our ticketing system with request, approval, and completion dates.
Service Account Provisioning: Service accounts are created through a similar ticket-based process. The requestor explains the business purpose, what systems the account will access, and what actions it will perform. A manager reviews and approves. The IT manager configures the account with only the permissions required for its documented purpose. Credentials are stored in [credential vault] with access restricted to those who need to retrieve them. Service account changes are also ticket-based and documented.
Access Changes: When an employee’s role changes or additional access is needed, the change is requested via ticket. The manager approves the specific additions or removals. Changes are made through our [identity provider / directory service] and documented in the ticket.
Account Deactivation: When an employee terminates employment, our Termination SOP is initiated. The employee’s manager submits a termination ticket that specifies the employee’s name, final date, and systems to be deactivated. Within one business day of the final date, the IT manager disables the account in Active Directory and revokes access from applications and systems. The termination ticket documents what was disabled, when, and who performed it. The disabled account is retained for [X period] for audit purposes, then removed per our retention policy.
Account Review and Audit: Active accounts are reviewed quarterly by department managers. Each manager reviews the accounts in their area and confirms they are current, belong to active employees, and have appropriate access for their roles. Reviews are documented via ticket or sign-off document with the date reviewed. Accounts found to be inactive or belonging to former employees are flagged for immediate deactivation.
Identifiers Uniqueness: All user accounts are assigned unique identifiers based on [first initial + last name / employee ID / etc.]. This scheme is documented in our Security Policy. Duplicate identifiers are not permitted. When an employee departs and their account is disabled, their identifier is not reused for a new hire for at least [X period].
This is detailed because it covers the entire lifecycle. The assessor reads this and doesn’t need to ask follow-up questions. They can simply ask you to show examples of tickets.
How to present your evidence
- Account provisioning/termination SOP or process document
- Example provisioning ticket showing request, approval, and completion
- Example termination ticket documenting account deactivation
- Active account audit with review dates and manager sign-off
You need these artifacts:
Your provisioning/termination SOP or process document. Written steps for creating and removing accounts. This doesn’t need to be long. One page is fine.
Example provisioning ticket(s). Find a recent one. Ticket should show the request, approval, who provisioned the account, and the completion confirmation. No sensitive details. Just show the request workflow.
Example termination ticket(s). Same structure. Request, approval, confirmation of deactivation.
Account audit showing active accounts and review dates. A report from Active Directory or your identity provider listing active accounts with a timestamp showing when the list was exported. If you have a documented review process, show a ticket or document proving a review happened.
Service account inventory (if applicable). List of service accounts with documented purpose and access.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP or MSSP
Your MSSP should own the day-to-day account provisioning and deactivation. You define the process in your SSP. The MSSP executes it. In the assessment, you can speak to the policy, and the MSSP can demonstrate the implementation.
This is one of the practices where an MSSP that has handled your onboarding should have excellent documentation. They provisioned accounts for all your employees. They know the process because they did it. They should be able to walk the assessor through examples.
Your SSP doesn’t need to say “we use ServiceNow” or name specific tools. It should describe the logical steps: request, approval, provisioning, deactivation. The MSSP implements those steps using whatever tools they have.
This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.