This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Training module · Draft

Microsoft Automation, Module 3: Intune through Microsoft Graph

Learn the Graph APIs, least-privileged permissions and v1.0-versus-beta status behind managed devices, compliance, configuration, assignment filters, Autopilot, apps and remote actions, then run five read-only checks mapped to NIST SP 800-53 Moderate, ScubaGear and M-22-09 on fixtures and in your test tenant

Research draft: Module 3 of the Microsoft Automation learning path, for Book 05. You learn managed devices, compliance policies and per-device compliance status, configuration profiles and the beta-only Settings Catalog, assignment filters, Windows Autopilot device identities and profiles, apps, remote actions and their privileged permission, which endpoints are beta-only, Intune’s throttling limits and the reports export-jobs API, and what differs in US Government clouds. Lab 1 runs five read-only checks, which complement the validation kit’s VK-INT checks, in Python and PowerShell against fixtures; Lab 2 runs them read-only against your test tenant.

Modified

November 1, 2026

Status — Draft

This page is still being written. Expect gaps and changes; it is not part of the workbook's production guidance. Last reviewed 2026-11-09.

Learning path: Microsoft Automation · Module 3 of 4 · 86 minutes · Code: examples/ms-automation (intune_tasks.py, FmwGraph.psm1) · Guide: Intune track, Gate 6

Watch: the narrated deck for this module: Deck · Narrated deck (about 14 minutes, captions) · ▶ Watch · MP4 · Script · Captions.

Unit 1: Introduction

5 minutes, with the objectives and prerequisites

Book 05 moves the fleet from Group Policy to Intune and then has to prove, continuously, what each device is. Its Chapter 10 asks for evidence a script can collect: which devices are failing which compliance policy, which devices no policy reaches, which have stopped checking in, which aren’t encrypted or are below the OS floor, and which Autopilot registrations won’t get a profile.

Your Conditional Access policies already require a compliant device. That’s only as good as Intune’s compliance records, and by default a device with no policy assigned counts as compliant. In this module you map each of Book 05’s questions to the Graph API that answers it, the least-privileged permission, and whether the API is in v1.0 or only in beta. Five of them are built as tested, read-only checks, in Python and PowerShell, which you run in the labs. They’re illustrative: unit-tested against fixtures, not proven against live tenants.

How this relates to the validation kit. The validation kit already has seven Intune-track checks, VK-INT-01 to VK-INT-07:

missing provisioning-written extension attributes (VK-INT-01);
stale and duplicate devices, from the Entra ID device object (VK-INT-02);
Autopilot group tags (VK-INT-03);
assignment through dynamic groups versus filters (VK-INT-04);
conflict candidates (VK-INT-05);
platform inventory against the coverage matrix (VK-INT-06);
Group Policy analytics reports, read from the beta endpoint (VK-INT-07).

This module doesn’t repeat them. Its checks read Intune’s own records instead: compliance status per policy, compliance coverage, the Intune sync time, encryption and OS posture, and Autopilot profile assignment.

The federal requirement. Each check evidences NIST SP 800-53 Rev. 5 controls in the Moderate baseline: configuration settings and the baseline (CM-6, CM-2), the component inventory (CM-8, CM-8(1)), protection of information at rest and encryption on mobile devices (SC-28(1), AC-19(5)), and flaw remediation for the OS floor (SI-2). Through Entra ID, compliance is the device-level signal that OMB M-22-09 asks agencies to consider, and that ScubaGear MS.AAD.3.7v1 relies on. Unit 7 maps each check to its controls. Don’t restate the requirements: the M-22-09 mapping is Book 11, Appendix A, and what an assessor reads is Book 05, Chapter 10.

Learning objectives

In this module, you’ll:

Name the Graph API, least-privileged application permission and stage (v1.0 or beta) for each of Book 05’s evidence questions.
Explain which of the things the program relies on are beta-only, and what that means for evidence.
Read managed devices and per-policy compliance status, and the traps in each, including the join on device name.
Explain why remote actions and report export jobs don’t belong in a read-only collector.
Say what differs in GCC High and DoD, why Windows Autopilot is a GCC and commercial check, and why GCC follows commercial Intune.
Run the five checks on fixtures in Python and PowerShell, and read each finding against its control.

Prerequisites

Module 1: the right cloud’s endpoints, app-only sign-in without a secret, paging, throttling and batching. Module 2 covers the Entra ID side, including the Conditional Access policies that consume device compliance.
For Lab 1: the lab tools. No tenant until Lab 2.

Unit 2: The APIs, and v1.0 versus beta

10 minutes

Every Intune API in Graph needs an active Intune license for the tenant.¹ The permission is the least-privileged application permission the API’s reference page lists. Each page’s national cloud table lists the API in the global service (which GCC uses) and in US Government L4 and L5.² The Stage column says whether the API is in v1.0 or only in beta. The Book column is where the workbook uses it.

