This post explains how to meet the Compliance Framework requirement IA.L2-3.5.6 (Disable identifiers after a defined period of inactivity) using Azure AD and Microsoft Intune — with practical, small-business examples, concrete technical steps, sample automation, and operational best practices to ensure you can implement, document, and audit inactivity-driven disabling of user and device identifiers.
Define policy, scope and inactivity windows
Start by documenting your organization-defined inactivity periods and scope as required by the Compliance Framework: which identifiers are covered (user accounts, guest accounts, service accounts, device objects), what counts as "inactivity" (no interactive sign-in within X days, no device check-in within Y days), and documented exceptions (service accounts, break-glass accounts, legal holds). Typical small-business defaults are 90 days for standard user accounts, 30–60 days for contractor or guest accounts, and 180 days for rarely used administrative accounts with documented business justification. Store this policy in your InfoSec policy library so auditors and assessors can see the defined thresholds and exception process.
Azure AD — automate disabling of inactive user identifiers
Approach and prerequisites
Azure AD does not permanently delete or disable inactive accounts automatically by default, but you can implement a robust solution using Microsoft Graph signInActivity data, Azure Automation (Runbooks) or Azure Functions, and Access Reviews for human oversight. Requirements and recommendations: Azure AD Premium P1/P2 to access sign-in and audit data reliably; Microsoft Graph directory permissions (Directory.Read.All and Directory.ReadWrite.All for automation); a managed identity or service principal for the automation runbook; logging to Log Analytics or Storage Account for audit trail. You should also use Access Reviews (Identity Governance) to validate accounts before disabling, especially for privileged groups.
PowerShell / Microsoft Graph automation example
# Example (conceptual) using Microsoft Graph PowerShell
Connect-MgGraph -Scopes "User.Read.All","Directory.ReadWrite.All","AuditLog.Read.All"
# Query users with signInActivity older than 90 days
$cutoff = (Get-Date).AddDays(-90).ToString("o")
$users = Invoke-MgGraphRequest -Method GET -Uri "/users?$select=id,displayName,userPrincipalName,accountEnabled,signInActivity&$filter=signInActivity/lastSignInDateTime lt $cutoff"
foreach ($u in $users.value) {
# Optionally check for exceptions by group membership or an extension attribute
if (-not (IsException($u))) {
# Disable account
Invoke-MgGraphRequest -Method PATCH -Uri "/users/$($u.id)" -Body (@{accountEnabled = $false} | ConvertTo-Json)
# Log action, notify owner and security mailing list
}
}
Run this logic on a scheduled cadence (weekly) from an Azure Automation Runbook or Azure Function using a system-assigned managed identity. Grant the managed identity least-privilege Graph permissions, store runbook outputs to Log Analytics, and generate a notification (Teams/email) that lists accounts flagged and disabled. Always run an initial "report only" mode for several cycles to validate results and tune exceptions.
Intune — manage inactive device identifiers and cleanup
For endpoint identifiers, Intune has built-in device cleanup rules and lifecycle actions that map well to this control. In the Microsoft Endpoint Manager admin center: Devices > Device cleanup rules lets you automatically delete devices that haven’t checked in for a specified number of days. For stricter handling, combine Compliance Policies + Conditional Access to block access for devices that stop checking in, then automatically retire or wipe devices after a secondary threshold. Example small-business setup: mark devices that haven’t checked in for 30 days as noncompliant and block access via Conditional Access, then configure Device cleanup rules to retire/delete after 90 days with a 14-day pre-notification email to the device owner.
Operational controls: reviews, exceptions and re-enablement
Automated disabling must be paired with human review processes and documented exception handling. Use Azure AD Access Reviews to validate guest and privileged accounts quarterly; maintain an exceptions register with expiration dates and business justification for each allowed exception. Provide a simple re-enablement process (a service ticket workflow) that logs approver identity and reason. For service accounts, prefer managed identities or certificates with expiration and rotate credentials instead of blanket exclusion. Keep runbook logs for the full retention period required by your Compliance Framework evidence retention policy.
Small-business real-world scenario
Example: a 30-person contractor company handling DoD subcontract work decides on a 90-day user inactivity window and 60-day guest inactivity window. They add a weekly Azure Function that queries Microsoft Graph signInActivity, writes findings to Log Analytics, runs Access Reviews every 90 days for accounts flagged by automation, and disables accounts only after review. For endpoints, they configure Intune device cleanup rules to retire devices 120 days after last check-in. This approach reduces orphaned accounts and provides an auditable trail for CMMC assessors while keeping disruption low for the small IT team.
Risks of not implementing IA.L2-3.5.6
Failing to disable inactive identifiers increases the attack surface: orphaned user accounts can be compromised and used for lateral movement, stale device objects can be re-enrolled by attackers, and guest accounts can retain access longer than needed. Noncompliance risks include failed assessments under NIST SP 800-171 / CMMC, potential loss of contracts, and regulatory penalties. From an operational standpoint, cleanup saves licensing costs and reduces admin burden on identity and endpoint teams.
In summary, implement IA.L2-3.5.6 by documenting inactivity thresholds, using Microsoft Graph and Azure Automation (or Access Reviews) to identify and disable inactive Azure AD users, and applying Intune device cleanup rules and Conditional Access for inactive endpoints — all tied together with logging, exception handling, and periodic human reviews to meet Compliance Framework evidence requirements and reduce identity-related risk.
