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.

Federal Modernization Workbook

Intune Track Implementation: Attribute-Driven Management of End-User Devices

A step-by-step guide to the Intune track of the attribute-driven migration: the prerequisites (licensing, the GCC tenant, roles and the coverage matrix), the device sources and their single writer (Autopilot registration and group tags, enrollment profiles, and Microsoft Graph writes of device extension attributes by the device provisioning service), the targeting design (dynamic device groups, assignment filters, user groups and one owning policy per setting), the computer half of Group Policy moved through Book 05’s GPO-to-Intune migration, the dangers and their mitigations, cut-over waves with rollback, and operating the result: stale-device cleanup, drift, and evidence for CM-2, CM-6, CM-7, CM-8 and the M-22-09 device signals. Every gate names the validation kit checks that prove it.

A device gets the right policy because of what it says about itself, so the work is making one service say it, making nothing else able to, and proving both every week.

In this guide

The working path for the Intune track of the attribute-driven migration: end-user devices moving from OU-linked Group Policy to Intune policy targeted by device attributes. Seven gates, each with its steps, a Validate step that names the validation kit checks proving it, and its rollback: prerequisites; device sources and the single writer; the targeting design; the computer half of Group Policy, moved through Book 05’s migration; dangers and mitigations; cut-over waves; and operating the result, with stale-device cleanup, drift and the evidence an assessor reads. The depth is in Book 05, and this guide links to it rather than repeating it.

How to use this guide

The companion guide is the map of all four tracks; this guide is the route for one, end-user devices. Servers take the Arc track (Book 05, Chapter 09), and the user-configuration half of Group Policy moves with people on the HR track (Stage 6).

Link, don’t repeat. Each step says what to do and links to the Book 05 section that holds the procedure, script or table.
Labels. (Design guidance) marks the program’s recommendations. Facts cite a chapter or a primary source opened on October 29, 2026 and logged in this guide’s verification file.
Validation kit checks. Each Validate step names read-only checks: VK-INT-nn for this track, VK-DG-nn for dynamic groups. A gate passes when its checks come back clean, or every finding has an owner and a date.

The slot numbering is Book 05’s device attribute schema: region in extensionAttribute1, department in extensionAttribute3, security tier in extensionAttribute11, device role in extensionAttribute12 and environment in extensionAttribute13 (Book 05, Chapter 08). These are device slots, separate from the user slots in the program attribute map.

The path on one page

The Intune track’s gates and the checks that prove them
Gate	What it establishes	Validate with	Book 05 detail
0. Prerequisites	Licences, cloud, least-privileged roles; every platform placed in the coverage matrix or a tier	VK-INT-06	Ch 05 licensing and roles; coverage
1. Device sources	Procurement as the authority; Autopilot group tags as a controlled vocabulary; one writer for device extension attributes	VK-INT-01, VK-INT-03, VK-DG-05 (baseline snapshot)	Ch 03; Ch 04
2. Targeting design	Dynamic device groups for attribute rules, filters for time-sensitive assignment, user groups for user settings, one owning policy per setting	VK-DG-03, VK-DG-04, VK-DG-06, VK-INT-04, VK-INT-05	Ch 08 policy architecture
3. The computer half of Group Policy	Settings analysed, the library built, report-only and pilot rings run, GPO links disabled population by population	VK-INT-04, VK-INT-05	Ch 07; Ch 08 phases
4. Dangers covered	Each dynamic device group danger has its mitigation in place	VK-INT-01 to VK-INT-05; VK-DG-03 to VK-DG-06	Companion guide table
5. Cut-over waves	Division by division, each wave watched and drift-clean before the next; rollback tested	VK-DG-05, VK-INT-01, VK-INT-05	Ch 08 Phase 5; rollback
6. Operating it	Stale devices cleaned up, drift caught at the source, evidence on a schedule	VK-INT-02, every check on a schedule	Ch 10

The Endpoint & Device Modernization project plan schedules the same work as a 48-week network with its own gates; use its dates and this guide’s checks together.

Gate 0: prerequisites

Step 0.1: licensing

Confirm entitlements against the agency’s own agreements; Book 05 carries the program’s licensing table (Chapter 05). Three facts shape this track:

Intune Plan 1 is the base service, usually obtained through a Microsoft 365 bundle, and a licence is required for every user or device that benefits from the service.¹ For a GCC tenant, confirm which Government bundle carries Plan 1 and Defender for Endpoint.
Device-only licences cover userless kiosks and dedicated devices enrolled through self-deploying Autopilot, Apple enrollment without user affinity, Android Enterprise dedicated or a device enrollment manager account, but such a device doesn’t support app protection or Conditional Access.² For them, CP-005 (Chapter 08) is a configuration and evidence control, not an access control.
Dynamic groups need an Entra ID P1 licence per unique user in a dynamic group, and none for devices in device-based groups.³

Step 0.2: the tenant’s cloud

The workbook assumes a Microsoft 365 GCC tenant at FedRAMP Moderate (Book 14, Chapter 03). GCC uses the commercial Intune instance, so the admin center is intune.microsoft.com and Graph is graph.microsoft.com; GCC High and DoD differ (Book 05, Chapter 10). Classic Windows Autopilot is available in GCC and is the program’s default because its registration carries the group tag (Chapter 04). Windows Update for Business reports don’t meet GCC requirements, so update evidence comes from Intune and Autopatch reports (Chapter 10).

Step 0.3: roles

Assign least-privileged roles before anyone builds anything, and record them in the responsibility matrix (Book 05, Chapter 06).

Work	Role	Why this one
Compliance policies, configuration profiles, enrollment profiles, corporate identifiers, assignment filters	Intune Policy and Profile Manager (Intune RBAC), scoped with scope tags	Microsoft’s built-in role for exactly this work; it includes filter and enrollment-program permissions⁴
Endpoint security policies and baselines	Intune Endpoint Security Manager	Security and compliance features, including Defender for Endpoint⁵
Assigning Intune roles	Intune Role Administrator	The only Intune role that can assign permissions to administrators⁶
Read-only checks (the validation kit)	Intune Read Only Operator for people; read-only Graph application permissions for the kit	Views without change⁷
Dynamic device group rules	Groups Administrator, PIM-eligible	Rule validation needs at least Groups Administrator⁸
Writing device extension attributes	The device provisioning service’s application identity, app-only (Gate 1)	Keeps the writer a service, not a person
Break-fix writes to device attributes	Intune Administrator, PIM-eligible only, with an approval	The least-privileged Entra role for delegated device updates⁹

Microsoft advises against Intune Administrator for day-to-day work because it grants read and write across Intune (Book 05, Chapter 05), so the program uses it only for break-fix, through PIM, and never as the endpoint team’s working role (design guidance).

Step 0.4: the coverage matrix and the tiers

Place every end-user platform in the fleet against the coverage matrix before any design work, because a platform’s row decides whether the rest of this guide applies to it.

Export the platform inventory from Intune, Entra ID, Defender for Endpoint device discovery and the CMDB, by OS, version and ownership.
Mark each population’s row as managed, limited (Windows 10, Linux desktop, ChromeOS) or not an Intune platform.
Put every device outside tier 1 in a tier of the four-tier strategy: the platform’s own tool feeding the CMDB (with Ansible where it’s the tool), discovered and monitored only, or segmented and retired with a risk acceptance.
Record Windows 10 as an exception with an upgrade date; Book 05 sets Windows 11 as the floor (Chapter 08). Record devices that can’t enroll as path D exceptions, isolated first (Chapter 04).