Question	Graph API	Least-privileged application permission	Stage	Book
Which devices are enrolled, with what OS, compliance state, encryption and last sync?	`GET /deviceManagement/managedDevices`	`DeviceManagementManagedDevices.Read.All`³	v1.0	B05 Ch 10
Which compliance policies exist?	`GET /deviceManagement/deviceCompliancePolicies`	`DeviceManagementConfiguration.Read.All`⁴	v1.0	B05 Ch 08
Whom is a compliance policy assigned to?	`GET .../deviceCompliancePolicies/{id}/assignments`	`DeviceManagementConfiguration.Read.All`⁵	v1.0	B05 Ch 08
What does a compliance policy report for each device?	`GET .../deviceCompliancePolicies/{id}/deviceStatuses`	`DeviceManagementConfiguration.Read.All`⁶	v1.0	B05 Ch 10
Which configuration profiles exist (templates)?	`GET /deviceManagement/deviceConfigurations`	`DeviceManagementConfiguration.Read.All`⁷	v1.0	B05 Ch 08
Which Settings Catalog and endpoint security policies exist?	`GET /deviceManagement/configurationPolicies`	`DeviceManagementConfiguration.Read.All`⁸	beta only	B05 Ch 08
Which assignment filters exist?	`GET /deviceManagement/assignmentFilters`	`DeviceManagementConfiguration.Read.All`⁹	beta only	B05 Ch 08
Which devices are registered in Windows Autopilot?	`GET /deviceManagement/windowsAutopilotDeviceIdentities`	`DeviceManagementServiceConfig.Read.All`¹⁰	v1.0	B05 Ch 04
Has each registration been given a deployment profile?	The same, with `deploymentProfileAssignmentStatus`	`DeviceManagementServiceConfig.Read.All`¹¹	beta only	B05 Ch 04
Which Autopilot deployment profiles exist?	`GET /deviceManagement/windowsAutopilotDeploymentProfiles`	`DeviceManagementServiceConfig.Read.All`¹²	beta only	B05 Ch 04
Which apps does Intune deploy?	`GET /deviceAppManagement/mobileApps`	`DeviceManagementConfiguration.Read.All` (or `DeviceManagementApps.Read.All`)¹³	v1.0	B05 Ch 08
Export a large report	`POST /deviceManagement/reports/exportJobs`	`DeviceManagementConfiguration.ReadWrite.All` (a write permission)¹⁴	v1.0 and beta	B05 Ch 10
Sync, retire or wipe a device	`POST .../managedDevices/{id}/syncDevice`, `/retire`, `/wipe`	`DeviceManagementManagedDevices.PrivilegedOperations.All`¹⁵ ¹⁶ ¹⁷	v1.0	B05 Ch 10

The last two rows aren’t read-only, and the example code doesn’t use them. Unit 5 explains both.

v1.0 versus beta

Microsoft supports the Intune beta APIs but says they “are subject to more frequent change”, and recommends v1.0 where it can be used.¹⁸ Three of the things the program relies on are beta-only today (the compliance-policy settings and Group Policy analytics, below, are two more):

The Settings Catalog (configurationPolicies). Book 05’s policy library is mostly Settings Catalog profiles, so exporting the library as code (CM-2) depends on beta. The resource also carries endpoint security policies: its templateReference.templateFamily can be, for example, endpointSecurityAntivirus.¹⁹
Assignment filters. The filter list is beta-only.²⁰ So is the filter on an assignment: beta documents deviceAndAppManagementAssignmentFilterId and deviceAndAppManagementAssignmentFilterType (none, include or exclude) on the assignment target.²¹ The v1.0 base target type documents no properties,²² so v1.0 can’t tell you which filter an assignment uses. VK-INT-04 needs -IncludeBeta because the Settings Catalog’s configurationPolicies is beta; for the other policy types it reads the filter ID from v1.0 assignments and reports none if the property is absent.
Autopilot profiles. v1.0 lists Autopilot device identities with their group tag, enrollment state and last contact. It doesn’t have deploymentProfileAssignmentStatus or the deployment profiles themselves; both are beta.²³ ²⁴ ²⁵

Two more beta dependencies come from Book 05. Compliance-policy settings such as firewall, TPM and Defender exist only on the beta resource, so the v1.0 compliance-policy read (the first compliance rows in the table above) does not show them (Book 05, Chapter 08). Group Policy analytics (groupPolicyMigrationReports) is also beta-only; VK-INT-07 reads it with -IncludeBeta (Book 05, Chapter 08).

The example code calls v1.0 for everything except the Autopilot profile check, which reads the beta endpoint on the same Graph host. A beta-dependent check should be re-run after each Graph beta change, before its result is used as evidence (design guidance).

Unit 3: Managed devices and compliance

10 minutes

Managed devices

managedDevice is Intune’s record of an enrolled device. The properties the checks read are:²⁶

complianceState: one of unknown, compliant, noncompliant, conflict, error, inGracePeriod or configManager. It supports $filter with eq and or.
lastSyncDateTime: the last successful sync with Intune. It supports $filter with lt and gt.
complianceGracePeriodExpirationDateTime: when the device’s grace period ends.
operatingSystem, osVersion and isEncrypted (“Device encryption status”).
managedDeviceOwnerType: unknown, company or personal.
azureADDeviceId: the Entra device ID, which is the join key to the Entra device object (Book 05, Chapter 03).

The same resource also returns userPrincipalName, emailAddress, userDisplayName and phoneNumber.²⁷ The checks name the properties they need in $select and leave those out, so a check’s output never carries a person’s name or address (design guidance).

Some properties, such as ethernetMacAddress, physicalMemoryInBytes, iccid and udid, return a default value when the device is listed. Their real values come only from a GET of one device that names them in $select.²⁸ A script that reads them from the list sees blanks or zeros that look like data.

Compliance policies and compliance status

A compliance policy’s assignments list its targets. In v1.0 a group target is groupAssignmentTarget with a groupId.²⁹ Beta documents exclusionGroupAssignmentTarget, a group excluded from the assignment.³⁰ A policy with no assignments, or with only exclusions, applies to no device.

deviceStatuses gives one row per device for a policy. Its status is one of unknown, notApplicable, compliant, remediated, nonCompliant, error, conflict or notAssigned. Each row carries deviceDisplayName, deviceModel, lastReportedDateTime and complianceGracePeriodExpirationDateTime, as well as userName and userPrincipalName.³¹ The resource doesn’t document a managed-device ID. Its id is described only as “Key of the entity”. So the checks join a status row to a managed device on the device name, and flag names used by more than one device (inference: the key’s relationship to the managed device isn’t documented).

