This post explains how to write and enforce an inactivity-disablement policy to satisfy NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control IA.L2-3.5.6, including a ready-to-adopt policy template, technical enforcement options for common platforms, a practical checklist, and small-business scenarios showing how to balance security and operations.
What IA.L2-3.5.6 requires and how to interpret it
IA.L2-3.5.6 requires organizations to automatically disable inactive user accounts to reduce the attack surface created by stale credentials. In practice this means establishing a clear inactivity threshold (commonly 30–35 days in NIST-derived guidance), identifying the accounts subject to the rule (interactive users, service accounts, privileged accounts), documenting exceptions, and implementing controls to detect and disable accounts that meet the inactivity threshold. Note the distinction between session timeouts/lock screens (session inactivity) and account disablement (longer-term inactivity): both are important but address different risks.
Risk of not implementing inactivity disablement
Failing to disable inactive accounts leaves stale credentials available for exploitation: abandoned user accounts, unused service accounts, and dormant admin credentials are high-value targets for attackers seeking lateral movement, privilege escalation, or persistence. For small businesses that hold controlled unclassified information (CUI) or contract with the Department of Defense, the risks include data loss, contract noncompliance, loss of business, and penalties as well as failed CMMC assessments.
Policy template (use and adapt)
Below is a concise policy template suitable for small organizations—adapt the timeframe, exceptions, and owners to your environment before publishing. Policy: "Purpose: To reduce risk from unused credentials by disabling user accounts that show no sign-in activity. Scope: All user, administrative, and contractor accounts that provide access to organizational systems, cloud consoles, and applications processing CUI. Policy Statement: Accounts with no recorded interactive sign-in or authentication activity for a period of 35 days will be flagged for automatic disablement. Service accounts and system accounts are reviewed separately; an owner must justify any exemption in writing and document an alternate control (e.g., key rotation, restricted network scope). Exceptions: Temporary exceptions (e.g., extended leave) must be approved by the account owner's manager and the security officer and recorded in the exceptions register. Re-enablement: Re-enablement requires verification of identity, manager approval, a forced password reset, and MFA re-enrollment where applicable. Evidence and Logging: Account disablement events, exception approvals, and re-enablement actions will be logged and retained for 1 year. Roles and Responsibilities: IT operations implements detection and disablement; the security officer conducts quarterly reviews of disabled accounts and exceptions. Enforcement: Non-compliance will be addressed through standard change control and disciplinary processes."
Technical enforcement examples and specifics
Windows AD (on-premises): Use lastLogonTimestamp or better the newer authentication logs to detect inactivity. Example PowerShell detection: use Get-ADUser -Filter * -Properties LastLogonDate | Where-Object {($_.LastLogonDate -lt (Get-Date).AddDays(-35)) -and ($_.Enabled -eq $true)} to produce candidates; automate Disable-ADAccount for accounts that meet criteria after a review period. Evidence: scheduled task run logs, output CSV of disabled accounts, and ticketing change requests. Linux servers: use lastlog and "lastlog -b 35" to list users with no logons in the last 35 days; automate locking with passwd -l
Small-business scenarios and real-world guidance
Scenario 1 — Consultant leaves abruptly: a small business that uses contractors can detect the last successful console or VPN login and automatically disable the contractor's account after 7 days of inactivity if an expedited removal is required; for typical contractors use the standard 35-day rule but ensure onboarding/offboarding ties to HR so accounts can be manually disabled immediately on termination. Scenario 2 — Legacy service accounts: classify service accounts and require an owner and lifecycle checklist; if a service account cannot be disabled automatically, require credential rotation every 30 days, restrict the account to specific hosts by ACLs, and monitor for unusual actions. Scenario 3 — Remote employees: combine inactivity disablement with access reviews and reactivation workflows that require manager approval and MFA re-enrollment to prevent social-engineering reactivation attacks.
Checklist to implement and demonstrate compliance
Use this implementation checklist to collect evidence for IA.L2-3.5.6 audits: 1) Define inactivity threshold and document risk-based rationale (artifact: policy page). 2) Identify account types in scope and list exceptions with owners (artifact: account inventory). 3) Implement detection scripts or IAM rules across AD, Linux, cloud IAM, and web SSO (artifact: scripts, Lambda code, Config rules). 4) Implement disablement mechanism (automated or semi-automated) and record change tickets (artifact: disablement logs, change tickets). 5) Maintain logs of disablement and re-enablement events and store for required retention (artifact: SIEM logs, Windows event logs, IAM reports). 6) Perform quarterly access reviews and reconcile exceptions (artifact: access review reports). 7) Document reactivation process with approvals and MFA reset (artifact: reactivation request templates). 8) Include inactivity-disablement testing in your internal audit plan (artifact: test results). Each checklist item should include an owner, frequency, and expected evidence location to simplify assessor requests.
Compliance tips and best practices
Practical tips: pick a clear default timeframe (30–35 days) and document the rationale; automate detection but require human review before permanent deletion (disable first, delete later); treat service and privileged accounts separately with stricter controls; log everything and keep tamper-evident records for audits; use scheduled access reviews and tie exceptions to formal approvals with expiry dates. For small teams, start with a simple PowerShell or shell script and a scheduled job to flag accounts and create tickets—automation can be iterated once you have process maturity. Always require MFA for reactivation and mandate a forced password reset to remove the risk of credential reuse.
Summary: Implementing IA.L2-3.5.6 is a high-impact, practical control: write a short, risk-based policy with a clear inactivity threshold, automate detection across your platforms, apply stricter handling for service and privileged accounts, keep auditable evidence, and adopt a regular review cadence. For small businesses, start simple (scripts + tickets), document exceptions, and evolve toward automation and SIEM integration to maintain compliance and protect CUI with minimal operational overhead.