Validate Gate 0. Run VK-INT-06 (platform inventory by OS, version and ownership against the coverage matrix, out-of-support platforms flagged). The gate passes when every flagged population has a tier, an owner and, for tier 4 and Windows 10, a date. A device in no tier is a CM-8 finding (companion guide).

Rollback. Nothing to roll back; this gate only reads.

Gate 1: device sources and the single writer

The rule for this gate comes from Book 05: each fact has one authoritative origin, every derived value must be explainable from it, and a device with no source value carries an explicit unpositioned marker, never an empty attribute (Chapter 03, the rule). Business facts (ownership, purpose, location, organizational assignment) come from procurement and the asset record; technical state comes from Microsoft’s services (which system owns which fact). The primary user’s department is never a source, and a device rule can’t read it anyway.¹⁰

Step 1.1: fix the vocabulary

Publish the value list for each device slot, one spelling per value and an unpositioned value, used by provisioning, rules and reports alike (Chapter 08).
Publish the group-tag vocabulary: the organizational node code from the procurement record, never a free-text department name, so a reorganization changes a mapping table rather than thousands of registrations (Chapter 04).
Keep both lists under change control in the governance repository; a new value is a change, because a rule will match it.

Step 1.2: Autopilot registration and group tags

For new hardware, follow the Intune-first doctrine: the organizational assignment is set at the purchase order and carried by the vendor program (Chapter 04, the five-phase process).

Capture the procurement intake fields at purchase order time (procurement intake fields).
Have the OEM or reseller register the device with its group tag. Supplier registration needs a one-time Global Administrator consent per supplier; record it (registration and group tags).
Correct a tag only from the procurement record. Group tags can also be set through Microsoft Graph’s updateDeviceProperties action on the Autopilot device identity (v1.0), which takes groupTag and needs DeviceManagementServiceConfig.ReadWrite.All.¹¹ If the provisioning service corrects tags, it holds that permission too; nobody edits tags by hand in the portal (design guidance).
Block personal Windows enrollment so an unregistered device fails as an enrollment error instead of entering production ungoverned (enrollment restrictions).

The tag becomes the device’s [OrderID] physical ID, which dynamic rules can match; [ZTDid] marks every Autopilot device.¹² Where device preparation is used instead of classic Autopilot, there’s no registration and no tag, so the attribute comes from the serial-number mapping table after enrollment (which one, in a GCC tenant).

The existing fleet has no registration. Hybrid-joined devices enroll through Group Policy–triggered automatic enrollment (Chapter 05), and their attributes are derived once from existing structure and confirmed by an owner (the retrofit path); treat each derived value as provisional until reconciled with the CMDB.

Step 1.3: enrollment profiles

Enrollment profile names are a second carrier: a dynamic rule can read enrollmentProfileName, and so can an assignment filter.¹³ ¹⁴

Name profiles from the same vocabulary, with a fixed prefix per device role, such as the kiosk profile in Chapter 08’s filter examples.
Use each platform’s vendor program and carrier: Apple Business Manager assignment to the enrollment profile, Android zero-touch or Knox profiles, the mapping table for Linux (other platforms).
Never reuse a profile name for a different role. A reused name moves devices between policy sets (companion guide).

Step 1.4: the device provisioning service writes the extension attributes

Device extension attributes are set on the Entra device object through Microsoft Graph, PATCH /devices/{id} with an extensionAttributes body. Microsoft documents two ways to call it:¹⁵

Mode	Permission	Who	What it can update
Application (app-only)	`Device.ReadWrite.All` (least privileged; `Directory.ReadWrite.All` is the higher option)	The device provisioning service	Only `extensionAttributes`, which is all this track needs
Delegated	`Directory.AccessAsUser.All` (the only delegated permission)	A signed-in administrator with at least Intune Administrator	More properties on Windows devices; only `extensionAttributes` on non-Windows devices

The device resource describes the extension attributes as mastered in the cloud and settable when a device object is created or updated, and they support $filter with eq, not, startsWith and eq on null values.¹⁶ So they aren’t overwritten by directory synchronization, and a read-only check can find empty slots directly.

The program’s design (design guidance):

Exactly one writer. The device provisioning service, app-only, is the only principal that writes device slots. It holds Device.ReadWrite.All and nothing broader, signs in with a certificate or managed identity, never a secret, and is an owned workload identity on the non-person identity track.
Write from the source, at registration and on change. Values come from the asset record keyed on serial number; the service writes when enrollment completes and when the record changes, and logs the source record and change reference. Reconciliation corrects at the source (Chapter 10).
Use the house Graph pattern: per-cloud connection, paging, Retry-After on 429 and 503, batches of at most 20 (automation reference; Module 1).
Delegated writes are break-fix only, by an Intune Administrator activated through PIM with an approval, using Chapter 08’s delegated sample.

Illustrative, not tested against a production tenant

The sample below is illustrative. Review every name and value, and run it first against a test tenant.

# App-only, as the device provisioning service. GCC (Moderate) uses the default global environment.
# Device.ReadWrite.All application permission, consented by an administrator; certificate credential, no secret.
Connect-MgGraph -TenantId $tenantId -ClientId $provisioningAppId -CertificateThumbprint $thumbprint -NoWelcome

# $deviceObjectId is the Entra device object ID, not the deviceId. Values come from the asset record.
$body = @{
    extensionAttributes = @{
        extensionAttribute1  = $asset.Region          # e.g. EAST
        extensionAttribute3  = $asset.Department      # e.g. Finance
        extensionAttribute11 = $asset.Tier            # Tier0 | Tier1 | Tier2 | UNPOSITIONED
        extensionAttribute12 = $asset.Role            # PAW | Kiosk | SharedDevice | Dedicated | Standard
        extensionAttribute13 = $asset.Environment     # Production | Staging | Dev
    }
} | ConvertTo-Json -Depth 3

Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/devices/$deviceObjectId" -Body $body -ContentType 'application/json'

# Read back what was written, for the provenance record.
Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/v1.0/devices/$deviceObjectId`?`$select=id,deviceId,displayName,extensionAttributes"

Standard as a device-role value is an example; use the agency’s published list. The UNPOSITIONED tier value is the explicit marker for a device the source can’t place, and it lands in no tier group, so the tenant-wide compliance setting treats it as noncompliant (Chapter 10).

Step 1.5: close every other write path

A dynamic group is only as secure as the write permissions on the attributes its rule reads.¹⁷ So:

List every principal that can write device objects: holders of Device.ReadWrite.All or Directory.ReadWrite.All application permissions (the non-person track’s VK-NPI-05 lists them) and standing holders of Intune Administrator or higher.
Remove or record each one that isn’t the provisioning service; make Intune Administrator PIM-eligible and alert on activation.
Audit device updates in the Entra audit log; any actor other than the provisioning service is a finding.

Validate Gate 1. Run VK-INT-01 (managed devices missing provisioning-written tier, role or environment) and VK-INT-03 (Autopilot devices with no group tag, or one outside the vocabulary); both should be empty for the pilot population, or carry the unpositioned marker with an open finding. Take the first VK-DG-05 snapshot of device group membership, which every later wave compares with. Then review the writer list from Step 1.5 and sign it.

