Zero-touch laptop offboarding with Microsoft Intune

Overview

Employee offboarding is both an identity event and an endpoint-control problem. Disabling an account does not erase data already stored on a laptop, while sending an Intune action does not prove that an offline device received or completed it. A defensible design coordinates both control planes and records the state of each one.

A practical Microsoft architecture starts with an authoritative HR departure event, uses Microsoft Entra Lifecycle Workflows for supported identity tasks, calls an Azure Logic App through a custom task extension for device orchestration, and invokes the appropriate Intune remote action through Microsoft Graph. The design should fail closed for access, fail safely for device selection, and keep an exception open until the endpoint result is verified.

What the draft architecture needs to get right

• Identity containment is not instantaneous token destruction. Disable the account and revoke refresh and browser session tokens first. Existing access tokens can remain usable until the relying service reevaluates them or they expire; Continuous Access Evaluation shortens that window only for supported applications and conditions.
• Lifecycle Workflows do not natively perform every Intune action. Use built-in leaver tasks for supported identity operations. For device lookup, approval logic, and Intune actions, call an Azure Logic App through a Lifecycle Workflows custom task extension or use another controlled orchestration service.
• A successful Graph response is not proof of endpoint completion. The remote-action request can be accepted while the laptop is powered off or disconnected. Track request acceptance, pending delivery, device check-in, action status, and the verified client outcome as separate events.
• Remote wipe is not a universal cryptographic-erasure certificate. Intune Wipe removes data and settings by resetting the device, but storage behavior varies by platform and configuration. Keep a separate media-sanitization standard for disposal, legal holds, damaged hardware, and assurance requirements that demand verified destruction.
• Compliance policy is not an offline wipe engine. Intune can mark a stale or unhealthy device noncompliant and Conditional Access can block protected resources once that state is evaluated. Compliance actions do not make an internet-disconnected Windows laptop execute a wipe, and BitLocker key rotation is a separate remote action rather than an automatic consequence of a grace period.

The automated offboarding architecture

• 1. Receive an authoritative departure event. Use HR-driven provisioning or another approved source to provide the employee identifier, effective departure time, termination class, manager, legal-hold status, and known asset identifiers. Normalize time zones and make replayed events idempotent.
• 2. Contain the identity. At the effective time, disable the Microsoft Entra account, revoke refresh and browser session tokens, remove supported group, team, access-package, and direct-license assignments as policy requires, and preserve any access needed for legal hold or manager handover. Removing group membership can change Conditional Access scope, but it does not delete or strip the policies themselves.
• 3. Resolve the correct managed device. Map the person and asset record to the Intune managedDevice ID. Do not wipe every device merely associated with a user: account for shared devices, multiple assigned laptops, stale records, BYOD enrollment, loaners, and devices already transferred to another custodian.
• 4. Apply a risk-based decision. Use device ownership, physical custody, reuse intent, legal hold, encryption state, last check-in, and termination risk to select Retire, Wipe, Autopilot Reset, quarantine, or manual review. Require approval for ambiguous matches and destructive actions outside a pre-approved policy.
• 5. Dispatch with least privilege. Have the orchestration workload call Microsoft Graph with the Intune privileged-operations permission required for the selected action. Protect the workload identity, scope who can change the workflow, validate every identifier, and avoid placing broad Graph credentials in scripts or tickets.
• 6. Verify and close. Correlate the HR event, workflow run, identity tasks, device decision, Graph request, Intune action status, last check-in, client result, and physical asset return. Close the case only when the required outcome is confirmed or a named exception owner accepts the residual risk.

Choose the Intune action by outcome

Hardened PowerShell dispatch example

The following reference sample deliberately accepts one approved Intune managed-device ID and one expected serial number. It does not discover devices by UPN or reset every device associated with a departed user. Resolve and approve the asset earlier in the workflow, confirm that the recovered device is eligible for Autopilot Reset, and verify Windows Recovery Environment readiness in your deployment controls.

