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

Attribute-Driven Migration from Active Directory to Microsoft Entra ID

One end-to-end path for moving a forest to Entra ID on attributes instead of OU placement, in four tracks (people from HR, end-user devices through Intune, servers through Azure Arc, and non-person identities from their owners’ records), with the end state and how you know you’re there: source the attributes from HR and Federal HR 2.0, prove them, map them through sync, rebuild OU subtrees as dynamic groups, delegate with administrative units, retarget policy to Conditional Access and Intune, cut over in phases, and correct drift; plus what Microsoft documents for devices, Arc servers, applications and PIV certificate binding. A map of where each step is covered in the books.

In Active Directory an object’s place in the tree decided what applied to it; in Entra ID what the object says about itself decides, so the migration is really the work of making those statements true and keeping them true.

NoteIn this guide

What the migration accomplishes and how you know you’re there, and the four tracks it runs in, because one OU tree holds four populations with different sources of truth: people (the HR track), end-user devices (the Intune track), servers (the Azure Arc track), and service accounts, service principals, managed identities, workload identities and AI agents (the non-person identity track). Then one path for the migration, run on attributes rather than OU placement, in nine stages, each tagged with the tracks it applies to: read what the OU tree encodes, source the attributes (with Federal HR 2.0 as the coming authoritative source), prove them, map them through sync, rebuild OU subtrees as dynamic groups, delegate with administrative units, retarget Group Policy to Conditional Access and Intune, cut over in phases, and correct drift. For each stage: what it is, the decision and who owns it, the gate that says it’s done, how it fails, and links to the chapter sections that carry the detail. Then a worked example that follows one user through a mover event, an attribute-to-mechanism crosswalk, the Intune, Arc and non-person identity tracks with what Microsoft documents for each, PIV and CAC certificate binding as an attribute, the limits, the dangers of dynamic groups and how to avoid them, the federal requirements each track supports, and a checklist. This guide is a map. The books hold the depth, and it links to them rather than repeating them.

TipDownload and present

attribute-driven-migration-guide.docx: this guide as a Word document, regenerated on every site deploy.

Technical deep dive, in two parts (about 18 minutes narrated each): Part 1 covers the model and the HR track (the four tracks, the end state, the federal requirements, the attributes primer, sourcing and proving the attributes, dynamic user groups, administrative units and Conditional Access); Part 2 covers devices, servers and non-person identities, PIV and CAC binding, and running the migration. Both are on the Presentations page.

Deeper Dive Implementation, in three parts (about 15 to 17 minutes narrated each): the three-part Deeper Dive Implementation series (about 15 to 17 minutes narrated each) walks the ten gates at working level: Part 1, Gates 0–3, Part 2, Gates 4–6 and Part 3, Gates 7–9.

Step by step, the shared foundation: Attribute-Driven Migration: An Implementation Guide runs the stages the four tracks share as ten gates, in the decks’ order, each with the validation kit check that proves it, and the Attribute-Driven Migration project plan schedules them against the track plans and the program’s gates.

How to read this guide

The material for this migration is spread over several books. Book 01, Chapter 04 states the model. Book 02 moves the directory. Book 03 makes HR the source of the attributes. Book 06, Chapters 16 and 17 apply the same model to SQL Server, and Book 04, Chapter 03 and Book 05, Chapter 08 take policy targeting from Group Policy to Conditional Access and Intune. Each book numbers its own phases; this guide names stages instead, and the phase alignment table lines them up.

Facts in this guide come from the chapters it links to, and a few that the chapters don’t carry were checked against Microsoft Learn on October 29, 2026 and are footnoted. Statements marked (design guidance) are the program’s recommendations, as in the books. Attribute slots follow the program attribute map, and codes such as FIN-LED are placeholders for the agency’s own code lists.

What this migration accomplishes

The goal. Every person, device, server and workload is governed by attributes that are true, owned by exactly one source, and read by policy. That means:

• Joining, moving and leaving change access automatically and correctly, with no ticket and no hand-edited group. A new device or workload gets its access the same way, from its owning record.
• Delegation and policy follow facts about the object, not its position in a folder tree.
• Every non-person identity has a named owner, the least privilege it needs, and a credential that expires or is managed, so none is left orphaned.
• Every access decision and change leaves evidence.
• Active Directory can be reduced and eventually retired without losing any of the four jobs the OU tree did: delegation, policy scope, accountability and security scope (Book 01, Chapter 04).

How you know you’re there. The criteria below are (design guidance). Where a book states its own gate, that gate governs, and the last column links it.

The end state, track by track (design guidance)

Track	You’re there when	The books’ own gates	Federal requirement (mapping)
HR track: people	Every enabled account correlates to an authoritative record (HR or the contractor source) or carries an owned exception. Every OU-derived access group is a validated rule over coded attributes, so no hand-maintained membership remains for it	Book 03 Phase 1 and Phase 5; sole-source proof; Book 01 verification	AC-2, AC-2(1), AC-2(3), PS-4, PS-5, IA-4
Intune track: end-user devices	Every managed device carries attributes written by provisioning, its policy is targeted by them, and computer-side GPO links are disabled population by population, with rollback tested	Book 05 testing at each gate and rollback	CM-2, CM-6, CM-8, IA-3
Azure Arc track: servers	Every in-scope server is Arc-enabled with its tag taxonomy applied, and its baseline is assigned and evaluated by Azure Policy	Book 05 day-one baseline	CM-2, CM-6, CM-8
Non-person identity track	Every service account and service principal has an owner and sponsor, a reason and a target. Each one is retired, re-platformed to a managed identity or gMSA, or made a certificate or federated-credential workload identity. None holds a password that never expires, and none is orphaned	Book 02 Phase 4; Book 17 lifecycle	AC-2, AC-6(5), IA-4, IA-5, IA-9
Across all tracks	The scheduled drift comparison is clean, and findings are fixed at the source, not in the copy	Stage 8	AU-2, AU-6, AU-12, SI-4, CA-7

Four tracks, each with its own source of truth

One Active Directory OU tree holds four different populations of identity: the people who work for the agency, their workstations and mobile devices, the member servers, and the service accounts that workloads run as. They move to Microsoft Entra ID (and Azure) by different paths and take their attributes from different sources, so this guide treats them as four tracks. Mixing them is the commonest source of confusion in this material: an HR attribute and a Group Policy computer setting can sit side by side in the same OU, but they belong to different tracks and change for different reasons.

The four tracks

Track	What it covers	Source of truth for its attributes	Where the attributes are written	What reads them in the target
HR track: people	User accounts for employees and contractors	HR (Core HCM, Federal HR 2.0 for employees) and the contractor source of authority, through provisioning	The user object: in AD while users are synced (AD-mastered), in Entra ID once cloud-mastered	Dynamic user groups, administrative units, Conditional Access personas, Lifecycle Workflows (joiner, mover, leaver), license and access-package assignment
Intune track: end-user devices	Workstations, laptops and mobile devices	Device provisioning: Autopilot registration and group tag, Intune enrollment, and Graph writes by the device provisioning service	The Entra device object: extension attributes 1–15, enrollment profile, physical IDs	Dynamic device groups, Intune assignment filters, Conditional Access device filters, compliance
Azure Arc track: servers	Member servers on premises and in other clouds, brought under Azure Resource Manager	Arc onboarding (azcmagent connect --tags and the resource group), then the CMDB reconciliation, with Azure Policy filling derivable values	Azure resource tags and the resource group or subscription	Azure Policy and machine configuration, Update Manager scoping, Defender for Servers, Azure RBAC
Non-person identity track: workloads and services	AD service accounts, MSAs and gMSAs, application registrations and service principals, managed identities, workload identities, and AI agents	The application or workload’s owner/sponsor record: the system inventory or CMDB entry, the application registration and the AI inventory. These are not HR records	Service principal and application properties, custom security attributes, owners and sponsors, and credentials (certificates, federated credentials)	Conditional Access for workload identities, app role assignment, Azure RBAC (with ABAC conditions where supported), access reviews of owners, and credential-expiry and orphan checks

What this means for Group Policy. Group Policy splits the same way:

• User-configuration settings move with people, to user-targeted Intune policy and Conditional Access (Stage 6).
• Computer-configuration settings move with devices (Intune device policy and filters, Book 05, Chapter 08) and with servers (Azure Policy and machine configuration, Book 05, Chapter 09).

What each attribute can reach.

• HR never describes a device, a server or a service.
• A device rule can never read its owner’s attributes.¹
• A non-person identity has no HR record. Its owner and sponsor are its accountability, and its lifecycle is driven by the owning system’s record and by credential expiry, not by a hire or leave date.

How this guide is organized by track. The nine stages are written mostly for the HR track, because that’s where the attribute model starts. Each stage opens with a Tracks line that says which tracks it applies to and what differs for the others. Beyond users is the home of the Intune, Arc and non-person identity tracks.

Where each track is covered in the books:

• HR: Book 03.
• Intune: Book 05, Chapters 03, 04 and 08.
• Arc: Book 05, Chapter 09.
• What each track’s tools cover, including non-Microsoft platforms, AWS, Google Cloud and VMware, and the strategy for what they don’t: Intune coverage and Arc coverage.
• Non-person: service accounts in Book 02, Chapter 09 (“Service accounts” and Modernizing service accounts); SQL Server service accounts and application principals in Book 06; AI agents in Book 17; service principal attributes in this guide’s non-person identity track.

Step by step, the HR track: the stages below, built through Building Book 03’s HR Pipeline (research, under review), run as a lifecycle through HR-Driven Identity: An Implementation Guide (draft), and scheduled in the Identity Lifecycle & Provisioning plan. What the four tracks share (the schema and slots, the proof, sync, the group library and units, the personas, PIV binding, the mover proof, the cut-over and drift) runs as ten gates in Attribute-Driven Migration: An Implementation Guide, scheduled in the Attribute-Driven Migration plan.

Attributes: what you know from AD, and what Entra ID gives you

In Active Directory, where an object sits does half the work; in Entra ID, what the object says about itself has to do all of it. This section is the reference the later stages point back to: the attribute stores Entra ID offers, in the order to reach for them, which mechanisms read each one, and how the AD attributes an administrator already knows map across. The slot numbers (10 for the organization code, 11 for worker type, 12 for position category, 6 for division, 4 for region) are the program’s, from the program attribute map, not Microsoft’s.

The attribute stores, in the order to reach for them

1. Native properties. department, jobTitle, companyName, officeLocation, employeeId (at most 16 characters), employeeType, employeeHireDate, employeeOrgData (division and cost center), manager, usageLocation (required for users who are assigned licenses), userType (Member or Guest) and accountEnabled.² HR provisioning, sync from AD or an administrator writes them. Dynamic rules read many of them, but not employeeType, employeeOrgData or manager.³ Use a native property first.
2. extensionAttribute1–15. Fifteen predefined string slots on users (onPremisesExtensionAttributes) and on devices (extensionAttributes), which began as AD and Exchange custom attributes; each holds up to 1,024 characters.⁴⁵ On a synced user they’re mastered in AD and read-only in Entra ID; on a cloud-only user they’re writable; on a cloud-only user who was once synced, they’re read-only in Microsoft Graph and managed through Exchange.⁶ Test that last case before a population’s source of authority moves to the cloud (design guidance). Device slots are written through Graph (Intune track).⁷ Dynamic user and device rules read them.⁸ Conditional Access device filters read a device’s own slots, but only when the device is Intune-managed, compliant or hybrid joined.⁹ Lifecycle Workflows can scope on them (Book 02, Chapter 10). The catch: anyone who can read the object can read its extension data, so these slots aren’t for sensitive values.¹⁰
3. Directory extensions (extension_<appId-without-hyphens>_<name>). Registered on an application and targeted at users, groups, devices and other directory objects; synced from custom AD schema attributes by Entra Connect, or created through Graph; up to 100 values per object.¹¹¹² Cloud Sync supports them only through its own CloudSyncCustomExtensionsApp application or the one Entra Connect created.¹³ Dynamic rules read single-valued ones;¹⁴ Microsoft doesn’t document Conditional Access reading them. Use them when 15 slots aren’t enough, or for custom AD schema attributes.
4. Custom security attributes. Typed values in attribute sets, on users and service principals. Attribute Definition Administrator defines them and Attribute Assignment Administrator assigns them; Global Administrator can’t read, define or assign them by default. A tenant holds up to 500 active definitions and an object up to 50 values.¹⁵ HR provisioning, including API-driven provisioning, can set them, and Lifecycle Workflows can scope on them.¹⁶ Conditional Access application filters read them on service principals (string type only),¹⁷ and Azure ABAC conditions read them on principals.¹⁸ Dynamic membership rules can’t read them.¹⁹ Use them for sensitive values no rule reads, and for tagging service principals.
5. Schema extensions and open extensions. Application data in Microsoft Graph. They can’t be used in dynamic membership rules and don’t sync from AD,²⁰ so no targeting in this guide relies on them.
6. Device properties. On the Entra device object: deviceOSType, deviceOwnership (Personal, Company or Unknown), deviceTrustType (AzureAD, ServerAD or Workplace), enrollmentProfileName, accountEnabled and devicePhysicalIds ([ZTDId], and the Autopilot group tag as [OrderID]). Dynamic device rules read these, and a device rule can’t read its owner’s attributes.²¹²² In Intune’s inventory: model, manufacturer, OS SKU and version, category and ownership (which Intune calls Corporate, not Company). Assignment filters read these at check-in, and not extension attributes.²³
7. Azure resource tags (Arc track). Set at onboarding with azcmagent connect --tags, through the portal, CLI or ARM templates, or by Azure Policy inheritance.²⁴²⁵²⁶ Azure Policy, Resource Graph and Update Manager’s dynamic scoping read them (Book 05, Chapter 09). Tags aren’t a role-assignment scope: Azure RBAC attaches to the management group, subscription, resource group or resource.²⁷ Tags are plain text, so they’re no security boundary.
8. Credential binding: certificateUserIds (in authorizationInfo). Up to 10 values of up to 1,024 characters, each unique in the tenant. For synced users only Entra Connect writes it, from an AD value such as altSecurityIdentities through sync rules the administrator adds, because altSecurityIdentities isn’t in the default attribute set. For cloud-only users a Privileged Authentication Administrator writes it, or Graph does. Certificate-based authentication matches against it.²⁸ The PIV section carries the detail.

Which store each consumer reads

Store	Objects	Dynamic membership rules	Conditional Access	Other readers
Native properties	Users, devices	Yes, except employeeType, employeeOrgData and manager	Through groups	Lifecycle Workflows triggers and scope; licensing (usageLocation)
extensionAttribute1–15	Users (read-only in Entra ID for synced users); devices (Graph)	Yes, for users and devices	Device filters read the device’s slots, if it’s managed, compliant or hybrid joined (B04 Ch03)	Lifecycle Workflows scope (B02 Ch10)
Directory extensions (extension_<appId>_<name>)	Users, groups, devices and other directory objects; synced from AD or created through Graph	Yes, single-value only	Not documented	Token claims
Custom security attributes	Users; service principals	No29	Application filters (service principals, string type)	Azure ABAC principal attributes; Lifecycle Workflows scope; provisioning from HR sources, including API-driven provisioning30
Schema and open extensions	Many Graph resources	No	No	Application data only
Intune inventory	Managed devices	No	No	Assignment filters
Azure resource tags	Arc servers and other Azure resources	No	No	Azure Policy; Resource Graph; Update Manager dynamic scoping (B05 Ch09)
certificateUserIds	Users	No	Authentication strength, through CBA	Certificate-based authentication username binding

Custom security attributes suit sensitive values that no rule reads, because reading them is restricted to the attribute roles, while anyone who can read an object can read its extension data.³¹ Access codes stay in extensionAttribute10 to 12, as Book 03, Chapter 06 decides.

Compared with Active Directory

How the two directories differ

Topic	Active Directory	Entra ID
Structure	A hierarchy: distinguished names and OUs	Flat
Schema	An extensible LDAP schema; additions are forest-wide and can’t be removed, only made defunct32	Fixed properties plus the extension mechanisms above
Access	LDAP or AD PowerShell	Microsoft Graph; some filters, such as those on extension attributes, need advanced queries33
Write control	Per-attribute ACLs and OU delegation	Roles, scoped by administrative units; custom security attributes have their own roles
Groups from attributes	None natively; scripts	Dynamic rules, over the attributes they can read
Identity anchor	objectGUID and objectSid	The Entra object ID, plus onPremisesImmutableId, the source anchor: Entra Connect uses ms-DS-ConsistencyGuid (from version 1.1.524.0), and Cloud Sync uses ms-DS-ConsistencyGuid with a fallback to objectGUID, which can’t be changed3435
Mastering	AD	For synced users, AD still masters most attributes, read-only in Entra ID, until the source of authority moves

AD attributes and their Entra ID counterparts

AD attribute	Entra ID property	Notes
userPrincipalName	userPrincipalName	The sign-in name; its suffix must be a verified domain (B02 Ch09)
sAMAccountName	onPremisesSamAccountName	Read-only36
distinguishedName	onPremisesDistinguishedName	Read-only.37 Never use it for policy (design guidance): it’s the OU path the migration exists to stop depending on
objectGUID / ms-DS-ConsistencyGuid	onPremisesImmutableId	The source anchor38
objectSid	onPremisesSecurityIdentifier	Read-only39
department / title / company	department / jobTitle / companyName	Rules read codes in the extension slots, not these display strings (B03 Ch06)
physicalDeliveryOfficeName / l / st / co	officeLocation / city / state / country	Entra Connect also syncs the two-letter c; usageLocation is a separate property for licensing40
manager (a DN)	manager (a reference)	Rules can’t read it, except in the direct-reports rule41
employeeID / employeeType	employeeId / employeeType	employeeId carries the enterprise person key; rules can’t read employeeType, so slot 11 mirrors it
extensionAttribute1–15	onPremisesExtensionAttributes	AD-mastered for synced users; rules can read them
Custom schema attributes	Directory extensions	Up to 100 values per object42
memberOf / member	memberOf / members	No nesting in rules; the memberOf rule preview ended November 3, 202643
userAccountControl disabled bit	accountEnabled	Every access rule requires it to be true (B03 Ch10)
pwdLastSet / lastLogonTimestamp	lastPasswordChangeDateTime / signInActivity	Nearest equivalents, not synced copies. Entra Connect syncs pwdLastSet as a mechanical property used to invalidate tokens;44 signInActivity is Entra ID’s own record, read-only, and needs P1 or P2 and AuditLog.Read.All45
altSecurityIdentities	certificateUserIds	Only through sync rules the administrator adds46
servicePrincipalName (Kerberos SPNs)	No equivalent	Entra service principals are application objects; Kerberos SPNs stay in AD until their workloads move. This belongs to the non-person identity track
adminCount	None	Privilege comes from roles and PIM (B02 Ch09)
Computer object	Device object	Its own properties and extension slots; a device rule can’t read its owner47
Entra ID only	Custom security attributes, userType, employeeHireDate, employeeLeaveDateTime, signInActivity	employeeHireDate and employeeLeaveDateTime reach synced users through the sync rule on extensionAttribute2 and 3 (B03 Ch06)

What follows from the comparison.