Rollback. Attribute writes are reversible by rewriting the previous value from the provenance record. Until Gate 2 assigns policy to groups that read these slots, a wrong value changes no device’s configuration.

Gate 2: the targeting design

Book 05 sets the architecture: include groups, exclude groups and assignment filters, with one owning policy per setting (Chapter 08, policy architecture; Chapter 07, assignment strategy). The steps below turn it into a design an engineer can build and a reviewer can check.

Step 2.1: dynamic device groups for extension-attribute rules

Use a dynamic device group wherever the rule has to read a device extension attribute (tier, role, environment, region, department), because filters can’t read them (assignment strategy).

Build from Chapter 08’s templates, one group per value.
Guard every rule with device.accountEnabled -eq true so disabled stale objects drop out:¹⁸ (device.accountEnabled -eq true) -and (device.extensionAttribute11 -eq "Tier0").
Make tier groups mutually exclusive: one tier value per device, and an unpositioned value that matches no tier group.
Use each tool’s vocabulary: Company, Personal or Unknown ownership in Entra rules, Corporate in Intune filters, and different trust-type strings in each (companion guide). Device rules are written in the rule text box; the rule builder handles only user rules.¹⁹
Keep rules in Git and deploy them from the repository, so the nightly comparison finds any rule that differs (Book 02, Chapter 10). Don’t use memberOf (limits).

Step 2.2: assignment filters for time-sensitive assignment

Dynamic device groups take processing time before a new device appears in them. For a policy that has to land as the device enrolls, Microsoft’s guidance is to assign to a user group, or to All devices for userless devices, with an assignment filter that selects the devices at check-in; to prefer a filter where the rule needs only properties a filter can see; and not to use dynamic device groups as exclusions.²⁰

Decide per policy whether it’s time-sensitive. Enrollment-time security settings (BitLocker, Defender, firewall, compliance) usually are; regional variants usually aren’t (design guidance).
Assign time-sensitive policies to the user group or All devices with an include filter on Intune properties such as ownership, join type, enrollment profile name, OS SKU or version (filter examples).²¹
Exclude with a filter in exclude mode or an assigned break-glass group, never a dynamic device group.
Mind the limits: 200 filters per tenant, 3,072 characters each, enrolled devices only, evaluated at enrollment and check-in; managed-app filters apply only to app protection and app configuration policies.²² Conditional Access and licensing still need Entra groups (Chapter 07).

Step 2.3: user groups for user settings

Microsoft’s guidance is that settings belonging to the user, such as email profiles and user certificates, go to user groups, and settings that must stay on the device go to device groups.²³ On this track:

User-scope settings go to user groups built on the HR track’s coded attributes, with that track’s guards on accountEnabled and userType (dynamic user groups). These are the user-configuration half of Group Policy, and they move with people.
Device-scope settings go to the dynamic device groups from Step 2.1, or to All devices with a filter from Step 2.2.
A device rule never stands in for a user attribute. Where a device setting depends on the department, the provisioning service writes the device’s own department from the asset record (Gate 1).

Step 2.4: one owning policy per setting

Between configuration policies of any kind (settings catalog, endpoint security, security baselines) there’s no precedence: a conflict is reported and the setting may not apply until it’s resolved (Chapter 08, policy types). The program’s rule is that each setting has exactly one owning policy, and the same rule applies across tools (Ansible guide).

Keep a setting register in the repository: setting, owning policy ID (CP-, SC-, ES-, AP-), groups and filters, the GPO setting it replaces and the evidence method. It’s Chapter 07’s decision record plus the assignment.
Reject a policy at review if any of its settings already has an owner, and keep compliance thresholds aligned with configured values (coexistence).
Tag every policy with the program’s scope tags so delegated administrators see only their own (scope tags).

Validate Gate 2.

VK-DG-03: test each new device rule against named devices before it’s saved. The portal’s validation takes up to 20 users or devices at a time and needs at least Groups Administrator.²⁴ The kit marks the Graph form of the test with its release stage if it isn’t generally available.
VK-DG-04: shadow-diff each dynamic group against the group or OU population it replaces; every add and remove explained.
VK-DG-06: no rule uses the memberOf preview, and no device group is left paused.
VK-INT-04: policy assignment coverage, separating policies on dynamic device groups from those on filters, and listing any exclusion that uses a dynamic device group (which should be none).
VK-INT-05: devices in more than one group that assigns the same setting; the target is zero, with tier groups mutually exclusive.
For the user groups in Step 2.3, the HR track’s VK-DG-01 (guards present) and VK-DG-02 (no display-name attributes) apply.

Rollback. Groups and filters with no assignments change nothing. If a group is wrong, fix the rule in Git and redeploy it; if processing must be stopped for a bulk change, pause it and record the pause so VK-DG-06 finds it afterwards.²⁵

Gate 3: the computer half of Group Policy

This gate is Book 05’s GPO sunset, run at the working level of Chapter 08’s seven phases inside the program rules of Chapter 07: inventory before anything moves, one authority per setting, evidence before a link is disabled, and disable before delete. It covers the computer-configuration settings that reached workstations through OU links; servers go to Chapter 09.

Step 3.1: analyse (Phase 1)

Export every GPO as XML with its links, filtering and settings (Chapter 07, Step 1), and decide each GPO-on-GPO conflict the OU precedence hid.
Import into Group Policy analytics to find each setting’s landing zone, never to decide whether it’s still needed (Phase 1).
Tag and dispose of every setting with the four tags and four questions (Chapter 07, Step 2; Appendix A). User-configuration settings go to the HR track’s user groups (Step 2.3); this gate carries the computer half.
Capture the effective-policy baseline per tier with gpresult on a sample.

Validate. Every in-scope GPO imported and every setting tagged with a disposition and an owner in the setting register (testing at each gate, Phase 1). VK-INT-07 (Graph beta, with -IncludeBeta) reads the Group Policy analytics reports. It shows every GPO in gpo-scope.csv imported, and lists every GPO targeted in AD that isn’t complete, with its unsupported extensions.

Step 3.2: build the policy library (Phases 2 and 3)

Where Configuration Manager manages the fleet, enable co-management for a pilot collection and decide MDMWinsOverGP per population (Phase 2; coexistence rules). Never configure the settings that sit outside the Policy CSP, such as Defender and Windows Hello for Business, in both channels.
Build the library unassigned: compliance policies CP-001 to CP-003 and CP-005 (CP-004 is a server baseline, not an Intune policy), configuration profiles, endpoint security ES-001 to ES-006 and app protection AP-001 and AP-002, with attack surface reduction in audit mode (Phase 3; compliance policies).
Create them as code from the repository with the Graph templates, noting which resources are beta only.
Peer review each policy: every setting traces to a decision record, and no setting appears in two policies.

Validate. Run VK-INT-05 against the planned assignments (from the setting register, before anything is assigned) and confirm a lab ring reports Succeeded for every setting (Phase 3 in testing at each gate).

Step 3.3: report-only and pilot rings (Phase 4)

The pilot cohort is about 5% of the fleet, representative across tiers, regions and departments, with the GPOs still linked (Phase 4). Intune has no tenant-wide report-only switch, so the program builds the report-only ring from three parts (design guidance):

