Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - IA.L2-3.5.6 – Disable identifiers after a defined period of inactivity.
Understanding the Requirement
This control (from NIST SP 800-171 REV.2 / CMMC 2.0 Level 2) requires organizations to define a maximum period of inactivity for accounts and ensure identifiers are disabled once that period passes. The goal is to reduce the attack surface by removing or disabling accounts that are no longer used; specifically, your policy should state the inactivity window (commonly 90 days) and your processes must reliably disable accounts after that window. Together the definition and enforcement steps ensure unused accounts are identified and handled consistently.
Technical Implementation
- Define the inactivity period and document exceptions. Adopt a clear default (for example, 90 days) and document exceptions for service, shared, or privileged accounts. Keep an exceptions register with business justification, owner, and expiry date.
- Create a written policy and tie it to your identity lifecycle. Publish a short policy that states the inactivity period, who can grant/approve exceptions, and the process to request re-enablement. Link the policy to onboarding/offboarding workflows so HR and IT follow the same rules.
- Automate detection of inactive accounts. Use built-in reports or scripts to check last logon/sign-in activity. For Active Directory, use lastLogonTimestamp queries or scheduled PowerShell scripts; for Microsoft 365/Azure AD, use Sign-In Activity logs and the Graph API to identify accounts with no activity in the defined window.
- Automate or schedule disabling actions with safe controls. Implement a scheduled process (weekly or monthly) that moves inactive accounts into a "Disabled" OU or toggles the accountDisabled attribute. Include a pre-disable notice step (email to account owner) and maintain a grace window to catch false positives.
- Protect service and privileged accounts. Exclude or handle service and privileged accounts differently: require owners, store credentials in a secure vault, and set shorter or monitored inactivity rules. Where possible, convert persistent credentials to managed service principals or certificates with expiration and rotation.
- Log, monitor, and provide simple re-enable workflow. Keep audit logs of disabled accounts and the reason. Integrate records into your helpdesk or ticketing system so a verified re-enable request (with manager approval and identity verification) is required before restoration.
Example in a Small or Medium Business
Acme Solutions, a 120-person SMB using hybrid Active Directory and Microsoft 365, implements a 90-day inactivity policy. IT publishes the policy and trains HR and managers on the expectations for account lifecycle. Each month a PowerShell script queries AD and Azure AD for accounts with no sign-in activity in the last 90 days and generates a report with owner and last activity date. The script sends a single automated warning email to the account owner and their manager; if no response is received after 7 days the account is automatically disabled and moved to a restricted OU. Disabled accounts are retained for 180 days before deletion to allow business recovery, and all actions are logged to a central SIEM for review. Service accounts are flagged in the identity inventory and excluded from automatic disabling; each service account has an owner and a documented justification with a renewal date. Helpdesk staff follow a standard ticket process to re-enable accounts: the request must include a manager-approved ticket and identity verification before the account is restored and the action is logged for audit purposes.
Summary
Combining a clear inactivity policy with automated detection and controlled disabling processes meets IA.L2-3.5.6 by ensuring unused identifiers are removed from active use. For SMBs the pragmatic approach is to set a sensible default (such as 90 days), automate reporting and disabling where possible, protect exceptions like service or privileged accounts, and maintain an auditable re-enable workflow. These steps reduce your attack surface, make audits straightforward, and keep account recovery simple and secure.