Two tenant-wide settings sit above every policy (Book 05, Chapter 10). By default, Intune marks a device with no compliance policy assigned as Compliant. Microsoft recommends changing that setting to Not compliant, and recommends that every device be targeted by a compliance policy.³² In Graph the two settings are deviceManagementSettings.secureByDefault (the device is noncompliant when no policy targets it) and deviceComplianceCheckinThresholdDays (how many days a device may go without checking in and remain compliant).³³ The permission for reading them, through the deviceManagement singleton, wasn’t confirmed on Learn on October 30, 2026, so the checks don’t read them.

Unit 4: Configuration, filters, Autopilot and apps

8 minutes

Configuration profiles and the Settings Catalog

Template-based profiles are deviceConfigurations, in v1.0, read with DeviceManagementConfiguration.Read.All.³⁴ Settings Catalog and endpoint security policies are configurationPolicies, in beta. They’re read with DeviceManagementConfiguration.Read.All, and the page also lists DeviceManagementEndpointSecurity.Read.All.³⁵ A complete export of the policy library, for CM-2, needs both lists, so it depends on beta (inference). Per-setting conflict detection is VK-INT-05’s job, and the conflict rules are in Book 05, Chapter 10.

Assignment filters

Filters let a policy reach part of a group by device properties, without changing group membership. Book 05 uses them for time-sensitive assignment (Chapter 08), and VK-INT-04 checks the design. The filter list (/deviceManagement/assignmentFilters, DeviceManagementConfiguration.Read.All) is beta. Each filter has a platform, a rule and payloads that say which policies and groups use it.³⁶

Windows Autopilot

windowsAutopilotDeviceIdentities is the registration record: serial number, group tag, purchase order, enrollment state, last contact and the managed device ID. It’s in v1.0 and needs DeviceManagementServiceConfig.Read.All.³⁷ ³⁸ The v1.0 resource has no profile assignment status. Beta adds:³⁹

deploymentProfileAssignmentStatus: unknown, assignedInSync, assignedOutOfSync, assignedUnkownSyncState (Microsoft’s spelling), notAssigned, pending or failed;
deploymentProfileAssignmentDetailedStatus, such as hardwareRequirementsNotMet;
the deploymentProfile and intendedDeploymentProfile relationships.

The deployment profiles themselves (windowsAutopilotDeploymentProfiles) are listed only in beta, with the same permission.⁴⁰ Both resources also return userPrincipalName and addressableUserName,⁴¹ so the check leaves them out of $select. Group tags, and the vocabulary they draw on, are VK-INT-03’s job (Book 05, Chapter 04).

Apps

GET /deviceAppManagement/mobileApps lists the apps Intune manages, with publishingState among their properties. The page lists DeviceManagementConfiguration.Read.All first, then DeviceManagementApps.Read.All, as read permissions.⁴² A script that reads only apps should still ask for DeviceManagementApps.Read.All. It’s the permission named for apps, and it doesn’t also grant configuration reads (design guidance). None of the five checks reads apps.

Unit 5: Remote actions, limits and large exports

8 minutes

Remote actions

Graph exposes Intune’s device actions on managedDevice, including retire, wipe, syncDevice, remoteLock, rebootNow, shutDown, locateDevice, windowsDefenderScan and cleanWindowsDevice.⁴³ The ones checked for this page all need DeviceManagementManagedDevices.PrivilegedOperations.All, delegated or application. Each returns 204 No Content:

retire;⁴⁴
wipe, whose body sets keepEnrollmentData, keepUserData and the macOS options;⁴⁵
syncDevice, even though a sync changes nothing on the device.⁴⁶

That makes the permission an operator’s permission, not a reader’s. A collector that holds it could wipe the fleet. The example code never asks for it. Keep it in a separate pipeline with its own approval step and Book 05’s retirement order (Chapter 10): keys exported first, and the tenant’s daily retire and delete limits planned for (design guidance).

Paging and limits

Paging. Follow @odata.nextLink until it stops, as in Module 1. Microsoft notes that “different APIs might have different default and maximum page sizes”.⁴⁷ The managedDevices page doesn’t state its page size or a $top maximum.⁴⁸ The example code doesn’t set $top, and doesn’t assume a page size (unverified: Intune’s page size for managedDevices).

Throttling. Intune has its own limits in Graph. For the compliance and configuration resources, including deviceCompliancePolicy, its assignments, deviceComplianceDeviceStatus and deviceConfiguration, the limits are:⁴⁹

any request: 2,000 per 20 seconds per tenant across all apps, and 1,000 per 20 seconds per app per tenant;
writes (POST, PUT, PATCH and DELETE): 200 per 20 seconds per tenant, and 100 per app.

The coverage and noncompliance checks make one request for the policy list and two for each policy, so 100 policies cost about 201 requests. That’s well under the limit. The Retry-After handling from Module 1 covers the rest.

Reports export jobs

For data sets too large to page comfortably, Intune exports its reports through deviceManagement/reports/exportJobs. The export page lists both the beta and the v1.0 endpoint.⁵⁰ The flow:

POST a job with a reportName, an optional filter, the select columns and format (csv by default, or json).
Poll the job by its id until status is completed.
Download the compressed file from the url the job returns. It’s a temporary location, and expirationDateTime says when it ends.⁵¹ ⁵²

Three cautions:

