AD3.2 Auditing Your Current Device Estate

Running the enrollment audit

Navigate to intune.microsoft.com → Devices → All devices. Export the device list to CSV by clicking the "Export" button. This gives you every enrolled device with its OS, last check-in date, enrollment date, and management state.

In parallel, get your total device count from the M365 Admin Center → Devices → Active devices. This shows every device that has authenticated to M365, including devices not enrolled in Intune. The difference between the M365 device count and the Intune enrollment count is your enrollment gap.

For a more precise audit, use PowerShell to pull enrollment data programmatically:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

# Get all Intune-managed devices
$devices = Get-MgDeviceManagementManagedDevice -All
$total = $devices.Count

# Group by OS
$devices | Group-Object OperatingSystem |
    Select-Object Name, Count |
    Sort-Object Count -Descending | Format-Table

# Find devices with outdated OS
$devices | Where-Object {
    $_.OperatingSystem -eq "Windows" -and
    $_.OsVersion -lt "10.0.22631"  # Windows 11 23H2
} | Select-Object DeviceName, OsVersion, UserPrincipalName |
    Format-Table -AutoSize

# Find devices that haven't checked in for 30+ days
$stale = (Get-Date).AddDays(-30)
$devices | Where-Object { $_.LastSyncDateTime -lt $stale } |
    Select-Object DeviceName, LastSyncDateTime, UserPrincipalName |
    Format-Table -AutoSize

The stale devices check is critical. A device that hasn't checked into Intune for 30+ days isn't receiving policy updates, configuration changes, or compliance evaluations. It's functionally unmanaged even though it shows as "enrolled." These devices need investigation: is the device still in use? Has the employee left the company? Is the device broken or decommissioned?

Predicting compliance failures

Before building the compliance policy, predict how many devices would fail each check. This tells you the remediation workload before enforcement.

BitLocker. Check how many enrolled Windows devices have BitLocker enabled:

$devices | Where-Object { $_.OperatingSystem -eq "Windows" } |
    Select-Object DeviceName, IsEncrypted, UserPrincipalName |
    Group-Object IsEncrypted |
    Select-Object Name, Count

If IsEncrypted = False shows 30 devices, you have 30 devices that need BitLocker enabled before compliance enforcement. BitLocker can be pushed via Intune configuration profile — but it requires TPM and may need the user to set a PIN or save the recovery key. Plan for 15-30 minutes per device.

Operating system version. The query above (filtering by OsVersion -lt) shows how many devices are running an outdated OS. Each one needs a Windows Update, which may require a restart and 30-60 minutes of downtime. For devices that are multiple versions behind, the update may take longer.

Firewall and antivirus. These are harder to check before compliance policy deployment because Intune evaluates them during compliance check-in, not as static properties. The practical approach: deploy the compliance policy in report-only mode (or with a long grace period) and let Intune evaluate each device. After 48 hours, the compliance dashboard shows exactly which devices fail which checks.

Building the remediation plan

For each category of predicted failure, create a remediation action with a timeline:

BitLocker not enabled (estimated: 15-20 devices). Create an Intune configuration profile to enable BitLocker silently. Navigate to intune.microsoft.com → Devices → Configuration profiles → Create profile → Windows 10 and later → Endpoint protection → Windows Encryption. Configure BitLocker to enable silently (requires TPM 2.0, which all modern devices have). Deploy to a pilot group first, then all devices. Allow 1 week for deployment to complete across all devices.

Outdated OS (estimated: 10-15 devices). Verify your Windows Update ring in Intune is configured to deploy security updates within 7 days of release and feature updates within 30 days. For devices that are significantly behind, create a one-time update deployment or contact users individually to initiate updates.

Stale devices (estimated: 5-10 devices). Contact the assigned user for each stale device. If the device is no longer in use, remove it from Intune. If it's still in use, the user needs to connect to the network and sync with Intune. If the user has left the company, wipe the device remotely (corporate-owned) or remove corporate data (BYOD).

