IA.L2-3.5.6: Disable identifiers after a defined period of inactivity

📖 What This Means

This control requires organizations to automatically disable user accounts after a set period of inactivity (e.g., 90 days). It's like turning off unused lights to save energy—except here, you're shutting down potential entry points for attackers. For example, if an employee leaves the company but their account remains active, hackers could exploit it. Another scenario: a contractor's temporary account stays enabled long after their project ends. The goal is to minimize 'zombie accounts' that no one monitors but could be compromised.

🎯 Why It Matters

Dormant accounts are low-hanging fruit for attackers. The 2023 Verizon DBIR found that 60% of breaches involved credential abuse. In 2021, a defense contractor suffered a breach when an ex-employee's unused account was hijacked to steal sensitive DoD designs. The cleanup cost exceeded $500K. From the DoD's perspective, this control prevents 'ghost access'—where old credentials linger in systems handling CUI. It's especially critical for contractors with high staff turnover or temporary workers.

✅ How to Implement

Azure: Set inactivity thresholds in Entra ID (formerly Azure AD) under Users > All users > Account disablement policy
AWS: Configure IAM credential reports with Lambda to flag unused accounts (use 'password_last_used' field)
GCP: Create Organization Policy constraints for IAM with 'constraints/iam.disableServiceAccountKeyCreation'
Use CIEM tools like Sonrai or Orca to detect stale identities across multi-cloud environments
Document the policy in your SSP (e.g., 'All cloud accounts inactive >90 days will be disabled')

⏱️

Estimated Effort

2-3 days for initial setup (mid-level sysadmin), 1 hour/month for maintenance

📋 Evidence Examples

Account Disablement Policy

Format: PDF/DOCX

Frequency: Annual review

Contents: Written procedure defining inactivity threshold (e.g., 90 days) and disablement process

Collection: Export from document management system

AD/LDAP Configuration Screenshot

Format: PNG/PDF

Frequency: After changes

Contents: Show userAccountControl flags or pwdInactive settings

Collection: PrntScrn of ADSI Edit or ldapsearch output

Monthly Inactivity Report

Format: CSV/XLSX

Frequency: Monthly

Contents: List of accounts with last login dates and disablement actions taken

Collection: Export from PowerShell: Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00

SIEM Alert Log

Format: LOG/PDF

Frequency: Continuous

Contents: Records of automated alerts for inactive accounts

Collection: Splunk query: 'index=auth earliest=-30d | stats latest(_time) by user'

Exception Request Forms

Format: PDF/DOCX

Frequency: Per exception

Contents: Approved requests for accounts exempt from disablement (e.g., service accounts)

Collection: HRIS system export

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For IA.L2-3.5.6 ("Disable identifiers after a defined period of inactivity"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"IA.L2-3.5.6 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to disable identifiers after a defined period of inactivity. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"IA.L2-3.5.6 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to disable identifiers after a defined period of inactivity. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"IA.L2-3.5.6 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

• Identify all authentication entry points (local login, VPN, cloud, API)
• Document the identity provider(s) and authentication flow
• Specify MFA methods and coverage
• Ensure this control covers all systems within your defined CUI boundary where disable identifiers after a defined period of inactivity applies
• Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

📄 Identification and Authentication Policy
📄 Password policy configuration
📄 MFA enrollment records
📄 Service account registry
📄 Evidence artifacts specific to IA.L2-3.5.6
📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Do you have a written policy defining the inactivity period before account disablement?

✅ YES → Proceed to Q2

❌ NO → GAP: Create policy document with 30/60/90 day threshold based on your risk assessment. Template available at NIST SP 800-171A Appendix D.

Remediation:

2 weeks (Policy team)

Question 2: Can your systems automatically identify accounts inactive beyond the threshold?

✅ YES → Proceed to Q3

❌ NO → GAP: Implement AD/LDAP queries or cloud identity tools to detect inactivity. Use our provided PowerShell/CLI examples.

Remediation:

1 week (Sysadmin)

Question 3: Are disablement actions logged with timestamp and approving authority?

✅ YES → Proceed to Q4

❌ NO → GAP: Configure SIEM logging for account changes. Azure Sentinel/Microsoft 365 audit logs meet this requirement.

Remediation:

3 days (Security team)

Question 4: Do you review exceptions quarterly?

✅ YES → Proceed to Q5

❌ NO → GAP: Establish exception review process with HR/management. Calendar reminders help.

Remediation:

2 weeks (Compliance)

Question 5: Is the inactivity period enforced consistently across cloud/on-premise?

✅ YES → COMPLIANT

❌ NO → GAP: Map identity providers to ensure uniform policy application. Azure AD Connect helps sync settings.

Remediation:

1 week (Cloud team)

⚠️ Common Mistakes (What Auditors Flag)

1. Ignoring service accounts

Why this happens: Teams fear breaking automated processes

How to avoid: Document all service accounts in CMDB with business owners. Use 'managed service accounts' where possible.

2. Inconsistent thresholds

Why this happens: Different departments set their own policies

How to avoid: Centralize identity management under CISO with one enterprise standard (e.g., 90 days for all).

3. No disablement logs

Why this happens: Assuming AD/SIEM logs are sufficient

How to avoid: Require manual sign-off for each disablement via ticketing system (ServiceNow/Jira).

4. Forgetting contractors

Why this happens: HR systems don't track non-employees well

How to avoid: Integrate vendor management systems (VMS) with IAM tools like Okta Workflows.

5. Testing only happy path

Why this happens: Not simulating attacker recon of dormant accounts

How to avoid: Red team exercise: Try authenticating with known inactive credentials monthly.

📚 Parent Policy

This practice is governed by the Identification and Authentication Policy

View IA Policy →

📚 Related Controls

IA.L2-3.5.7 (Password lifetime) IA.L2-3.5.8 (Session lock) AC.L2-3.1.20 (Concurrent session control)