Creating a job needs a write permission. The v1.0 page lists DeviceManagementConfiguration.ReadWrite.All as the least privileged, then DeviceManagementApps.ReadWrite.All and DeviceManagementManagedDevices.ReadWrite.All. It lists no read-only permission.⁵³ A read-only collector can’t start an export job, which is why the example checks page through the list APIs instead.
The download isn’t on the Graph host. Microsoft’s example URL is a blob storage address with a signed query string.⁵⁴ Fetch it without the Graph token. graphkit.py refuses to send its token to any host but the cloud’s Graph host, so it can’t download the file (design guidance).
Name the columns. Microsoft says not to build automation on a report’s default columns, and to select columns explicitly. The export API takes up to 100 requests per tenant per minute: 48 per app, and 8 per user.⁵⁵

The report names include:⁵⁶

DeviceNonCompliance and DevicesWithoutCompliancePolicy (with V3 variants);
Devices and DevicesWithInventory;
TpmAttestationStatus, under the device encryption status report;
AutopilotV1DeploymentStatus.

The Devices and DevicesWithInventory exports ignore the localizationType parameter.⁵⁷

Unit 6: Where agencies are

7 minutes

The starting state. Book 05’s agency manages Windows with Group Policy and, often, Configuration Manager, and is moving the fleet to Intune in a Microsoft 365 GCC tenant. During the move some devices have no compliance policy, the tenant-wide default may still mark them compliant, and stale records pile up.

GCC. Intune has no separate GCC instance. “GCC is the same instance as Microsoft Intune in the commercial space,” and Intune’s government feature table doesn’t apply to GCC.⁵⁸ GCC uses the worldwide Graph endpoint, https://graph.microsoft.com, as Module 1 sets out.⁵⁹ The Intune feature gaps a GCC tenant does have are Book 05’s subject (Chapter 10, GCC (Moderate) boundary facts). For example, Windows Update for Business reports don’t meet GCC requirements.

GCC High and DoD (High only). These tenants use their own Graph hosts, https://graph.microsoft.us and https://dod-graph.microsoft.us.⁶⁰ Intune runs a separate government instance shared by GCC High and DoD tenants, and moving between the commercial and government instances means unenrolling and re-enrolling every device.⁶¹ Microsoft’s service description, read on October 30, 2026, lists these differences that affect the APIs on this page:⁶²

Not available, with no plans to add them:
- Windows Autopilot;
- Remediations;
- reports for feature update policies;
- app and driver compatibility reports;
- the ServiceNow connector;
- Windows Subscription Activation.
Not available yet, with planning started:
- Windows Autopatch and feature, quality, expedite and driver updates;
- Windows Device Health Attestation;
- BIOS configuration and DFCI;
- some Windows Autopilot device preparation features.
Available:
- standard MDM features (compliance, configuration profiles and app policies);
- Log Analytics export;
- Defender for Endpoint security settings management;
- Endpoint Privilege Management and some other add-ons.
- Cloud PKI and Remote Help are listed for GCC High only, not DoD.

One discrepancy to note. The Graph reference pages for Autopilot device identities list the API as available in US Government L4 and L5,⁶³ while the service description lists Windows Autopilot as not available in GCC High and DoD.⁶⁴ The service description decides whether the feature can be used. That an endpoint answers doesn’t mean the feature is supported (inference). The autopilot-profiles check is therefore for GCC and commercial tenants: in gcchigh and dod it reports “not evaluated” without calling Graph, as Lab 1 shows.

Interim paths (design guidance):

Devices with no compliance policy yet. Run compliance-coverage until it lists none, then change the tenant-wide setting to Not compliant, as Microsoft recommends;⁶⁵ until then, Conditional Access treats an unassigned device as compliant.
Devices still managed by Group Policy or Configuration Manager. Their records aren’t in Intune yet, so these checks don’t see them; VK-INT-06’s platform inventory and the companion guide’s coverage matrix track what’s left.
A GCC High or DoD tenant. Classic Autopilot isn’t available; Book 05, Chapter 04 compares it with Autopilot device preparation, which its table lists for GCC High and DoD. Evidence the enrollment with the other four checks.
Settings Catalog export depends on beta. Keep the export, label it beta in the evidence, and re-run it after a beta change before relying on it.

Unit 7: The five checks

5 minutes

Each check is read-only, and each is tied to the federal requirement it evidences. The mapping is the program’s reading; the agency’s assessor decides whether a control is satisfied (Book 05, Chapter 10). Every control named below is in the NIST SP 800-53 Rev. 5 Moderate baseline.⁶⁶ ScubaGear has no Intune baseline. Its baselines cover Entra ID, Exchange Online, Power BI, Power Platform, SharePoint, the security suite and Teams, plus a placeholder for Super Intelligence (SI) and SI agents, added on November 4, 2026, with no policies yet.⁶⁷ The ScubaGear tie is through Entra ID: MS.AAD.3.7v1, “Managed devices SHOULD be required for authentication”, rests on M-22-09’s requirement that agencies “consider at least one device-level signal” when authorizing users.⁶⁸ Intune compliance is that signal. The M-22-09 mapping is Book 11, Appendix A.

Check	What it reports	Evidences	Complements
`noncompliant-devices`	Devices in `noncompliant`, `inGracePeriod`, `error` or `conflict`, each with the policies reporting `nonCompliant`, `error` or `conflict`, and the grace-period end	CM-6; M-22-09’s device-level signal; supports ScubaGear MS.AAD.3.7v1	Book 05’s compliance status review
`compliance-coverage`	Compliance policies with no assignment or only exclusions; managed devices that no policy reports on	CM-2, CM-6; supports MS.AAD.3.7v1, because by default an unassigned device counts as compliant	VK-INT-04 (assignment design)
`stale-checkin`	Devices whose last Intune sync is older than the compliance validity period or the cleanup age (the check defaults to the program’s values: 14 days, where Intune’s own default is 30, and 90 days, set for Windows), and devices with no sync	CM-8; M-22-09’s device inventory	VK-INT-02, which reads the Entra device’s sign-in instead
`device-posture`	Windows and macOS devices not reporting encryption, and devices below the OS floor for their platform (default Windows 10.0.26100, Book 05’s CP-001 floor)	SC-28(1) and AC-19(5) for encryption; SI-2 and CM-6 for the OS floor	VK-INT-06 (platform inventory)
`autopilot-profiles` (beta)	Autopilot registrations by profile assignment status; every one not `assignedInSync`, with the detailed status	CM-8(1); CM-2 (devices provisioned to the baseline)	VK-INT-03 (group tags)