Audit mode for attack surface reduction rules and controlled folder access, and a 7-day compliance grace period instead of 1 for the pilot groups.
Conditional Access in report-only for the compliant-device policies, owned by Book 04 (rollout). Report-only compliance policies can repeatedly prompt macOS, iOS and Android users to pick a device certificate, and Microsoft advises excluding those platforms,²⁶ so scope report-only to Windows and pilot Apple and Android in a small enforced ring.
The comparison: each device’s gpresult against Intune’s per-setting status, where a Conflict, an Error or a differing value is a finding; then application and user tests against the Phase 1 baseline.

Validate. No unexplained Conflict or Error; no application regressions; VK-INT-05 clean on the pilot groups; VK-INT-01 clean on the pilot devices, since a pilot device with a missing tier proves nothing about its tier’s policy.

Step 3.4: workload waves (Phase 5)

Move one workload at a time for each ring: compliance, then Endpoint Protection, then device configuration, then Windows Update (Phase 5). Endpoint Protection moves before device configuration on co-managed devices, because switching device configuration also moves Endpoint Protection and resource access. The program’s division waves are the rings (Gate 5), and each ring is watched for 72 hours before the next.

Step 3.5: disable GPO links population by population

For each population, once the owning Intune policy reports success on it, freeze the GPO, back it up with Backup-GPO, prove the replacement, disable that population’s link with Set-GPLink -LinkEnabled No (not the GPO), and watch before the next population. The procedure and script are Chapter 07, freezing and unlinking. Don’t block inheritance on migrated OUs; it stops domain-level policy that hybrid-joined devices still need (Phase 6).

Rollback for this step. Re-enable the link for the affected population (-LinkEnabled Yes), and, for co-managed devices, move the affected workload’s slider back. Two facts shape it: in Pilot Intune, unassigning a policy doesn’t remove its settings, so a rollback reassigns a policy carrying the old value; and moving a workload back to Configuration Manager can leave some state behind (rollback).

Step 3.6: residual cleanup and retirement (Phases 6 and 7)

Clear what unlinking leaves: Group Policy preference items stay on the device unless configured to remove themselves, so each one gets an Intune setting that takes over the value or a Remediation that clears it (Chapter 07).
Disable GPO objects and keep them 90 days; then back up, archive and delete (Phase 7). Deletion is the only destructive step and needs approval per GPO.
Close the exception register: every remaining link is a dated exception with an owner and a review date (the end state).

Validate Gate 3. No migrated device processes an in-scope GPO (a device-side check); every preference item cleared or owned; VK-INT-04 shows every library policy assigned as the setting register says; VK-INT-05 is clean fleet-wide for migrated populations; backups restore in a test domain before any deletion (testing at each gate, Phases 6 and 7).

Step 3.7: sign-in and network clients on managed devices

Two things reach the device through Intune but aren’t Group Policy settings, so they get their own step: single sign-on for apps, and the Global Secure Access client. Build both into the library unassigned with the rest of Gate 3, and pilot them in the same rings.

Single sign-on. On Windows, Entra joined and hybrid joined devices sign apps in through the Primary Refresh Token (Book 05, Chapter 02). Apps that use the Microsoft Authentication Library reach it through the Windows broker, Web Account Manager (WAM), which also carries passkey (FIDO2) sign-in; an embedded WebView2 or the system browser are Microsoft’s next choices, so ask application owners which their in-house apps use.²⁷ ²⁸ On Android, passkeys work in apps that use the Microsoft Authentication Library with the browser or a broker (Microsoft Authenticator or Company Portal); on iOS, with ASWebAuthenticationSession or the Authenticator broker.²⁹ For iOS and iPadOS, deploy the Microsoft Enterprise SSO plug-in, which is built into Microsoft Authenticator and extends single sign-on to apps that don’t use the library. It needs iOS 13 or later, MDM enrollment, Authenticator installed, and a configuration profile pushed to the device.³⁰ In Intune:³¹

Devices > Manage devices > Configuration > Create > New policy; platform iOS/iPadOS, profile type Templates > Device features.
Single sign-on app extension: SSO app extension type = Microsoft Entra ID; Enable shared device mode = Not configured unless the devices use Entra shared device mode.
Additional configuration, Microsoft’s recommended values:

AppPrefixAllowList              String   com.apple.
browser_sso_interaction_enabled Integer  1
disable_explicit_app_prompt     Integer  1

Assign the profile to the iOS device groups from Gate 2, with Microsoft Authenticator assigned as a required app to the same groups.

Exclude Apple’s associated-domain URLs (app-site-association.cdn-apple.com, app-site-association.networking.apple) from TLS inspection; the plug-in and passkey sign-in both fail intermittently when a proxy intercepts them.³² ³³ macOS is outside the program’s scope, so its Platform SSO isn’t part of this track.

Global Secure Access client. Where the tenant licenses Microsoft Entra Private Access or Internet Access, the client sends the traffic named by the forwarding profiles to the service and everything else directly to the network. Global Secure Access is available in GCC; it isn’t yet supported in GCC High or DoD.³⁴

Windows: the device must be Entra joined, hybrid joined or, in preview, registered (registered devices carry Private Access traffic only), on 64-bit Windows 10 LTSC 2021 or later or Windows 11; Azure Virtual Desktop multi-session isn’t supported, and Arm64 devices take a separate installer.³⁵ Deploy it as a Win32 app: package Microsoft’s install script with the installer (renamed GlobalSecureAccessClient.exe) using the Win32 Content Prep Tool, then add it in Intune with these values:³⁶
```
Install command:    powershell.exe -ExecutionPolicy Bypass -File <install-script>.ps1
Uninstall command:  "GlobalSecureAccessClient.exe" /uninstall /quiet /norestart
Install behavior:   System
Return codes:       0 Success · 3010 Soft reboot · 1618 Retry
Detection rule:     File · C:\Program Files\Global Secure Access Client\TrayApp
                    GlobalSecureAccessClient.exe · String (version) · >= <client version>
```
Secure DNS (DNS over HTTPS) must be off in browsers for traffic acquisition, which Microsoft sets with a settings catalog profile for Edge and Chrome. To stop users turning the client off, set RestrictNonPrivilegedUsers = 1 under HKLM\SOFTWARE\Microsoft\Global Secure Access Client with a Remediation, after a pilot shows nobody needs to disable it.³⁷ Remediations aren’t available in GCC High or DoD.³⁸
iOS and iPadOS: the client is part of Microsoft Defender for Endpoint. Deploy the Defender app as a required iOS store app, then an iOS VPN profile (custom VPN, server 127.0.0.1, identifier com.microsoft.scmx, on-demand rule Connect VPN for all domains) with the keys EnableGSA and SilentOnboard = True. The device needs iOS 16 or later and Authenticator or Company Portal; Defender for Endpoint on iOS doesn’t support userless or shared devices.³⁹
Android: also through Defender for Endpoint, configured by an Android Enterprise app configuration policy for the Defender app with the Global Secure Access key; Android 11 or later, Entra registered. Private DNS must be off, and Android (Go edition) and shared devices aren’t supported.⁴⁰ ⁴¹

On iOS and Android the client doesn’t coexist with Microsoft Tunnel, so a mobile population uses one or the other.⁴²

Validate. On a pilot Windows device, dsregcmd /status shows AzureAdPrt : YES for the signed-in user,⁴³ and the Global Secure Access client reports Connected; on a pilot iPhone, the SSO profile reports Succeeded in Intune and a non-library app on the allow list signs in without a prompt. (Design guidance: no validation kit check covers this step yet; record the pilot results with the Gate 3 evidence.)