For readability, the sample obtains a client secret from a process environment variable. In production, prefer a managed identity or certificate credential and inject secrets from an approved secret store rather than command history, source code, logs, or tickets. The app needs DeviceManagementManagedDevices.Read.All to read the target and DeviceManagementManagedDevices.PrivilegedOperations.All to dispatch the wipe action.

• Destructive guardrails. SupportsShouldProcess and ConfirmImpact High provide -WhatIf and an interactive confirmation. An unattended workflow should pass -Confirm:$false only after its own policy and approval gates have selected the exact managed-device ID and serial number.
• Current Graph action. Microsoft's current Autopilot Reset documentation points to POST /deviceManagement/managedDevices/{managedDeviceId}/wipe. The sample keeps enrollment data and removes user data; validate this behavior in a nonproduction ring against the Windows and Intune versions you operate.
• Dispatch is not completion. A successful request produces a Dispatched record only. The surrounding workflow must continue tracking Intune action state, device check-in, client completion, and physical custody before closing the case.

<#
.SYNOPSIS
    Dispatches an approved Windows Autopilot-style reset through Microsoft Graph.
.DESCRIPTION
    Validates one Intune managed-device ID against an expected serial number,
    then calls the documented managedDevice wipe action while retaining enrollment.
.NOTES
    Required application permissions:
    DeviceManagementManagedDevices.Read.All
    DeviceManagementManagedDevices.PrivilegedOperations.All
#>

[CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')]
param (
    [Parameter(Mandatory = $true)]
    [guid]$TenantId,

    [Parameter(Mandatory = $true)]
    [guid]$ClientId,

    [Parameter(Mandatory = $true)]
    [guid]$ManagedDeviceId,

    [Parameter(Mandatory = $true)]
    [ValidateNotNullOrEmpty()]
    [string]$ExpectedSerialNumber
)

Set-StrictMode -Version Latest
$ErrorActionPreference = 'Stop'

$clientSecret = $env:GIDEON_GRAPH_CLIENT_SECRET
if ([string]::IsNullOrWhiteSpace($clientSecret)) {
    throw 'GIDEON_GRAPH_CLIENT_SECRET must be injected by an approved secret store.'
}

$tokenResponse = $null
$headers = $null

try {
    $tokenUri = "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token"
    $tokenBody = @{
        client_id     = $ClientId
        client_secret = $clientSecret
        scope         = 'https://graph.microsoft.com/.default'
        grant_type    = 'client_credentials'
    }

    $tokenResponse = Invoke-RestMethod -Uri $tokenUri -Method Post -Body $tokenBody
    if ([string]::IsNullOrWhiteSpace($tokenResponse.access_token)) {
        throw 'Microsoft identity platform returned no access token.'
    }

    $headers = @{
        Authorization = "Bearer $($tokenResponse.access_token)"
        'Content-Type' = 'application/json'
    }

    $deviceUri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($ManagedDeviceId)?`$select=id,deviceName,serialNumber,operatingSystem,lastSyncDateTime,managementAgent"
    $device = Invoke-RestMethod -Uri $deviceUri -Method Get -Headers $headers

    if ($device.operatingSystem -ne 'Windows') {
        throw "Managed device '$ManagedDeviceId' is not a Windows device."
    }

    if (-not [string]::Equals(
        $device.serialNumber,
        $ExpectedSerialNumber,
        [System.StringComparison]::OrdinalIgnoreCase
    )) {
        throw "Serial mismatch for managed device '$ManagedDeviceId'."
    }

    $operation = 'Remove user data while retaining Intune enrollment'
    $target = "$($device.deviceName) [$($device.serialNumber)]"
    if (-not $PSCmdlet.ShouldProcess($target, $operation)) {
        return [pscustomobject]@{
            Status = 'Skipped'
            ManagedDeviceId = $device.id
            DeviceName = $device.deviceName
            SerialNumber = $device.serialNumber
        }
    }

    $resetUri = "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices/$($device.id)/wipe"
    $payload = @{
        keepEnrollmentData = $true
        keepUserData = $false
    } | ConvertTo-Json

    Invoke-RestMethod -Uri $resetUri -Method Post -Headers $headers -Body $payload

    [pscustomobject]@{
        Status = 'Dispatched'
        ManagedDeviceId = $device.id
        DeviceName = $device.deviceName
        SerialNumber = $device.serialNumber
        LastSyncDateTime = $device.lastSyncDateTime
        DispatchedAtUtc = (Get-Date).ToUniversalTime().ToString('o')
    }
}
finally {
    $clientSecret = $null
    $tokenResponse = $null
    $headers = $null
}

Design for laptops that are offline

Intune remote actions require the device to connect to the internet and check in. A powered-off laptop therefore remains a pending endpoint risk even after its identity is disabled. The workflow should surface that state instead of reporting the offboarding as complete.

Use defense in depth for the waiting period: full-disk encryption, disabled user access, Conditional Access tied to current device compliance, short and well-governed local credential paths, endpoint detection controls, and physical recovery procedures. None of these controls should be described as proof that a queued remote action executed.

• Set escalation thresholds. Escalate based on departure risk, ownership, custody, and time since last check-in. A missing corporate laptop after an involuntary termination should not share the same timer as a confirmed device in an IT return cage.
• Keep the action pending. Poll or subscribe to the available Intune action and device state, record each retry safely, and avoid replacing a destructive command with a contradictory queued action.
• Coordinate physical recovery. Link the security workflow to asset management, shipping, manager attestation, and lost-device procedures so technical containment and hardware custody converge on one case.

Evidence that supports an audit

• Trigger evidence. Authoritative source, event identifier, effective time, received time, workflow version, and idempotency key.
• Identity evidence. Account-disable result, refresh-session revocation result, entitlement changes, exceptions, and the timestamp for each task.
• Decision evidence. Resolved device ID, serial number, ownership, custody, last check-in, selected action, policy version, approver when required, and rejected alternatives.
• Endpoint evidence. Graph request correlation, Intune action state, delivery or check-in evidence, client outcome, physical-return state, and escalation history.
• Retention and integrity. Send records to a retention-controlled audit or security platform with access controls and tamper-evident handling. Microsoft service logs are valuable evidence, but describing all offboarding logs as immutable overstates their default guarantees.

Implementation checklist

• Define voluntary, involuntary, contractor, lost-device, legal-hold, shared-device, and deceased-employee paths before enabling destructive automation.
• Separate the effective departure time from the time the source event arrives, normalize time zones, and test daylight-saving transitions.
• Use stable Microsoft Entra and Intune object identifiers instead of display names, email addresses, or device names as destructive-action keys.
• Make event processing idempotent and prevent duplicate or out-of-order events from dispatching conflicting device actions.
• Require manual approval when ownership, custody, legal hold, or device identity is ambiguous.
• Test powered-off, airplane-mode, stale-record, multi-device, shared-device, and already-retired cases in a nonproduction ring.
• Measure identity-containment time, device-delivery time, completion time, exception age, wrong-device prevention, and physical-return time separately.

Related resources

• Use the complete lifecycle model in Zero-touch endpoint management for security teams.
• Build the preventive Windows control floor with the Windows Autopilot security baseline for mid-market teams.
• Plan deeper offline visibility and approved local controls with MDM plus native agent architecture.
• Explore Gideon Endpoint Management for lifecycle, posture, and remediation evaluation paths.

Primary references

• Microsoft describes built-in identity tasks and Logic Apps extensibility in Plan a Lifecycle Workflows deployment.
• Microsoft documents the custom extension boundary in Lifecycle Workflows custom task extensions.
• Microsoft defines remote-action connectivity, precedence, and status behavior in Device actions in Microsoft Intune.
• Microsoft documents company-data removal and next-check-in behavior in Remote device action: Retire.
• Microsoft documents reset behavior and platform-specific options in Device action: Wipe.
• Microsoft documents reuse behavior and retained configuration in Device action: Autopilot Reset.
• Microsoft explains why access-token enforcement varies by service in Continuous access evaluation in Microsoft Entra.

How to use this resource

Turn each architecture stage into an owned control with a measurable service level. Pilot first with synthetic departures and test devices, prove that ambiguous device matches stop safely, and define success as verified identity containment plus a confirmed endpoint outcome or a formally accepted exception.