The permissions for all five together are DeviceManagementManagedDevices.Read.All, DeviceManagementConfiguration.Read.All and DeviceManagementServiceConfig.Read.All. That’s a reader’s set: none of them can change a device or a policy. Grant only the ones for the checks you run. autopilot-profiles is the only one that needs DeviceManagementServiceConfig.Read.All, and the only one on beta.

Some notes on what the checks can and can’t say:

Joined on device name. Compliance status rows carry a device name, not a documented managed-device ID, so both compliance checks join on the name. They flag names held by more than one device, because a finding on one of those may belong to the other. Book 05’s naming convention builds Autopilot names from the serial number, which makes duplicates rare on that path (inference).
isEncrypted is what Intune reports. It doesn’t say which method or which volumes. BitLocker’s own state is a compliance setting measured at boot through Device Health Attestation (Book 05, Chapter 08). Treat notEncrypted as a lead to confirm in the encryption report, not as proof (inference).
Personal iOS and Android devices aren’t held to the encryption rule by default. The platforms are a parameter.
A placeholder date counts as no sync. A lastSyncDateTime before 1971 is treated as no sync. That guards against a default date, which wasn’t confirmed in Microsoft’s documentation (design guidance).

Unit 8: Exercise: Lab 1 (fixtures, no tenant)

25 minutes

Every command in Lab 1

Every command in this lab, in order, from examples/ms-automation. Each step below says what it does and what to look for.

In a POSIX shell (Git Bash on Windows):

# Step 1
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z noncompliant-devices

# Step 2
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z compliance-coverage

# Step 3
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z stale-checkin

# Step 3
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z stale-checkin --validity-days 30

# Step 4
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z device-posture

# Step 5
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z autopilot-profiles

# Step 6
python -c "import sys; sys.path.insert(0, 'python'); from graphkit import GraphClient, try_beta; print(try_beta(GraphClient('gcchigh', lambda s: 't'), '/deviceManagement/windowsAutopilotDeviceIdentities'))"

In PowerShell 7:

# Step 7
Import-Module ./powershell/FmwGraph.psm1
$intune = Get-Content -Raw tests/fixtures/intune.json | ConvertFrom-Json -AsHashtable -DateKind String
Test-FmwIntuneStaleCheckin -Devices $intune.managedDevices -AsOf '2026-10-30T00:00:00Z' | ConvertTo-Json
(Test-FmwIntunePosture -Devices $intune.managedDevices).findings.deviceName

In a POSIX shell (Git Bash on Windows):

# Step 8
python -m pytest -q -p no:cacheprovider tests/python/test_intune_tasks.py

You run each check against the kit’s fictional fleet of nine devices and six Autopilot registrations. Work in examples/ms-automation. --from-json evaluates a saved Graph response instead of calling Graph, and --as-of fixes the evaluation time so your output matches this page. Every result starts with the task’s name and the controls it evidences.

Find the devices that need attention.
```
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z noncompliant-devices
```
Expected: four devices, IPH-0001, WS-0002, WS-0003 and WS-0005, each with its failing policy, ending with:
```
    "counts": {
      "noncompliant": 2,
      "inGracePeriod": 1,
      "error": 1,
      "conflict": 0
    }
```
WS-0003’s grace period ends 2026-10-31T00:00:00Z. WS-0002 has "nameNotUnique": true: two devices share that name, so its policy status may belong to the other one.
Find what no policy reaches.
```
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z compliance-coverage
```
Expected: "policyFindings": 2. CP-005 Kiosk and shared devices is exclusionOnly and CP-099 Old macOS pilot is unassigned. KSK-0001 and MAC-0001 are in devicesWithNoPolicyReported, and "ambiguousNames" lists WS-0002. With the tenant’s default setting, those two devices count as compliant.

Find devices that stopped checking in.

python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z stale-checkin

Expected result:

  "result": [
    {
      "id": "md9",
      "deviceName": "KSK-0001",
      "operatingSystem": "Windows",
      "lastSync": null,
      "daysSinceSync": null,
      "band": "noSync"
    },
    {
      "id": "md5",
      "deviceName": "WS-0005",
      "operatingSystem": "Windows",
      "lastSync": "2026-07-01T00:00:00Z",
      "daysSinceSync": 121,
      "band": "beyondCleanup"
    },
    {
      "id": "md4",
      "deviceName": "WS-0004",
      "operatingSystem": "Windows",
      "lastSync": "2026-10-10T00:00:00Z",
      "daysSinceSync": 20,
      "band": "beyondValidity"
    }
  ]

KSK-0001’s fixture date is a placeholder before 1971, so it counts as no sync. Run it again with --validity-days 30 after stale-checkin:

python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z stale-checkin --validity-days 30

WS-0004, at 20 days, drops out.