1. Placement has to become coded data before cutover.
2. While users are synced, edit attributes in AD or HR, never in Entra ID.
3. Not every familiar attribute can be read by a rule, which is why the coded mirrors exist.
4. Write access to an attribute is the new security boundary (dynamic group dangers).
5. Some AD concepts, such as Kerberos SPNs and adminCount, carry over as a different mechanism, not as an attribute.

The path on one page

The nine stages of an attribute-driven migration

#	Stage	Tracks	What it is	Decision, and who decides	Gate: done when	Detail
0	Read what the tree encodes	All four	Read-only inventory of the OU tree, its GPO links and its hand-made delegations, and of the service accounts it holds	Which OU functions survive as attributes, groups, units or policy. Identity engineering	Inventory in Git; a decision for every group; OU-to-unit mapping drafted; service accounts classified by risk	B02 Ch08, B02 Ch10 Phase 0
1	Source the attributes	HR; names the device, server and non-person sources	HR as the authority, Federal HR 2.0 as the coming source, contractor sources, one canonical schema, one writer per attribute	The authority map, the person key and the contractor source: the ICAM governance body. Code lists: HR. Schema: the data architect	Identifier decision, authority map and schema signed	B03 Ch04, Ch06, Ch07
2	Prove they’re true	HR; non-person owners	Correlate accounts to worker records, fix data at the source, remove other writers	Correlation threshold: the agency, through risk governance. Write permissions: the CISO (Book 03’s matrix calls the same decider “Security”)	Approved correlation threshold met on the pilot; every enabled account correlated or excepted	B03 Ch12 Phase 1
3	Map them through sync	HR	Land HR data in AD or Entra ID, carry it to the cloud, choose the sync engine	Sync engine and sign-in method: identity engineering. Provisioning rules: identity engineering	Object counts match; no sync errors; shadow-mode differences explained	B03 Ch05, B02 Ch09
4	Rebuild subtrees as dynamic groups	HR, Intune	Each OU-derived group becomes a rule over coded attributes	Access rules for an application: its owner	Each rule validated, shadowed against the group it replaces, and piloted	B01 Ch04, B03 Ch10
5	Delegate with administrative units	HR, Intune	OU access-control lists become units, scoped roles and PIM-eligible groups	Delegation model: identity engineering. Restriction, per unit: default no	Unit rules mirror group rules; no rule paused; role assignments match the matrix	B02 Ch05
6	Retarget policy	All four	GPO inheritance becomes Conditional Access personas and Intune assignments for people and devices, Azure Policy for servers, and workload-identity policy for service principals	Control requirements: the CISO	Report-only results reviewed; policies enforced in waves; GPO links disabled per population	B04 Ch03, B05 Ch08
7	Cut over in phases	All four	Division by division, population by population, with HR’s cutover and the directory’s on one schedule	Wave go/no-go: identity engineering	Seven days of sole-source proof; ticket path closed for the population; rollback tested	B03 App C, B03 Ch12 Phase 5
8	Detect and correct drift	All four	Compare HR, the registry and the tenant on a schedule; fix at the source	Drift findings: the CISO	Zero-action plan; high-severity findings closed or on a dated plan	B03 Ch11, B02 Ch05

The deciders come from the two responsibility matrices: Book 02, Chapter 06 for the directory and Book 03, Chapter 07 for the data. Both are the program’s recommended model, with one decider per row.

Stage 0: read what the OU tree encodes

Tracks: all four. The same tree holds user accounts, computer objects for workstations and servers, and service accounts, so the inventory reads all of them: the user OUs and their delegations for the HR track, the computer OUs and their GPO links for the Intune and Arc tracks, and the service-account inventory, classified by type and risk, for the non-person identity track (Book 02, Chapter 09). Record which track each OU and each GPO belongs to; a GPO’s user-configuration and computer-configuration halves can belong to different tracks.

What it is. The OU tree did four jobs at once: delegation, policy scope, accountability and security scope (Book 01, Chapter 04). The assessment captures what each OU actually encodes so the target reproduces intent, not structure: placement and size, GPO links and inheritance, and the non-inherited access-control entries that someone delegated by hand (Book 02, Chapter 08). Record what read-only discovery couldn’t see (Chapter 07).

Decision. For every OU function, where it goes: GPO scoping to Conditional Access and Intune, delegation to administrative units, logical organization to attributes and dynamic groups (Book 02, Chapter 09). For every security group: keep synced, convert to cloud-only, convert to dynamic, or retire (the per-group decision).

Gate. Book 02’s Phase 0: a complete inventory in Git, a UPN remediation plan, a recorded decision for every group, the OU structure mapped to proposed units, and the service-account risk classification complete (Book 02, Chapter 10).

Failure modes. A site-linked GPO looks unlinked to an OU-only search (Book 02, Chapter 08). adminCount overstates current privilege, because it stays set after an account leaves a protected group (Chapter 09).

Stage 1: source the attributes

Tracks: mostly HR. This stage is about people. The other three tracks source their attributes elsewhere, never from HR, and their authorities are decided here too:

• Intune: device provisioning, from the procurement or asset record through the Autopilot registration and group tag, Intune enrollment and Graph writes by the device provisioning service. The primary user’s department isn’t a source (Book 05, Chapter 03; Chapter 04).
• Arc: the tags applied at onboarding and the resource group, carrying the same procurement or asset record, then the CMDB reconciliation, with Azure Policy filling derivable values (Book 05, Chapter 09).
• Non-person: the owning application or workload’s record: the system inventory or CMDB entry, the application registration and, for AI, the AI use-case inventory (Book 17, Chapter 03). Book 03 keeps these identities out of the human-worker pattern on purpose (Chapter 01).

What it is. One governed set of HR-sourced attributes drives five outcomes: dynamic group membership, administrative-unit scope, Conditional Access targeting, license assignment and drift visibility (Book 01, Chapter 04). This stage decides where each attribute comes from, what it’s called, what it holds and who may write it.

Decisions and owners.

• Which system owns each fact. HR is authoritative for who a worker is and where they sit; the identity platform for how identity is proven and whether a request is permitted now (Book 03, Chapter 04). Every attribute is authoritative in one system and derived everywhere else, and corrections flow upstream (authoritative versus derived).
• The enterprise person key. A key the agency controls, carried in employeeId (at most 16 characters), with the source person number mapped to it, so a change of HR source changes only the source key (Book 03, Chapter 04). The governance body decides it.
• The canonical schema. Native Entra attributes first; three coded extension attributes for access (organization code, worker type code and position category in extensionAttribute10 to 12); codes, never display strings, in anything a rule reads (Book 03, Chapter 06; the stores are compared in Attributes). The data architect owns the schema and HR owns the code lists (Chapter 07).
• Writers. The provisioning service is the only writer of every schema field; help-desk, self-service and Exchange-admin write paths to the access slots are removed, and any other write is drift (Book 03, Chapter 06). Security decides write permissions on HR-mastered attributes.

Gate. Book 03’s Phase 1 gate: the identifier decision, authority map and schema signed (Chapter 12).

Failure modes. A key owned by the source breaks at the Core HCM cutover; an owner without the means leaves duty station stale; the help desk becomes a shadow source (Book 03, Chapter 07).

Building the attributes from Federal HR 2.0

Federal HR 2.0 is what will supply most of these attributes for federal employees, so it belongs in this stage, not after it.

The coming source. The joint OMB/OPM memorandum of December 10, 2025 consolidates the government’s Core HCM systems onto one government-wide platform, and OPM awarded the Core HCM contract to Oracle (Oracle Fusion Cloud HCM) on June 10, 2026. Wave 1 is the agencies that volunteered; Wave 2 is everyone else, transitioning in FY 2027; the government-wide adoption goal is FY 2028; and the memo expects the platform eventually to make eOPF and EHRI redundant. The memo’s sample onboarding runs about eight months, with interconnections live around month 5, which the chapter treats as a planning assumption to confirm with the HR 2.0 program office (Book 03, Chapter 03).

What OPM does and doesn’t require. No OPM document mandates or specifies how the platform integrates with the agency’s own directory. The solicitation’s identity requirements point into the platform: its users sign in through OPM’s identity provider and are provisioned into it by SCIM 2.0. The reverse direction appears only as a sample interconnection, an “Identity Management Solution” fed by Core HCM as the authoritative source for user identity data, with no protocol, product or directory named, and the Core HCM Steering Committee approves agency-specific integrations (Book 03, Chapter 03). So the Entra design is the agency’s own decision. The book’s recommendation, as design guidance, is to take the HR-to-identity feed to the Steering Committee in Phase 0, before the interconnection goes live, and to name it in the memo’s integration-point inventory (Chapter 12, Phase 0). The window closes at interconnection go-live (Chapter 03).

The path from HR to Entra ID. Oracle Fusion Cloud HCM has no native Entra connector, so the Microsoft realization is API-driven inbound provisioning: HCM Extracts for the full load and Atom feeds for changes, read by middleware in the agency’s boundary that validates, sequences, normalizes to SCIM, writes provenance and reconciles each event, then posts to Microsoft Graph /bulkUpload (Book 03, Chapter 05). Read the hire, termination and cancellation feeds by published date, or pre-hire workflows never run (what the feeds do). The HCM-to-Entra research guide carries the build detail. Each provisioning app has its own endpoint and lands users in one of two places:⁴⁸

The two landing zones (Book 03, Chapter 05; Chapter 06)

Population	Where HR writes the attributes	How they reach Entra ID	What that means
AD-mastered (synced) users, most of the estate today	Active Directory, through the Microsoft Entra provisioning agent; the OU is computed from HR attributes and manager becomes a DN reference	Entra Connect Sync or Cloud Sync projects them; for synced users the Entra extension-attribute values are read-only	AD is still where the attributes are written. Hire and leave dates land in extensionAttribute2 and 3 and a sync rule maps them to employeeHireDate and employeeLeaveDateTime
Cloud-mastered users	Entra ID directly; structure lands as attributes, not as an OU	Already there	Any AD account an application still needs is provisioned from Entra ID

The two converge population by population: HR stays the source of authority for the person, the account’s object source of authority moves to Entra ID, and AD becomes a shrinking downstream target (Book 03, Chapter 05).

What HR supplies, and what it doesn’t.

Where each attribute comes from (Book 03, Chapter 06; matching default per the research guide)

HR supplies (from the Core HCM record)	Carrier	Not from HR	Writer instead
Person number or enterprise key, the match key	employeeId; SCIM externalId matches it by default	Contractors and vendors (not in HRIT)	One authority per fact: suitability register, contract record, PIV system, a federal sponsor mastered in HR (Book 03, Chapter 06)
Department name; organization code	department; extensionAttribute10	Account type (Standard, Service, Privileged)	Identity team; during transition a sync rule derives it from OU placement (slot 7)
Division and cost center	employeeOrgData; mirrors in extensionAttribute6 and 5	Clearance level	Personnel security system (slot 9)
Manager (supervisor’s person number)	manager	DoNotSync	Identity operations, in AD (slot 15)
Job title and job code; position category	jobTitle, extensionAttribute1; extensionAttribute12	Device region, department, tier, role, environment	Device provisioning at registration, through Graph (Book 05, Chapter 08)
Worker type	employeeType; code in extensionAttribute11	Where someone signs in from	Sign-in signals, not HR; duty location is for scoping, and network-location policy enforces on the sign-in (Book 03, Chapter 04)
Hire and leave dates	employeeHireDate, employeeLeaveDateTime	Credentials, sessions, group membership	The identity platform
Duty station, as a region code; work country	extensionAttribute4; country
Legal employer	companyName

For federal employees the durable contract is OPM’s standard data elements and nature-of-action codes, not vendor fields (Book 03, Chapter 06). Populate employeeId on existing accounts before the first full sync, because matching is what prevents duplicate identities at go-live (Chapter 05).

What the HR-sourced attributes then drive. Organization, division and position codes feed the dynamic groups of Stage 4 and the unit rules of Stage 5. The dates feed Lifecycle Workflows’ time-based joiner and leaver triggers, and an attribute change on department, division or position category is the mover trigger (Book 02, Chapter 10). The worker type code defines the Internals persona that Conditional Access targets in Stage 6, and manager becomes the approver for access packages and the reviewer for access reviews (Book 03, Chapter 10).

Before the agency’s wave lands. The pipeline doesn’t wait for Core HCM. Book 03’s reference deployment builds the middleware against extracts from the current HR system and sandbox extracts from Core HCM at once, because the source changes mid-program; only the source contract and boundary transformation differ, and at interconnection go-live they switch source (Book 03, Chapter 13). Four choices make the switch a source swap rather than a redesign:

1. Key on an enterprise person key the agency controls, not on the source’s person number (Book 03, Chapter 04).
2. Map to OPM’s standard elements and codes, not to the current system’s or Oracle’s field names (Chapter 06).
3. Keep one door into the directory, so validation, provenance and reconciliation live in middleware that outlasts the source (Chapter 05).
4. Don’t build against EHRI or eOPF feed shapes, which the memo expects to retire (Chapter 03).

Where there is no HR feed yet for a population, (design guidance) treat whoever stewards its attributes by hand as a temporary source contract: name the owner, route every change through the same single writer and its provenance, and plan to retire the manual source the way the contractor sequence does, read-only reconciliation first (Book 03, Chapter 06).

For contractors, whether Oracle’s contingent worker could be that source, and the phased path to it, see the evaluation Contractors as Oracle Contingent Workers.

Licensing and GCC, as of October 29, 2026. API-driven inbound provisioning is included with Entra ID P1, P2 and ID Governance;⁴⁹ it became generally available in the US Government cloud in June 2025, and Microsoft’s feature-availability table lists it, with provisioning-agent registration for US Government tenants.⁵⁰⁵¹ Lifecycle Workflows need Entra ID Governance or Entra Suite,⁵² and ID Governance is available in GCC, GCC High and DoD.⁵³ The /bulkUpload daily cap is 2,000 calls with P1 or P2 and 6,000 with ID Governance, at up to 50 operations a call.⁵⁴

Stage 2: prove the attributes are true before anything depends on them

Tracks: HR, with the non-person equivalent. Correlation here means accounts to worker records. The non-person equivalent is correlating every service account and service principal to an owner and a reason, which Book 02’s Phase 0 classifies and Phase 4 acts on (Book 02, Chapter 10). The device equivalent is the read-only correlation pass across the device records (Book 05, Chapter 03).

What it is. Every later control reads these attributes, so a drifted HR feed produces drifted access faster than any ticket queue (Book 03, Chapter 12). A token has to assert an authorization that is true, not just well-formed (Book 01, Chapter 04).

Decision. The correlation threshold, set by the agency’s risk governance; 99% on the pilot cohort is a proposed starting point, not a requirement, and a risk-tiered threshold is usually better (Book 03, Chapter 12). HR owns the fix for every wrong value.

Work. Baseline HR against reality for worker type, organization, supervisor and status, and fix errors at the source; populate employeeId; flag every unmatched enabled account as an orphan candidate with an owner; confirm the extension-attribute carriers are free (Phase 1). In AD, remove write paths on the target OUs and Exchange’s custom-attribute cmdlets (Chapter 06).

Gate. Correlation threshold met on the pilot; every enabled account correlated or on a dated exception list (Phase 1). Privacy basis, PIA and the minimized attribute set are Phase 1 gate items too (Book 03, Chapter 07).

Validate. The read-only validation kit measures this gate: VK-HR-01 (uncorrelated accounts), VK-HR-02 (coded attribute coverage), VK-HR-03 (reconciliation with an HR export) and VK-HR-04 (duplicate employeeId).

Failure modes. Automating against unverified data in month one (Book 03, Chapter 12). Expect a burst of high-severity findings in the first month of a new pipeline; that is the measurement working (Chapter 11).

Stage 3: map the attributes through sync

Tracks: HR. Hybrid-joined Windows devices also synchronize from AD,⁵⁵ but the program’s device attributes are written to the Entra device object by provisioning, not carried from AD (Book 05, Chapter 08).

What it is. The plumbing between HR, AD and Entra ID during coexistence.

Decisions. The sync engine (Cloud Sync unless a Connect-only requirement applies) and the sign-in method (password hash sync everywhere), both decided by identity engineering (Book 02, Chapter 09). Filtering, including the DoNotSync scoping filter on extensionAttribute15 (filtering), and attribute flow, including the date mappings for AD-landed users (Book 03, Chapter 06) and the transitional account-type rule that derives slot 7 from OU placement, which is dropped once the value is on the source object (Book 02, Chapter 09). Use the same carrier in both landing zones (Attributes), so a rule on extensionAttribute10 works for a hybrid user and a cloud-mastered one (Book 03, Chapter 06).

Gate. Book 02’s Phase 1: object counts within ±1%, no sync errors, an attribute spot check (Chapter 10). Book 03’s Phase 3: initial full sync reconciled before deltas, then shadow mode with every pipeline-versus-directory difference explained, and zero unmatched-record creations (Chapter 12).

Failure modes. A soft or hard match overwrites cloud attributes with on-premises values, so clean AD first and keep both match types blocked outside a planned window (Book 02, Chapter 09). A Connect Sync server not on 2.6.84.0 with application-based authentication stops synchronizing on April 7, 2027 (Connect Sync deadline). An omitted attribute in a /bulkUpload record can clear the target value if clearing is enabled, so send the complete record every time (Book 03, Chapter 05).

Stage 4: materialize OU subtrees as dynamic groups

Tracks: HR and Intune. Dynamic user groups are the HR track; dynamic device groups, on the device’s own attributes, are the Intune track. Arc servers are scoped by resource group and tag, not by group, and Microsoft documents no dynamic rule type for service principals (non-person identity track). Read Dynamic group dangers and how to avoid them before the first rule grants access.

What it is. AD answered “who is in the Finance branch?” by walking the tree; Entra ID answers it by evaluating a rule. Every governed group uses one of two patterns: a node query on an organization code (with -in for a roll-up) or a functional query that combines an organizational attribute with another (Book 01, Chapter 04). Every access rule excludes disabled accounts and guests, and agents’ user accounts, explicitly (Book 03, Chapter 10).

Decision. For each group whose membership really follows department, location or role, convert; otherwise keep it assigned (Book 02, Chapter 09). The application owner decides the access rule; HR owns the attribute values it reads (Book 03, Chapter 07). Flatten nested chains rather than rebuilding them (Book 02, Chapter 09; Book 06, Chapter 16).

Gate. No dynamic group grants production access until its attributes are populated and verified for a pilot cohort and its rule has been validated, shadowed against the group it replaces and reconciled (Book 06, Chapter 17).

Failure modes. A rule written on a display string breaks the next time someone retypes it (Book 06, Chapter 17). A rule change removes existing members who no longer match (same chapter).

Stage 5: delegate with administrative units

Tracks: HR and Intune. Units hold users, groups or devices. Delegation over Arc servers is Azure RBAC at management group, subscription or resource group scope (Arc track), and a non-person identity’s accountability is its owner and sponsor, not a unit (non-person identity track).

What it is. OU-level delegation becomes administrative units: containers of users, groups or devices against which a role is assigned so that it applies only to the unit’s members (Book 02, Chapter 05). The three-tier model puts tenant-scoped readers above department and division units, and each unit’s dynamic rule mirrors the corresponding group’s rule (Book 01, Chapter 04). Division units read the division code in extensionAttribute6 (Book 02, Chapter 05).

