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.
\n\nStart 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.
\n\nAzure 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.
\n\n# Example (conceptual) using Microsoft Graph PowerShell\nConnect-MgGraph -Scopes \"User.Read.All\",\"Directory.ReadWrite.All\",\"AuditLog.Read.All\"\n# Query users with signInActivity older than 90 days\n$cutoff = (Get-Date).AddDays(-90).ToString(\"o\")\n$users = Invoke-MgGraphRequest -Method GET -Uri \"/users?$select=id,displayName,userPrincipalName,accountEnabled,signInActivity&$filter=signInActivity/lastSignInDateTime lt $cutoff\"\nforeach ($u in $users.value) {\n # Optionally check for exceptions by group membership or an extension attribute\n if (-not (IsException($u))) {\n # Disable account\n Invoke-MgGraphRequest -Method PATCH -Uri \"/users/$($u.id)\" -Body (@{accountEnabled = $false} | ConvertTo-Json)\n # Log action, notify owner and security mailing list\n }\n}\nRun 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.
\n\nFor 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.
\n\nAutomated 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.
\n\nExample: 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.
\n\nFailing 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.
\n\nIn 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.
", "plain_text": "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.\n\nDefine policy, scope and inactivity windows\nStart 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.\n\nAzure AD — automate disabling of inactive user identifiers\nApproach and prerequisites\nAzure 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.\n\nPowerShell / Microsoft Graph automation example\n# Example (conceptual) using Microsoft Graph PowerShell\nConnect-MgGraph -Scopes \"User.Read.All\",\"Directory.ReadWrite.All\",\"AuditLog.Read.All\"\n# Query users with signInActivity older than 90 days\n$cutoff = (Get-Date).AddDays(-90).ToString(\"o\")\n$users = Invoke-MgGraphRequest -Method GET -Uri \"/users?$select=id,displayName,userPrincipalName,accountEnabled,signInActivity&$filter=signInActivity/lastSignInDateTime lt $cutoff\"\nforeach ($u in $users.value) {\n # Optionally check for exceptions by group membership or an extension attribute\n if (-not (IsException($u))) {\n # Disable account\n Invoke-MgGraphRequest -Method PATCH -Uri \"/users/$($u.id)\" -Body (@{accountEnabled = $false} | ConvertTo-Json)\n # Log action, notify owner and security mailing list\n }\n}\n\nRun 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.\n\nIntune — manage inactive device identifiers and cleanup\nFor 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.\n\nOperational controls: reviews, exceptions and re-enablement\nAutomated 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.\n\nSmall-business real-world scenario\nExample: 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.\n\nRisks of not implementing IA.L2-3.5.6\nFailing 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.\n\nIn 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." }, "metadata": { "description": "Step-by-step guidance to implement NIST SP 800-171 / CMMC IA.L2-3.5.6 by automating Azure AD account disabling and Intune device cleanup after defined inactivity periods.", "permalink": "/how-to-configure-azure-ad-and-intune-to-disable-identifiers-after-defined-inactivity-periods-nist-sp-800-171-rev2-cmmc-20-level-2-control-ial2-356.json", "categories": [], "tags": [] } }