Unenrolled corporate devices (estimated: 10 devices). Contact the assigned user and walk them through Intune enrollment. For Windows devices joined to Azure AD, enrollment is typically automatic via Windows Autopilot. For devices that were set up before Autopilot, manual enrollment takes 5-10 minutes.

Cross-referencing Entra ID devices with Intune enrollment

Intune shows enrolled devices. Entra ID shows all devices that have authenticated. The gap between them reveals unenrolled devices accessing your data.

Connect-MgGraph -Scopes "Device.Read.All","DeviceManagementManagedDevices.Read.All"

# All devices registered in Entra ID
$entraDevices = Get-MgDevice -All |
    Where-Object { $_.OperatingSystem -ne $null }

# All devices managed in Intune
$intuneDevices = Get-MgDeviceManagementManagedDevice -All

Write-Host "Entra ID devices: $($entraDevices.Count)"
Write-Host "Intune managed:   $($intuneDevices.Count)"
Write-Host "Enrollment gap:   $($entraDevices.Count - $intuneDevices.Count) devices"

# Find Entra devices NOT in Intune
$intuneIds = $intuneDevices | Select-Object -ExpandProperty AzureAdDeviceId
$unmanaged = $entraDevices | Where-Object { $_.DeviceId -notin $intuneIds }
$unmanaged | Select-Object DisplayName, OperatingSystem,
    @{N="LastSignIn";E={$_.ApproximateLastSignInDateTime}} |
    Sort-Object LastSignIn -Descending | Format-Table -AutoSize

This gives you the exact list of devices that authenticate to M365 but aren't managed by Intune. Each one needs a plan before CA003 enforcement: enroll it (corporate device), apply app protection (BYOD), or accept it will be blocked.

For a visual overview, navigate to intune.microsoft.com → Devices → Enrollment → Overview. The enrollment dashboard shows enrollment trends, failure rates, and devices pending enrollment. If you see enrollment failures, investigate the cause (license assignment, MDM authority, or user/device limits) before building compliance policies.

Additionally, check whether Windows Autopilot is configured for your environment. Navigate to intune.microsoft.com → Devices → Enrollment → Windows → Windows Autopilot → Devices. If you have Autopilot profiles, new devices automatically enroll during setup — reducing the future enrollment gap. If Autopilot isn't configured, new devices need manual enrollment, which means the enrollment gap will grow with every hardware refresh unless you address it.

Estimating your BYOD population

The enrollment audit tells you about managed devices. But some employees access M365 from personal devices that aren't enrolled and won't appear in Intune. Estimate this population from the Entra ID sign-in log:

Connect-MgGraph -Scopes "AuditLog.Read.All"
$start = (Get-Date).AddDays(-30).ToString("yyyy-MM-ddTHH:mm:ssZ")

# Sign-ins from unmanaged devices in the last 30 days
Get-MgAuditLogSignIn -Filter "createdDateTime ge $start" -Top 500 |
    Where-Object { $_.DeviceDetail.IsManaged -eq $false -and $_.Status.ErrorCode -eq 0 } |
    Group-Object UserPrincipalName |
    Select-Object Name, Count |
    Sort-Object Count -Descending |
    Format-Table -AutoSize

This shows every user who successfully signed in from an unmanaged device in the last 30 days. Each of these users needs a plan before CA003 enforcement: either enroll their device (if it's a corporate device that was missed) or configure app protection policies (if it's a personal BYOD device). Without this analysis, enforcement day blocks users you didn't know were accessing M365 from unmanaged devices.

Documenting and sharing the audit results

Compile your audit findings into a brief summary for your manager. The summary should include: total enrolled vs total expected (with enrollment percentage), the count and list of unenrolled corporate devices (with remediation plan), the BYOD population estimate (users accessing from personal devices), predicted compliance failures by check type (BitLocker, OS, firewall, AV), and the timeline to remediation before enforcement.

This summary serves two purposes: it secures management buy-in for the enforcement timeline (showing you've done the preparation work), and it sets expectations for the enforcement day impact ("we expect 2-3 users to need helpdesk support on day one, down from 30+ if we hadn't done the audit"). Keep the audit data alongside your configuration register — it's the baseline that demonstrates improvement when you run the same audit after enforcement.