Decisions. The delegation model is identity engineering’s decision (Book 02, Chapter 06). Restricted management is a per-unit decision with a default of no, made before the unit exists because it can’t be changed afterward (Book 02, Chapter 05). Role principals are assigned, role-assignable groups whose members are PIM-eligible (role assignment matrix). Create the unit and its scoped assignment before the groups it will hold, so no window exists where only a tenant-wide administrator can manage them (Book 06, Runbook R07).

Gate. Every unit’s rule matches the registry and its processing is on; every role assignment is in the matrix; the scoped role is denied outside its unit (Book 02, Chapter 05; R07 verification).

Failure modes. Treating a unit as a confidentiality boundary when it only scopes writes. Restricting a broad HR-driven population, which removes it from PIM, entitlement management, Lifecycle Workflows and access reviews. Expecting a Global Administrator to be locked out, when restriction only makes the bypass deliberate and audited (Book 01, Chapter 04).

Stage 6: replace GPO inheritance with Conditional Access and Intune targeting

Tracks: all four. The user-configuration half of Group Policy goes to user-targeted Intune policy and Conditional Access (HR track). The computer-configuration half goes to Intune device policy and filters for end-user devices (Intune track) and to Azure Policy and machine configuration for servers (Arc track, Book 05, Chapter 09). Service principals get Conditional Access for workload identities, assigned directly (non-person identity track).

What it is. GPOs inherited down the tree; Conditional Access policies and Intune assignments target groups. Conditional Access targets personas built from authoritative attributes, such as Internals from the worker type code in extensionAttribute11 (Book 04, Chapter 03). Intune assigns policies to dynamic device groups built from device extension attributes, with assignment filters as a second layer for hardware, ownership, join type and OS, and for time-sensitive assignment uses a filter on a user group or on All devices instead, keeping dynamic device groups where a rule must read extension attributes (Book 05, Chapter 08). Intune can also assign to user groups, and Microsoft’s guidance is that settings belonging to the user, such as email and user certificates, go to user groups and settings that must stay on a device go to device groups.⁵⁶ Device rules can read only device attributes, not the attributes of the device’s owner,⁵⁷ so a user’s organization code never reaches a device group by itself; device attributes come from device provisioning.

Decisions. Control requirements belong to the CISO (Book 02, Chapter 06). Each GPO setting is classified before it moves, and every setting has exactly one owning policy (Book 05, Chapter 08). Settings such as account lockout aren’t Conditional Access controls; they go to Entra smart lockout or Intune (Book 01, Chapter 04).

Gate. Every Conditional Access policy in report-only for two to four weeks as the plan (the gate’s minimum is seven days), then enforced in waves behind a monitoring gate, with the emergency-access group excluded (Book 02, Chapter 09). Every policy targets only governed groups (Book 01, Chapter 04). On the device side, each workload wave reports success on its ring and its GPO links are disabled, not deleted (Book 05, Chapter 08).

Failure modes. A grant policy restricts nothing on its own; it needs a paired block (Book 04, Chapter 03). A policy that includes a dynamic group silently misses every user whose attribute is empty (exclusions). Role targeting doesn’t reach roles scoped to an administrative unit, so target the administrators’ group (users, groups and roles). Conditional Access doesn’t inherit through units, so the branch group has to include everyone the ancestor GPO targeted (Book 01, Chapter 04).

Stage 7: cut over in phases

Tracks: all four. Waves select users and devices by attribute value, servers by resource group and tag, and non-person identities by the application that owns them; a service account moves with its application, running old and new credentials in parallel before the legacy account is disabled (Book 02, Chapter 10).

What it is. A phased runbook, not a flag day: a pilot division, then division by division, two or three at a time, each drift-clean before the next (Book 01, Chapter 04). Waves are defined by attribute values, so each wave’s scope is a query and its dynamic groups already exist (Book 00, Chapter 09). Book 05’s workload waves run inside those division waves (Book 05, Chapter 08).

Decisions. Wave go/no-go: identity engineering (Book 02, Chapter 06). Leaver automation goes first, because revocation is where the risk and the evidence are (Book 03, Chapter 12). Align each population’s HR cutover with its move to Entra ID and with the agency’s Core HCM interconnection (Phase 5). As a population becomes cloud-mastered, retarget its provisioning from the AD app to the Entra app, with the AD leg dormant but intact. Microsoft’s source-of-authority guidance says the same: once the users’ sync cycle completes, remove them from the HR-to-AD provisioning scope and add them to the HR-to-Entra configuration.⁵⁸

Gate. A signed validation report; a dry run on production data with writes disabled; seven days after cutover in which every change for the population traces to an HR event; then the ticket path for account creation closes (Book 03, Appendix C). Cloud-mastered populations run the full lifecycle with evidence and no AD writes, and rollback has been tested once (Book 03, Chapter 12). Legacy retirement is the only destructive phase and needs approval per item (Book 01, Chapter 04).

Failure modes. A division reaching full availability before its own pilot is drift-clean. Deleting GPOs instead of disabling links, which removes the one-command rollback (Book 05, Chapter 08). Deleting a synced user only in Entra ID, which the next sync restores (Book 03, Chapter 08).

Stage 8: detect and correct drift

Tracks: all four. Each track has its own comparison: HR against the directory (below); device inventories reconciled on the Entra device ID (Book 05, Chapter 10); Arc connection state and policy compliance (Book 05, Chapter 09); and declared against observed AI and workload identities, including orphans and expiring credentials (Book 17, Chapter 07).

What it is. A scheduled comparison of what HR says with what the directory holds, and of the unit and role registry with the tenant. HR-side drift classes are missing identity, stale access, orphan account, attribute drift, unauthorized write, credential drift, contractor credential drift and schema drift (Book 03, Chapter 11). Directory-side checks catch unit rule drift, paused rule processing, unmatched role assignments and restriction mismatches (Book 02, Chapter 05).

Decision. Continuous monitoring evidence and drift findings: the CISO (Book 02, Chapter 06). Each finding is closed at the source, by fixing the record or the rule, never the copy (Book 02, Chapter 10).

Gate. Book 01’s verification list: valid attributes for every HR-listed worker, every group on one of the two patterns, every unit rule mirroring its group with processing on, every policy targeting only governed groups, zero drift findings, and a zero-action nightly plan (Chapter 04). Book 03’s recurring gate: the six lifecycle metrics within thresholds on the ConMon cadence (Chapter 12).

Failure modes. Entra ID’s log retention is far shorter than federal records schedules and isn’t retroactive, so route logs out from the pilot’s first day (Book 03, Chapter 11). Access-review decisions don’t change dynamic-group membership, so review the rule and its inputs instead (Book 06, Chapter 17).

Worked example: one user and one mover event

A budget analyst in a finance division, a federal employee, AD-mastered because her division hasn’t cut over. The codes are placeholders. The example is the HR track; step 5 is where the Intune track starts, and it shows why the two don’t mix.

Stage 1, the record. Core HCM holds her worker record and assignment. The crosswalk projects it as employeeId (the enterprise person key), department “Finance”, organization code FIN-LED in extensionAttribute10, division code in extensionAttribute6, worker type EMP in extensionAttribute11, position category ANALYST in extensionAttribute12, a region code in extensionAttribute4, and her supervisor as manager (Book 03, Chapter 06).

Stage 3, the landing. Because she’s AD-mastered, the provisioning agent writes these values to her AD account and Cloud Sync projects them to Entra ID, where her extension attributes are read-only (Book 03, Chapter 05).

Stages 4 to 6, the effects. She’s in the node group for FIN-LED and the functional group for analysts across organizations (Book 03, Chapter 10); in the department and division units, so the division’s scoped help desk can reset her password (Book 02, Chapter 05); in the Internals persona, so the baseline Conditional Access policies apply (Book 04, Chapter 03); and in a SQL Server reader group whose rule reads her organization and position codes (Book 06, Chapter 17). Her laptop’s policies come from device groups on its own tier and role attributes (Book 05, Chapter 08).

The mover event. HR processes her reassignment to the accounts-payable division as a personnel action, nature-of-action code 721, which is a mover (Book 03, Chapter 08). Nobody opens a ticket. The chain:

1. Core HCM publishes the change on its assignment feed; the middleware validates it, writes a provenance record and sends her complete record to /bulkUpload with organization code FIN-AP and the new division code (Book 03, Chapter 05; research guide sequences).
2. The provisioning agent updates her AD account; the next sync cycle carries the values to Entra ID. Attribute-change triggers fire only after the sync delivers the change (Book 02, Chapter 10).
3. Dynamic groups and units recompute. She leaves the FIN-LED groups and the old division unit and joins the FIN-AP ones, usually within a few hours but possibly more than 24 (Book 01, Chapter 04). The analyst group and the Internals persona don’t change, because position category and worker type didn’t. Access the SQL Server group gave her ends at the engine only after rule processing, token expiry and session turnover (Book 06, Chapter 16).
4. The mover workflow, triggered by the change in division code, removes the old department’s access package, requests the new one, notifies the managers and starts a review of what’s left (Book 02, Chapter 10). The review matters because access from a package or a direct assignment doesn’t leave on its own (Book 03, Chapter 08). Approvals now route to her new supervisor of record.
5. Her laptop’s device groups don’t move, because device rules can’t read her attributes.⁵⁹ If the device’s department attribute should change, that’s device reconciliation, not HR (Book 05, Chapter 08).
6. The drift scan compares her HR record with her directory values field by field. Any difference is attribute drift, fixed in HR or in the mapping. The evidence is the provenance record, the provisioning log entry, the workflow run history, and the transfer-to-review interval that PS-5 asks for (Book 03, Chapter 11).

When her division cuts over (Stage 7), the same record is retargeted to the Entra app and lands in Entra ID directly. Her groups, units and policies don’t change, because they read the same carriers in both landing zones.

Attribute-to-mechanism crosswalk

Attribute → sync mapping → rule → use; the stores are in Attributes. Slots per the program attribute map; carriers per Book 02, Appendix C

Attribute (user unless noted)	Carrier, AD → Entra ID	Through sync or provisioning	Dynamic group or unit rule	Conditional Access, Intune or app use
Enterprise person key	employeeID → employeeId	SCIM externalId; the match key	Rarely; readable	Audit joins; drift correlation (B03 Ch04)
Employment active	accountDisabled → accountEnabled	SCIM active; one writer per transition	Every access rule requires true	Leaver block (B03 Ch08)
Department name	department → department	Direct	AU-Enterprise population predicate (B02 Ch05)	Display; coarse scoping
Organization code	extensionAttribute10	Custom SCIM orgCode	Node and roll-up groups (B01 Ch04); department units (B02 Ch05)	Application access groups; SQL Server logins (B06 Ch17)
Division code	extensionAttribute6 (mirrors employeeOrgData.division)	Business unit	Division units (B02 Ch05)	Mover trigger (B02 Ch10)
Cost center code	extensionAttribute5 (mirrors employeeOrgData.costCenter)	Cost center	License assignment groups	Group-based licensing
Region code	extensionAttribute4	Duty station, through the crosswalk	Region groups	Region-scoped policy, such as phishing-resistant MFA (B01 Ch04)
Worker type code	extensionAttribute11 (mirrors employeeType, which rules can’t read)	Worker type	Employee-only and exclusion rules (B03 Ch10)	Internals persona (B04 Ch03)
Position category	extensionAttribute12	Job family or position category	Functional groups	Mover trigger; access-package auto-assignment; privileged eligibility (B03 Ch10)
Manager	manager DN → manager	Supervisor’s person number, resolved	Direct-reports rule only	Approver and reviewer (B03 Ch10)
Hire date	extensionAttribute2 → employeeHireDate	Sync rule with a date-format expression	Readable only in preview; keep it out of production rules (B06 Ch17)	Pre-hire and joiner workflows (B02 Ch10)
Leave date	extensionAttribute3 → employeeLeaveDateTime	Same	Not readable	Leaver workflows
Legal employer	company → companyName	Direct	Component-wide baseline
Account type	extensionAttribute7	Identity team; transitional rule from OU placement	Admins persona group	Admins persona; service account scoping (B02 Ch09)
Clearance level	extensionAttribute9	Personnel security system		Restricted access packages
DoNotSync	extensionAttribute15	Sync scoping filter	Not used
Certificate binding	altSecurityIdentities → certificateUserIds	Entra Connect sync; Graph for cloud-only users	Not readable	CBA username binding (below)
Device tier, role, environment, region, department	Device extensionAttribute11, 12, 13, 1, 3	Written through Graph at device registration	Device groups (B05 Ch08)	Intune assignment; Conditional Access device filters, such as the privileged-workstation block (B04 Ch03)

Beyond users: the Intune, Arc and non-person identity tracks

The stages above move people. This section is the home of the other three tracks: end-user devices, servers and non-person identities. For each it says where the attributes come from, what the computer half of Group Policy becomes, how you know the track is done, and then whether Microsoft documents targeting those objects by attribute. The Microsoft answers come from Microsoft Learn as of October 29, 2026. Where Microsoft doesn’t document something, this section says so.

Intune track: end-user devices

Source of truth. Device provisioning, not HR. The procurement or asset record owns ownership, purpose, location and organizational assignment; the Autopilot registration carries the group tag; Intune enrollment and the device provisioning service’s Graph writes put the values on the Entra device object (Book 05, Chapter 03; Chapter 04). A device with no source value carries an explicit “unpositioned” marker rather than an empty attribute (Chapter 03).

Group Policy. The computer-configuration settings that reached workstations through OU links become Intune device policy, assigned to dynamic device groups and narrowed by filters, with one owning policy per setting (Book 05, Chapter 08). Settings that belong to the user go to user groups instead.⁶⁰

Done when (design guidance): every managed device carries attributes written by provisioning, its policy is targeted by them, and computer-side GPO links are disabled population by population, with rollback tested (Book 05’s gates). Federal requirement: CM-2, CM-6, CM-8 and IA-3, and M-22-09’s device inventory and signal (mapping).

Step by step: the Intune Track Implementation guide runs this track as seven gates, each with the validation kit checks that prove it. The device targeting conventions it builds on are set in Gate 5 of the Attribute-Driven Migration implementation guide.

What Microsoft documents for targeting by attribute: yes.

• Dynamic device groups. Device rules can read device properties such as deviceOSType, deviceOwnership, deviceTrustType, enrollmentProfileName, devicePhysicalIds and extensionAttribute1 to 15, and only device properties: a device rule can’t read the attributes of the device’s owner.⁶¹ Windows Autopilot devices carry their own markers: (device.devicePhysicalIDs -any (_ -startsWith "[ZTDid]")) selects every Autopilot device, and the Autopilot group tag maps to the device’s OrderID, so (device.devicePhysicalIds -any (_ -eq "[OrderID]:<tag>")) selects one tag.⁶²
• Writing device extension attributes. They’re set through Microsoft Graph with PATCH /devices/{id} and an extensionAttributes body. The least-privileged application permission is Device.ReadWrite.All; for delegated calls it’s Directory.AccessAsUser.All, with Intune Administrator as the least-privileged supported role; and in app-only calls, or for non-Windows devices, only extensionAttributes can be updated.⁶³ Book 05, Chapter 08 carries the program’s device slots and a delegated sample that connects with Directory.AccessAsUser.All.
• Assignment filters. Filters evaluate Intune device properties at check-in, not Entra attributes: among them deviceName, deviceOwnership (Personal or Corporate), deviceTrustType (Intune’s own values), enrollmentProfileName, manufacturer, model, operatingSystemSKU, deviceCategory, cpuArchitecture and operatingSystemVersion, which became generally available in August 2026.⁶⁴⁶⁵ Extension attributes aren’t on the list.
• Scope tags. Intune delegates with its own role-based access control: a role assignment combines permissions, scope groups (the users and devices an administrator manages) and scope tags (the Intune objects the administrator can see). Tags can be assigned to devices through groups, an object or role takes at most 100, and Intune RBAC doesn’t apply to Entra roles.⁶⁶

Which end-user devices Intune covers

Intune isn’t only for Microsoft platforms: it manages Apple, Android and Linux devices as well as Windows, within the limits below, which are what Microsoft Learn documents as of October 29, 2026. Book 05, Chapter 03 carries a summary.

What Intune covers, by platform (Microsoft Learn, October 29, 2026)

Platform	Coverage	How it enrolls
Windows 11 (Pro, Enterprise, Education, IoT Enterprise and other editions); Windows 10 LTSC 2019 and 2021; Windows 11 LTSC 2024	Managed67	Autopilot or Autopilot device preparation; Entra join with automatic enrollment; provisioning package; co-management; Group Policy-triggered enrollment for hybrid-joined devices; a work account for personal devices68
Windows 10, not LTSC	Limited: out of support since October 14, 2025, so Intune treats it as allowed; it enrolls, but functionality isn’t guaranteed69	As Windows 11
Windows 7, 8.1 and other old editions; devices with Unified Write Filter on	Not supported: not on Microsoft’s list, and UWF devices are excluded70	—
Windows 365 Cloud PC	Managed: provisioned, joined and enrolled automatically71	Provisioning policy
Azure Virtual Desktop, including Windows Enterprise multi-session	Managed with limits: settings catalog plus certificate and device-tunnel VPN templates only; no Autopilot or Enrollment Status Page; update rings and some remote actions not supported; supported in GCC, GCC High and DoD; pooled host pools only for multi-session72	Entra join with Enroll the VM with Intune, or hybrid join with device-credential enrollment
macOS	Managed: macOS 15 and later supported; 13 and later allowed for devices with no user affinity73	Automated Device Enrollment through Apple Business Manager or Apple School Manager; Company Portal for personal devices; Apple Configurator74
iOS and iPadOS	Managed: 18 and later supported; 16 and later allowed for devices with no user affinity75	Automated Device Enrollment; Apple Configurator; device enrollment or account-driven user enrollment for personal devices76
Android Enterprise: personally owned work profile, corporate-owned work profile, fully managed, dedicated	Managed (Android 10 and later; dedicated devices 8 and later)77	Work profile through the Company Portal; corporate modes by QR code, zero-touch, Knox Mobile Enrollment, NFC or token78
AOSP (Android Open Source Project), user-associated and userless	Managed, for a listed set of devices without Google Mobile Services, mostly AR/VR headsets and rugged devices79	AOSP corporate enrollment
Android device administrator	Not supported on devices with Google Mobile Services since December 2024, except Teams Android devices80	—
Linux desktop	Limited: Ubuntu Desktop 24.04 and 26.04 LTS and Red Hat Enterprise Linux 9 and 10; management is compliance, including custom Bash scripts, and Conditional Access for Microsoft 365 in Edge8182	Microsoft Intune app
ChromeOS	Limited: the Chrome Enterprise connector syncs inventory and allows deprovision, lost mode, restart and wipe. Enrollment and policy stay in the Google Admin console, compliance shows Not evaluated, and app protection isn’t supported83	Google Admin console
HoloLens 2, Surface Hub, Teams Rooms on Windows, AR/VR headsets	Managed; some specialty devices need extra licensing84	Autopilot, Entra join or provisioning package, per device
Kiosks; shared and frontline devices	Managed: kiosk profiles and Windows shared PC on Windows; Entra shared device mode on iOS, iPadOS and Android, which is an Entra feature that works alongside Intune85	Per platform
Windows Server	Not an Intune platform; servers go to Azure Arc86	—
Printers, network gear, IoT and OT, cameras; thin clients that don’t run a supported Windows edition	Not Intune platforms. Defender for Endpoint device discovery finds unmanaged endpoints, network devices and IoT devices, and OT devices once Defender for IoT is onboarded87	Tiers 2 to 4

