Identifier deactivation is straightforward in principle but often neglected in practice. Your policy says “disable accounts after 90 days of inactivity.” Good. But do you actually have a process checking for inactive accounts? Do you run a report? Do you deactivate them? If not, the policy is fiction.
This ties into termination (IA.L2-3.5.5) but goes further. You remove accounts when people leave. But you also remove accounts when people stop using them, even if they’re still employed. An employee goes on permanent leave, takes a different role that doesn’t need the old system access, or just stops using a legacy application. Their account should be disabled. Inactive accounts also affect audit logging and compliance tracking covered in AU.L2-3.3.1 and AU.L2-3.3.2.
What the assessor is actually evaluating
The assessor is checking two things. One: do you have a written policy that defines inactivity and triggers deactivation? Two: are you actually following it?
For most small contractors, 90 days is the industry standard for inactivity thresholds. Some use 60 days. The number matters less than the fact that you have one and you’re enforcing it. The assessor will ask how you monitor for inactive accounts. They want to hear that you have a process (automated or manual) that checks for accounts that haven’t logged in within your defined period, and you disable them.
If you say “we have a policy but we’ve never actually deactivated an account due to inactivity,” that’s a finding. The policy doesn’t count if you’re not executing it.
What a realistic SSP definition looks like
Practice IA.L2-3.5.6: Identifier Deactivation
Identifiers are deactivated when users are no longer active or when devices are no longer in use. Additionally, identifiers are disabled after a defined period of inactivity.
User Account Deactivation:
Accounts for terminated employees are disabled within one business day of separation per our Termination SOP documented in the Human Resources section of our SSP.
Accounts that remain inactive for 90 consecutive days are disabled. “Inactive” means no login activity on any system with CUI. The IT manager reviews Active Directory and application logs on a monthly basis to identify accounts with no login activity in the past 90 days. Identified accounts are marked for deactivation. The account owner or manager is notified and given the opportunity to re-activate if the account is still needed. After 5 business days without response or confirmation that the account is needed, the account is disabled.
In special cases where an account must remain active but is expected to be unused for extended periods (e.g., seasonal employees, employees on leave), the account remains active at the manager’s documented request and is reviewed separately.
Account deactivation is documented in a ticket showing the account disabled, the reason (inactivity, termination), the date disabled, and who performed the action. Disabled accounts are retained in a disabled state for [X period] per our retention policy, then removed.
Device Identifier Deactivation:
Devices no longer in use are decommissioned from the device inventory. Devices that have not connected to the network for 90 days are flagged for review. The network administrator confirms whether the device is still authorized. If no longer in use, the device is decommissioned and removed from the authorized device list.
Service Account Deactivation:
Service accounts that are no longer needed for any business function are disabled. The service account registry is reviewed quarterly by the IT manager. Service accounts no longer listed as required are disabled and archived.
This is specific about the 90-day threshold, the review process (monthly), and what happens next (notification, 5-day window, then deactivation). The assessor reads this and knows exactly what to ask for: your last inactivity review and the deactivations you made.
How to present your evidence
- Inactivity policy defining the threshold (typically 90 days)
- Documentation of your monitoring process and frequency
- Example inactivity deactivation records showing accounts disabled
- Active Directory or identity provider logs showing account state changes
You need these artifacts:
Your inactivity policy. Written statement of your inactivity threshold (e.g., 90 days) and the process for monitoring and deactivating. This can be part of your Access Control policy or your Security Policy.
Documentation of your monitoring process. What system generates the report? How often do you run it? How do you track accounts flagged for deactivation? A simple document describing this is enough.
Example inactivity deactivation records. Run a report showing accounts that were recently disabled due to inactivity. Include the account name, last login date, deactivation date, and who performed the deactivation. Anonymize names if needed, but show the evidence of the process working.
Active Directory or identity provider logs showing account state changes. If you have logs showing accounts being disabled, that’s good supporting evidence.
Notification records. If your process includes notifying the account owner before deactivation, show an example of that notification (anonymized).
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 be running the inactivity reports and doing the deactivations. They have access to all the logs and can identify unused accounts. You define the policy (90 days or whatever), and they execute it.
In the assessment, the MSSP should be able to pull up the inactivity report and show recent deactivations. They should be able to explain the process. If your MSSP is mature, they probably already monitor for this and have a documented process.
Your SSP documents the policy and the general process. The MSSP handles the technical implementation. Both should be aligned and documented.
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.