Gate 4: dangers and mitigations

The companion guide lists the ways a dynamic device group goes wrong and how to avoid each (Dynamic device groups (Intune track)). Its table is the reference; this one says where each mitigation sits in this guide and which check proves it’s in place.

Where each dynamic device group danger is mitigated, and the check that proves it
Danger (companion table)	Mitigation, and where in this guide	Proved by
Who can write device extension attributes	One app-only writer; every other write path closed; Intune Administrator PIM-eligible (Steps 1.4 and 1.5)	VK-INT-01; the signed writer list; VK-NPI-05 for Graph grants
Autopilot group tag and enrollment profile rules	Controlled vocabularies; tags corrected only from procurement (Steps 1.1 to 1.3)	VK-INT-03
Device rules can’t read the owner’s attributes	Device’s own department written from the asset record; user settings to user groups (Step 2.3)	VK-DG-04 shadow diff
Stale and duplicate device objects	`accountEnabled` guard; stale-device cleanup (Step 6.1)	VK-INT-02
Evaluation delay	Filters for time-sensitive assignment; no dynamic device group exclusions (Step 2.2)	VK-INT-04
Blast radius	Validate and shadow each rule; rings; rule changes under change control (Gate 5)	VK-DG-03, VK-DG-04, VK-DG-05
Conflicts and overlap	One owning policy per setting; mutually exclusive tiers (Step 2.4)	VK-INT-05
Ownership values and enrollment edge cases	Each tool’s vocabulary; `Unknown` ownership and enrollment without registration as findings (Step 2.1)	VK-INT-03, VK-INT-06

A device that falls out of every tier group gets no compliance policy, and the tenant setting then marks it noncompliant, so Conditional Access blocks it (Chapter 08). That fails closed, as intended, but a rule edit that empties a tier group blocks the whole tier; VK-DG-05’s delta threshold is the alarm. Before a bulk write, such as a reorganization rewriting a division’s department slot, consider pausing the affected groups on Microsoft’s guidance,⁴⁴ and confirm with VK-DG-06 afterwards that none stayed paused.

Validate Gate 4. Every row above has its mitigation in place for the populations in the next wave, and its check is scheduled. The monitoring the companion guide describes (membership-delta alerts, rule change history, emergency-access exclusions) is on.

Gate 5: cut-over waves and rollback

Waves select devices by attribute value, so each wave’s scope is a query and its groups already exist (Book 00, Chapter 09). The program moves a pilot division first, then two or three divisions at a time, each drift-clean before the next (Stage 7). Book 05’s workload waves run inside those division waves: the division waves decide which devices move, and the workload waves decide which workload Intune takes over on them (Phase 5).

Step 5.1: the runbook for one wave

Entry criteria. Gates 0 to 4 passed for the wave’s divisions; VK-INT-01 and VK-INT-03 clean for its devices; a fresh VK-DG-05 snapshot from the day before; the wave’s rollback written, GPO backups taken and re-enable owners named; the help desk briefed.

Steps.

Add the wave’s divisions to the workload’s pilot collection (co-managed devices), or confirm the wave’s cloud-only devices are in the target groups.
Assign or widen the workload’s policies to the wave’s groups.
Watch for 72 hours: per-setting status, compliance, Tier 0 compliance polled hourly from Graph, and ticket volume (alerts).
Disable the matching GPO links for the wave’s OUs, population by population (Step 3.5), and watch again before the next workload or wave.

Validate (exit criteria). Success on the wave’s population for every policy in the workload; no rise in attributable tickets; VK-DG-05 shows only the planned membership changes; VK-INT-05 shows no new conflict candidates; VK-INT-01 still clean. When every division is in, set the workload’s slider to Intune (Phase 5).

Step 5.2: rollback

Rollback is defined before each wave starts (rollback):

Rollback per failure, by wave
What went wrong	Roll back by	Notes
A policy setting breaks an application or the user experience	Reassign a policy that sets the previous value to the affected groups; re-enable the GPO link for the population if it was disabled	In Pilot Intune, unassigning doesn’t remove settings
A workload misbehaves on co-managed devices	Move that workload’s slider back to Configuration Manager	Some state, such as Windows and Office versions, stays
A rule change or bulk write moved devices into the wrong groups	Restore the previous rule from Git, or rewrite the previous attribute values from the provenance record; pause processing first for a large change	VK-DG-05 against the pre-wave snapshot shows what to reverse
Compliant-device enforcement blocks a population	Book 04’s Conditional Access rollback: return the policy to report-only (rollback)	Fix the compliance signal, not the access policy
GPO already deleted	Restore from backup and re-link	Why Phase 7 waits 90 days

Test rollback once on the pilot division before the first production wave: re-enable one link, reassign one prior-value policy, move one slider back, and record the time each took (design guidance).

Gate 6: operating it

Once a population is cut over, the track runs as a loop: snapshot, compare, classify, alert, remediate, verify (Chapter 10, drift detection). The validation kit runs the read-only side of it on a schedule.

Step 6.1: stale-device cleanup

Stale objects still match dynamic rules and inflate the inventory, so clean them up on Microsoft’s guidance, in this order (Chapter 10, stale records):

Find candidates with VK-INT-02: no sign-in or check-in beyond the threshold, and hybrid-joined devices that also have a registered or joined record. Microsoft advises at least 21 days, because the activity timestamp isn’t updated on every sign-in;⁴⁵ the program uses 90 days for Windows in Intune.
Retire in Intune first, export BitLocker recovery keys (deleting the device deletes them), then disable the Entra object for a grace period before deleting it.⁴⁶
Clean hybrid-joined devices in Active Directory and let sync carry it, and don’t delete system-managed Autopilot devices from Entra ID.⁴⁷
Don’t count on Intune cleanup rules: they only hide records after 30 to 270 days and leave the Entra object.⁴⁸ Prevent the hybrid dual state at its source (companion guide).

A device leaving the fleet follows Book 05’s retirement sequence, with the Entra object deleted last (Chapter 10).

Step 6.2: drift

Run the checks on a schedule and route findings to the owner of the source, because a finding is closed at the origin, not in the copy (Chapter 03).

The track’s drift checks and where each finding is fixed (design guidance)
Cadence	Check	What a finding usually means	Fix at
Daily	VK-INT-01	An asset-record change the provisioning service didn’t write, or a device enrolled outside the path	Provisioning service or the asset record
Daily	VK-DG-05	A rule edit, a bulk write or a writer that shouldn’t exist	Git rule history; the writer list
Weekly	VK-INT-02	Reimaging duplicates, broken hybrid trust, devices in drawers	The stale-device procedure
Weekly	VK-INT-03	A tag outside the vocabulary or a supplier registering without one	Procurement intake; the supplier
Weekly	VK-INT-04, VK-INT-05	A policy assigned outside the register, or two policies owning a setting	The setting register and the library
Weekly	VK-DG-06	A group left paused, or a `memberOf` rule	Group owner
Monthly	VK-INT-06	A platform reaching end of support, or a new device class	The coverage matrix and tiers

The weekly reconciliation of Intune, Entra ID and Defender inventories is the core of the loop (device inventory reconciliation). Log Analytics exports can take up to 48 hours, so Tier 0 and per-setting status come from Graph (what Log Analytics receives). Book 05’s drift classes for net-new devices (Chapter 04) mostly surface through VK-INT-01 and VK-INT-03.

Step 6.3: evidence