Azure Arc track: servers

Source of truth. Arc onboarding: the resource group a server lands in and the tags applied at connection (Environment, Workload, Criticality, Owner, CostCenter, PatchGroup and ArcOnboardedDate), carrying the organizational attributes from the procurement or asset record, then the CMDB reconciliation to keep them, with Azure Policy filling derivable values only (Book 05, Chapter 09). Intune doesn’t manage Windows Server, so servers never enter the Intune track (same chapter).

Group Policy. The computer-configuration settings that reached servers through OU links become Azure Policy and machine configuration, scoped by subscription, resource group or machine rather than by OU (Book 05, Chapter 09). Arc attaches the management plane; it doesn’t remove the domain join, which is a separate decision per workload (same chapter).

Done when (design guidance): every in-scope server is Arc-enabled with its tag taxonomy applied, and its baseline is assigned and evaluated by Azure Policy (the day-one baseline). Federal requirement: CM-2, CM-6 and CM-8; IA-9 for the server’s workload identity (mapping).

Step by step: the Azure Arc Track: Implementation Guide runs this track as eight gated steps, and the Endpoint & Device plan’s Phase 4 schedules it. The server targeting conventions it builds on are set in Gate 5 of the Attribute-Driven Migration implementation guide.

What Microsoft documents for targeting by attribute: yes, through Azure Resource Manager.

• The server is an Azure resource. Connecting a server with the Connected Machine agent gives it an Azure resource ID. It’s organized by management group, subscription and resource group like an Azure VM, and policies, role assignments and tags apply to it the same way.⁸⁸
• Tags are its attributes. Tags are key-value pairs set when the server is onboarded or afterward through the portal, CLI, PowerShell, ARM templates or Azure Policy.⁸⁹ At onboarding, azcmagent connect --tags takes a comma-delimited list such as Datacenter=NY3,Application=SharePoint.⁹⁰ Book 05 sets the program’s tag taxonomy and warns that tags are plain text (Chapter 09).
• Azure Policy. Assignments are scoped by management group, subscription or resource group, and policy rules can test tag values. The built-in Inherit a tag from the resource group if missing uses the modify effect to add a resource group’s tag to new or updated resources, and a remediation task fixes existing ones.⁹¹ Machine configuration carries Policy into the operating system (Book 05, Chapter 09).
• Azure Resource Graph queries server metadata and tags at scale across subscriptions.⁹²
• Azure RBAC with ABAC conditions: not for Arc. Role assignments at those scopes govern who manages the server. Role-assignment conditions (Azure ABAC) can currently be added only to role assignments that have blob storage or queue storage data actions.⁹³ Microsoft doesn’t document ABAC conditions for managing Arc-enabled servers.

Which servers Arc covers

Arc isn’t limited to Microsoft platforms either: it manages Linux servers, VMware virtual machines and AWS and Google Cloud instances. The last column says whether Microsoft documents the entry or whether it’s the program’s reading. Book 05, Chapter 09 carries the same table at working level.

What Azure Arc covers (Microsoft Learn, October 29, 2026)

Server or platform	Coverage	How it connects	Documented by Microsoft?
Windows Server 2016, 2019, 2022 and 2025, Desktop Experience and Server Core	Supported; 2016 gets new agent versions until February 203094	Connected Machine agent	Yes
Windows Server 2012 and 2012 R2	Windows Server 2012 got its last new agent version, 1.69, in October 2026, serviced for 12 months after its release; Windows Server 2012 R2 is still listed for new agent versions. Their Extended Security Updates ended October 13, 2026, and Arc support doesn’t extend them95	Agent	Yes
Windows Server 2008 R2 and earlier; any 32-bit OS	Not supported: an OS version not on Microsoft’s list isn’t supported, and the agent doesn’t run on 32-bit systems. Machine configuration doesn’t run on Arm6496	—	Yes
Linux: Red Hat Enterprise Linux 7–10, Rocky 8–9, AlmaLinux 8–9, Oracle Linux 7–10, SUSE Linux Enterprise Server 12 SP5 and 15, Ubuntu 18.04–26.04, Debian 11–13, Amazon Linux 2 and 2023, Azure Linux 3.0	Supported. Red Hat Enterprise Linux 7, Oracle Linux 7, Amazon Linux 2, Debian 11 and 12, SUSE 12 SP5 and 15 SP3–SP6, and Ubuntu 18.04 and 20.04 got their last new agent version, 1.69, in October 2026, as did AlmaLinux 8 and Oracle Linux 8 on Arm64; Azure Linux 3.0 gets no new agent versions after February 2027; the agent isn’t tested on CIS-hardened systems97	Agent	Yes
Physical servers, and VMs on any other hypervisor	Supported98	Agent	Yes
VMware vSphere VMs, including Azure VMware Solution	Supported. Arc-enabled VMware vSphere works with vCenter Server 8, up to 9,500 VMs per resource bridge, and adds VM create, resize, delete and power operations99	Arc resource bridge to vCenter, then guest management (the agent)	Yes
ESXi hosts	Discovered as inventory, with clusters and datastores; no guest management100	Stay under vCenter	Discovery yes; that the host itself takes no agent is the program’s reading
VMs under System Center Virtual Machine Manager	Retiring: new onboardings stop by October 2026 and the service ends in September 2029; Microsoft points to Arc-enabled servers instead101	Agent	Yes
AWS EC2 instances and Google Cloud VMs	Supported: the agent on each VM, or the multicloud connector, which inventories instances and installs the agent. The connector covers AWS, with Google Cloud in preview, and isn’t available in Azure Government102	Agent or multicloud connector	Yes
Azure Local (formerly Azure Stack HCI)	Supported, through its own built-in Arc control plane103	Built in	Yes
Azure VMs	Not Arc: Microsoft says not to install Arc on VMs hosted in Azure.104 They’re native Azure resources, so the same Azure Policy, RBAC and tags apply	Native	The instruction yes; “the same Policy and tags” is the program’s restatement
Kubernetes clusters	Arc-enabled Kubernetes attaches any CNCF-certified cluster as an Azure resource with resource groups and tags105	Cluster agents	Yes
SQL Server	SQL Server enabled by Azure Arc (Book 06, Chapter 09)	SQL extension	Yes (carried from Book 06)
Windows 10 and 11 clients	Only in server-like roles, such as signage or point of sale, on machines that are always on and connected; end-user machines belong in Intune106	Agent	Yes
AIX, Solaris, HP-UX, mainframe operating systems, network devices	Not supported: none is on Microsoft’s list107	—	Yes, by absence from the list
Vendor-sealed appliances and virtual appliances	Not covered where the vendor doesn’t allow an agent	—	No: the program’s reading

What neither tool reaches: a tiered strategy

(Design guidance.) Both tools manage non-Microsoft platforms, Intune for Apple, Android, Linux and ChromeOS (within the limits above), Arc for Linux, VMware, AWS and Google Cloud, but neither reaches everything. The four-track rule still holds for what’s left: every device and server has exactly one source of truth for its attributes. For anything Intune and Arc don’t manage, that source is the CMDB or asset inventory, the same record that owns the business facts for managed devices (Book 05, Chapter 03).

Tiers for devices and servers outside Intune and Arc (design guidance)

Tier	What’s in it	How it’s governed
1. Managed by Intune or Arc	The default for every platform in the two tables above	Attributes written at enrollment or onboarding from the procurement record; policy reads them
2. Managed by the platform’s own tool, with an evidence feed	ChromeOS in the Google Admin console; network devices under their controllers (Book 09, Chapter 09); the mainframe under its own security system (Book 01, Chapter 04); ESXi hosts under vCenter	Attributes mastered in the CMDB; each tool sends its inventory and configuration state there on a schedule
3. Discovered and monitored only	Printers, cameras, badge readers, OT equipment and anything else that can’t take an agent	Defender for Endpoint device discovery, with Defender for IoT for OT;108 network access control connection records (Book 09, Chapter 07); CISA CDM asset feeds under BOD 23-01 (Book 12, Chapter 01). The CMDB record exists even though no tool manages the device
4. Segmented and isolated, or retired	Out-of-support systems, and anything that can’t be inventoried with confidence	Behind segmentation, with a recorded risk acceptance and a retirement date (Book 05, Chapter 09)

The tiers are how the inventory supports CM-8, System Component Inventory, in the program’s mapping: it includes every component and counts none twice (Book 05, Chapter 10; federal requirements). A device in no tier is a finding.

Non-person identity track

Source of truth. The owning application or workload’s record: the system inventory or CMDB entry, the application registration, and for AI the AI use-case inventory. None of these is an HR record, and Book 03 deliberately leaves non-person identities out of the human-worker pattern (Book 03, Chapter 01). Accountability is a named owner and sponsor; the lifecycle runs on the owning system’s record and on credential expiry, not on hire and leave dates. What a person contributes is the sponsor’s own HR-driven lifecycle: when the sponsor moves or leaves, that is an event for every identity they sponsor (Book 17, Chapter 05).

Done when (design guidance): every service account and service principal has an owner and sponsor, a reason and a target; each one is retired, re-platformed to a managed identity or gMSA, or made a certificate or federated-credential workload identity; none holds a password that never expires, and none is orphaned. Book 02’s Phase 4 is the gate for service accounts (Chapter 10). Federal requirement: AC-2, AC-6(5), IA-4, IA-5 and IA-9, and M-25-21 for AI (mapping).

Step by step: Non-Person Identity: An Implementation Guide runs this track as six gated steps, and the Non-Person Identity Modernization plan schedules it. Owners and sponsors are recorded by the enterprise person key, a convention set in Gate 5 of the Attribute-Driven Migration implementation guide.

Service accounts, MSAs, gMSAs and dMSAs

• What they are and where they go. Traditional user-object service accounts, managed service accounts, group managed service accounts and, on Windows Server 2025 domains, delegated managed service accounts. Each has its own target: a traditional account becomes an application registration with a certificate or federated credential, or a managed identity where the workload runs in Azure; an MSA is upgraded to a gMSA; gMSAs and dMSAs stay for on-premises Kerberos workloads and move to workload identity federation or a managed identity when the workload moves (Book 02, Chapter 09; the migration path matrix). SQL Server’s engine accounts follow the same logic: a gMSA or domain service account works only while AD is authoritative (Book 06, Chapter 09; Chapter 02).
• Owner and sponsor. The application owner is identified before the account is touched, and every replacement application gets two human owners (Book 02, Chapter 10, Phase 4). An account nobody will own is a retirement candidate.
• Credential rules. High-risk accounts (password never expires, over-privileged) convert first. The targets remove the stored secret: AD manages gMSA and dMSA passwords, Azure manages managed identities, and federation replaces the secret with a token from a trusted issuer (Book 02, Chapter 09).
• Lifecycle. Driven by the owning application: discovered and classified in Phase 0, converted with old and new credentials in parallel for 30 days, then the legacy account disabled, and retired when the application is (Book 02, Chapter 10).

Service principals, managed identities and workload identities

• Owner and sponsor. At least two human owners per application registration and service principal, never service accounts, with recurring reviews of delegated and application permissions by those owners (Book 02, Chapter 09). Microsoft’s access reviews cover service principals assigned to privileged roles, including managed identities; the reviewers need Entra ID P2 and the reviewed service principals need Workload ID Premium.¹⁰⁹
• Credential rules. Managed identities first, then federated credentials, then certificates on a rotation schedule; no client secrets for production workloads (Book 02, Chapter 09). Microsoft’s application management policies can enforce that: a tenant-wide default policy, with per-application exceptions, can block new password secrets on applications and service principals and cap the lifetime of secrets and certificates. Configuring them needs Security Administrator plus Cloud Application Administrator or Application Administrator,¹¹⁰ and Microsoft’s Workload ID FAQ lists them among the free capabilities.¹¹¹
• Lifecycle. Driven by the application registration and the system it serves, with credential expiry as a scheduled review point. Workload ID Premium adds recommendations that identify unused or inactive workload identities.¹¹² Conditional Access for workload identities can block a single-tenant service principal by location or risk, but not a managed identity, which access reviews cover instead.¹¹³

AI agents

• Where they fit. An AI agent is a non-person identity: most AI runs today as a service principal or managed identity, and Microsoft Entra Agent ID adds agent identities, which are special service principals (Book 17, Chapter 04). Agent identities can’t be members of dynamic membership groups; an agent’s user account is a kind of user, and user rules include it unless they exclude it.¹¹⁴
• Owner and sponsor. A sponsor is required when an agent identity or blueprint is created (Book 17, Chapter 04). The program’s rule is two named humans and a record: an HR-mastered federal sponsor, a small sponsoring group, a technical owner who isn’t the sponsor, and an inventory record that names the same sponsor (Book 17, Chapter 05).
• Credential rules. No stored secrets, least-privilege access chosen by access mode, and no standing privileged roles (Book 17, Chapter 06).
• Lifecycle. Hangs from the sponsor and the inventory record: creation, sponsor change, reorganization, change of purpose, recertification by expiry, retirement and the orphaned agent (Book 17, Chapter 05).

What Microsoft documents for targeting service principals by attribute: partly

• Custom security attributes can be assigned to users and to enterprise applications (service principals). Attribute Definition Administrator defines them and Attribute Assignment Administrator assigns them; Global Administrator and other administrator roles can’t read, define or assign them by default. A tenant holds up to 500 active attribute definitions, and an object up to 50 assigned values.¹¹⁵
• Conditional Access filter for applications. A policy can select target applications by a custom security attribute on their service principals, evaluated at token issuance; only attributes of type string work.¹¹⁶ Book 04 uses this to target applications by environment (Chapter 03).
• ABAC principal attributes. A role-assignment condition can read a custom security attribute on the principal, a user or a service principal, through @Principal, within the storage data actions above.¹¹⁷
• App role assignment. Users and security groups are assigned to an enterprise application, optionally to an app role that reaches the application in the token’s roles claim. Group-based assignment needs Entra ID P1 or P2 and doesn’t cascade to nested groups.¹¹⁸
• Conditional Access for workload identities. Policies apply to single-tenant service principals registered in the tenant, assigned to the policy directly; a policy assigned to a group that contains a service principal isn’t enforced for it. Block is the only grant, managed identities aren’t covered, and Workload ID Premium is required.¹¹⁹
• Dynamic groups of service principals: not documented. Microsoft documents user rules and device rules only, and says agent identities, which are service principals, aren’t supported as members of dynamic membership groups.¹²⁰ It documents no rule type for service principals.

Which attribute store each mechanism can read

The store-by-consumer table, and when to use custom security attributes rather than extension slots, are in Attributes near the top of this guide.

Object types, stores, writers and consumers

Attribute-driven targeting by object type

Object	Attribute store	Who writes it	What consumes it	Microsoft source
User	Native attributes and extensionAttribute1–15	HR through API-driven inbound provisioning, into Entra ID, or into AD and then sync	Dynamic groups and units; Conditional Access through groups; Lifecycle Workflows	121122
User	Custom security attributes	Attribute Assignment Administrator; HR provisioning	Azure ABAC; Lifecycle Workflows scope	123124
User	certificateUserIds	Entra Connect from AD altSecurityIdentities (synced users); Graph or the admin center (cloud-only users)	CBA username binding	125
Device	extensionAttribute1–15	Graph: Device.ReadWrite.All app-only, or Directory.AccessAsUser.All delegated as at least Intune Administrator	Dynamic device groups; Conditional Access device filters	126
Device	enrollmentProfileName; devicePhysicalIds ([ZTDId], [OrderID])	Intune at enrollment; Autopilot registration and group tag	Dynamic device groups; Intune filters on enrollmentProfileName	127128
Device	Intune inventory (model, ownership, OS SKU)	Intune	Assignment filters	129
Arc server	Azure tags; resource group	azcmagent connect --tags; CLI, PowerShell, ARM; Policy modify	Azure Policy; Resource Graph; RBAC scope	130131
Service principal	Custom security attributes	Attribute Assignment Administrator	Conditional Access application filters; Azure ABAC	132133
Service principal	None: direct assignment	Conditional Access Administrator	Conditional Access for workload identities	134

PIV and CAC certificates as attributes

Certificate-based authentication (CBA) is attribute-driven too: Entra ID finds the user by matching a field of the presented certificate to a user attribute. Book 03, Chapter 09 and Book 07, Chapter 06 carry the design; this section ties it to attribute sourcing.

Username binding. By default the SAN Principal Name maps to userPrincipalName.¹³⁵ The bindable fields and the attributes they can match:

CBA username bindings¹³⁶

Certificate field	User attributes it can bind to	Affinity
PrincipalName (SAN), RFC822Name	userPrincipalName, onPremisesUserPrincipalName, certificateUserIds	Low
Subject, IssuerAndSubject	certificateUserIds	Low
SKI, SHA1PublicKey, IssuerAndSerialNumber	certificateUserIds	High

Affinity. High-affinity bindings use identifiers that can’t be reused. The tenant’s Required affinity binding defaults to low; it can be set to high or overridden by custom rules on issuer, policy OID or both, and when high affinity applies the low-affinity bindings are dropped. With several bindings, CBA is only as secure as the lowest-affinity one.¹³⁷ Setting the tenant to high before every user’s certificateUserIds is correct can lock users out.¹³⁸ The program’s position is high affinity in production (Book 07, Chapter 06).

certificateUserIds (the credential-binding store in Attributes). It holds up to 10 values of up to 1,024 characters, each unique in the tenant, with case-sensitive X509:<…> prefixes. For cloud-only users, at least a Privileged Authentication Administrator writes it in the admin center (up to four values of 120 characters there) or through Microsoft Graph (PATCH /users/{id} with authorizationInfo.certificateUserIds). For synced users, at least the Hybrid Identity Administrator role is needed and only Microsoft Entra Connect can update it, by syncing a value from AD such as altSecurityIdentities, or an expression over userPrincipalName. Microsoft notes that AD administrators can change the value for any synced account, and asks that only values for current valid certificates be populated and that values be removed when a certificate expires or is revoked.¹³⁹ The page names Entra Connect only; it doesn’t document Cloud Sync for this attribute.

Authentication strength. The built-in Phishing-resistant MFA strength accepts Windows Hello for Business or a platform credential, a FIDO2 security key and multifactor CBA; single-factor CBA isn’t in any built-in strength.¹⁴⁰ The CBA authentication binding policy treats every certificate as single-factor by default, and rules by issuer or policy OID raise a card’s certificates to multifactor.¹⁴¹ Microsoft’s M-22-09 guidance lists Entra CBA, including PIV, CAC and derived PIV credentials, among the phishing-resistant options.¹⁴² The Conditional Access side is Book 04, Chapter 03 and Book 02’s phishing-resistant roadmap; trust in both directions during coexistence is Book 07, Chapter 07.

