Identification and Authentication 3.5.6 (3.5.6)
Disable identifiers after a defined period of inactivity.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to automatically disable user accounts and system identifiers after they have been inactive for a specified period of time. The goal is to prevent unauthorized access through dormant accounts that may go unmonitored, reducing the attack surface by ensuring only actively used accounts remain enabled.
Control Intent
Prevent unauthorized access to organizational systems and CUI through inactive or abandoned user accounts and system identifiers that may be exploited without detection.
Who This Control Applies To
- •All user accounts with access to CUI or systems processing CUI
- •Service accounts and system accounts that authenticate to CUI systems
- •Privileged and administrative accounts across all CUI environments
- •Contractor, vendor, and third-party accounts with CUI access
- •Shared accounts or role-based accounts if used within scope
- •Cloud-based identity providers managing CUI system access
- •On-premises Active Directory or LDAP systems managing CUI identities
Not Applicable When
- •The organization has no user accounts or system identifiers (theoretical only)
- •Accounts are used exclusively for systems with no CUI and completely outside the assessment boundary
- •Emergency or break-glass accounts explicitly documented and monitored through compensating controls
- •Service accounts that must remain enabled for continuous automated processes, provided they are monitored and reviewed regularly
Key Objectives
- 1Reduce the attack surface by disabling accounts that are no longer actively used
- 2Prevent exploitation of dormant accounts that may lack monitoring or oversight
- 3Ensure timely detection and remediation of accounts that should be deprovisioned
- 4Minimize the risk of credential compromise through unmonitored inactive identifiers
Sample Self-Assessment Questions (Partial)
Does your organization have a defined inactivity period after which user accounts are automatically disabled?
What is the maximum number of days an account can remain inactive before being disabled?
Implementation Approaches (High-Level)
Active Directory Group Policy with Account Lockout
Use Active Directory Group Policy Objects to automatically disable user accounts after a defined period of inactivity based on last logon timestamp.
Cloud Identity Provider Inactivity Policies
Configure inactivity-based account disablement in cloud identity providers such as Azure AD, Okta, Google Workspace, or AWS IAM.
Hybrid Identity Management with Centralized Monitoring
Implement centralized identity governance tools that monitor and enforce inactivity policies across hybrid environments including on-premises AD, cloud identity providers, and SaaS applications.
Per-System Inactivity Policies with Centralized Reporting
Configure inactivity-based disablement policies individually on each system or application, with centralized reporting and monitoring to ensure consistency.
Automated Scripts with Scheduled Execution
Develop and deploy custom scripts (PowerShell, Python, Bash) that query authentication logs, identify inactive accounts, and automatically disable them based on defined thresholds.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If no inactivity period is currently defined, document a target threshold (commonly 35-45 days) and timeline for policy implementation If manual processes are currently used, create a POA&M to implement automated technical enforcement within 6-12 months If service accounts are not monitored, document a plan to implement periodic reviews or automated monitoring within 3-6 months If inactivity policies are inconsistent across systems, create a POA&M to standardize the threshold and enforcement across all identity systems If disabled accounts are not reviewed for permanent deletion, document a process and timeline for implementing periodic reviews For legacy systems without native inactivity features, document compensating controls such as manual quarterly reviews or scripted enforcement If cloud identity providers lack inactivity policies, document a plan to enable native features or implement third-party monitoring tools Ensure POA&M includes specific milestones, responsible parties, and measurable completion criteria Consider phased implementation starting with highest-risk accounts (privileged, administrative) if full implementation is not immediately feasible
Frequently Asked Questions
What is an acceptable inactivity period before accounts must be disabled?
While NIST SP 800-171 does not specify an exact timeframe, CMMC assessments commonly expect inactivity periods of 35-45 days or less. Organizations should define their threshold based on risk tolerance and document it in policy. Longer periods (e.g., 90+ days) may be questioned during assessment and require strong justification.
Do service accounts and system accounts need to be disabled for inactivity?
Service accounts that authenticate continuously for automated processes typically cannot be disabled based on inactivity. However, they must be monitored through periodic reviews, access logging, or other compensating controls. Organizations should document which service accounts are excluded from inactivity policies and why, along with alternative monitoring mechanisms.
How do we handle employees on extended leave or sabbatical?
Organizations should document a process for handling legitimate extended absences. Options include temporarily exempting the account with documented approval, disabling the account with a streamlined re-enablement process upon return, or implementing a longer inactivity threshold for specific approved cases. The key is having a documented, consistent process that balances security with operational needs.
What happens if we cannot automatically disable accounts in a legacy system?
If technical limitations prevent automated disablement, organizations must implement compensating controls such as manual quarterly reviews of account activity, scripted monitoring with manual disablement, or enhanced logging and alerting. These compensating controls must be documented and evidence of their execution must be maintained. A POA&M should address plans to implement automated enforcement.
Does this control apply to accounts in systems outside the CUI boundary?
The control applies to all identifiers that can access CUI or systems processing CUI. If an account exists in a system outside the boundary but can authenticate to in-scope systems (e.g., through federation or trust relationships), it falls within scope. Accounts used exclusively in systems with no CUI access and no connection to CUI systems are typically out of scope.
How is this control verified during a CMMC assessment?
Assessors will request documentation of your inactivity policy, technical configuration evidence showing automated enforcement, and reports of accounts disabled due to inactivity. They will compare account last login dates against your defined threshold to identify any accounts that should have been disabled but remain active. Assessors will also verify that the policy is consistently applied across all identity systems in scope and that service accounts are appropriately handled.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.