The program’s evidence is the records the services keep, exported on a schedule and retained. The control wording and the full evidence table are in Chapter 10; the mapping is the program’s reading, and the agency’s authorizing official and assessors decide whether a control is satisfied (federal requirements).

Evidence for the track’s controls (the program’s mapping, from Book 05 Chapter 10 and Book 11 Appendix A)
Requirement	Evidence this track produces	Checks that feed it
CM-2 Baseline Configuration	The policy library exported as JSON from Graph, under version control with its review history; the setting register	VK-INT-04, VK-INT-05
CM-6 Configuration Settings	Per-setting status reports; the exception register with approvals, including every GPO link that remains; Intune audit logs of every policy change	VK-INT-05; `IntuneAuditLogs`
CM-7 Least Functionality	Attack surface reduction in block mode with its audit-to-block decisions, firewall rules, the Edge extension allow list	Policy status for ES-003, ES-005, SC-003, SC-010
CM-8 System Component Inventory	The weekly reconciliation with findings and their closure; the tier assignment for every device outside Intune; provisioning-written attributes on every managed device	VK-INT-01, VK-INT-02, VK-INT-06
CM-3 Configuration Change Control (supporting)	Rule and policy changes through the repository and change record; the provisioning service’s provenance records	VK-DG-05; Git history
OMB M-22-09, devices (§III.B): a reliable asset inventory through CDM, and EDR	The reconciled inventory, fed to CDM; Defender for Endpoint onboarding on every managed device	VK-INT-02, VK-INT-06; reconciliation
OMB M-22-09, identity (§III.A): at least one device-level signal in authorization	Device compliance read by Conditional Access; compliance records	Compliance export; Book 04’s sign-in reports

The M-22-09 rows follow Book 11, Appendix A, and CDM’s role follows Book 12, Chapter 01. IA-3 is evidenced by the same compliance records (federal requirements), and Book 05 maps the evidence to FedRAMP 20x indicators (Chapter 10).

Evidence checklist

Configuration: the policy library exported as JSON from Graph with its commits; the setting register; dynamic group rules in Git; the signed writer list (Gate 1)
Operational: the scheduled VK-INT-* and VK-DG-* results; per-setting status and compliance reports; IntuneAuditLogs; the weekly inventory reconciliation, each with its retention location
Test: the pilot ring’s gpresult comparison (Step 3.3), each wave’s exit criteria (Step 5.1) and the rollback test on the pilot division, with dates and testers
Exception: the exception register (every remaining GPO link, dated, with an owner and review date); device-only licensing and path D exceptions (Gate 0); Windows 10 devices as dated exceptions
Assessor-ready artifact: the monthly evidence package for CM-2, CM-6, CM-7, CM-8 and M-22-09, traceable to the four above (Book 05, Chapter 10)

Validate Gate 6. The checks run on their cadence with results retained; each evidence row has a named producer and a retention location; the first monthly evidence package has been assembled from them once, end to end.

Control states, change safety and assessment mapping

The workbook’s conventions for implementation procedures are in Book 00, Appendix D; this section applies them to the Intune track.

Control states.

State	This page	Evidence
Designed	Gate 0 to Gate 2: coverage matrix and tiers, vocabularies, one writer, the targeting design and the setting register	The signed writer list; the setting register with a decision record per setting
Configured	Step 3.2: the library built unassigned, as code; Step 3.3: the report-only ring	The JSON export with its commits; lab ring Succeeded
Enforced	Gate 5: policies assigned wave by wave, GPO links disabled, sliders at Intune; compliant-device Conditional Access enforced under Book 04	Assignments matching the register (VK-INT-04); link state; the exception register
Evidenced	Each gate’s Validate step; the rollback test on the pilot division	`VK-INT-` and `VK-DG-` results; `gpresult` comparisons; the rollback timings
Operated	Gate 6	The drift schedule and its owners (Step 6.2); stale-device procedure; the monthly evidence package

A finding this page addresses is ready for closure when every applicable state has evidence; the authorizing official or assessor decides.

How-template coverage. Where the guide carries each part of the How-section template:

How-section template, mapped to the Intune track
Subsection	Where
Prerequisites	Gate 0 (licences, cloud, roles, coverage)
Pilot	The pilot cohort of about 5% in Step 3.3; the pilot division in Gate 5
Report-only or audit phase	Step 3.3: audit mode, a 7-day grace period and Conditional Access report-only
Enforcement	Step 3.4 and Step 5.1
Rollback	Step 3.5 and Step 5.2
Exclusions	The exception register (Step 3.6); Apple and Android out of report-only compliance (Step 3.3); emergency access accounts excluded from the compliant-device policies, which Book 04 owns (emergency access)
Telemetry	Per-setting status, compliance, `IntuneAuditLogs` and the membership-delta alarm (Step 6.2; Gate 4)
Evidence	Step 6.3 and its evidence checklist
Day-two ownership	Gate 6: each drift finding routed to the owner of its source

Change safety

Ring	Scope	Exit criteria
0	Lab ring	Succeeded for every setting; VK-INT-05 clean on the planned assignments (Step 3.2)
1	Pilot cohort, about 5% of the fleet, GPOs still linked	No unexplained Conflict or Error; no application regressions (Step 3.3)
2	Pilot division	Wave exit criteria met; rollback tested once (Step 5.2)
3	Two or three divisions at a time, until every division is in	Each wave drift-clean and watched for 72 hours before the next (Step 5.1)

Emergency access: the compliant-device Conditional Access policies exclude the emergency access group, as Book 04 requires of every policy that blocks or restricts sign-in (Book 04, Chapter 04); VK-CA-01 checks it.
Change window: each wave is its own change, with the help desk briefed and re-enable owners named in the entry criteria (Step 5.1).
Backout triggers: set per wave before it starts: a policy breaking an application, a rise in attributable tickets, unplanned membership changes in VK-DG-05, or a population blocked by compliant-device enforcement (Step 5.2) (program decision, settled as WD-150).
Post-change validation: the wave’s exit criteria after each ring.

Assessment mapping

Microsoft Zero Trust pillar: Devices
CISA ZTMM pillar: Devices
Depends on: Identity (compliant-device Conditional Access in Book 04, Chapter 07; the device provisioning service as a non-person identity, Non-Person Identity guide); the asset record as the source of device facts (Book 05, Chapter 03); SecOps (Defender for Endpoint onboarding, Book 12)
Attack chain interrupted: Initial Access (unmanaged or noncompliant devices refused at sign-in); Execution and Defense Evasion (attack surface reduction and configuration baselines); Persistence (drift caught at the source)

Checklist