Where the binding comes from. HR supplies the person: the record, the key and the joiner event that starts sponsorship and proofing. The card management system supplies the binding, because a high-affinity value identifies one certificate and a reissue or renewal changes it (Book 03, Chapter 09). During hybrid the value is written to altSecurityIdentities in AD, the attribute strong certificate mapping also uses on domain controllers (Book 07, Chapter 06), and synced. After AD, (design guidance, unverified) the card management system writes certificateUserIds through Microsoft Graph at issuance. That is an open pilot in the workbook repository, issue #130, which asks which permission a workload needs and how the write behaves for users whose source of authority moved to the cloud; Microsoft documents neither. The leaver removes the value as well as revoking the card (Book 03, Chapter 09).

Contractors. A contractor has no HR record, so the contractor source chosen in Stage 1 supplies the three links HR supplies for employees (design guidance): its joiner sends the sponsorship request, so no card is requested for someone it doesn’t hold; the card management system publishes termination, revocation and expiry events back to the pipeline, where a contractor’s termination or expiry ends the engagement and a reissue only rewrites the binding; and the contractor’s end date, capped by the contract’s completion date, is the notification that starts FIPS 201-3’s 18-hour termination clock for a card that can’t be collected.¹⁴³ Until the card arrives, a Temporary Access Pass registers a FIDO2 key that meets the phishing-resistant strength (Book 04, Chapter 03). The path is set out in Book 03, Chapter 09 and Book 07, Chapter 04, with the evidence in the evaluation Contractors as Oracle Contingent Workers.

Pending proof. The contractor PIV path is the program’s design and hasn’t yet been validated in practice; the criteria for Proved are in the evaluation’s Status and review.

Limits

These are the limits as the chapters state them, with the Learn pages re-checked on October 29, 2026 where noted.

Where dynamic membership stops. Groups that hold Entra roles must have assigned membership, can’t nest, and are capped at 500 per tenant. PIM for Groups doesn’t take dynamic groups or groups synced from AD, so privileged access is assigned, cloud-only and time-bound, and HR attributes decide only eligibility (Book 03, Chapter 10). Break-glass accounts depend on none of this machinery (same section). Explicit role-assignment groups stay assigned (Book 06, Chapter 16).

Rule limits. A rule body is at most 3,072 characters, a tenant can have at most 15,000 dynamic groups, and dynamic units count against the same total (Book 03, Chapter 10). Rules can’t read employeeType, employeeOrgData or manager, which is why the coded mirrors exist, and multi-value extension properties aren’t supported (Book 03, Chapter 06); both still held on October 29.¹⁴⁴ Dynamic groups hold users or devices, never groups. The memberOf preview ended on November 3, 2026, and groups, units and auto-assignment policies that use it are frozen in their last state (Book 02, Chapter 09); Microsoft’s page, read on October 29, still gave that date as five days away.¹⁴⁵ Prefer -eq, -startsWith and -in to -match and -contains (Book 03, Chapter 10).

Latency. Dynamic membership is usually processed within a few hours but can take more than 24, depending on the number of groups, the volume of changes and rule complexity; for bulk changes (more than 500 groups or 20,000 membership changes) Microsoft recommends pausing nonessential groups for at least 24 hours.¹⁴⁶ Book 06 adds the token lifetime (60 to 90 minutes by default) and open sessions, so urgent removal disables the account and revokes sessions instead of waiting for a rule (Chapter 16). Conditional Access evaluates group targeting at token issuance (Book 04, Chapter 03). Lifecycle Workflows run on a tenant schedule, every 3 hours by default and settable from 1 to 24, with a three-day catch-up window (Book 03, Chapter 08). For AD-mastered users, every change also waits for the sync cycle. Dynamic Intune device groups add the same processing delay; Microsoft’s guidance for time-sensitive assignment is an assignment filter on a user group or on All devices.¹⁴⁷

Dynamic group behaviour, which these limits feed, has its own section: Dynamic group dangers and how to avoid them.

Administrative units

Administrative-unit limits, what they mean and the response

Limit	Implication	Response (design guidance)
No nesting (Book 01, Chapter 04)	A unit can’t inherit from a parent unit the way an OU did	Keep units flat. Where one role must cover several units, give it one assignment per unit, generated from one list (Book 02, Chapter 05)
A write boundary, not a confidentiality boundary (same section)	Units limit who can change members, not who can read them	Use custom security attributes (Attributes) and application-level controls for confidentiality
Only some roles can be unit-scoped (same section)	A delegation-matrix role may have no unit scope	Check every role in the matrix against Microsoft’s list; roles that can’t be scoped stay central or go behind PIM approval
Dynamic units hold one object type and run only in the global Azure cloud: a GCC tenant can use them, GCC High and DoD can’t (Book 01, Chapter 04); the prerequisite still reads that way148	The tenant’s cloud changes the design	Fine in GCC, the program’s target. In GCC High or DoD, maintain unit membership with an automation job under change control, covered by the drift checks
At most 100 restricted management units, and their members are outside Entra ID Governance (Book 02, Chapter 05)	Restricting a broad HR population stops joiner, mover and leaver automation, PIM and access reviews for it	Restrict only by explicit decision, default no (Stage 5); never restrict a large HR-driven population

Lifecycle Workflows

A workflow automates one scenario, such as pre-hire, joiner, mover or leaver. Its execution conditions are a trigger (a time-based attribute such as employeeHireDate or employeeLeaveDateTime with an offset, or an attribute change) and a scope (a rule over user properties), followed by an ordered list of tasks. A custom task extension is a task that calls an Azure Logic App, so the workflow can reach systems Microsoft doesn’t, such as a card management system, an Intune retire or a ticketing system, either fire-and-forget or waiting for a callback.¹⁴⁹ Scheduled workflows run on one tenant-wide interval, and scheduling is switched on per workflow; an on-demand run is a manual run for testing or exceptions.¹⁵⁰ The real-time leaver and mover workflows can’t be scheduled.¹⁵¹ Lifecycle Workflows need Entra ID Governance or Entra Suite.¹⁵²

Lifecycle Workflows limits and behaviour, checked on Microsoft Learn October 29, 2026

Limit or behaviour	Value	Implication	Response (design guidance)
Workflows per tenant	100153154	One workflow per tree, component or worker type runs out fast	A small set of general workflows that branch through scope rules, and a workflow budget in change control (at scale)
Tasks per workflow	25155	A four-track leaver can be long	Group steps in one Logic App, or chain a leaver and a post-leaver workflow
Custom task extensions per tenant	100156	Each integration and each variant uses one	One parameterized Logic App per integration
Trigger offset (offsetInDays)	−180 to +180 days157	Pre-hire and post-leaver steps fit within six months of the date	Keep longer horizons, such as records retention, outside Lifecycle Workflows
Administrative scopes per workflow	5158	A workflow can be delegated to at most five units	Delegate by scope, not by copying workflows
Schedule interval	Every 3 hours by default, settable from 1 to 24159160	A scheduled leaver isn’t immediate, and the sync cycle and group processing add to it (latency)	Urgent terminations use the real-time leaver plus an out-of-band disable and session revocation (Book 03, Chapter 08)
On-demand run	At most 10 users;161 it ignores the workflow’s execution conditions, so its tasks apply to whoever is selected162	There’s no manual bulk run, and a wrong selection is applied anyway	Fix data at the source and let the scheduled run process it; treat each on-demand run as a change with a second-person check
Execution limits and quarantine	A tenant-wide or per-workflow threshold, as a percentage of users, a count or both (either trips it). A scheduled run that would exceed it is quarantined until an administrator approves; on-demand runs aren’t subject to it163	A mass event, such as a reorganization, either quarantines or runs for everyone	Size thresholds to normal weekly volume; plan reorganizations as change events with a pre-agreed release
Three-day catch-up	A user whose trigger or scope attributes are set late is still processed if setup completes within three days of the intended time; this doesn’t apply to the Time based attribute V2 preview trigger164	HR data entered more than three days late can miss a time-based joiner or leaver	Monitor HR timeliness and report triggers in the past that never ran (Book 03, Chapter 08)
Versions, not edits	Changing an existing workflow’s tasks or execution conditions creates a new version165	A change reaches everyone in scope at the next run	Change control, a test tenant, a scoped pilot, and the version history kept as evidence
Custom task extension timeout	Microsoft’s pages disagree: the service-limits page says 30 minutes to 3 hours,166 the deployment page 3 minutes to 5 hours167	A long callback may time out	Design callbacks to finish well inside 30 minutes until Microsoft reconciles the pages
Built-in tasks	None revokes a certificate or PIV credential or retires a device (Book 03, Chapter 08)	One HR leaver event has to reach all four tracks	Custom task extensions for the card management system and Intune; until they exist, a leaver checklist with owners (one leaver, four tracks)

Microsoft notes that these default limits can be raised through Microsoft Support.¹⁶⁸ The same limits sit in Book 02, Chapter 10, and the operational side of joiner, mover and leaver in Book 03, Chapter 08.

Lifecycle Workflows at scale

(Design guidance.) The target estate is one forest of twelve trees synchronized to a live GCC (Moderate) tenant, with every user synced, so attributes are AD-mastered (Book 03, Chapter 05). At that size the limits above bite in predictable ways.

What could break at this estate’s size (design guidance)

Risk	Why it bites at this size	Mitigation
Running out of the 100 workflows	A workflow per tree, per component, per worker type or per scenario multiplies fast: 12 trees × joiner, mover and leaver × 3 worker types is 108, before pre-hire, rehire, conversion and reminders	A small set of general workflows (pre-hire, joiner, mover, leaver, rehire, conversion) that branch on coded attributes through scope rules, with up to 5 administrative scopes each. Never one workflow per organization. Keep a workflow budget in change control, and ask Microsoft Support before planning beyond the default
Running out of the 100 custom task extensions	Each integration becomes an extension: card management (revoke, rebind), Intune retire and wipe, server access removal, ticketing, mainframe security, mailbox delegation, HR write-back; variants per component or environment multiply them	One parameterized Logic App per integration, taking the component or code as input. Count extensions per tenant, test and production
25 tasks per workflow	A four-track leaver (account, groups and licenses, PIV revoke, devices, server access, mailbox, tickets) can be long	Group steps inside one Logic App, or chain a leaver and a post-leaver offset workflow
The on-demand cap of 10 users	A reorganization, a failed HR batch or a correction can affect hundreds or thousands of people at once, and there’s no manual bulk run	Fix the data at the source and let the scheduled run process it. Keep a documented bulk-remediation procedure, such as a provisioning re-run, for incidents
On-demand ignores execution conditions and bypasses quarantine	An administrator who runs the leaver workflow on the wrong 10 people disables them, and no execution limit stops it	Make the Lifecycle Workflows Administrator role PIM-eligible with approval; treat each on-demand run as a change with a second-person check, and log it
Mass events and quarantine	A reorganization that recodes many people’s organization codes fires the mover workflow for all of them; a good threshold quarantines it, and without one it runs	Tenant-wide and per-workflow execution limits sized to normal weekly volume; reorganizations planned as change events with a pre-agreed approval to release the quarantine, and rehearsed in test
Latency for urgent terminations	The scheduled interval plus sync plus dynamic-group processing means a scheduled leaver isn’t immediate	The real-time leaver plus an out-of-band disable and session revocation through the help desk’s emergency path
Late HR data outside the three-day catch-up	A hire or separation entered more than three days late can be missed	Monitor HR timeliness, report “trigger date in the past and never processed” as a validation check, and run catch-up deliberately
No built-in PIV revoke or device retire	One HR leaver event must reach all four tracks, and natively only the account side is done	Custom extensions for card management (revoke the certificate, remove certificateUserIds) and Intune retire; until then, a leaver checklist with owners
Workflow changes are new versions	Editing a live workflow changes behaviour for everyone in scope at the next run	Change control, a test tenant, a scoped pilot, and version history kept as evidence

What still needs AD during hybrid

What still needs AD, what it means and the response

Dependency	Implication	Response (design guidance)
The attributes themselves, for every synced user: AD is where they’re written, and the Entra copies are read-only (Book 03, Chapter 06)	The provisioning service writes to AD until the population moves (Book 03, Chapter 05)	Moving the source of authority is a gated step per population (last row)
Kerberos applications, which need a cloud group provisioned back to AD as a universal group (Book 02, Chapter 09)	Each written-back group is a dependency to retire	Inventory them; write the group back, or move the application to SAML or OIDC
Disposition of synced users, which happens in AD or through the provisioning agent (Book 03, Chapter 08)	Deleting a synced user only in Entra ID doesn’t stick	Dispose of synced users at the source
DNS, DHCP and Kerberos-bound legacy applications, which keep the forest alive after it stops being the governance model (Book 01, Chapter 04); any surviving Windows login to SQL Server bypasses Conditional Access (Book 06, Chapter 16)	These block AD retirement	Track them in Books 08 and 06; report each Windows-authenticated SQL login as an IA-2 gap, the program’s mapping (Book 06, Appendix A)
Domain-level GPOs that hybrid-joined devices still need, which is why migrated OUs don’t block inheritance (Book 05, Chapter 08)	The domain baselines stay until the last hybrid device goes	Move the policy to Intune first; disable links population by population with rollback tested
Moving a user’s source of authority to Entra ID has prerequisites Microsoft lists: the HR system integrated so that changes go directly to Entra ID, no on-premises Exchange workloads, no AD FS federation for those users, and no applications that need password-based authentication such as LDAP bind169	A population can leave AD only when nothing it uses still needs AD	Make these the entry checks per population; the populations that pass move first. Whether user source-of-authority transfer is available in GCC remains open in Book 03’s verification register: give it an owner and a decide-by date, and plan the AD-mastered path as the default until it’s confirmed

The same dependencies, as retirement prerequisites, are in Book 02, Chapter 10 and Book 00, Chapter 10. Hybrid lasts: retiring AD means clearing this list, not reaching a date.

Dynamic group dangers and how to avoid them

Tracks: HR and Intune. Dynamic user groups are the HR track’s mechanism and dynamic device groups the Intune track’s. They fail in the same pattern, so each has its own table below. Arc servers aren’t grouped this way, and service principals can’t be dynamic members (non-person identity track). Stage 4 builds the groups; this section is what to guard against while it does. Facts come from the chapters first and were checked on Microsoft Learn on October 29, 2026; the responses are (design guidance) unless a chapter states them as its rule.

Dynamic user groups (HR track)

Dynamic user group dangers

Danger	What goes wrong	How to avoid it
Write access to an attribute is access	Anyone who can write an attribute a rule reads can put an account into the group. Microsoft warns that the group is only as secure as the write permissions on the attributes its rule references, in Entra ID and in any source directory, and that some synced AD attributes may let users write their own values170	Make the provisioning service the only writer; remove help-desk, self-service and Exchange custom-attribute write paths, in AD and Entra ID (Book 03, Chapter 06). Audit the write permissions on every attribute a security-relevant rule reads
One rule edit has a large blast radius	A typo or a wrong operator adds or drops every matching member at the next evaluation, and a rule change removes existing members who no longer match (Book 06, Chapter 17)	Validate the rule (the Validate rules tab tests up to 20 users or devices at a time and needs at least Groups Administrator),171 shadow it against the group it replaces, pilot it, and put rule changes under change control with the rules held in Git (Book 03, Chapter 10)
Rules that forget the guards	A rule without accountEnabled and userType clauses includes disabled accounts and guests. An agent’s user account is a kind of user, and user rules include it unless they exclude it172	Every access rule requires accountEnabled -eq true and userType -eq "Member" and excludes agents’ user accounts (Book 03, Chapter 10)
Display names instead of codes	Renames, retyping, case and whitespace move people silently (Book 06, Chapter 17)	Rules read coded attributes in extensionAttribute10 to 12 from HR-owned code lists; a value not on the list is drift (Book 03, Chapter 06; Attributes)
Empty or missing values	An account with an empty carrier falls out of every group that tests for a value, and a Conditional Access policy that includes a dynamic group silently misses it (Book 04, Chapter 03)	No rule grants production access until its attributes are populated and verified for a pilot cohort (Stage 4); test for the value you expect rather than the absence of another, and report empty carriers as drift
Processing delay and paused processing	Membership is usually processed within hours but can take more than 24, and bulk changes can call for pausing groups;173 a paused rule stops updating. Removal from a group doesn’t revoke tokens or sessions already issued (Book 06, Chapter 16)	Never make a dynamic group the only control for urgent revocation: pair it with disabling the account and revoking sessions (Book 03, Chapter 08). Check for paused rules in the drift scan (Book 02, Chapter 05)
Automatic removal has side effects	A mover or a mis-coded record leaves a group and loses what it gave: application access, and with group-based licensing the license itself. If a user leaves one licensed group before the new license from another is applied, they’re unlicensed until processing finishes, and in large tenants that can last longer than expected.174 When an Exchange Online license goes, mailbox access goes with it; the data is held for 30 days, and adding the license back in that window restores it175	Base license groups on attributes that don’t change on an ordinary move, such as legal employer or worker type, rather than on organization codes. Monitor group-based licensing errors. A mis-coded record is fixed at the source inside the 30-day window. Microsoft also documents an optional Exchange Online delicensing-resiliency setting that delays mailbox loss; confirm it’s available in the tenant’s cloud before relying on it176
What dynamic groups can’t do	They can’t be role-assignable or used by PIM for Groups, they don’t nest, a rule body is at most 3,072 characters, a tenant has at most 15,000 of them, and the memberOf preview ended November 3, 2026	Keep privileged access assigned, cloud-only and time-bound; see Limits for the detail rather than restating it here
Slow operators	-match and -contains slow dynamic group processing, and Microsoft asks that they be minimized177	Prefer -eq, -startsWith and -in (Book 03, Chapter 10)

Dynamic device groups (Intune track)

Dynamic device group dangers

Danger	What goes wrong	How to avoid it
Who can write device extension attributes	Device slots are written through Graph, with Device.ReadWrite.All app-only or, delegated, Directory.AccessAsUser.All as at least Intune Administrator.178 Whoever can write them can retarget compliance, configuration and app policy	Make the device provisioning service the only writer, holding the app-only permission; keep Intune Administrator PIM-eligible rather than standing; reconcile weekly (Book 05, Chapter 10)
Autopilot group tag (OrderID) and enrollment profile rules	The group tag becomes the device’s [OrderID] physical ID and enrollmentProfileName comes from enrollment,179180 so a wrong or reused tag or profile name moves a device into the wrong policy set	Take the tag from the procurement intake (Book 05, Chapter 04) as a controlled vocabulary, and reconcile it against the CMDB
Device rules can’t read the owner’s attributes	A device group keyed to the user’s department finds nothing, because a device rule can reference only device attributes;181 the primary user’s department isn’t a source anyway (Book 05, Chapter 03)	Write the device’s own department or organization value at provisioning from the procurement record, or send user-owned settings to user groups182
Stale and duplicate device objects	Reimaging leaves duplicates; a domain-joined device that is also Entra registered has two states that can evaluate nondeterministically;183 stale objects still match rules. Intune cleanup rules only hide records (after 30 to 270 days without check-in) and don’t remove the Entra device object184	Include device.accountEnabled -eq true in device rules.185 Follow Microsoft’s stale-device guidance: a timeframe of at least 21 days, disable for a grace period before deleting, retire in Intune first, delete hybrid-joined devices in AD and let sync carry it, back up BitLocker keys, and don’t delete system-managed Autopilot devices.186 Prevent the dual state on Windows 10 1803 and later, or block Entra registration on domain-joined devices187 (Book 05, Chapter 10)
Evaluation delay	Membership-driven policy is slower than assignment filters, which are evaluated at check-in; a dynamic exclusion computed late lets the policy reach the device first	For time-sensitive assignment, use a filter on a user group or on All devices; don’t use dynamic device groups as exclusions (Book 05, Chapter 08)188
Blast radius	One rule edit can push or pull compliance, configuration, endpoint security and app assignments for a whole fleet. A device that falls out of its tier group lands in none, and the tenant setting marks it noncompliant, so Conditional Access blocks it (Book 05, Chapter 08)	Validate and shadow the rule, move it through the pilot rings, and keep rule changes under change control (Book 05, Chapter 08)
Conflicts and overlap	A device in two groups gets two policies that set the same setting; between configuration policies there’s no precedence, and the setting may not apply until the conflict is resolved (Book 05, Chapter 08)	One owning policy per setting, and tier groups that are mutually exclusive by design
Ownership values and enrollment edge cases	Entra rules use Company, Personal or Unknown while Intune shows Corporate, so a rule written with Corporate matches nothing; deviceTrustType values differ the same way (AzureAD, ServerAD, Workplace in rules).189190 Devices enrolled outside Autopilot carry no group tag (Book 05, Chapter 03)	Use each tool’s vocabulary; treat Unknown ownership and an enrollment without a registration as findings