Check encryption and the OS floor.
```
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z device-posture
```
Expected: "devices": 9, "notEncrypted": 3 and "belowOsFloor": 1. KSK-0001 reports no encryption state (null), MAC-0001 reports false, and WS-0002, on 10.0.22631.4317, is both unencrypted and below the Windows floor of 10.0.26100.
Read Autopilot profile assignment, on beta.
```
python python/intune_tasks.py --from-json tests/fixtures/intune.json --as-of 2026-10-30T00:00:00Z autopilot-profiles
```
Expected: "stage": "beta", "evaluated": true, "total": 6, with two assignedInSync and four in notInSync: SN-1004 (assignedOutOfSync), SN-1003 (failed, hardwareRequirementsNotMet), SN-1002 (notAssigned) and SN-1005 (pending, with no group tag).

See why the Autopilot check is for GCC and commercial tenants. Ask the client to read the beta collection as a GCC High run would:

python -c "import sys; sys.path.insert(0, 'python'); from graphkit import GraphClient, try_beta; print(try_beta(GraphClient('gcchigh', lambda s: 't'), '/deviceManagement/windowsAutopilotDeviceIdentities'))"

Expected output:

{'stage': 'beta', 'available': False, 'items': [], 'reason': "autopilot-device-identities isn't offered in gcchigh (graph-calls.json not_in_clouds)"}

No request was made: graph-calls.json follows the service description, not the API page.

Run two of the same checks in PowerShell. Start pwsh in examples/ms-automation, then:

Import-Module ./powershell/FmwGraph.psm1
$intune = Get-Content -Raw tests/fixtures/intune.json | ConvertFrom-Json -AsHashtable -DateKind String
Test-FmwIntuneStaleCheckin -Devices $intune.managedDevices -AsOf '2026-10-30T00:00:00Z' | ConvertTo-Json
(Test-FmwIntunePosture -Devices $intune.managedDevices).findings.deviceName

Expected: the same three stale devices as step 3, then KSK-0001, MAC-0001 and WS-0002 on three lines.

Run the Intune tests.
```
python -m pytest -q -p no:cacheprovider tests/python/test_intune_tasks.py
```
Expected: 17 passed. Two of them, test_permissions_are_read_only and test_fetch_devices_selects_no_personal_fields, prove the checks ask for no write permission and select no person’s name or address.

Check your work: for each finding, you can name the Graph property it came from, the control it evidences, and whether it depends on beta.

Unit 9: Exercise: Lab 2 (your test tenant)

Not timed. Not run by the authors.

Every command in Lab 2

Every command in this lab, in order, from examples/ms-automation. Each step below says what it does and what to look for.

In a POSIX shell (Git Bash on Windows):

# Step 3: Run the checks
pip install azure-identity
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem noncompliant-devices
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem compliance-coverage
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem stale-checkin
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem device-posture
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem autopilot-profiles

In PowerShell 7:

# Step 3: Run the checks
Import-Module ./powershell/FmwGraph.psm1
Connect-FmwGraph -Cloud gcc -TenantId <tenant-id> -ClientId <app-id> -CertificateThumbprint <thumbprint>
Invoke-FmwIntuneTask -Task device-posture

You run the checks read-only against a test tenant and compare them with the Intune admin center.

You need: a test tenant in the worldwide or GCC cloud, never production, with an active Intune license and a few enrolled test devices; a Privileged Role Administrator, in practice typically a Global Administrator, to grant admin consent (Module 1); Python with the azure-identity package (step 3 installs it), or Microsoft Graph PowerShell.
You’ll replace: <tenant-id> (the test tenant’s ID), <app-id> (the app’s application (client) ID), <thumbprint> (its certificate’s thumbprint, for PowerShell); app.pem is the PEM file with the certificate and its private key. Work in examples/ms-automation.

Register one app in the tenant’s own cloud, with a certificate credential and no secret.

Grant only the application permissions for the checks you run, and admin consent:

Check	Permissions
`noncompliant-devices`, `compliance-coverage`	`DeviceManagementManagedDevices.Read.All`, `DeviceManagementConfiguration.Read.All`
`stale-checkin`, `device-posture`	`DeviceManagementManagedDevices.Read.All`
`autopilot-profiles` (beta)	`DeviceManagementServiceConfig.Read.All`

Never grant DeviceManagementManagedDevices.PrivilegedOperations.All to this app (Unit 5).

Run the checks. In Python, one command per task:

pip install azure-identity
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem noncompliant-devices
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem compliance-coverage
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem stale-checkin
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem device-posture
python python/intune_tasks.py --cloud gcc --tenant <tenant-id> --client <app-id> --cert app.pem autopilot-profiles

In PowerShell:

Import-Module ./powershell/FmwGraph.psm1
Connect-FmwGraph -Cloud gcc -TenantId <tenant-id> -ClientId <app-id> -CertificateThumbprint <thumbprint>
Invoke-FmwIntuneTask -Task device-posture

A missing permission stops the run before any Graph call.

Compare each result with the Intune admin center’s compliance, device and Autopilot views, and record the open review items: whether a status row’s id matches a managed device’s, and whether $select returns every selected property (Status and review).
Back it out. Remove the permissions, delete the app registration and its certificate, and delete the saved results: they hold device names and serial numbers.

Unit 10: Knowledge check

5 minutes

Which of these is beta-only today?
1. Listing managed devices.
2. Listing compliance policies’ device statuses.
3. Reading an Autopilot registration’s deploymentProfileAssignmentStatus.
A compliance policy’s only assignment is an exclusion group. Which check reports it, and why does it matter?
1. stale-checkin, because its devices stop syncing.
2. compliance-coverage, because the policy applies to no device and, by default, an unassigned device counts as compliant.
3. device-posture, because its devices aren’t encrypted.
Why doesn’t the example code start a report export job?
1. Creating a job needs a write permission, and the download is on a host the client won’t send its token to.
2. Export jobs aren’t available in v1.0.
3. Export jobs can’t return JSON.
What does autopilot-profiles report in a GCC High tenant?
1. Every registration as notAssigned.
2. An error from Graph.
3. “Not evaluated,” without calling Graph, because the service description lists Windows Autopilot as not available there.
Why do both compliance checks flag device names held by more than one device?
1. Intune rejects duplicate names.
2. Status rows are joined to devices on the name, because the status row’s id isn’t documented as the managed device ID.
3. M-22-09 forbids duplicate device names.