Intune track checklist
Gate	Check
0	Intune and Entra ID P1 entitlements confirmed for the tenant’s cloud · Device-only licensing decided for userless devices, knowing it excludes Conditional Access · Least-privileged Intune roles assigned; Intune Administrator PIM-eligible, break-fix only · Every platform in the coverage matrix or a tier (VK-INT-06) · Windows 10 and path D devices as dated exceptions
1	Value lists and group-tag vocabulary published under change control · Suppliers register with tags · Personal Windows enrollment blocked · Provisioning service is the only writer, app-only with `Device.ReadWrite.All` and a certificate · Other write paths removed or recorded · VK-INT-01 and VK-INT-03 clean on the pilot · First VK-DG-05 snapshot
2	Device rules on device attributes only, with the `accountEnabled` guard · Tiers mutually exclusive, unpositioned matches none · Filters for time-sensitive assignment; no dynamic device group exclusions · User settings to user groups · Setting register with one owner per setting · VK-DG-03, VK-DG-04, VK-DG-06, VK-INT-04, VK-INT-05 clean
3	Every GPO exported, analysed, tagged and disposed · User and computer halves split · Library built unassigned and peer reviewed · Report-only ring on Windows; Apple and Android excluded from report-only compliance policies · Pilot conflicts explained · Links disabled, not GPOs deleted · Preference items cleared or owned · iOS SSO profile and, where licensed, the Global Secure Access client piloted in the same rings
4	Every danger in the companion table mitigated and checked · Membership-delta alerts on · Bulk-change pause procedure written
5	Entry criteria met per wave · 72-hour watch per ring · Rollback written per wave and tested once on the pilot · Sliders at Intune when every division is in
6	Stale-device procedure on Microsoft’s guidance, keys exported before deletes · Drift checks scheduled and routed to source owners · Evidence for CM-2, CM-6, CM-7, CM-8 and M-22-09 produced and retained

Back to the books

Book 05 — Devices: Chapter 03 for where device data lives, Chapter 04 for Intune-first onboarding, Chapter 07 and Chapter 08 for the GPO sunset, Chapter 10 for operations and evidence.
Book 04 — Access & Privilege for the Conditional Access policies that consume device compliance.
The Attribute-Driven Migration companion guide for the map of all four tracks, and the Ansible guide for tier-2 configuration outside Intune.
The Endpoint & Device Modernization project plan for the schedule.

Version and revision history

Version 2.0, in edition 2026.11.5 (November 8, 2026). Every edition is kept on the Archive page; every change between editions is in the commit history.