Monitoring both

(Design guidance.)

• Alert on membership deltas above a threshold per group per evaluation, from the audit logs routed to Log Analytics (Book 02, Chapter 10); for devices, add membership counts to the weekly reconciliation report (Book 05, Chapter 10).
• Review the rule change history: the rules live in Git and the nightly comparison flags any rule in the tenant that differs (Book 02, Chapter 10).
• Keep emergency-access accounts excluded from every Conditional Access policy, and dependent on none of this machinery (Book 03, Chapter 10).
• Know how to pause processing before a bulk change, and check afterwards that no rule stayed paused.¹⁹¹

The federal requirements each track supports

The tracks and their end state aren’t only good practice: each one supports controls and mandates an agency already has to meet. The table maps each track, and the stages and success criteria in it, to those requirements. It reuses only mappings the books already make and verified; the control identifiers and titles are SP 800-53 Rev. 5 (Release 5.2.0),¹⁹² and the mapping itself is the program’s reading, as it is in every book: the architecture contributes mechanisms and evidence to a control, and the agency’s authorizing official and assessors decide whether the control is satisfied (Book 02, Appendix A). The evidence column names the record the program produces; the read-only validation kit collects much of it, and each track’s implementation guide names the check behind each record.

The federal requirements each track supports (the program’s mapping, reusing the books’ crosswalks)

Track and stage	Requirement	What supports it	Evidence	Where the books map it
HR: Stages 1, 2 and 7	SP 800-53 AC-2 Account Management; AC-2(1) Automated System Account Management; AC-2(3) Disable Accounts	Every account traces to a worker record; hire, transfer and separation events create, change and disable accounts by workflow, not ticket	Provenance records, provisioning logs, Lifecycle Workflows run history	Book 03, Chapter 11; Book 02, Appendix A
HR: Stage 7 (leaver and mover)	PS-4 Personnel Termination; PS-5 Personnel Transfer	A leaver’s access is blocked and credentials revoked; a mover’s access is re-derived and what remains is reviewed	Separation-to-block, separation-to-revocation and transfer-to-review intervals	Book 03, Chapter 08; Chapter 11
HR: Stage 1 (the person key)	IA-4 Identifier Management; IA-4(4) Identify User Status	One enterprise person key kept across rehire and conversion; worker type as the status characteristic	Correlation report; the key’s crosswalk	Book 03, Chapter 11
HR and Intune: Stages 4 and 5	AC-3(13) Attribute-based Access Control (outside the Moderate baseline, so tailored in); AC-6 Least Privilege; AC-6(7) Review of User Privileges	Access computed from coded attributes; administrative units and scoped roles; access reviews over groups, roles and packages	The rule set in Git, which is itself the audit evidence; review decisions	Book 02, Appendix A; Book 06, Appendix A
HR: Stage 1 (HR as the source)	OMB M-19-17, the enterprise ICAM policy framework;193 the FICAM Identity Lifecycle Management Playbook, which recommends HR as the authoritative source for creation and termination and states that it isn’t official policy194	HR authoritative for who works for the agency; one governed feed	Authority map and schema, signed	Book 03, Chapter 02
HR: Stage 1 (the coming source)	The OMB/OPM Federal HR 2.0 memorandum of December 10, 2025, consolidating Core HCM;195 contractors and vendors are outside it	The pipeline keyed and mapped so the source can change; a designated contractor source	The integration-point inventory entry; the contractor authority decision	Book 03, Chapter 03; Chapter 01
HR: Stage 1 and contractors	PS-7 External Personnel Security	Contractor engagements end on the contractor source’s earliest end date, not on the provider’s notice; the provider’s termination notice is one more leaver input	End-date-to-block interval for contractors; provider notices received against engagements already ended	Book 03, Chapter 11; HR-Driven Identity guide
HR: Stage 6 and the PIV binding	OMB M-22-09 phishing-resistant MFA for staff, contractors and partners;196 IA-2 Identification and Authentication, with IA-2(1), IA-2(2), IA-2(8) and IA-2(12) Acceptance of PIV Credentials; FIPS 201-3;197 SP 800-63-4198	Cloud authentication for every user; PIV-bound certificate-based authentication at a phishing-resistant strength; card reissue and termination reach the binding	Authentication-method and sign-in reports; the binding record	Book 02, Appendix A; Book 03, Chapter 09
HR: Stage 6	AC-3 Access Enforcement; CISA BOD 25-01 required SCuBA policies such as MS.AAD.1.1v1 (block legacy authentication) and MS.AAD.3.1v1 (phishing-resistant MFA for all users)199	Conditional Access evaluates every sign-in; the mandatory policies configured	ScubaGear reports	Book 02, Appendix A
Intune	CM-2 Baseline Configuration; CM-6 Configuration Settings; CM-7 Least Functionality; CM-8 System Component Inventory; CM-3 Configuration Change Control	The policy library as code; per-setting status and an exception register; attack surface reduction and firewall; weekly reconciliation of Intune, Entra ID and Defender; every Intune change in the change record	Exported policy JSON; status reports; the reconciliation report	Book 05, Chapter 10
Intune	IA-3 Device Identification and Authentication; OMB M-22-09 device inventory and a device-level signal alongside identity200	Device compliance and device certificates feed Conditional Access	Compliance records; the device inventory	Book 05, Chapter 04; Book 01, Appendix A; Book 11, Appendix A
Arc	CM-2, CM-6 and CM-8	Machine-configuration baselines as code; a reconciled inventory across Intune, Arc, cloud accounts and hypervisor hosts; the tiers for what neither tool reaches	Versioned manifests; Azure Policy compliance; the inventory	Book 01, Appendix A; Book 11, Appendix A
Arc and non-person	IA-9 Service Identification and Authentication (in no baseline, so tailored in)	The Arc managed identity or app registration authenticates the server’s workload, such as SQL Server, to Entra ID	Graph permission grants per machine identity	Book 06, Appendix A
Non-person	AC-2, AC-2(1), AC-2(3), AC-6 and AC-6(5) Privileged Accounts	Every workload and agent identity is a defined account type with a sponsor; retired and orphaned identities are disabled; no standing privileged roles	Sponsor and owner records; the orphan check	Book 17, Appendix A
Non-person	IA-4, IA-5 Authenticator Management, IA-9	Each identity’s own identifier, joined to its inventory record and never reused; managed identities and federation first, no stored secrets; service principal credentials rotated	Credential-expiry report; application management policies	Book 17, Appendix A; Book 02, Chapter 10
Non-person	AC-6 and CM-7, through the SCuBA policies MS.AAD.5.1v1 to 5.3v1 (application creation and consent restricted)	Only privileged users register applications; consent restricted, with an admin consent workflow	ScubaGear reports	Book 02, Appendix A
Non-person: AI agents	OMB M-25-21, which requires an AI use-case inventory and the ability to discontinue non-compliant AI201	The inventory as the seed list for AI identity records; disabling the identity is how an AI system is stopped	The inventory joined to the directory	Book 17, Appendix A
All tracks: Stage 8	AU-2 Event Logging; AU-6 Audit Record Review, Analysis, and Reporting; AU-12 Audit Record Generation; SI-4 System Monitoring; CA-7 Continuous Monitoring; OMB M-26-14 on agency logging, which rescinded M-21-31202	Logs routed out of Entra ID from the first day; the scheduled drift comparison; lifecycle metrics on the ConMon cadence	Drift reports; SIEM ingestion; the metrics	Book 12, Appendix A; Book 03, Chapter 11
All tracks	FedRAMP and the GCC boundary: Microsoft 365 GCC is offered at FedRAMP Moderate, with Entra ID in Microsoft’s commercial cloud;203 the NIST baseline and the FedRAMP class are separate facts	Features chosen and checked against the tenant’s cloud	The authorization package	Book 14, Chapter 03

Left out for lack of support in the books: AC-2(13), which the books map to incident response, not to the lifecycle; IA-8 for contractors (the books map it to guests and agents acting for the public); OMB M-21-31, rescinded by M-26-14; and a direct control mapping from Book 05, Chapter 09, which maps none itself, so the Arc rows come from Books 01, 06 and 11.

How the books’ phase numbers line up

Each book’s own phases against this guide’s stages (approximate; each book’s gates govern its own work)

Stage	Book 01 identity phases	Book 02 playbook	Book 03 phases	Book 05 GPO phases
0 Read the tree	0 Assessment	0 Assessment	0 Program alignment	1 Inventory and classify
1–2 Source and prove			1 Attribute authority and schema
3 Map through sync		1 Sync; 2 Sign-in and report-only	2 Build and test; 3 Hybrid go-live	2 Coexistence planning
4–5 Groups and units	1 Authoring	3 Groups; 5 PIM	4 Lifecycle automation and derived access	3 Baseline authoring
6 Retarget policy		6 Conditional Access enforcement		4 Pilot; 5 Workload cutover
7 Cut over	2 Pilot; 3 Rollout; 4 Legacy retirement	7–9 Authentication, legacy cutoff, federation	5 Cutover by population	6 Verification; 7 Retirement
8 Drift	5 Steady state	10 Steady-state governance	6 Sustained posture

Checklist

Stage	Tracks	Check
0	All four	OU links, inheritance and hand-made delegations exported, site links included · A decision for every group · OU-to-unit mapping drafted · Every OU and GPO tagged with its track, user and computer halves separately · Service accounts inventoried and classified by risk
1	HR; sources for all	Authority map, identifier decision and schema signed · Code lists owned by HR · HR-to-identity feed named in the HR 2.0 integration inventory and taken to the Steering Committee · Contractor source decided, one authority per fact · Privacy basis and PIA under way · Device, server and non-person attribute authorities named: procurement record, Arc onboarding tags, owning-system record
2	HR, non-person	employeeId populated before the first full sync · Correlation threshold met on the pilot · Orphans owned · Every other write path to access slots removed, in AD and Entra ID · Every service account and service principal correlated to an owner and a reason
3	HR	Sync engine and PHS decided · Carriers free and in the provisioning apps’ target lists · Date mappings tested · Feeds read by published date · Shadow-mode differences explained
4	HR, Intune	Every access rule on codes, excluding disabled accounts, guests and agents · Validated, shadowed, piloted · No memberOf · Nesting flattened · Every rule carries accountEnabled and userType guards · Rule changes under change control · Device rules on device attributes only · No dynamic device groups as exclusions · Membership-delta alerts on
5	HR, Intune	Unit rules mirror group rules; processing on · Restriction decided per unit before creation · Role principals assigned and PIM-eligible · Units created before the groups they hold
6	All four	Personas from authoritative attributes · Grant and block policies in pairs · Report-only first · Emergency-access group excluded · Device attributes written at registration · One owning policy per setting · User-configuration GPO settings to user-targeted policy; computer-configuration to Intune device policy or Azure Policy
7	All four	Validation report signed · Dry run with writes off · Seven days of sole-source proof · Ticket path closed · Provisioning retargeted per population · Rollback tested · Leaver reaches all four tracks (custom extensions or an owned checklist) · Real-time leaver and out-of-band revocation for urgent cases
PIV	HR	Card management system named as the binding writer · High affinity piloted before the tenant setting changes · Phishing-resistant strength for CBA users · Leaver removes the binding
8	All four	Drift scans scheduled for HR, units and roles · Logs routed outside Entra ID from day one · Findings closed at the source · Metrics on the ConMon cadence · Device inventories reconciled weekly · Arc connection state monitored · Orphaned and expiring non-person credentials reported
Intune track	Intune	Every managed device has provisioning-written attributes · Platform coverage checked against the coverage table · Uncovered devices placed in a tier · Stale and duplicate device objects cleaned up by Microsoft’s guidance
Arc track	Arc	Every in-scope server Arc-enabled with the tag taxonomy · Baseline assigned and evaluated by Azure Policy · Out-of-support servers on a retirement date or segmented · AWS, Google Cloud and VMware estates connected or tiered
Non-person track	Non-person	Owner and sponsor for every service account, service principal and agent · No password that never expires · Application management policies restrict secrets and lifetimes · Orphan and credential-expiry checks scheduled
Lifecycle Workflows	HR	Workflow and custom-extension budgets in change control · Execution limits set, tenant-wide and per workflow · Lifecycle Workflows Administrator PIM-eligible, on-demand runs logged · HR timeliness monitored against the three-day catch-up
Federal requirements	All four	Each track’s evidence named against the requirement table

TipBack to the books

This is a companion guide, not part of a numbered book. ← The Workbook Books

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); Guides A: fix confirmed crosswalk errors (book count, PS-7 row, Chapter 03 absorbed findings, slots 4-6, VK-ARC-01 and 04 descriptions) (#411); Guides A: fix 14 inconsistency findings (#441); 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); Claim language: supports, not satisfies (rule, check, first sweep) (#474); and 4 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); Restore the developer workbook as Book 19, and the ADM implementation guide to Books > Guides (#270); Content rules: one home per type, and the federal layers every guide carries (#271); HR-Driven Identity: An Implementation Guide (draft) (#272)
1.0	2026.10	2026-10-31	First edition (9 merged changes since the guide began)

Footnotes

1. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

2. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

3. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

4. Microsoft Learn, “Add custom data to resources by using extensions,” Microsoft Graph (the 15 extension attributes on users and devices, originally AD and Exchange custom attributes; directory extensions and their naming convention; “Comparison of extension types”: sync from on-premises, dynamic membership rules, 100 extension values per resource instance), https://learn.microsoft.com/graph/extensibility-overview (accessed Oct 29, 2026).

5. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

6. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

7. Microsoft Learn, “Update device,” Microsoft Graph v1.0 (permissions; Intune Administrator as least-privileged delegated role; app-only and non-Windows calls update only extensionAttributes; Example 2, write extensionAttributes), https://learn.microsoft.com/graph/api/device-update?view=graph-rest-1.0 (accessed Oct 29, 2026).

8. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

9. Microsoft Learn, “Conditional Access: Filter for devices,” “Supported operators and device properties for filters” (extensionAttribute1-15 available only for devices that are Intune-managed, compliant or Microsoft Entra hybrid joined) and “Policy behavior with filter for devices,” https://learn.microsoft.com/entra/identity/conditional-access/concept-condition-filters-for-devices (accessed Oct 29, 2026).

10. Microsoft Learn, “What are custom security attributes in Microsoft Entra ID?” (supported objects; comparison with extensions; roles; limits), https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview (accessed Oct 29, 2026).

11. Microsoft Learn, “Add custom data to resources by using extensions,” Microsoft Graph (the 15 extension attributes on users and devices, originally AD and Exchange custom attributes; directory extensions and their naming convention; “Comparison of extension types”: sync from on-premises, dynamic membership rules, 100 extension values per resource instance), https://learn.microsoft.com/graph/extensibility-overview (accessed Oct 29, 2026).

12. Microsoft Learn, “Microsoft Entra Connect Sync: Directory extensions,” “Important considerations when using Directory Extensions” (up to 100 directory extension values per object; strings over 256 characters truncated) and “Use the attributes in dynamic membership groups,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-sync-feature-directory-extensions (accessed Oct 29, 2026).

13. Microsoft Learn, “Cloud sync directory extensions and custom attribute mapping,” “Syncing directory extensions for Microsoft Entra Cloud Sync” (supported only for the CloudSyncCustomExtensionsApp application and the Tenant Schema Extension App created by Entra Connect), https://learn.microsoft.com/entra/identity/hybrid/cloud-sync/custom-attribute-mapping (accessed Oct 29, 2026).

14. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

15. Microsoft Learn, “What are custom security attributes in Microsoft Entra ID?” (supported objects; comparison with extensions; roles; limits), https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview (accessed Oct 29, 2026).

16. Microsoft Learn, “Archive for Microsoft Entra releases and announcements,” June 2025 (“API-driven provisioning is now generally available in US Gov cloud”; “Provision custom security attributes from HR sources,” including API-driven provisioning) and August 2024 (“Configure Lifecycle Workflow Scope Using Custom Security Attributes”), https://learn.microsoft.com/entra/fundamentals/whats-new-archive (accessed Oct 29, 2026).

17. Microsoft Learn, “Conditional Access: Filter for applications” (custom security attributes on service principals; evaluated at token issuance; string type only), https://learn.microsoft.com/entra/identity/conditional-access/concept-filter-for-applications (accessed Oct 29, 2026).

18. Microsoft Learn, “What is Azure attribute-based access control (Azure ABAC)?,” “Where can conditions be added?” (role assignments with blob storage or queue storage data actions) and “Status of condition features” (custom security attributes on a principal, GA November 2023), https://learn.microsoft.com/azure/role-based-access-control/conditions-overview; and “Azure role assignment condition format and syntax,” Attributes (@Principal is a custom security attribute on a user or service principal), https://learn.microsoft.com/azure/role-based-access-control/conditions-format (both accessed Oct 29, 2026).

19. Microsoft Learn, “Assign, update, list, or remove custom security attributes for a user,” FAQ (custom security attributes assigned to users aren’t supported in rules for dynamic membership groups), https://learn.microsoft.com/entra/identity/users/users-custom-security-attributes (accessed Oct 29, 2026).

20. Microsoft Learn, “Add custom data to resources by using extensions,” Microsoft Graph (the 15 extension attributes on users and devices, originally AD and Exchange custom attributes; directory extensions and their naming convention; “Comparison of extension types”: sync from on-premises, dynamic membership rules, 100 extension values per resource instance), https://learn.microsoft.com/graph/extensibility-overview (accessed Oct 29, 2026).

21. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

22. 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).

23. 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).

24. Microsoft Learn, “Organize and inventory servers with hierarchies, tagging, and reporting” (tags at onboarding or per server through the portal, CLI, PowerShell, ARM or Azure Policy; Azure Resource Graph queries), https://learn.microsoft.com/azure/azure-arc/servers/organize-inventory-servers (accessed Oct 29, 2026).

25. Microsoft Learn, “azcmagent connect,” Flags (--tags), https://learn.microsoft.com/azure/azure-arc/servers/azcmagent-connect (accessed Oct 29, 2026).