Check your answers

c. The profile assignment status, the profiles, the Settings Catalog and assignment filters are beta-only. See v1.0 versus beta.
b. A policy with only exclusions reaches no device. See Compliance policies and compliance status, and CP-005 in Lab 1, step 2.
a. See Reports export jobs.
c. See Unit 6: Where agencies are, and Lab 1, step 6.
b. See Compliance policies and compliance status, and WS-0002 in Lab 1, step 1.

Unit 11: Summary

3 minutes

You mapped Book 05’s evidence questions to Graph APIs, their least-privileged permissions and their stage, learned the traps in managed devices and compliance status, kept remote actions and export jobs out of the collector, and saw why Autopilot is a GCC and commercial check. In Lab 1 you ran the five checks on fixtures in Python and PowerShell and read each finding against its control.

Evidence an ISSO keeps from this module: each check’s dated output, with its evidences list, the app’s permissions and consent record, and the beta label on autopilot-profiles; the coverage result showing every device under a policy, and the record of the tenant-wide setting changed to Not compliant; the encryption findings confirmed in Intune’s encryption report; and the validation kit’s VK-INT results beside them. Book 05, Chapter 10 lists what an assessor reads, and the Intune track guide’s Gate 6 puts it on a schedule.

Continue the path

Previous: Module 2 · Learning path · Next: Module 4, Azure Arc through Azure Resource Manager and Resource Graph →

Status and review

Draft. Every API, permission, property, limit and cloud difference was checked against Microsoft Learn on October 30, 2026. The ScubaGear baseline and the NIST SP 800-53 Moderate baseline were checked the same day. Inferences, design guidance and unverified points are labeled, and the verification log lists each claim with its source. The checks are tested against fixtures only, and the Lab 1 commands were run on November 1, 2026; the output shown is what they printed.

To move this page to In review: - a reviewer confirms the permissions table and the beta list; - someone confirms that deviceComplianceDeviceStatus.id can’t be joined to the managed device ID; - someone confirms the permission for reading deviceManagement/settings.

To move it to Proved: run the five checks against a test tenant and compare the results with the Intune admin center’s compliance, device and Autopilot views. Record that comparison here. Comments and corrections are welcome as issues on GitHub.

Footnotes