Versions of this guide, newest first
Version	Edition	Date	Changes
2.0	2026.11.5	2026-11-08	Release 2.0, the baseline: checked against every other book; Draft becomes Baseline; Edition 2026.11.4: record the edition and point deck links at it (#362); Fix confirmed crosswalk errors in guides and explainers (#406); Book 05: inconsistency fixes (b05) (#429); Decisions pass: guides, reference and training (#455); Approve 116 gated pages (Nov 7); fix RMF map stale-review test (#457); Consistency read D: Books 15-19, guides, non-book pages (#483); Approve 15 gated pages (Nov 8, after the consistency read) (#490); and 1 more (all changes)
1.4	2026.11.4	2026-11-05	Deck and audio links point at edition 2026.11.4
1.3	2026.11.3	2026-11-05	Review gate: Mike’s approval of the 15 implementation guides gated on November 3 (#348)
1.2	2026.11.1	2026-11-01	Edition 2026.11: record the edition, and publish the four gate-level decks and videos (#282)
1.1	2026.11	2026-11-01	Move the decks and narration audio out of git, onto edition 2026.10 (#260); Retire Research: move each page to a home by type (guides, training, reference, evaluations, explainers) (#269)
1.0	2026.10	2026-10-31	First edition (3 merged changes since the guide began)

Footnotes

Microsoft Learn, “Microsoft Intune licensing” (Plans 1, 2 and the Suite; licence required for any user or device that benefits from the service; device-only licences and their limitations, no app protection policies or Conditional Access; unlicensed admin access for tenants created after July 2021), https://learn.microsoft.com/intune/fundamentals/licensing (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Microsoft Intune licensing” (Plans 1, 2 and the Suite; licence required for any user or device that benefits from the service; device-only licences and their limitations, no app protection policies or Conditional Access; unlicensed admin access for tenants created after July 2021), https://learn.microsoft.com/intune/fundamentals/licensing (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID,” sections “Rules for devices” and “Considerations for dynamic membership groups” (device rules reference only device attributes; attribute write permissions; Entra ID P1 per unique user, no licence for devices in device-based groups; rule builder for user rules only), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Role-based access control (RBAC) with Microsoft Intune,” “Built-in roles,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/overview, and “Built-in role permissions for Microsoft Intune,” “Policy and Profile manager,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/ref-built-in-roles (both accessed Oct 29, 2026).↩︎
Microsoft Learn, “Role-based access control (RBAC) with Microsoft Intune,” “Built-in roles,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/overview, and “Built-in role permissions for Microsoft Intune,” “Policy and Profile manager,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/ref-built-in-roles (both accessed Oct 29, 2026).↩︎
Microsoft Learn, “Role-based access control (RBAC) with Microsoft Intune,” “Built-in roles,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/overview, and “Built-in role permissions for Microsoft Intune,” “Policy and Profile manager,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/ref-built-in-roles (both accessed Oct 29, 2026).↩︎
Microsoft Learn, “Role-based access control (RBAC) with Microsoft Intune,” “Built-in roles,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/overview, and “Built-in role permissions for Microsoft Intune,” “Policy and Profile manager,” https://learn.microsoft.com/intune/fundamentals/role-based-access-control/ref-built-in-roles (both accessed Oct 29, 2026).↩︎
Microsoft Learn, “Validate rules for dynamic membership groups in Microsoft Entra ID” (at least Groups Administrator; up to 20 users or devices at a time), https://learn.microsoft.com/entra/identity/users/groups-dynamic-rule-validation (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Update device,” Microsoft Graph v1.0, “Permissions” (delegated Directory.AccessAsUser.All; application Device.ReadWrite.All, higher Directory.ReadWrite.All; app-only and non-Windows calls update only extensionAttributes; Intune Administrator the least-privileged delegated role) and Example 2, https://learn.microsoft.com/graph/api/device-update?view=graph-rest-1.0 (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID,” sections “Rules for devices” and “Considerations for dynamic membership groups” (device rules reference only device attributes; attribute write permissions; Entra ID P1 per unique user, no licence for devices in device-based groups; rule builder for user rules only), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).↩︎
Microsoft Learn, “updateDeviceProperties action,” Microsoft Graph v1.0 (Autopilot device identity; groupTag parameter; DeviceManagementServiceConfig.ReadWrite.All, delegated and application), https://learn.microsoft.com/graph/api/intune-enrollment-windowsautopilotdeviceidentity-updatedeviceproperties?view=graph-rest-1.0 (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Create device groups for Windows Autopilot” ([ZTDid] rule for all Autopilot devices; the group tag maps to the Entra device OrderID), https://learn.microsoft.com/autopilot/enrollment-autopilot (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID,” sections “Rules for devices” and “Considerations for dynamic membership groups” (device rules reference only device attributes; attribute write permissions; Entra ID P1 per unique user, no licence for devices in device-based groups; rule builder for user rules only), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).↩︎
Microsoft Learn, “App and device properties, operators, and rule editing when creating assignment filters in Microsoft Intune,” “Managed device properties,” https://learn.microsoft.com/intune/fundamentals/filters/ref-device-properties (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “Update device,” Microsoft Graph v1.0, “Permissions” (delegated Directory.AccessAsUser.All; application Device.ReadWrite.All, higher Directory.ReadWrite.All; app-only and non-Windows calls update only extensionAttributes; Intune Administrator the least-privileged delegated role) and Example 2, https://learn.microsoft.com/graph/api/device-update?view=graph-rest-1.0 (accessed Oct 29, 2026).↩︎
Microsoft Learn, “device resource type,” Microsoft Graph v1.0, property extensionAttributes (mastered in the cloud; set on creation or update; supports $filter with eq, not, startsWith and eq on null), https://learn.microsoft.com/graph/api/resources/device?view=graph-rest-1.0 (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID,” sections “Rules for devices” and “Considerations for dynamic membership groups” (device rules reference only device attributes; attribute write permissions; Entra ID P1 per unique user, no licence for devices in device-based groups; rule builder for user rules only), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID,” sections “Rules for devices” and “Considerations for dynamic membership groups” (device rules reference only device attributes; attribute write permissions; Entra ID P1 per unique user, no licence for devices in device-based groups; rule builder for user rules only), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID,” sections “Rules for devices” and “Considerations for dynamic membership groups” (device rules reference only device attributes; attribute write permissions; Entra ID P1 per unique user, no licence for devices in device-based groups; rule builder for user rules only), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group processing time; assignment filters on user groups or All devices for time-sensitive scenarios; dynamic device groups not recommended as exclusions), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “App and device properties, operators, and rule editing when creating assignment filters in Microsoft Intune,” “Managed device properties,” https://learn.microsoft.com/intune/fundamentals/filters/ref-device-properties (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “Use assignment filters to assign your apps, policies, and profiles in Microsoft Intune,” “How assignment filters work” and “Restrictions” (up to 200 filters per tenant; 3,072 characters each; managed devices must be enrolled; managed-app filters apply to app protection and app configuration policies only), https://learn.microsoft.com/intune/fundamentals/filters/overview (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group processing time; assignment filters on user groups or All devices for time-sensitive scenarios; dynamic device groups not recommended as exclusions), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “Validate rules for dynamic membership groups in Microsoft Entra ID” (at least Groups Administrator; up to 20 users or devices at a time), https://learn.microsoft.com/entra/identity/users/groups-dynamic-rule-validation (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Understand and manage dynamic group processing in Microsoft Entra ID” (pausing groups for large changes; wait at least 24 hours), https://learn.microsoft.com/entra/identity/users/manage-dynamic-group (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “Analyze Conditional Access policy impact,” “Overview” (report-only policies requiring a compliant device can prompt macOS, iOS and Android users to select a device certificate; exclude those platforms), https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-report-only (accessed Oct 29, 2026).↩︎
Microsoft Learn, “Support passwordless authentication with FIDO2 keys in apps you develop,” section “Platform-specific best practices,” https://learn.microsoft.com/entra/identity-platform/support-fido2-authentication (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Microsoft Entra ID Windows Account Manager (WAM) API reference,” https://learn.microsoft.com/entra/identity-platform/reference-entra-id-wam-api (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Support passwordless authentication with FIDO2 keys in apps you develop,” section “Platform-specific best practices,” https://learn.microsoft.com/entra/identity-platform/support-fido2-authentication (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Microsoft Enterprise SSO plug-in for Apple devices,” sections “Requirements,” “iOS requirements” and “Enable SSO for apps that don’t use MSAL,” https://learn.microsoft.com/entra/identity-platform/apple-sso-plugin (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Use the Microsoft Enterprise SSO plug-in on iOS/iPadOS devices,” section “Create a single sign-on app extension configuration policy,” https://learn.microsoft.com/intune/device-configuration/settings-catalog/configure-enterprise-sso-plugin-ios (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Microsoft Enterprise SSO plug-in for Apple devices,” sections “Requirements,” “iOS requirements” and “Enable SSO for apps that don’t use MSAL,” https://learn.microsoft.com/entra/identity-platform/apple-sso-plugin (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Support passwordless authentication with FIDO2 keys in apps you develop,” section “Platform-specific best practices,” https://learn.microsoft.com/entra/identity-platform/support-fido2-authentication (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Known limitations for Global Secure Access,” sections “Global Secure Access client limitations” and “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Install the Global Secure Access client for Windows,” sections “Prerequisites,” “Use Microsoft Intune to deploy the Global Secure Access client,” “Configure settings for Microsoft Entra Internet Access by using Intune” and “Client registry keys,” https://learn.microsoft.com/entra/global-secure-access/how-to-install-windows-client (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Install the Global Secure Access client for Windows,” sections “Prerequisites,” “Use Microsoft Intune to deploy the Global Secure Access client,” “Configure settings for Microsoft Entra Internet Access by using Intune” and “Client registry keys,” https://learn.microsoft.com/entra/global-secure-access/how-to-install-windows-client (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Install the Global Secure Access client for Windows,” sections “Prerequisites,” “Use Microsoft Intune to deploy the Global Secure Access client,” “Configure settings for Microsoft Entra Internet Access by using Intune” and “Client registry keys,” https://learn.microsoft.com/entra/global-secure-access/how-to-install-windows-client (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Microsoft Intune for US Government GCC High and DoD service description,” section “Intune features not available in GCC High and DoD” (Remediations), https://learn.microsoft.com/intune/fundamentals/government-service (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Install the Global Secure Access client for iOS,” sections “Prerequisites,” “Requirements” and “Installation steps,” https://learn.microsoft.com/entra/global-secure-access/how-to-install-ios-client (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Install the Global Secure Access client for Android,” sections “Prerequisites” and “Deploy Microsoft Defender for Endpoint on Android,” https://learn.microsoft.com/entra/global-secure-access/how-to-install-android-client (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Known limitations for Global Secure Access,” sections “Global Secure Access client limitations” and “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Known limitations for Global Secure Access,” sections “Global Secure Access client limitations” and “Global Secure Access In Government Cloud limitations,” https://learn.microsoft.com/entra/global-secure-access/reference-current-known-limitations (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Troubleshoot devices by using the dsregcmd command,” section “SSO state” (AzureAdPrt), https://learn.microsoft.com/entra/identity/devices/troubleshoot-device-dsregcmd (accessed Nov 9, 2026).↩︎
Microsoft Learn, “Understand and manage dynamic group processing in Microsoft Entra ID” (pausing groups for large changes; wait at least 24 hours), https://learn.microsoft.com/entra/identity/users/manage-dynamic-group (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “How To: Manage stale devices in Microsoft Entra ID” (activity timestamp and the 21-day caution; disable before delete; retire MDM-controlled devices first; hybrid-joined devices cleaned up in AD and synced; don’t delete system-managed Autopilot devices; BitLocker keys deleted with the device), https://learn.microsoft.com/entra/identity/devices/manage-stale-devices (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “How To: Manage stale devices in Microsoft Entra ID” (activity timestamp and the 21-day caution; disable before delete; retire MDM-controlled devices first; hybrid-joined devices cleaned up in AD and synced; don’t delete system-managed Autopilot devices; BitLocker keys deleted with the device), https://learn.microsoft.com/entra/identity/devices/manage-stale-devices (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “How To: Manage stale devices in Microsoft Entra ID” (activity timestamp and the 21-day caution; disable before delete; retire MDM-controlled devices first; hybrid-joined devices cleaned up in AD and synced; don’t delete system-managed Autopilot devices; BitLocker keys deleted with the device), https://learn.microsoft.com/entra/identity/devices/manage-stale-devices (accessed Oct 29, 2026, as verified in the companion guide).↩︎
Microsoft Learn, “Device cleanup rules” (hide devices that haven’t checked in for 30 to 270 days; hidden devices aren’t removed from Microsoft Entra ID), https://learn.microsoft.com/intune/governance/configure-cleanup-rules (accessed Oct 29, 2026, as verified in the companion guide).↩︎