26. Microsoft Learn, “Assign policy definitions for tag compliance” (Inherit a tag from the resource group if missing, modify effect, remediation of existing resources), https://learn.microsoft.com/azure/azure-resource-manager/management/tag-policies (accessed Oct 29, 2026).

27. Microsoft Learn, “Cloud-native server management with Azure Arc-enabled servers” (connected machines get an Azure resource ID and are organized, governed and tagged like Azure VMs), https://learn.microsoft.com/azure/azure-arc/servers/cloud-native/overview (accessed Oct 29, 2026).

28. Microsoft Learn, “Mapping to the certificateUserIds attribute in Microsoft Entra ID” (limits; patterns; roles for cloud-only and synced users; Graph update; Entra Connect sync from altSecurityIdentities; hygiene), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-certificateuserids (accessed Oct 29, 2026).

29. Microsoft Learn, “Assign, update, list, or remove custom security attributes for a user,” FAQ (custom security attributes assigned to users aren’t supported in rules for dynamic membership groups), https://learn.microsoft.com/entra/identity/users/users-custom-security-attributes (accessed Oct 29, 2026).

30. Microsoft Learn, “Archive for Microsoft Entra releases and announcements,” June 2025 (“API-driven provisioning is now generally available in US Gov cloud”; “Provision custom security attributes from HR sources,” including API-driven provisioning) and August 2024 (“Configure Lifecycle Workflow Scope Using Custom Security Attributes”), https://learn.microsoft.com/entra/fundamentals/whats-new-archive (accessed Oct 29, 2026).

31. Microsoft Learn, “What are custom security attributes in Microsoft Entra ID?” (supported objects; comparison with extensions; roles; limits), https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview (accessed Oct 29, 2026).

32. Microsoft Learn, “Impact of Schema Changes,” Active Directory Domain Services (schema changes are forest-wide; additions can’t be removed, only disabled), https://learn.microsoft.com/windows/win32/ad/impact-of-schema-changes (accessed Oct 29, 2026).

33. Microsoft Learn, “Advanced query capabilities on Microsoft Entra ID objects,” “User properties” (filters on onPremisesExtensionAttributes/extensionAttribute1-15 are advanced queries), https://learn.microsoft.com/graph/aad-advanced-queries (accessed Oct 29, 2026).

34. Microsoft Learn, “Microsoft Entra Connect: Design concepts,” “Using ms-DS-ConsistencyGuid as sourceAnchor” (version 1.1.524.0 and later), https://learn.microsoft.com/entra/identity/hybrid/connect/plan-connect-design-concepts (accessed Oct 29, 2026).

35. Microsoft Learn, “Microsoft Entra Cloud Sync FAQ,” “Can I change the source anchor for cloud sync?” (ms-DS-ConsistencyGuid with fallback to objectGUID; no supported way to change it), https://learn.microsoft.com/entra/identity/hybrid/cloud-sync/reference-cloud-sync-faq (accessed Oct 29, 2026).

36. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

37. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

38. Microsoft Learn, “Microsoft Entra Connect: Design concepts,” “Using ms-DS-ConsistencyGuid as sourceAnchor” (version 1.1.524.0 and later), https://learn.microsoft.com/entra/identity/hybrid/connect/plan-connect-design-concepts (accessed Oct 29, 2026).

39. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

40. Microsoft Learn, “Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID” (c, co, l, st and physicalDeliveryOfficeName synced; pwdLastSet a mechanical property used to invalidate issued tokens; usageLocation a mechanical property used for license assignment), https://learn.microsoft.com/entra/identity/hybrid/connect/reference-connect-sync-attributes-synchronized (accessed Oct 29, 2026); the AD co to Entra country pairing follows Microsoft’s attribute mapping for Domain Services, https://learn.microsoft.com/entra/identity/domain-services/synchronization (accessed Oct 29, 2026).

41. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

42. Microsoft Learn, “Microsoft Entra Connect Sync: Directory extensions,” “Important considerations when using Directory Extensions” (up to 100 directory extension values per object; strings over 256 characters truncated) and “Use the attributes in dynamic membership groups,” https://learn.microsoft.com/entra/identity/hybrid/connect/how-to-connect-sync-feature-directory-extensions (accessed Oct 29, 2026).

43. Microsoft Learn, “Configure dynamic membership groups with the memberOf operator in the Entra Admin Center (preview)” (preview ended November 3, 2026), https://learn.microsoft.com/entra/identity/users/groups-dynamic-rule-member-of (accessed Oct 29, 2026).

44. Microsoft Learn, “Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID” (c, co, l, st and physicalDeliveryOfficeName synced; pwdLastSet a mechanical property used to invalidate issued tokens; usageLocation a mechanical property used for license assignment), https://learn.microsoft.com/entra/identity/hybrid/connect/reference-connect-sync-attributes-synchronized (accessed Oct 29, 2026); the AD co to Entra country pairing follows Microsoft’s attribute mapping for Domain Services, https://learn.microsoft.com/entra/identity/domain-services/synchronization (accessed Oct 29, 2026).

45. Microsoft Learn, “user resource type,” Microsoft Graph v1.0, Properties (employeeId maximum 16 characters; employeeType; employeeOrgData; usageLocation required for users assigned licenses; userType Member or Guest; onPremisesExtensionAttributes up to 1,024 characters each, read-only for synced users, and read-only in Graph for cloud-only users previously synced; onPremisesSamAccountName, onPremisesDistinguishedName and onPremisesSecurityIdentifier read-only; signInActivity read-only, needing P1 or P2 and AuditLog.Read.All), https://learn.microsoft.com/graph/api/resources/user?view=graph-rest-1.0 (accessed Oct 29, 2026).

46. Microsoft Learn, “Mapping to the certificateUserIds attribute in Microsoft Entra ID” (limits; patterns; roles for cloud-only and synced users; Graph update; Entra Connect sync from altSecurityIdentities; hygiene), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-certificateuserids (accessed Oct 29, 2026).

47. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

48. Microsoft Learn, “API-driven inbound provisioning concepts” (provisioning to on-premises AD for hybrid users or to Entra ID for cloud-only users; one endpoint per provisioning app; throttling and daily limits; license requirements), https://learn.microsoft.com/entra/identity/app-provisioning/inbound-provisioning-api-concepts (accessed Oct 29, 2026).

49. Microsoft Learn, “API-driven inbound provisioning concepts” (provisioning to on-premises AD for hybrid users or to Entra ID for cloud-only users; one endpoint per provisioning app; throttling and daily limits; license requirements), https://learn.microsoft.com/entra/identity/app-provisioning/inbound-provisioning-api-concepts (accessed Oct 29, 2026).

50. Microsoft Learn, “Archive for Microsoft Entra releases and announcements,” June 2025 (“API-driven provisioning is now generally available in US Gov cloud”; “Provision custom security attributes from HR sources,” including API-driven provisioning) and August 2024 (“Configure Lifecycle Workflow Scope Using Custom Security Attributes”), https://learn.microsoft.com/entra/fundamentals/whats-new-archive (accessed Oct 29, 2026).

51. Microsoft Learn, “Microsoft Entra feature availability” (HR provisioning apps: API-driven inbound provisioning; provisioning agent registration for US Government tenants; Microsoft Entra ID Governance in GCC, GCC High and DoD), https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Oct 29, 2026).

52. Microsoft Learn, “What are lifecycle workflows?” (license requirements; up to 100 workflows and 100 custom task extensions), https://learn.microsoft.com/entra/id-governance/what-are-lifecycle-workflows (accessed Oct 29, 2026).

53. Microsoft Learn, “Microsoft Entra feature availability” (HR provisioning apps: API-driven inbound provisioning; provisioning agent registration for US Government tenants; Microsoft Entra ID Governance in GCC, GCC High and DoD), https://learn.microsoft.com/entra/identity/authentication/feature-availability (accessed Oct 29, 2026).

54. Microsoft Learn, “API-driven inbound provisioning concepts” (provisioning to on-premises AD for hybrid users or to Entra ID for cloud-only users; one endpoint per provisioning app; throttling and daily limits; license requirements), https://learn.microsoft.com/entra/identity/app-provisioning/inbound-provisioning-api-concepts (accessed Oct 29, 2026).

55. 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).

56. Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group latency; assignment filters on user groups or All devices for time-sensitive scenarios), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026).

57. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

58. Microsoft Learn, “Guidance for using user Source of Authority (SOA),” “Transition user management” (remove users from the HR-to-AD provisioning scope and add them to the HR-to-Microsoft Entra ID configuration), https://learn.microsoft.com/entra/identity/hybrid/user-source-of-authority-guidance (accessed Oct 29, 2026).

59. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

60. Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group latency; assignment filters on user groups or All devices for time-sensitive scenarios), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026).

61. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

62. 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).

63. Microsoft Learn, “Update device,” Microsoft Graph v1.0 (permissions; Intune Administrator as least-privileged delegated role; app-only and non-Windows calls update only extensionAttributes; Example 2, write extensionAttributes), https://learn.microsoft.com/graph/api/device-update?view=graph-rest-1.0 (accessed Oct 29, 2026).

64. 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).

65. Microsoft Learn, “What’s new in Microsoft Intune,” week of August 25, 2026 (service release 2608), “Operating system version property in assignment filters is generally available,” https://learn.microsoft.com/intune/whats-new/ (accessed Oct 29, 2026).

66. Microsoft Learn, “Use role-based access control (RBAC) and scope tags for distributed IT” (roles, scope groups and scope tags; at most 100 scope tags per object or role; Intune RBAC doesn’t apply to Entra roles), https://learn.microsoft.com/intune/fundamentals/role-based-access-control/scope-tags (accessed Oct 29, 2026).

67. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

68. Microsoft Learn, “Step 5 - Enroll devices in Microsoft Intune,” “Enrollment for Windows,” https://learn.microsoft.com/intune/device-enrollment/enroll-devices (accessed Oct 29, 2026).

69. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

70. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

71. Microsoft Learn, “What is Windows 365 Enterprise?,” https://learn.microsoft.com/windows-365/enterprise/overview (accessed Oct 29, 2026).

72. Microsoft Learn, “Windows Enterprise multi-session remote desktops,” “Prerequisites,” “Create the configuration profile,” “Remote actions” and “Additional configurations that aren’t supported on Windows Enterprise multi-session VMs,” https://learn.microsoft.com/intune/solutions/azure-virtual-desktop-multi-session (accessed Oct 29, 2026).

73. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

74. Microsoft Learn, “Enrollment guide: Enroll Apple mobile devices in Microsoft Intune,” https://learn.microsoft.com/intune/device-enrollment/apple/guide-ios-ipados, and “Enrollment guide: Enroll macOS devices in Microsoft Intune,” https://learn.microsoft.com/intune/device-enrollment/apple/guide-macos (both accessed Oct 29, 2026).

75. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

76. Microsoft Learn, “Enrollment guide: Enroll Apple mobile devices in Microsoft Intune,” https://learn.microsoft.com/intune/device-enrollment/apple/guide-ios-ipados, and “Enrollment guide: Enroll macOS devices in Microsoft Intune,” https://learn.microsoft.com/intune/device-enrollment/apple/guide-macos (both accessed Oct 29, 2026).

77. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

78. Microsoft Learn, “Enrollment guide: Enroll Android devices in Microsoft Intune,” https://learn.microsoft.com/intune/device-enrollment/android/guide, and “Enroll your Android Enterprise dedicated, fully managed, or corporate-owned with work profile devices,” https://learn.microsoft.com/intune/device-enrollment/android/ref-corporate-methods (both accessed Oct 29, 2026).

79. Microsoft Learn, “Android Open Source Project Supported Devices,” https://learn.microsoft.com/intune/fundamentals/aosp-supported-devices (accessed Oct 29, 2026).

80. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

81. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

82. Microsoft Learn, “Deployment guide: Manage Linux devices in Microsoft Intune,” https://learn.microsoft.com/intune/fundamentals/platform-guide-linux (accessed Oct 29, 2026).

83. Microsoft Learn, “Configure Chrome Enterprise connector,” https://learn.microsoft.com/intune/device-enrollment/configure-chrome-enterprise-connector, and “View ChromeOS device information in Intune,” “View ChromeOS devices,” https://learn.microsoft.com/intune/device-management/inventory-and-status/chrome-enterprise-details (both accessed Oct 29, 2026).

84. Microsoft Learn, “Specialty device management,” “Licensing considerations,” https://learn.microsoft.com/intune/device-management/specialty-devices (accessed Oct 29, 2026).

85. Microsoft Learn, “Frontline worker device management overview in Microsoft Intune,” “Microsoft Entra shared device mode for FLW,” https://learn.microsoft.com/intune/solutions/frontline-worker/, and “Frontline worker for Windows devices in Microsoft Intune,” “Step 2 - Shared device or user associated device,” https://learn.microsoft.com/intune/solutions/frontline-worker/windows (both accessed Oct 29, 2026).

86. Microsoft Learn, “Supported operating systems and browsers in Intune,” sections “Microsoft,” “Apple,” “Android” and “Linux,” https://learn.microsoft.com/intune/fundamentals/ref-supported-platforms (accessed Oct 29, 2026).

87. Microsoft Learn, “Microsoft Defender for Endpoint device discovery overview,” “Discovered assets” and “Discovery modes and scans,” https://learn.microsoft.com/defender-endpoint/device-discovery (accessed Oct 29, 2026).

88. Microsoft Learn, “Cloud-native server management with Azure Arc-enabled servers” (connected machines get an Azure resource ID and are organized, governed and tagged like Azure VMs), https://learn.microsoft.com/azure/azure-arc/servers/cloud-native/overview (accessed Oct 29, 2026).

89. Microsoft Learn, “Organize and inventory servers with hierarchies, tagging, and reporting” (tags at onboarding or per server through the portal, CLI, PowerShell, ARM or Azure Policy; Azure Resource Graph queries), https://learn.microsoft.com/azure/azure-arc/servers/organize-inventory-servers (accessed Oct 29, 2026).

90. Microsoft Learn, “azcmagent connect,” Flags (--tags), https://learn.microsoft.com/azure/azure-arc/servers/azcmagent-connect (accessed Oct 29, 2026).

91. Microsoft Learn, “Assign policy definitions for tag compliance” (Inherit a tag from the resource group if missing, modify effect, remediation of existing resources), https://learn.microsoft.com/azure/azure-resource-manager/management/tag-policies (accessed Oct 29, 2026).

92. Microsoft Learn, “Organize and inventory servers with hierarchies, tagging, and reporting” (tags at onboarding or per server through the portal, CLI, PowerShell, ARM or Azure Policy; Azure Resource Graph queries), https://learn.microsoft.com/azure/azure-arc/servers/organize-inventory-servers (accessed Oct 29, 2026).

93. Microsoft Learn, “What is Azure attribute-based access control (Azure ABAC)?,” “Where can conditions be added?” (role assignments with blob storage or queue storage data actions) and “Status of condition features” (custom security attributes on a principal, GA November 2023), https://learn.microsoft.com/azure/role-based-access-control/conditions-overview; and “Azure role assignment condition format and syntax,” Attributes (@Principal is a custom security attribute on a user or service principal), https://learn.microsoft.com/azure/role-based-access-control/conditions-format (both accessed Oct 29, 2026).

94. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

95. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

96. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

97. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

98. Microsoft Learn, “Choosing the right Azure Arc service for machines,” “General recommendations” and “Azure Local,” https://learn.microsoft.com/azure/azure-arc/choose-service (accessed Oct 29, 2026).

99. Microsoft Learn, “What is Azure Arc-enabled VMware vSphere?,” “How does it work?” and “Supported scenarios,” https://learn.microsoft.com/azure/azure-arc/vmware-vsphere/overview (accessed Oct 29, 2026).

100. Microsoft Learn, “What is Azure Arc-enabled VMware vSphere?,” “How does it work?” and “Supported scenarios,” https://learn.microsoft.com/azure/azure-arc/vmware-vsphere/overview (accessed Oct 29, 2026).

101. Microsoft Learn, “Retirement of Azure Arc-enabled System Center Virtual Machine Manager,” https://learn.microsoft.com/azure/azure-arc/system-center-virtual-machine-manager/transition-guidance (accessed Oct 29, 2026).

102. Microsoft Learn, “What is Multicloud connector enabled by Azure Arc?,” supported solutions and “Supported regions,” https://learn.microsoft.com/azure/azure-arc/multicloud-connector/overview (accessed Oct 29, 2026).

103. Microsoft Learn, “Choosing the right Azure Arc service for machines,” “General recommendations” and “Azure Local,” https://learn.microsoft.com/azure/azure-arc/choose-service (accessed Oct 29, 2026).

104. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

105. Microsoft Learn, “What is Azure Arc-enabled Kubernetes?,” “Supported Kubernetes distributions,” https://learn.microsoft.com/azure/azure-arc/kubernetes/overview (accessed Oct 29, 2026).

106. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

107. Microsoft Learn, “Connected Machine agent prerequisites,” “Supported environments,” “Supported operating systems” (including the Windows Server 2012 ESU note), “Operating systems no longer supported by new agent versions,” “Azure Connected Machine Agent OS support and deprecation,” “Arm64 architecture support” and “Client operating systems,” https://learn.microsoft.com/azure/azure-arc/servers/prerequisites (accessed Nov 9, 2026).

108. Microsoft Learn, “Microsoft Defender for Endpoint device discovery overview,” “Discovered assets” and “Discovery modes and scans,” https://learn.microsoft.com/defender-endpoint/device-discovery (accessed Oct 29, 2026).

109. Microsoft Learn, “Frequently asked questions about Microsoft Entra Workload ID,” “What are Workload ID Premium features, and which are free?” (application management policies free; access reviews of service principals in privileged roles, and app health recommendations, Premium) and “How many licenses do I need?” (access reviews cover service principals assigned to privileged roles, including managed identities; P2 for reviewers, Workload ID Premium for the reviewed service principals), https://learn.microsoft.com/entra/workload-id/workload-identities-faqs (accessed Oct 29, 2026).

110. Microsoft Learn, “Configure restrictions on how applications can be configured” (application management policies: block password addition, restrict password and certificate lifetimes, tenant-wide default with exceptions; Security Administrator plus Cloud Application Administrator or Application Administrator), https://learn.microsoft.com/entra/identity/enterprise-apps/configure-app-management-policies (accessed Oct 29, 2026).

111. Microsoft Learn, “Frequently asked questions about Microsoft Entra Workload ID,” “What are Workload ID Premium features, and which are free?” (application management policies free; access reviews of service principals in privileged roles, and app health recommendations, Premium) and “How many licenses do I need?” (access reviews cover service principals assigned to privileged roles, including managed identities; P2 for reviewers, Workload ID Premium for the reviewed service principals), https://learn.microsoft.com/entra/workload-id/workload-identities-faqs (accessed Oct 29, 2026).

112. Microsoft Learn, “Frequently asked questions about Microsoft Entra Workload ID,” “What are Workload ID Premium features, and which are free?” (application management policies free; access reviews of service principals in privileged roles, and app health recommendations, Premium) and “How many licenses do I need?” (access reviews cover service principals assigned to privileged roles, including managed identities; P2 for reviewers, Workload ID Premium for the reviewed service principals), https://learn.microsoft.com/entra/workload-id/workload-identities-faqs (accessed Oct 29, 2026).