Microsoft Learn, “List managedDevices” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
The national cloud deployment table on each API’s Microsoft Graph reference page, cited for each API below, accessed October 30, 2026.↩︎
Microsoft Learn, “List managedDevices” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceCompliancePolicies” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-devicecompliancepolicy-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceCompliancePolicyAssignments” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-devicecompliancepolicyassignment-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceComplianceDeviceStatuses” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-devicecompliancedevicestatus-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceConfigurations” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-deviceconfiguration-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceManagementConfigurationPolicies” (beta), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfigv2-devicemanagementconfigurationpolicy-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceAndAppManagementAssignmentFilters” (beta; the v1.0 selector returns the beta page), https://learn.microsoft.com/en-us/graph/api/intune-policyset-deviceandappmanagementassignmentfilter-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List windowsAutopilotDeviceIdentities” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-enrollment-windowsautopilotdeviceidentity-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “windowsAutopilotDeviceIdentity resource type” (beta), https://learn.microsoft.com/en-us/graph/api/resources/intune-enrollment-windowsautopilotdeviceidentity?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List azureADWindowsAutopilotDeploymentProfiles” (beta), https://learn.microsoft.com/en-us/graph/api/intune-enrollment-azureadwindowsautopilotdeploymentprofile-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List mobileApps” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-apps-mobileapp-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Create deviceManagementExportJob” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-reporting-devicemanagementexportjob-create?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “syncDevice action” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-syncdevice?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “retire action” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-retire?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “wipe action” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-wipe?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceManagementConfigurationPolicies” (beta), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfigv2-devicemanagementconfigurationpolicy-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceManagementConfigurationPolicies” (beta), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfigv2-devicemanagementconfigurationpolicy-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceAndAppManagementAssignmentFilters” (beta; the v1.0 selector returns the beta page), https://learn.microsoft.com/en-us/graph/api/intune-policyset-deviceandappmanagementassignmentfilter-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “exclusionGroupAssignmentTarget resource type” (beta), https://learn.microsoft.com/en-us/graph/api/resources/intune-deviceconfig-exclusiongroupassignmenttarget?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “deviceAndAppManagementAssignmentTarget resource type” (v1.0; “Properties: None”), https://learn.microsoft.com/en-us/graph/api/resources/intune-shared-deviceandappmanagementassignmenttarget?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “windowsAutopilotDeviceIdentity resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-enrollment-windowsautopilotdeviceidentity?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “windowsAutopilotDeviceIdentity resource type” (beta), https://learn.microsoft.com/en-us/graph/api/resources/intune-enrollment-windowsautopilotdeviceidentity?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List azureADWindowsAutopilotDeploymentProfiles” (beta), https://learn.microsoft.com/en-us/graph/api/intune-enrollment-azureadwindowsautopilotdeploymentprofile-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “managedDevice resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “managedDevice resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “managedDevice resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “groupAssignmentTarget resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-shared-groupassignmenttarget?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “exclusionGroupAssignmentTarget resource type” (beta), https://learn.microsoft.com/en-us/graph/api/resources/intune-deviceconfig-exclusiongroupassignmenttarget?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “deviceComplianceDeviceStatus resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-deviceconfig-devicecompliancedevicestatus?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Intune reports”, section “Devices without compliance policy (Organizational)”, https://learn.microsoft.com/en-us/intune/device-management/reports/overview#device-compliance-reports, accessed October 30, 2026.↩︎
Microsoft Learn, “deviceManagementSettings resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-deviceconfig-devicemanagementsettings?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceConfigurations” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfig-deviceconfiguration-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceManagementConfigurationPolicies” (beta), https://learn.microsoft.com/en-us/graph/api/intune-deviceconfigv2-devicemanagementconfigurationpolicy-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List deviceAndAppManagementAssignmentFilters” (beta; the v1.0 selector returns the beta page), https://learn.microsoft.com/en-us/graph/api/intune-policyset-deviceandappmanagementassignmentfilter-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List windowsAutopilotDeviceIdentities” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-enrollment-windowsautopilotdeviceidentity-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “windowsAutopilotDeviceIdentity resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-enrollment-windowsautopilotdeviceidentity?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “windowsAutopilotDeviceIdentity resource type” (beta), https://learn.microsoft.com/en-us/graph/api/resources/intune-enrollment-windowsautopilotdeviceidentity?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List azureADWindowsAutopilotDeploymentProfiles” (beta), https://learn.microsoft.com/en-us/graph/api/intune-enrollment-azureadwindowsautopilotdeploymentprofile-list?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “windowsAutopilotDeviceIdentity resource type” (beta), https://learn.microsoft.com/en-us/graph/api/resources/intune-enrollment-windowsautopilotdeviceidentity?view=graph-rest-beta, accessed October 30, 2026.↩︎
Microsoft Learn, “List mobileApps” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-apps-mobileapp-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “managedDevice resource type” (v1.0), https://learn.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “retire action” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-retire?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “wipe action” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-wipe?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “syncDevice action” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-syncdevice?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Paging Microsoft Graph data in your app”, https://learn.microsoft.com/en-us/graph/paging, accessed October 30, 2026.↩︎
Microsoft Learn, “List managedDevices” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-devices-manageddevice-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Graph service-specific throttling limits”, section “Intune service limits”, https://learn.microsoft.com/en-us/graph/throttling-limits#intune-service-limits, accessed October 30, 2026.↩︎
Microsoft Learn, “Export Intune reports using Graph APIs”, https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/reports-export-graph-apis, accessed October 30, 2026.↩︎
Microsoft Learn, “Export Intune reports using Graph APIs”, https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/reports-export-graph-apis, accessed October 30, 2026.↩︎
Microsoft Learn, “Create deviceManagementExportJob” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-reporting-devicemanagementexportjob-create?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Create deviceManagementExportJob” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-reporting-devicemanagementexportjob-create?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Export Intune reports using Graph APIs”, https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/reports-export-graph-apis, accessed October 30, 2026.↩︎
Microsoft Learn, “Export Intune reports using Graph APIs”, https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/reports-export-graph-apis, accessed October 30, 2026.↩︎
Microsoft Learn, “Intune reports and properties available using Graph API”, https://learn.microsoft.com/en-us/intune/device-management/reports/ref-graph-available-reports, accessed October 30, 2026.↩︎
Microsoft Learn, “Export Intune reports using Graph APIs”, https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/reports-export-graph-apis, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Intune for US Government GCC High and DoD service description”, https://learn.microsoft.com/en-us/intune/fundamentals/government-service, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Graph national cloud deployments”, https://learn.microsoft.com/en-us/graph/deployments, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Graph national cloud deployments”, https://learn.microsoft.com/en-us/graph/deployments, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Intune for US Government GCC High and DoD service description”, https://learn.microsoft.com/en-us/intune/fundamentals/government-service, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Intune for US Government GCC High and DoD service description”, https://learn.microsoft.com/en-us/intune/fundamentals/government-service, accessed October 30, 2026.↩︎
Microsoft Learn, “List windowsAutopilotDeviceIdentities” (v1.0), https://learn.microsoft.com/en-us/graph/api/intune-enrollment-windowsautopilotdeviceidentity-list?view=graph-rest-1.0, accessed October 30, 2026.↩︎
Microsoft Learn, “Microsoft Intune for US Government GCC High and DoD service description”, https://learn.microsoft.com/en-us/intune/fundamentals/government-service, accessed October 30, 2026.↩︎
Microsoft Learn, “Intune reports”, section “Devices without compliance policy (Organizational)”, https://learn.microsoft.com/en-us/intune/device-management/reports/overview#device-compliance-reports, accessed October 30, 2026.↩︎
NIST, SP 800-53 Rev. 5 Moderate baseline, OSCAL profile version 5.2.0 (includes AC-19(5), CM-2, CM-6, CM-8, CM-8(1), SC-28, SC-28(1) and SI-2), https://github.com/usnistgov/oscal-content/blob/main/nist.gov/SP800-53/rev5/json/NIST_SP-800-53_rev5_MODERATE-baseline_profile.json, accessed October 30, 2026.↩︎
CISA, ScubaGear baselines folder (aad.md, exo.md, powerbi.md, powerplatform.md, securitysuite.md, sharepoint.md, teams.md, plus removedpolicies.md), https://github.com/cisagov/ScubaGear/tree/main/PowerShell/ScubaGear/baselines, accessed October 30, 2026; re-read November 9, 2026, when it also held si.md, a Super Intelligence (SI) and SI agents baseline added at commit 8c954fc with its description and policies marked TBD.↩︎
CISA, ScubaGear Microsoft Entra ID baseline (aad.md), policies MS.AAD.3.7v1 and 3.8v1 and the M-22-09 quotation in their rationale, https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/baselines/aad.md, accessed October 30, 2026.↩︎