113. Microsoft Learn, “Conditional Access for workload identities” (single-tenant service principals; group assignment not enforced; block only; managed identities not covered; Workload ID Premium), https://learn.microsoft.com/entra/identity/conditional-access/workload-identity (accessed Oct 29, 2026).

114. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

115. Microsoft Learn, “What are custom security attributes in Microsoft Entra ID?” (supported objects; comparison with extensions; roles; limits), https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview (accessed Oct 29, 2026).

116. Microsoft Learn, “Conditional Access: Filter for applications” (custom security attributes on service principals; evaluated at token issuance; string type only), https://learn.microsoft.com/entra/identity/conditional-access/concept-filter-for-applications (accessed Oct 29, 2026).

117. Microsoft Learn, “What is Azure attribute-based access control (Azure ABAC)?,” “Where can conditions be added?” (role assignments with blob storage or queue storage data actions) and “Status of condition features” (custom security attributes on a principal, GA November 2023), https://learn.microsoft.com/azure/role-based-access-control/conditions-overview; and “Azure role assignment condition format and syntax,” Attributes (@Principal is a custom security attribute on a user or service principal), https://learn.microsoft.com/azure/role-based-access-control/conditions-format (both accessed Oct 29, 2026).

118. Microsoft Learn, “Manage users and groups assignment to an application” (app roles; group-based assignment needs P1 or P2; no cascade to nested groups), https://learn.microsoft.com/entra/identity/enterprise-apps/assign-user-or-group-access-portal (accessed Oct 29, 2026).

119. Microsoft Learn, “Conditional Access for workload identities” (single-tenant service principals; group assignment not enforced; block only; managed identities not covered; Workload ID Premium), https://learn.microsoft.com/entra/identity/conditional-access/workload-identity (accessed Oct 29, 2026).

120. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

121. Microsoft Learn, “API-driven inbound provisioning concepts” (provisioning to on-premises AD for hybrid users or to Entra ID for cloud-only users; one endpoint per provisioning app; throttling and daily limits; license requirements), https://learn.microsoft.com/entra/identity/app-provisioning/inbound-provisioning-api-concepts (accessed Oct 29, 2026).

122. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

123. Microsoft Learn, “What are custom security attributes in Microsoft Entra ID?” (supported objects; comparison with extensions; roles; limits), https://learn.microsoft.com/entra/fundamentals/custom-security-attributes-overview (accessed Oct 29, 2026).

124. Microsoft Learn, “Archive for Microsoft Entra releases and announcements,” June 2025 (“API-driven provisioning is now generally available in US Gov cloud”; “Provision custom security attributes from HR sources,” including API-driven provisioning) and August 2024 (“Configure Lifecycle Workflow Scope Using Custom Security Attributes”), https://learn.microsoft.com/entra/fundamentals/whats-new-archive (accessed Oct 29, 2026).

125. Microsoft Learn, “Mapping to the certificateUserIds attribute in Microsoft Entra ID” (limits; patterns; roles for cloud-only and synced users; Graph update; Entra Connect sync from altSecurityIdentities; hygiene), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-certificateuserids (accessed Oct 29, 2026).

126. Microsoft Learn, “Update device,” Microsoft Graph v1.0 (permissions; Intune Administrator as least-privileged delegated role; app-only and non-Windows calls update only extensionAttributes; Example 2, write extensionAttributes), https://learn.microsoft.com/graph/api/device-update?view=graph-rest-1.0 (accessed Oct 29, 2026).

127. 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).

128. 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).

129. 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).

130. Microsoft Learn, “azcmagent connect,” Flags (--tags), https://learn.microsoft.com/azure/azure-arc/servers/azcmagent-connect (accessed Oct 29, 2026).

131. Microsoft Learn, “Assign policy definitions for tag compliance” (Inherit a tag from the resource group if missing, modify effect, remediation of existing resources), https://learn.microsoft.com/azure/azure-resource-manager/management/tag-policies (accessed Oct 29, 2026).

132. Microsoft Learn, “Conditional Access: Filter for applications” (custom security attributes on service principals; evaluated at token issuance; string type only), https://learn.microsoft.com/entra/identity/conditional-access/concept-filter-for-applications (accessed Oct 29, 2026).

133. Microsoft Learn, “What is Azure attribute-based access control (Azure ABAC)?,” “Where can conditions be added?” (role assignments with blob storage or queue storage data actions) and “Status of condition features” (custom security attributes on a principal, GA November 2023), https://learn.microsoft.com/azure/role-based-access-control/conditions-overview; and “Azure role assignment condition format and syntax,” Attributes (@Principal is a custom security attribute on a user or service principal), https://learn.microsoft.com/azure/role-based-access-control/conditions-format (both accessed Oct 29, 2026).

134. Microsoft Learn, “Conditional Access for workload identities” (single-tenant service principals; group assignment not enforced; block only; managed identities not covered; Workload ID Premium), https://learn.microsoft.com/entra/identity/conditional-access/workload-identity (accessed Oct 29, 2026).

135. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts,” “Username binding policy” (default binding; fields, user attributes and affinity; required affinity binding and custom rules; multiple bindings), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Oct 29, 2026).

136. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts,” “Username binding policy” (default binding; fields, user attributes and affinity; required affinity binding and custom rules; multiple bindings), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Oct 29, 2026).

137. Microsoft Learn, “Microsoft Entra certificate-based authentication technical concepts,” “Username binding policy” (default binding; fields, user attributes and affinity; required affinity binding and custom rules; multiple bindings), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-technical-deep-dive (accessed Oct 29, 2026).

138. Microsoft Learn, “Set up Microsoft Entra certificate-based authentication,” Steps 3 to 5 (default single-factor protection level and low affinity; rules by issuer and policy OID; tenant-wide affinity lockout warning), https://learn.microsoft.com/entra/identity/authentication/how-to-certificate-based-authentication (accessed Oct 29, 2026).

139. Microsoft Learn, “Mapping to the certificateUserIds attribute in Microsoft Entra ID” (limits; patterns; roles for cloud-only and synced users; Graph update; Entra Connect sync from altSecurityIdentities; hygiene), https://learn.microsoft.com/entra/identity/authentication/concept-certificate-based-authentication-certificateuserids (accessed Oct 29, 2026).

140. Microsoft Learn, “Conditional Access authentication strengths,” “Built-in and custom authentication strengths,” https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strengths (accessed Oct 29, 2026).

141. Microsoft Learn, “Set up Microsoft Entra certificate-based authentication,” Steps 3 to 5 (default single-factor protection level and low affinity; rules by issuer and policy OID; tenant-wide affinity lockout warning), https://learn.microsoft.com/entra/identity/authentication/how-to-certificate-based-authentication (accessed Oct 29, 2026).

142. Microsoft Learn, “Meet multifactor authentication requirements of memorandum 22-09,” “Phishing-resistant methods” (Entra certificate authentication, including CAC, PIV and derived PIV credentials), https://learn.microsoft.com/entra/standards/memo-22-09-multi-factor-authentication (accessed Oct 29, 2026).

143. National Institute of Standards and Technology, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, §2.9.1, §2.9.4 and §2.10.2 (§2.9.4: termination when a contractor changes positions and no longer needs access; if the card can’t be collected, termination procedures completed within 18 hours of notification), https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf, accessed October 29, 2026.

144. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

145. Microsoft Learn, “Configure dynamic membership groups with the memberOf operator in the Entra Admin Center (preview)” (preview ended November 3, 2026), https://learn.microsoft.com/entra/identity/users/groups-dynamic-rule-member-of (accessed Oct 29, 2026).

146. Microsoft Learn, “Understand and manage dynamic group processing in Microsoft Entra ID” (processing time; pausing groups for more than 500 groups or 20,000 membership changes; wait at least 24 hours), https://learn.microsoft.com/entra/identity/users/manage-dynamic-group (accessed Oct 29, 2026).

147. Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group latency; assignment filters on user groups or All devices for time-sensitive scenarios), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026).

148. Microsoft Learn, “Manage users or devices for an administrative unit with rules for dynamic membership groups,” Prerequisites (global Azure cloud only; P1 for each unit administrator and member), https://learn.microsoft.com/entra/identity/role-based-access-control/admin-units-members-dynamic (accessed Oct 29, 2026).

149. Microsoft Learn, “Lifecycle Workflows task extensibility” (custom task extensions calling Azure Logic Apps; launch and continue, or launch and wait for a response), https://learn.microsoft.com/entra/id-governance/lifecycle-workflow-extensibility (accessed Oct 29, 2026).

150. Microsoft Learn, “Understanding lifecycle workflows” (scheduling switched on per workflow; on-demand runs ignore execution conditions; three-day catch-up, not for Time based attribute V2), https://learn.microsoft.com/entra/id-governance/understanding-lifecycle-workflows (accessed Oct 29, 2026).

151. Microsoft Learn, “Plan a Lifecycle Workflow deployment,” “Limitations and constraints” (100 workflows per tenant; on-demand runs of at most 10 users; schedule every 3 hours by default, 1 to 24 hours), https://learn.microsoft.com/entra/id-governance/lifecycle-workflows-deployment (accessed Oct 29, 2026).

152. Microsoft Learn, “What are lifecycle workflows?” (license requirements; up to 100 workflows and 100 custom task extensions), https://learn.microsoft.com/entra/id-governance/what-are-lifecycle-workflows (accessed Oct 29, 2026).

153. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

154. Microsoft Learn, “What are lifecycle workflows?” (license requirements; up to 100 workflows and 100 custom task extensions), https://learn.microsoft.com/entra/id-governance/what-are-lifecycle-workflows (accessed Oct 29, 2026).

155. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

156. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

157. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

158. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

159. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

160. Microsoft Learn, “Plan a Lifecycle Workflow deployment,” “Limitations and constraints” (100 workflows per tenant; on-demand runs of at most 10 users; schedule every 3 hours by default, 1 to 24 hours), https://learn.microsoft.com/entra/id-governance/lifecycle-workflows-deployment (accessed Oct 29, 2026).

161. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

162. Microsoft Learn, “Understanding lifecycle workflows” (scheduling switched on per workflow; on-demand runs ignore execution conditions; three-day catch-up, not for Time based attribute V2), https://learn.microsoft.com/entra/id-governance/understanding-lifecycle-workflows (accessed Oct 29, 2026).

163. Microsoft Learn, “Configure execution limits and quarantine for lifecycle workflows” (percentage, count or both; quarantine pending administrator approval; on-demand runs not subject to limits), https://learn.microsoft.com/entra/id-governance/lifecycle-workflow-execution-limits (accessed Oct 29, 2026).

164. Microsoft Learn, “Understanding lifecycle workflows” (scheduling switched on per workflow; on-demand runs ignore execution conditions; three-day catch-up, not for Time based attribute V2), https://learn.microsoft.com/entra/id-governance/understanding-lifecycle-workflows (accessed Oct 29, 2026).

165. Microsoft Learn, “Lifecycle Workflows versioning” (changing tasks or execution conditions creates a new version), https://learn.microsoft.com/entra/id-governance/lifecycle-workflow-versioning (accessed Oct 29, 2026).

166. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

167. Microsoft Learn, “Plan a Lifecycle Workflow deployment,” “Limitations and constraints” (100 workflows per tenant; on-demand runs of at most 10 users; schedule every 3 hours by default, 1 to 24 hours), https://learn.microsoft.com/entra/id-governance/lifecycle-workflows-deployment (accessed Oct 29, 2026).

168. Microsoft Learn, “Microsoft Entra ID Governance service limits,” “Lifecycle Workflows” (100 workflows, 25 tasks per workflow, 100 custom task extensions, offsetInDays -180 to 180, schedule 1-24 hours, 10 users per on-demand selection, custom task extension timeout 30 minutes to 3 hours, 5 administrative scopes) and the note that limits can be increased through Microsoft Support, https://learn.microsoft.com/entra/id-governance/governance-service-limits (accessed Oct 29, 2026).

169. Microsoft Learn, “Transfer user Source of Authority (SOA) to Microsoft Entra ID,” “Prerequisites for transferring user SOA,” https://learn.microsoft.com/entra/identity/hybrid/user-source-of-authority-overview (accessed Oct 29, 2026).

170. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

171. 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).

172. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

173. Microsoft Learn, “Understand and manage dynamic group processing in Microsoft Entra ID” (processing time; pausing groups for more than 500 groups or 20,000 membership changes; wait at least 24 hours), https://learn.microsoft.com/entra/identity/users/manage-dynamic-group (accessed Oct 29, 2026).

174. Microsoft Learn, “Assign or unassign licenses to a group in the Microsoft 365 admin center,” “Move users between licensed groups” (a user removed from the source group first is unlicensed until processing finishes; in large tenants the gap can last longer than expected) and “Before you begin” (no nested groups), https://learn.microsoft.com/entra/fundamentals/concept-group-based-licensing (accessed Oct 29, 2026).

175. Microsoft Learn, “Delete or restore user mailboxes in Exchange Online,” “License removal” (Exchange Online data held for 30 days after the license is removed; adding the license back in that period restores access), https://learn.microsoft.com/exchange/recipients-in-exchange-online/delete-or-restore-mailboxes (accessed Oct 29, 2026).

176. Microsoft Learn, “Get Started with Delicensing Resiliency in Exchange Online,” “What is Exchange Online Delicensing Resiliency,” https://learn.microsoft.com/exchange/recipients-in-exchange-online/manage-user-mailboxes/exchange-online-delicensing-resiliency (accessed Oct 29, 2026).

177. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

178. Microsoft Learn, “Update device,” Microsoft Graph v1.0 (permissions; Intune Administrator as least-privileged delegated role; app-only and non-Windows calls update only extensionAttributes; Example 2, write extensionAttributes), https://learn.microsoft.com/graph/api/device-update?view=graph-rest-1.0 (accessed Oct 29, 2026).

179. 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).

180. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

181. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

182. Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group latency; assignment filters on user groups or All devices for time-sensitive scenarios), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026).

183. Microsoft Learn, “Microsoft Entra device management FAQ,” “Why do I see a duplicate Microsoft Entra registered record for my Windows 10/11 Microsoft Entra hybrid joined device in the Microsoft Entra devices list?” (dual state can result in nondeterministic evaluation), https://learn.microsoft.com/entra/identity/devices/faq (accessed Oct 29, 2026).

184. Microsoft Learn, “Device cleanup rules” (hide devices that haven’t checked in for 30 to 270 days; no action on the device; hidden devices aren’t removed from Microsoft Entra ID), https://learn.microsoft.com/intune/governance/configure-cleanup-rules (accessed Oct 29, 2026).

185. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

186. 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).

187. Microsoft Learn, “Plan your Microsoft Entra hybrid join implementation,” “Handling devices with Microsoft Entra registered state” (Windows 10 1803 and later clean up the registered state; the BlockAADWorkplaceJoin registry value), https://learn.microsoft.com/entra/identity/devices/hybrid-join-plan (accessed Oct 29, 2026).

188. Microsoft Learn, “Assign policies in Microsoft Intune” (user groups versus device groups; dynamic device group latency; assignment filters on user groups or All devices for time-sensitive scenarios), https://learn.microsoft.com/intune/device-configuration/assign-device-profile (accessed Oct 29, 2026).

189. Microsoft Learn, “Manage rules for dynamic membership groups in Microsoft Entra ID” (supported user properties; device rules can reference only device attributes, not the user attributes of the device owner; multi-value extension properties not supported), https://learn.microsoft.com/entra/identity/users/groups-dynamic-membership (accessed Oct 29, 2026).

190. 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).

191. Microsoft Learn, “Understand and manage dynamic group processing in Microsoft Entra ID” (processing time; pausing groups for more than 500 groups or 20,000 membership changes; wait at least 24 hours), https://learn.microsoft.com/entra/identity/users/manage-dynamic-group (accessed Oct 29, 2026).

192. National Institute of Standards and Technology, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 (updated December 10, 2020; Release 5.2.0, August 27, 2025), https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (accessed Oct 20, 2026, as verified in Book 02 Appendix A and Book 03 Chapter 11).

193. Office of Management and Budget, M-19-17, Enabling Mission Delivery through Improved Identity, Credential, and Access Management, May 21, 2019, https://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf (accessed Oct 20, 2026, as verified in Book 03 Chapter 02).

194. General Services Administration, IDManagement.gov, Identity Lifecycle Management Playbook (Executive Summary; the disclaimer states it “is not official policy”), https://www.idmanagement.gov/playbooks/ilm/ (accessed Oct 20, 2026, as verified in Book 03 Chapter 02).

195. Office of Management and Budget and Office of Personnel Management, Creating “Federal HR 2.0” by Consolidating Core Human Capital Management Across the Federal Government, December 10, 2025, p. 1 and §I, https://www.opm.gov/chcoc/latest-memos/creating-federal-hr-20-by-consolidating-core-human-capital-management-across-the-federal-government.pdf (accessed Oct 20, 2026, as verified in Book 03 Chapters 01 and 03).

196. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, §III and §III.A–E, https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (accessed Oct 21, 2026, as verified in Book 01 Appendix A).

197. National Institute of Standards and Technology, FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022, §2.9.1, §2.9.4 and §2.10.2 (§2.9.4: termination when a contractor changes positions and no longer needs access; if the card can’t be collected, termination procedures completed within 18 hours of notification), https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf, accessed October 29, 2026.

198. National Institute of Standards and Technology, SP 800-63-4, Digital Identity Guidelines, July 2025, https://csrc.nist.gov/pubs/sp/800/63/4/final (accessed Oct 21, 2026, as verified in Book 01 Appendix A and Book 03 Chapter 09).

199. Cybersecurity and Infrastructure Security Agency, BOD 25-01, Implementing Secure Practices for Cloud Services, December 17, 2024, https://www.cisa.gov/news-events/directives/bod-25-01-implementing-secure-practices-cloud-services, and “BOD 25-01: Implementing Secure Practices for Cloud Services Required Configurations,” https://www.cisa.gov/resources-tools/services/bod-25-01-implementing-secure-practices-cloud-services-required-configurations (both accessed Oct 20, 2026, as verified in Book 02 Appendix A).

200. Office of Management and Budget, M-22-09, Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022, §III and §III.A–E, https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf (accessed Oct 21, 2026, as verified in Book 01 Appendix A).

201. Office of Management and Budget, M-25-21, Accelerating Federal Use of AI through Innovation, Governance, and Public Trust, April 3, 2025, Sections 3(b) and 4(a)–(b), https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf (accessed Oct 21, 2026, as verified in Book 17 Appendix A).

202. Office of Management and Budget, M-26-14, Ensuring Effective and Efficient Agency Logging and Network Visibility to Defend Against Evolving Cyber Threats, May 22, 2026, https://www.whitehouse.gov/wp-content/uploads/2026/05/M-26-14-Ensuring-Effective-and-Efficient-Agency-Logging-and-Network-Visibility-to-Defend-Against-Evolving-Cyber-Threats.pdf (accessed Oct 21, 2026, as verified in Book 01 Appendix A).

203. Microsoft Learn, “Plan for Microsoft 365 Government - GCC deployments” (GCC “provides compliance with US government requirements for cloud services, including FedRAMP Moderate”), https://learn.microsoft.com/microsoftteams/plan-for-government-gcc (accessed Oct 20, 2026, as verified in Book 03 Chapter 01).