What's New

This page summarizes significant changes between releases. If you've read a previous version and want to know what to revisit, start here.

Unreleased

Significant Updates

8-6: "Guests Cannot Register Passkeys in Your Tenant" (new section), with a phishing-resistant variant of G001 in Chapter 9 and a cross-reference from 8-2. Microsoft lists it as a known issue: passkey (FIDO2) registration isn't supported for internal or external guest users, including B2B collaboration users in the resource tenant. The section states what follows: where a guest completes MFA is decided by the Trust multifactor authentication from Microsoft Entra tenants setting, and only the home-tenant path accepts FIDO2, Windows Hello for Business, and certificate-based claims; the resource-tenant path accepts SMS, voice, Authenticator push, and OATH software token only, so a phishing-resistant strength on guests with trust off is unsatisfiable and reads as "passkeys don't work for guests." The partner's tenant has to issue the passkey; strengths apply only to Entra-authenticated guests (email one-time passcode, SAML/WS-Fed, Google, and personal account guests stay on the MFA grant); a local account helps only as a Member. The trust setting's description in 8-6 previously called it a re-registration convenience.
11-3: "Stage 4: Join the Device" (new stage); the checklist never actually joined the device. The Entra Join checklist went from tenant configuration (Stage 3) straight to verification "once the device is joined" without a stage that performs the join. The new Stage 4 lists the device-side preconditions (a supported edition, no prior domain or tenant join, a corporate designation in place before the join when personal devices are blocked, a licensed user in the MDM scope who can satisfy the register-or-join MFA policy, line of sight to both DRS hostnames), then the three documented paths: OOBE Set up for work or school, the Settings app Join this device to Microsoft Entra ID link (with the warning that the email box above it performs a registration, not a join), and the bulk provisioning package. It states the rule that a failed enrollment rolls the join back, and what the join leaves behind (a standard user; LAPS for admin access). Verification is now Stage 5 with its anchor unchanged; the AVD runbook and the 12-9 tenant-move procedure now cite Stage 5, and the tenant-move text is corrected: an undesignated device does not "join while enrollment is silently refused," the join rolls back with an enrollment error. Stage 3 also gained the Disable MDM enrollment when adding work or school account toggle (leave Off; it governs only the BYOD Edge and Teams account-add prompt on Entra registered devices) and its MDM URL list now follows the blade's order, with the Hybrid Stage 6 and Autopilot cross-references sending readers to the sovereign URL check as well.
12-2: "New Entra-joined device: the golden path" (new section), and the join chapters now hand off to Defender. The per-device path from bare hardware to a fully configured, compliant, sensor-onboarded machine was spread across seven chapters with no reading order; 12-2 § Enrollment Methods now opens with a nine-step table (four tenant steps done once, five per device) giving each step its done-when test and its chapter. Entra Join Stage 5 and Hybrid Stage 6 both gained a closing "security onboarding landed" verification item: the Layer 1 EDR policy onboards the device to Defender for Endpoint and, by the same act, Purview Endpoint DLP, so a join is not finished until the sensor is Onboarded. Hybrid Stage 6 also gained the ordering warning that Defender onboarding must follow hybrid join (the Intune path is safe by construction; a GPO or script onboarding in the same policy cycle mints a synthetic Entra object and breaks device-based Conditional Access with AADSTS53001/53000, gated by 12-6 Path B), and its unexplained "Managed by MDE means enrollment failed" line now names the synthetic-registration cause and links the cleanup. 12-4 row 15 and 12-6 Step 2 now cross-reference each other: the manually created Win - Custom - ES - Defender for Endpoint Onboarding policy is the 12-6 EDR onboarding procedure, and OIB compliance row 18 depends on it. Appendix E Stage 3 now enables the Intune connector before creating that policy (its Auto from connector package type has nothing to pull otherwise); Stage 4 verifies rather than enables.
12-6, 14-3, 13-3: Endpoint DLP device onboarding, which the book had never described. The DLP chapter defined device policies and the Compliance Manager checklists said "Enable Endpoint DLP on managed Windows devices," but nothing explained how a device becomes an Endpoint DLP location. New 12-6 § Endpoint DLP Uses the Same Onboarding states the mechanism Microsoft documents: device onboarding is one thing shared by Defender for Endpoint and Purview, so every MDE-onboarded device is already onboarded for Endpoint DLP and insider risk, and the remaining work is one tenant switch (Purview Settings > Device onboarding > Devices > Turn on device onboarding, with the GCC High portal) plus a per-device confirmation: the three status reads (listed at all, Configuration status, Policy sync status, including that Not available is the expected sync value until the first device-scoped policy exists), the details-pane attributes, the DeviceInfo.DlpInfo advanced-hunting alternative, the on-device signals, and what onboarding does not give you (per-user licensing, Edge-native browser enforcement, the opt-in server toggle, the shared MDE connectivity URL set). 14-3 § Endpoint DLP gained a prerequisites checklist ahead of the policy table and its workload column now says Devices (onboarded) rather than Devices (Intune-enrolled), since Intune enrollment is not what onboards a device. The 13-3 checklists and the 12-9 tenant-move procedure link to the new section.
12-6, 12-9, 12-2: Defender for Endpoint offboarding was missing from every tear-down and retirement procedure in the book. New 12-6 § Offboarding is the single home for the mechanics: the portal path, the deployment methods (Defender deployment tool for single devices, Intune EDR policy with package type Offboard, the custom OMA-URI, GPO, ConfigMgr, and the legacy local script where the portal still offers it), the short package expiry (three days per the portal help text, seven per Learn; the date is in the filename), disable-not-uninstall semantics and the normal seven-day drift to Inactive, the never-co-deploy rule, and the Event ID 70 tell that a package came from the wrong tenant. The 12-9 Hybrid and Entra Joined tear-down procedures (now ten and seven steps; headings keep their original anchors), the 12-9 Pre-Imaging Checklist, and the 12-2 Device Retirement steps all offboard Defender first, matching the retirement order the book already asserted elsewhere. New 12-9 § Moving a Device to Another Tenant covers what the wedge procedures don't: a Prepare block that has to happen before either tenant is touched (confirm the sensor is actually onboarded, export the BitLocker recovery key, create and test an offline local administrator, copy out the old profile), then the old-tenant cleanup order with the reasons (Intune before Autopilot is Microsoft's documented sequence; Autopilot before Entra is the inversion that resurrects the deleted object), the offline-local-admin disconnect, profile non-portability across tenants, and (GCC High edition) the sovereign portal, connectivity, MDM-URL, and connector differences for a commercial-to-GCC High move. Two facts surfaced by a live move are now stated where they bite: Microsoft documents that retiring or deleting the Intune object of an Entra-joined BitLocker device removes key protectors and suspends BitLocker on the OS volume, and the redesigned Intune device page moves Retire into the Remove data dropdown while Delete alone also initiates a Retire. A matching field note records the offboarding symptom.
Chapter 9: "The Registration Bootstrap: Why TAP Lives in the Resource Strength" (new section). Explains why the catalog's TAP-in-strength design is the tested answer to the passkey bootstrap problem, not an accident. Microsoft documents an interrupt-mode preference rule (a strength on the Register security information user action is preferred over All-resources strengths), but in December 2025 field testing the registration flow escaped the user-action context and was re-evaluated against the All-resources strength, recreating the deadlock; Jan Bakker independently documented the same behavior, the exclusion workarounds it forces, and the failure of attested Authenticator passkey registration under them. The section states the model's deliberate costs (an issued TAP opens resources, so TAP issuers are governed by the RMAU runbook; an in-scope user cannot register a first passkey with push MFA, so rollouts sequence registration before enforcement scope and TAP issuance is the steady-state budget), the defensive upside (a phished push session cannot enroll an attacker's passkey), the registration-surface mitigations (B006, registration alerting), and the platform watch items: the new account recovery flow composes with the model, the recovery-specific user action has not shipped, and registration-policy machinery changed July 6, 2026 (WHfB and macOS Platform SSO enrollment now evaluate registration-targeting policies), so re-test before building on the user-action pattern in either direction.
11-4 (Hybrid Deployment): the architecture section now names its mechanisms. The WHfB GPO paragraph explains the cloud Kerberos trust provisioning prerequisite check (partial TGT at sign-in proving Entra Kerberos is deployed), notes the one interactive MFA step during provisioning (registered method or Temporary Access Pass required once), and links the PRT MFA-claim documentation that makes silent Intune enrollment work. The enrollment GPO paragraph names the policy setting (Enable automatic MDM enrollment using default Microsoft Entra credentials), the User Credential requirement (Device Credential is ConfigMgr co-management and AVD multi-session only), and the five-minute retry task. The Conditional Access section now answers the ordering question directly: order matters at runtime, not at GPO deployment time, and a mis-ordered rollout costs time, not state.
11-5: WHfB policy precedence corrected: GPO beats CSP, and MDMWinsOverGP cannot flip it. The chapter previously said Intune wins over GPO for WHfB once the co-management Device Configuration workload switches. Microsoft documents the opposite: WHfB settings live in the PassportForWork CSP, a GPO-configured setting takes precedence, the conflicting CSP value is not applied until the GPO setting is cleared, and MDMWinsOverGP covers only the Policy CSP. The co-management conflict section is rewritten around the real migration consequence: moving a WHfB setting to Intune does nothing while the GPO still sets it, so retire the GPO setting first, and the "GPO to bootstrap, Intune to govern" split works precisely because the two sources never configure the same setting.
11-5: security info registration URL now shows the sovereign variant. The Missing MFA Registration blocker pointed all readers at mysignins.microsoft.com; the GCC High edition now carries mysignins.azure.us.
11-7 correctness fix: label priority direction was inverted. The enclave chapter told readers to place CUI - AVD "at or near the top of the label priority order" so the library default wins; the Purview Labels list displays lowest-priority-first, so the top is priority 0 and the instruction as written made the label lose every override decision. Rewritten to state the direction explicitly (higher priority number = toward the bottom of the list) with the documented reorder mechanics (priority options, not drag).
14-2: the label-vs-DLP priority reversal now stated out loud. New warning callout ahead of the taxonomy tables: for sensitivity labels a higher priority number means more sensitive (wins inheritance and override; most restrictive label sits at the bottom of the portal list), while DLP policies evaluate lowest-number-first with 0 as the highest priority; cross-linked to 14-3's Policy Priority and Execution Order. The book used both Priority columns without ever defining either convention, and they run in opposite directions.
14-6 (CAB runbook): validation warning: test DLP blocking with a second account. The SharePoint/OneDrive block action exempts the content owner, last modifier, and site admins by design (the wizard label says so; they are the remediation path), so a validator testing their own upload, or any site admin, sees no blocking and concludes the policy is broken (field-verified with a client team, September 2026). New admonition at the top of the Validation Plan: verify blocked-access expectations with an account holding none of the three roles, for whom the file is trimmed from the library entirely; notes that the permission change survives policy deletion and that quarantine (preview) is the action that removes even the owner's access.
Chapter-internal "Phases" renamed to "Stages" book-wide, numbered from 1. Chapter section headings labeled "Phase N" collided with the book's part names in the left navigation (a reader conflated the hybrid chapter's "Phase 5: Intune Enrollment" with the nav's "Phase 5: Microsoft 365 Security"). The vocabulary is now reserved: Phase = book part, Stage = chapter checklist or timeline section, Step = atomic action. Renamed in 11-3 and 11-4 (deployment checklists), 11-6 (AVD build), 12-9 (device hygiene), 12-10 (GPO migration timeline), 14-2 (label rollout), 14-6 (CAB runbook, Stages A/B; its "Phase 2 submission" language became "follow-up submission"), and Appendices D.2 and E (engagement timelines). Every renamed heading carries an explicit anchor so future renames stop breaking links; client deliverables and historical release notes keep their original wording.
11-3: "Stage 1: Tenant Device Settings" (new canonical section). The Entra ID > Devices > Device settings blade now has one authoritative walkthrough: all nine settings in portal order, grouped as the portal groups them, each with a recommended value, the join types it actually gates, and the mechanism behind it (the join-time local-admin Graph defaults, the Intune lock on Users may register, the CA-user-action alternative to the MFA toggle, LAPS activation vs. rotation policy, owner-based BitLocker self-recovery). The Autopilot chapter, the Hybrid chapter, and the AVD runbook now reference this section instead of restating fragments; the runbook keeps only its AVD-specific constraints. The hybrid chapter states explicitly which rows do not gate a userless Entra Connect registration.
11-3/11-6 flag: Microsoft documents Entra-joined Azure VMs as exempt from "Users may join." The AVD chapters treat All as required for session-host provisioning; current Microsoft documentation says the setting does not apply to userless joins including the AADLoginForWindows extension. The new section carries a warning holding the All-plus-compensating-controls doctrine until a lab retest settles it. TODO before release: lab-test whether "Users may join devices to Microsoft Entra" actually gates the AADLoginForWindows Azure VM join (set Selected, provision a session host, watch the extension). If the documented exemption holds, retire the compensating-controls narrative in 11-6 and relax the runbook prerequisite; if it does not, remove the exemption language from the 11-3 warning and record the field result.
11-4: ten field anomalies from a GCC High hybrid-join deployment folded into the stages. Stage 3 now tabs the enterpriseregistration CNAME by cloud (sovereign enterpriseregistration.microsoftonline.us field-verified for GCC High; both DRS hostnames must be reachable in US Government clouds regardless of the CNAME target). Stage 4 gains the arrives-Disabled check on the Automatic-Device-Join task, and the step E "device not found" path (0x801c03f3): the documented wait-for-sync resolution, plus the field-verified unwedge when a stale Entra-registered record keeps the synced object from ever appearing (delete the record, force a delta sync, re-run the task). Stage 5 documents that WHfB provisioning never launches over Remote Desktop and the PRT bootstrap for RDP-only VMs: an interactive MFA sign-in in a WAM-brokered app (classic Outlook) stamps the MFA claim, letting the enrollment task succeed without WHfB. Stage 6 records the enrollment task's five-minutes-for-one-day schedule, that the task vanishing is the success signal (Event ID 75 is the durable proof, and Task Scheduler's Event 102 fires on failure too), and that the Intune portal device list can lag the actual enrollment by hours. The step E error carries its full signature (0x801c03f3 / error_missing_device) with the out-of-scope-OU cause, and 11-3's Stage 2 CNAME table is tabbed identically so the two deployment paths agree on the sovereign DNS story.
11-4/11-5: two quiet WHfB GPO blockers and one missing click documented. The 11-5 hybrid GPO step now warns that an older Group Policy central store won't show the cloud Kerberos trust setting at all (copy Passport.admx/Passport.adml from a current client) and that an enabled Use certificate for on-premises authentication policy takes precedence over Cloud Kerberos Trust. The 11-4 Stage 6 enrollment GPO checklist now states the User Credential dropdown selection explicitly.

v2026.08.31

New Sections

Field Notes (new page): 23 field-verified failures in GCC High and Azure Government where the official documentation is absent, scattered, or wrong. Organized by symptom rather than subject, because the book is arranged the way you build a tenant and this page is arranged the way you break one. Every entry shares a signature: it fails quietly. Each gives the symptom as you encounter it, the mechanism, and the fix, then links into the chapter that carries the full procedure. Web only; excluded from the printed edition.
8-2: Third-Party MFA Cannot Satisfy an Authentication Strength. External authentication methods (EAM), the GA replacement for Conditional Access custom controls, work only with the Require multifactor authentication grant control. Microsoft's wording is that grant controls based on authentication strengths, including the built-in MFA strength, aren't satisfied by the external MFA method, so no authentication strength is reachable, not merely the phishing-resistant one. Closing a phishing-resistant requirement means migrating the cohort to native FIDO2, Windows Hello for Business, or Entra CBA. Custom controls stop accepting new or edited configurations in September 2026 and retire fully in early 2027.
13-2: Scoping Economics: Drawing the Boundary. New closing section of the asset-inventory chapter arguing the two-cost-curves model: hygiene controls scale with endpoint and user count and belong estate-wide always, while boundary-tier controls (validated-encryption mandates, cloud and vendor assurance, incident-reporting blast radius, the 3.7-3.10 process families, specialized assets) scale with boundary size and are contained deliberately. Covers the label's three distinct jobs (enforce the boundary, keep the system scope honest, prove the negative with Content and Activity Explorer) and the data-diffusion heuristic for choosing between a contained boundary and high-water-mark estate-wide treatment. The two encryption de-scoping debates (encrypted content at rest on out-of-boundary storage, encrypted transit through conduits) appear in the online edition only.

Significant Updates

CMMC Program Currency (July 2026 Suspension)

Chapter 9: What Each Policy Proves. New closing section mapping every policy in the Conditional Access catalog to the NIST 800-171 controls it implements (Rev 2 and Rev 3 side by side, derived from Appendix A, with the Rev 3 withdrawn-control handling stated) and to its primary "Brilliant at the Basics" IT practice. Includes the evidence pairing an assessor expects (exported policy JSON plus the sign-in log filtered to that policy) and the honesty note that the campaign itself ships no evidence standard.
Appendix A: Brilliant at the Basics IT Top 10 crosswalk. Each of the DoW CIO's ten IT practices mapped to where the book implements and evidences it, including two explicit outside-this-book's-scope rows (development lifecycle, workforce readiness) rather than forced mappings.
Chapter 4 (Contract Flow-Downs): the certification gate is paused, the obligations are not. The 7021 discussion now carries a dated callout: on July 13, 2026 the Department of War suspended the CMMC Phase 2 rollout (third-party certification as a condition of covered new awards, originally November 10, 2026) and chartered a Reform Task Force. The callout is explicit about what did not change: DFARS 7012, NIST 800-171 implementation, the SPRS score, and the Affirming Official's False Claims Act-enforced attestation all remain in force, with self-assessments plus selected government-led assessments during the pause. Readers are directed to the clause in each solicitation rather than an assumed regime.
13-2 (Scoping Economics): the hygiene tier now cites the Pentagon's own endorsement. The DoW CIO's "Brilliant at the Basics" campaign, issued alongside the suspension, distills the hygiene tier into voluntary Top 10 practice lists for IT and OT, guidance that applies whether one document is marked or ten thousand.

Chapter 12: Device Operations

12-4: ngen update guidance corrected. The command must run on both the 32-bit and 64-bit paths, since the native image caches are separate and doing one leaves the other invalid. It also stops new 3092 events rather than clearing ones already logged, which matters when you are watching an Advanced Hunting count expecting it to drop.
12-4: policy verification no longer suggests bare Get-Content, which dumps roughly 800 lines of XML with no search. Replaced with a Select-String filter that prints only the rule options.
12-4: OIB ZIP layout updated. The repo's Windows policy set now lives at WINDOWS\IntuneManagement inside the wrapper folder, with five policy-type children (CompliancePolicies, DeviceConfiguration, DriverUpdateProfiles, SettingsCatalog, UpdatePolicies); the navigation steps, Bulk Import path, and no-policies-found troubleshooting rows now match, plus the durable rule for future reorganizations: select the folder whose immediate children are the policy-type folders.
12-4: Bulk Import selects object types, not files. The dialog has no per-file picker, so the Layer 1 scoping instruction was rewritten around what actually works: stage a copy of the policy tree holding only the Layer 1 JSON files and point Import root at it. The procedure also now unchecks Import Assignments, so an import cannot carry an assignment ahead of the required environment modifications.
12-4: Layer 2/3 membership re-sorted against current OIB. OIB has grown to roughly 70 policies, and four that the layer catalog didn't know exist are now sorted: Disable NTLM and the per-rule Windows Firewall Security Rules into Layer 2 (with a caution that Disable NTLM overlaps the LAN Manager Authentication Level setting Layer 1's Local Security Policies already enforces), and Automatic Restart Sign-On plus Endpoint Analytics into Layer 3. OIB's newly shipped WUfB and driver-update rings are cataloged in Layer 2 with a pointer to the 12-10 ring design: adopt one ring structure, not both. Layer counts updated (Layer 2: 41, Layer 3: 12). The Layer 2 heading now carries a stable {#layer-2-defense-in-depth} anchor so inbound links survive future count changes.
OIB version true-up (12-4, 12-6, Appendix B). Current OIB ships Login and Lock Screen, Edge User Experience, and Copilot at v3.8; every pinned name now matches. The v3.8 Login and Lock Screen policy also drops its two Automatic Restart Sign-On settings, which OIB now ships as a separate Windows User Experience policy outside the Layer 1 core; the Appendix B settings snapshot and a note reflect the move.
12-4: ASR audit-first rollout sequence added (Step 8). Import both ASR policies, assign Audit Mode to the full population (it blocks nothing and surfaces what enforcement would break), bake exclusions into the L2 policy, then swap per wave in one change window. Never both at once: they write the same CSP nodes with different values. The Layer 3 Audit Mode row cross-links the sequence, and the pilot-assignment step now points to it.
12-10 restructured around the top-down model it already claimed. The chapter now names the OIB Layer 1 core (12-4) as the canonical target and treats the GPO estate purely as evidence. A new read-only estate assessment script (export-gpo-estate.ps1) exports the per-GPO XMLs plus the link map and inventory that Group Policy analytics discards, since its readiness analysis is settings-only and never sees where a GPO applies. A new disposition analysis section replaces the migrate-by-readiness framing: settings are scope-weighted first (unlinked, disabled, and nowhere-applying GPOs drop without analysis), then bucketed as covered by Layer 1, genuine ORG requirement, obsolete, or out of scope, with a table translating OU links, security filtering, WMI filters, and loopback into Entra groups, assignment filters, and device-versus-user scope. The duplicated Tier 1/2 policy tables are gone in favor of the canonical 12-4 list, portal paths and classification states now match the current documentation, and the import constraints (4 MB per XML, English-only scoring, 20-minute refresh, server-side auto-rescore) are stated. The script listing is generator-emitted from the file of record, like the D.2/D.4 listings.
12-10: co-management workload path corrected. Workload sliders are switched in the Configuration Manager console (Administration > Cloud Services > Cloud Attach > Properties > Workloads), not the Intune admin center as previously stated. Two documented behaviors added: switching Device configuration moves Endpoint Protection and Resource Access with it, and Pilot Intune deploys policies but does not remove them on unassignment.

Appendix B: Intune Baseline Configurations

Ready-to-use logon banner text added to § Local Security Policies. The book previously said "replace with your banner text" and handed the reader nothing. Now it carries a placeholder version of the DoD Notice and Consent Banner adapted for a contractor organization: field-tested wording that has cleared multiple client legal reviews unedited, with the standing caveat that counsel approves before deployment. Linked from the 12-4 control-mapping row that calls for the customization.

Appendix D.2: AVD Firewall Reference

PowerShell Gallery rule corrected, and it was actively broken. It carried psg-prod-eastus.azureedge.net, which Microsoft documents as retired, and omitted cdn.powershellgallery.com entirely. Because discovery and download are different hosts, Install-Module resolved a package version and then failed with Source Location '...' is not valid, which reads as a broken repository rather than a firewall block. Now carries the current host set plus the go.microsoft.com and aka.ms redirection services.
KMS activation row corrected to match the template. The prose table said service tag AzureCloud; the Bicep has always used explicit IPs because the Azure Government KMS endpoints are published under Internet, not AzureCloud. Following the table produced exactly the 0xC004F074 failure the template was written to avoid.
Defender for Endpoint endpoints added: *.securitycenter.microsoft.us (a different namespace from security.microsoft.us, carrying the GCC High MDE API) and us4-v20.events.data.microsoft.com, both documented Required for GCC High and both missing. Plus a field-observed *.securitycenter.windows.us, flagged in place as absent from Microsoft's published lists and marked for re-check.
Algolia DocSearch allowed so operators can search the runbook from inside the enclave, not just browse it. Both *.algolia.net and *.algolianet.com are required: the client resolves a primary host then retries across numbered failover hosts on the second apex.
Bicep CLI endpoint discovered and allowed. az deployment on a session host failed with SSLEOFError UNEXPECTED_EOF_WHILE_READING because the Azure CLI downloads Bicep on first use from downloads.bicep.azure.com, an endpoint absent from Microsoft's documentation, which still routes air-gapped guidance through GitHub. A dedicated Bicep-CLI rule now covers it; Bicep needs no GitHub access and no manual staging.
SmartScreen app-reputation apex added. Launching a downloaded executable checks checkappexec.microsoft.com, served at the apex even though Microsoft documents only the *.checkappexec.microsoft.com wildcard, and Azure Firewall wildcards never match the apex. The block fails open: SmartScreen reports it "can't be reached right now" and offers a Run button, so the deny reads as a service outage while every launch stalls on the firewall timeout.
New section: Azure CLI on a session host. winget fails inside the enclave by design (0x8a15000f, msstore source blocked), and it is the wrong path anyway: the section documents the pinned-version install from the azcliprod distribution endpoints, via MSI or the no-admin ZIP whose az must stay inside its extracted tree.
New section: Acquiring GitHub-distributed admin tools. Some Microsoft tooling ships only from GitHub (the Win32 Content Prep Tool among them). Rather than a standing allowance, the section documents a time-boxed firewall window: the five FQDNs GitHub's download flow needs, opened for the fetch, removed after. Bicep is explicitly not in this category.
The Azure-Administration collection and its adminSubnetAddressSpace parameter were removed. The Azure CLI installer rule now applies to every session-host subnet. The admin-pool gate was not a boundary: ARM, the Azure portal, Graph, and the PowerShell Gallery are all reachable from every session host, so any user could reach Azure management through the browser or Install-Module Az without touching the gated FQDN. Authorization for Azure administration is an Entra RBAC and PIM concern; the firewall is not an identity boundary.

Appendix D.4: AVD East-West Segmentation

Deployment commands extracted to load-nsg.azcli, mirroring load-firewall.azcli. The previous block used bash line continuations and a shell loop, neither of which runs in PowerShell on a Windows host. Now one command per line, no continuations, no loops.

Chapter 17: SIEM Strategy

The eight CMMC evidence queries moved online. KQL is meant to be pasted into a query window, so the printed edition now carries the mapping table, save-dialog settings, and gotchas, with a pointer to the query text online. The mapping table doubling as a client handout is unaffected.

Book-wide

Shell command blocks no longer use bash line continuations. Four az blocks across the runbook and appendices used trailing backslashes and would fail if pasted into PowerShell, including the firewall deployment in runbook Step 2.

v2026.08.03

Major Rewrites

Dual-track rendering pass (Chapters 11, 12, and Appendix B): the device chapters now render as two clean tracks, gated by a pair of scope tags. gcch-only carries the CMMC framing (control IDs, C3PAO and assessor language, sovereign-endpoint caveats) and is what the book and website print. comm-only carries the same technical guidance framed against NIST SP 800-171 Rev. 3, for client deliverables where CMMC is not in scope. The website and the printed book both render the GCC High track; the Commercial track appears only in deliverables built for Commercial engagements, selected per job by the DocRaptor pipeline.

New Sections

Device Management Strategy (11-1): when moving device management to Intune is actually required versus when GPO/MECM remains fine. Hybrid Join is reframed to match: maintained for backward compatibility or where hybrid plus GPO/MECM still meets every need, not merely "legacy."
Endpoint scope and peripheral redirection (11-6): why an out-of-scope endpoint and full in-session productivity (including voice-only Teams) coexist. The dividing line is directionality: data-egress channels (clipboard, drives, USB, printers, COM) are disabled server-side, while inbound channels are ingest-only and no more place the endpoint in scope than typing CUI does. Adds an SC.L2-3.13.12 row to the control-mapping table; the Chapter 10 screen-capture-protection scoping question and an 11-7 cross-link were updated to match.
Why Shared PC Mode, and how to get back out of it (11-8): shared physical devices collapse two concerns onto one endpoint, access control and media sanitization, because the local profile is the media being reused at every sign-out. It also answers the question honestly: Shared PC Mode is not literally required (Autopilot Reset or wipe-on-reboot reach the same outcome), it is just the only built-in option that makes profile cleanup automatic and continuously enforced. A second addition covers the exit path, because the SharedPC CSP tattoos: its registry writes survive un-assigning the policy or un-enrolling the device, so removal is now a first-class procedure with Remove-SharedPCTattoo.ps1 and Restore-SharedPCTattoo.ps1.
Why Intune diagnostics for audit evidence (12-5): why the portal is not enough. It shows current state, which is fine operationally, but audit records, baseline configuration management, and incident reporting all ask questions it cannot answer on demand: the in-product audit log retains a year but is neither queryable nor exportable, Devices > Monitor shows current compliance rather than the timeline of when a device fell out and returned, and "we watch the portal" is not an alerting mechanism. The diagnostic-settings export that follows moves Intune logs into Log Analytics, where each of those answers in KQL under your own retention and alerting control.
Deploying Option B to devices already in service (12-4): the validation sequence for rolling the three-policy (24H2+) local-admin set onto in-service devices. Azure VMs rename the built-in Administrator at provisioning, so find it by SID (Get-LocalUser | Where-Object { $_.SID.Value.EndsWith('-500') }) and put that name in the row-13 policy. Validate one device before assigning row 14; a transient 65000 error on row 13 is expected and self-heals.
AVD East-West Segmentation (new Appendix D.4, summarized in 11-6 § Network Architecture): the Azure Firewall never sees subnet-to-subnet or AVD-to-AVD traffic, so nothing stopped a compromised session host from probing SMB/RDP/WinRM across AVDs or pools. One NSG with a single inbound deny, associated to every session-host subnet, closes it.
Managed by: MDE proves the channel, not a healthy Entra registration (12-6): MDE-channel policy reaches a device through its Entra device object, and two degraded states keep reporting Managed by: MDE while delivering no policy.
1. Registration never completed (SCP or Entra Connect misconfiguration), diagnosed via HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus error codes.
2. Registration completed, then the Entra object was deleted (OU moved out of sync scope, or stale-device cleanup). dsregcmd /status shows AzureAdJoined: YES but DeviceAuthStatus: FAILED and sign-ins fail with AADSTS50155; fix sync scope first, then re-register, because deleted device objects cannot be restored.
In either state only the GPO half and sensor-based assessment still operate, so treat the device as unmanaged for evidence purposes.

Print Edition

Printed table of contents reduced to three levels (Phase → Chapter → Section). The fourth level, generated from every H3, ran to roughly 540 entries and cost 8 to 10 pages of front matter against KDP's 828-page cap. H3 headings keep their anchor IDs so PDF cross-references still resolve, and the online table of contents retains full depth.

Significant Updates

(ordered front-to-back by where each change appears in the book)

Chapter 8: Identity Foundation

8-2 (Phishing-Resistant Auth): a same-hour workaround and a two-field diagnostic for the AAGUID desktop-app limitation. AAGUID-restricted authentication strengths fail on Windows desktop apps because the PRT carries the MFA claim at method level with no field for WebAuthn attestation metadata, so the AAGUID arrives as all zeros. The fix is a grant-control swap to the built-in Phishing-resistant strength, and the sign-in log fingerprint is now two fields: the all-zeros AAGUID plus incomingTokenType (primaryRefreshToken fails, none works). Three things look like fixes and are not: adding AAGUIDs, dropping to Require-MFA, and allowlisting the all-zeros AAGUID itself, which the portal accepts but which would act as a silent wildcard for attestation-absent credentials rather than make-and-model enforcement. Microsoft Support confirmed the limitation in writing (April 2026); it remains absent from public documentation.

Chapter 11: Device Architecture

11-2 (Autopilot): Device Preparation (v2) compared against classic Autopilot (v1) in a new table, with a warning not to mix Entra Join and Hybrid Join profiles: an Entra-joined device given a Hybrid profile tries to reach the Intune Connector for a domain join that cannot succeed, so provisioning fails or lands in an ambiguous join state.
11-3 (Cloud-Only): MDM enrollment URL verification added to the Phase 2 checklist, including the GCC High trap that "Restore default MDM URLs" resets a sovereign tenant to commercial .com endpoints and fails enrollment with 0x80192efd. The 11-3/11-4 callouts were renamed "Critical Cloud Check" because the failure is symmetric: a Commercial device pointing at .us is in the wrong cloud too.

Chapter 12: Device Operations

12-3 (Mobile and Endpoint Security): scope clarified, and the MAM enrollment sequence documented. A new callout states that the chapter covers iOS and Android and points Windows endpoint hardening at Open Intune Baseline Deployment. The enrollment walkthrough covers Workplace Join, Intune App SDK policy pickup on next sign-in, and the 1-to-4-hour (occasionally 24) delay before the user appears in Apps → App protection status.
12-4 (OIB Deployment): App Control for Business promoted from Layer 2 to Layer 1, and clarified as manually created rather than an OIB import (OIB ships no App Control policy and can't, since it is a different policy type entirely). 3.4.8 speaks to software execution, which least privilege plus Discovered-apps monitoring implements only as paperwork, so permit-by-exception execution control is now core baseline; the procedure gained ring-sequenced assignments, the CodeIntegrity 3076/3077 audit-evidence loop with its Advanced Hunting queries, and the post-enforcement assessor evidence set.
12-4: App Control needs a Microsoft-signed base and path rules for what Microsoft's own agents execute (field-diagnosed). Intune's Built-in controls are hard-wired to DefaultWindows, which doesn't authorize the Microsoft software shipping outside the Windows image, so the procedure now builds custom XML on Allow Microsoft Mode in four in-box PowerShell lines and merges the Microsoft Recommended Block List to re-block the ≈40 signed binaries that can bypass App Control. That base is necessary but not sufficient: it starts the Azure guest agent's services, then the agent fails anyway on code its signature doesn't cover. Four file path rules complete it, scoped by fleet type: C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\* (any fleet running Defender for Endpoint, whose own live-response and data-collection scripts are otherwise blocked, silently degrading incident response), C:\WindowsAzure\* and C:\Packages\Plugins\* (Azure VMs, where the Run command extension ships third-party Newtonsoft.Json.dll), and C:\Program Files\Microsoft RDInfra\* (AVD session hosts, for the RD Agent boot loader script). Without the base, the guest agent's services fail to start with Service Control Manager event 7000 and the VM reports Not ready; with the base but without the paths, the services run while Run command still returns nothing from the portal, extensions stall, and Azure Backup degrades to crash-consistent snapshots while reporting success. Step 4 also gained guidance on reading the evidence: only AppControlCodeIntegrityPolicyBlocked (3077) and AppControlCIScriptBlocked (8029) are block decisions, while AppControlCodeIntegrityOriginBlocked (3092) is context about a blocked file and is where .NET native-image noise accumulates after every policy change (documented benign, self-healing, cleared immediately with ngen update).
12-6 (Defender for Endpoint): "Onboard Defender for Endpoint after Entra hybrid join completes" section added for the GPO onboarding race, where onboarding MDE too early leaves a synthetic Entra device object that Conditional Access then resolves against (AADSTS53001 / AADSTS53000). Includes the MDE-Onboarding-Gate.ps1 wrapper and remediation for already-duplicated fleets.
12-9 (Entra Device Hygiene): the hybrid rejoin procedure is now nine numbered steps. The pre-state capture (dsregcmd /status plus a BitLocker escrow check) sat above the list as an unnumbered "Step 0," so the heading promised eight steps while the reader had nine things to do.

Chapter 14: Information Protection (Implementation)

14-8 (Copilot Data Readiness): guardrail set updated for the RSS retirement. Restricted Access Control is now the durable governance boundary, Restricted Content Discovery the temporary hide-from-Copilot control, and Restricted SharePoint Search is retiring (new enablement blocked from July 31, 2026). Licensing corrected on both tabs: a single Microsoft 365 Copilot license unlocks the SharePoint Advanced Management feature set, so the SharePoint Premium add-on is needed only where no Copilot licenses exist.

Chapter 17: SIEM Strategy

Sentinel workspace setup is now create-or-reuse, matching the AVD runbook's Step 5: enable Sentinel on an existing Log Analytics workspace rather than creating a second one. The chapter previously produced exactly the split-workspace state its own cost note warns against.
Workspace setup gained substep 5: connect the workspace to the Defender portal (field-found). Sentinel's menus, Content hub included, appear there only after System → Settings → Microsoft Sentinel → Connect a workspace; Microsoft's "auto-onboarded in many cases" claim did not hold in the field.
Content-deployment navigation flipped to Azure-portal-primary. The Defender portal's Sentinel menus render only for accounts with directly assigned Azure RBAC (GDAP and Lighthouse delegation are unsupported for Sentinel data), which blanks the experience for partner-delivered engagements even on a healthy workspace. A note records the Azure-portal retirement date of March 31, 2027.
Defender XDR raw-table baseline added: "enable selectively" is now a concrete greenfield recommendation of 7 of 21 tables, anchored on the billing boundary (SecurityIncident/SecurityAlert and OfficeActivity are free, every raw table is billable but stays queryable free for 30 days in advanced hunting), with a skip rationale per group and a 30-day review loop.
NIST-standard enablement path gained its missing click (field-found): after selecting the subscription from Manage compliance standards, the standards list appears only after selecting Security policies in the left nav.
Defender for Cloud connector guidance corrected (field-found): the bi-directional alert sync toggle exists only for workspaces not onboarded to the Defender portal, so on a connected workspace MDC alerts arrive via unified Defender XDR integration, the legacy card stays disconnected to avoid duplicates, and Continuous export remains required for SecurityRegulatoryCompliance data.
UEBA enablement path corrected (field-found: the described UI does not exist). The M365 connector has no "Advanced Options" UEBA prompt and OfficeActivity is not a UEBA source; the note now documents the real path (Defender portal → Settings → Microsoft Sentinel → SIEM workspaces → workspace flyout) and the corrected source list.

Appendix B: Intune Baseline Configurations

Removable Media (Device Control) section compressed for the print edition (≈19 pages, an order of magnitude larger than its sibling sections, against KDP's 828-page cap): four per-entry settings tables merged into two side-by-side, the 130-character example serial elided, prose tightened. All load-bearing content is preserved, including the Block-then-Allow pattern, the Excluded-Devices trap, Sid semantics, and every Learn citation.

Appendix D: AVD Firewall Reference

Operations-Documentation rule collection added (priority 165): docs.mindline.com, learn.microsoft.com, and docs.microsoft.com (HTTPS, apex only) are now reachable from the AVD subnets, so the runbook and the Learn articles it cites open without leaving the session. docs.microsoft.com needs its own entry despite only redirecting, because Azure Firewall matches HTTPS rules on the TLS SNI before any request is sent, so older Microsoft links would otherwise fail inside the enclave while working everywhere else.
Azure-Administration rule collection added (priority 168, conditional): operators in a designated admin pool can run the Azure CLI from a session host, gated on a new adminSubnetAddressSpace parameter that is empty by default. It carries one rule (azcliprod.blob.core.windows.net) because everything az uses at runtime is already allowed; aka.ms and GitHub are deliberately excluded, with the air-gapped Bicep pre-staging path documented in place.
Embedded template listing re-synced to the canonical avd-firewall.bicep, and drift made structurally impossible: generate-client-firewall.mts now emits the template as a generated module rendered through CodeBlock, replacing a hand-maintained copy that had drifted to a pre-array revision contradicting the multi-subnet documentation on the same page.

Appendix D: AVD Runbook

Flow logging to Log Analytics and Sentinel added to Appendix D.4, with three KQL queries (daily denied-flow triage, denies attributed to DenyVnetEastWest as the SC.L2-3.13.1 / 3.13.6 evidence artifact, and hourly cross-pool lateral-movement attempts). Carries the warning that NSG flow logs can no longer be created: the path is virtual network flow logs with traffic analytics, and the table is NTANetAnalytics, not the retired AzureNetworkAnalytics_CL.
Step 13 now warns that backup depends on the VM guest agent, which App Control can block. A DefaultWindows-based policy blocks the agent, and the failure is quiet: backups still report success while degrading to crash-consistent snapshots, so the step says to base the policy on AllowMicrosoft.xml and confirm the agent reads Ready before signing the vault off.
"Backup now" is on the row overflow menu, not the toolbar (field-corrected): the action is behind the … menu at the end of the VM's row on the Backup items > Azure Virtual Machine list.
Backup policy retention: the 30-day recommendation now says it is overriding a 180-day portal default (field-reported), with the rationale that session-host backup protects provisioning state rather than CUI, plus what justifies going longer: retention must exceed the realistic incident detection window, not just the recovery window.
Soft Delete cost claim corrected (field-reported from a portal screenshot): only the first 14 days are free, not the full 180, so you pay standard backup storage for (retention − 14) days (secure-by-default documentation). The runbook now identifies MUA as the free control and presents 14 as the default.
Pooled multi-session variant documented end-to-end (prompted by a live deployment): a new section maps all 15 runbook steps to the pooled case, 11-6 gained the "when pooled multi-session is the right call" decision framework, and three field notes close it, including end-to-end validation (three concurrent users on one host at Max session limit 3, with Intune enrollment and policy delivery completed).
Virtual Machine User Login must be an Active, permanent assignment (not PIM-eligible): the role is checked at the moment of desktop sign-in, so a PIM-eligible assignment turns unactivated users away at the Windows logon with "Access Denied."
Entra device-settings row updated to the current portal: the setting is now "Global administrator role is added as local administrator on the device during Microsoft Entra join" (Preview), it defaults to on (Graph azureADJoin.localAdmins.enableGlobalAdmins = true), so it must be actively disabled.
Field flexibility notes: Log Analytics workspace and VM-count rows no longer assume greenfield values; RDP device-redirection hardening framed as "if needing to restrict access."

v2026.06.30

New Sections

Microsoft 365 Security Assessments (new framework section): a structured, evidence-based posture-review framework built on Microsoft's published Zero Trust Assessment, with Mindline overlays that translate raw configuration findings into compliance language (HIPAA, CMMC L2 / NIST 800-171, CJIS, SOC 2, NIST CSF), executive synthesis (risk heatmap, top-5 findings, Secure Score current vs. projected), and a phased remediation roadmap. 75 Tier 1 checks across six pillars (Identity (25), Devices (16), Data (11), Applications (6), Email & Collaboration (12), Network (5)), each pillar mapped to its Microsoft Zero Trust Assessment source, with a per-check license legend.
Microsoft 365 Copilot Data Readiness (new section, 14-8): preparing the data layer before Copilot is enabled, framed on Microsoft's four-step Purview model (discover, protect grounding data, protect interactions, govern). Copilot answers in the asking user's security context and grounds on the semantic index, so oversharing becomes an overshared Copilot answer at machine speed. Covers DLP for Copilot (label-based exclusion that keeps labeled CUI out of grounding and responses), sensitivity labels as the keystone guardrail, oversharing remediation (SAM reports, EEEU and "Anyone" links, Restricted Content Discovery / Restricted SharePoint Search as interim guardrails), DSPM for AI, licensing, and a recommended sequence (labels first). Includes the GCC High availability caveats verified against Microsoft Learn: Copilot is GA in GCC High, DSPM for AI covers supported AI sites only, and built-in agents plus Copilot in Teams chat/channels are not yet in GCC High. Mapped to CMMC AC.L2-3.1.3 / 3.1.1 / 3.1.5 and AU.L2-3.3.1.
GCC High Tenant Buildout Timeline (new Appendix E): a phased ~80-hour implementation timeline for a greenfield GCC High tenant CMMC Level 2 baseline, modeled on the AVD Deployment Timeline (Appendix D.3) and calibrated for a cloud-only tenant of 25 users / 25 Entra-joined workstations. Ten phases plus contingency: tenant and identity settings, Conditional Access (Report-Only → enforced), the Layer 1 Intune baseline, Defender (MDE / MDO / MDCA), a lean Purview baseline, Microsoft Sentinel, workstation enrollment, validation and audit evidence, and SSP handoff. Includes required-access and provisioning-lead-time tables and field-verified gotchas (break-glass first, sovereign .us enrollment URLs, EDR-block-mode-off for a Defender-AV-primary fleet, the 12-24h Sentinel regulatory-compliance lag, P006-after-compliance). Every phase traces to the Appendix A control matrix as the SSP backbone.

Significant Updates

(ordered front-to-back by where each change appears in the book)

Introduction

Scope boundary sharpened: the book is now explicitly the Microsoft GCC High implementation layer, not an SSP or end-to-end assessment guide: the SSP, POA&M, evidence narratives, and the C3PAO assessment are authored separately (typically by a CCP). Added OSC / CSP / ESP / CRM terminology with cross-links to the External Service Provider chapter.

Chapter 1: Scoping

1-1 (CUI Data Flows): scoping reframed around the CMMC Scoping Guide, Level 2 (32 CFR § 170.19). The COPR framework is recast as one scope gate plus three lenses: only Possession determines assessment scope, while Creation, Ownership, and Regulation govern adjacent questions (whether content counts as CUI, who holds authority and flow-down, and how it must be handled). A new note grounds scope in the guide's five asset categories and the process, store, or transmit (PST) test; adds Security Protection Assets and Security Protection Data to the authorization-boundary checklist (in scope even when no CUI flows through them); separates GFI from GFE (GFE being a Specialized Asset); and carries the guide's verbatim VDI keyboard/video/mouse Out-of-Scope example as the scoping basis for the thin-client enclave model. The 3.12.4 control gloss was corrected to the System Security Plan description.
1-3 (External Service Providers): new "What Triggers ESP Scope" section. Per 32 CFR § 170.19(c)(2), a provider is an ESP only if CUI or Security Protection Data resides on its assets, so a cloud SIEM holding your logs is an ESP even when no CUI flows through it. A decision table (CSP vs. CUI handling) sets whether the ESP needs its own assessment, alongside the CSP-vs-MSP distinction and the staff-augmentation carve-out (when the OSA supplies all processes, technology, and facilities, the ESP needs no separate CMMC assessment).

Chapter 8: Identity Foundation

8-2 (Phishing-Resistant Auth): Azure Blob Storage CRL-hosting walkthrough added and expanded (Entra CBA): the one-line "publish the CRL to a public URL" note is now a 6-step procedure: the two-level anonymous-blob-access default, the "Secure transfer required" HTTP/HTTPS trap (with a CMMC-clean HTTPS recommendation), application/pkix-crl content type, CA CDP → Entra registration, and refresh automation. Expanded with a concrete resource-naming table (storage-account name rules: 3–24 lowercase chars, globally unique, and publicly embedded in every cert's CDP, plus container/blob naming), an explicit New-AzResourceGroup / New-AzStorageAccount Step 1 with an LRS rationale, an anonymous-reachability check before wiring the CDP, and a "Portal equivalent" callout mapping the Create a storage account wizard (Basics + Advanced→Security tabs) for portal-first admins. All steps verified against Microsoft Learn; GCC High 45 MB / 10-second CRL limits called out.
8-2 (Phishing-Resistant Auth): WAM/PRT AAGUID-stripping finding given engagement provenance: the undocumented behavior now reads as field-observed (FIDO2 desktop step-up failure) and reproducible in the sign-in logs, grounded in the cited Microsoft architecture pages.
8-2 (Phishing-Resistant Auth): AAGUID limitation confirmed in writing by Microsoft Support (April 2026), diagnostics upgraded. The warning now cites the case correspondence ("product limitation consistent with the current design"), still absent from public docs including the auth-strengths known-issues list. The mechanism is restated at claim granularity: the PRT is imprinted with the MFA claim at method level but has no field for WebAuthn attestation metadata, per the Understanding PRT page, with the partitioned-PRT distinction (founding credential vs. step-up amendment) and why WHfB's key-registration identity needs no AAGUID. The sign-in log diagnostic gains incomingTokenType (primaryRefreshToken failing vs. none working) as the second half of a two-field fingerprint alongside the all-zeros AAGUID. The workaround tip gains a third non-fix: allowlisting the all-zeros AAGUID itself, which the portal accepts (field-verified July 2026, match behavior untested) but which would be a silent wildcard for attestation-absent credentials rather than make-and-model enforcement.
8-5 (Identity Governance): control identifiers switched to CMMC L2 prefix format: the PIM + Lifecycle Workflows mapping tables now use AC.L2- / AU.L2- / PS.L2- identifiers instead of bare NIST numbers, for consistency with Appendix A.

Chapter 9: Conditional Access

B011 Require Token Protection (native clients): new CA policy that defeats adversary-in-the-middle (AiTM) token theft (EvilProxy, Tycoon, Mamba) by cryptographically binding the Primary Refresh Token to the device (TPM-backed on Windows). Scoped to mobile and desktop clients (browser unsupported, pair with CAE strict enforcement); report-only-first rollout with device-registration coverage checks, since the policy blocks unregistered/BYOD devices.

Chapter 11: Device Architecture

11-6 (Scenario: AVD): enclave cost figures framed as field-observed: the Secure Enclave Pricing totals, savings, and percentages are labeled as drawn from real deployments (illustrative of shape, not a tenant quote) with the Azure pricing-calculator link.
11-7 (AVD Secure Enclave): CA/DLP policy IDs renumbered to make room for the new B011 (Token Protection): the enclave block policies each shifted up one (former B011→B012, B012→B013, B013→B014, B014→B015). Mechanical renumber only, no behavioral change, but update any saved references to the old IDs.
11-7 (AVD Secure Enclave): "The CMMC basis for an enclave" callout added, grounded in the Scoping Guide's Use of Enclaves guidance: an enclave on an existing tenant is explicitly contemplated, enterprise-wide tools that serve it are in scope as Security Protection Assets without pulling in the rest of the enterprise, and inherited controls must still be MET. A caveat records that the thin-client Out-of-Scope status holds only while redirection stays keyboard/video/mouse: enabling microphone or camera redirection turns the connecting endpoint into an in-scope CUI Asset (a live assessor finding), so the session is kept KVM-only via host-pool and session-host redirection settings.

Chapter 12: Device Operations

12-4: Canonical 1–21 OIB policy numbering and clearer Intune-vs-MDE labeling across the Layer 1 baseline.
12-4: Dual-framed CMMC / Commercial baseline: ungated CMMC-specific prose (C3PAO findings, "mandatory minimum," Rev. 2 "anchor") reframed so Commercial (Rev. 3) readers aren't shown CMMC framing as universal; the GCC-High tool/sovereign-cloud setup heading converted to a scoped GCC High only callout.
12-4: Application Control (App Control for Business) section added: managed-installer model (Intune Management Extension as a trusted source), audit-mode-first rollout, the Allow-/*-before-delete teardown, and CMMC 3.4.8 / 3.4.9 mapping; confirmed supported in US Government clouds.
12-4: Commercial (Rev. 3) control glosses corrected in the baseline mapping table: 3.5.12 → Authenticator Management (was mislabeled "replay-resistant"), 3.1.9 → System Use Notification, 3.1.10 → Device Lock, with 3.1.3 / 3.4.5 / 3.8.x aligned to Rev. 3 titles. The GCC High (Rev. 2) glosses are unchanged.
12-6: Onboarding consolidated under one parent: the three onboarding procedures (Intune-managed, MDE-attached workstations, MDE-attached servers) were scattered across two heading levels and split by the Portal section; they're now peers under a single Onboarding parent led by the routing table, with Portal & Tenant Endpoints repositioned just before it as a pre-onboarding reference.
12-6: Intro rewrite + section concision: intro reframed to bind the chapter into the OIB Layer-1 taxonomy and explain the Endpoint-security-blade co-location in one paragraph; Management Models de-duplicated; Server Endpoint Security set compressed (channel detail deferred to the delivery matrix, gotchas kept).
12-6: MDE-for-Servers licensing clarity: Plan 2 table cells reworded ("Same as Plan 1") to match the table's own labels and avoid the MDE-P2-vs-Servers-P2 overload.
12-6: ConfigMgr "Microsoft Defender ATP" node clarified: noted that current-branch ConfigMgr retains the legacy "Defender ATP" node name (the product is Defender for Endpoint), verified against current Microsoft Learn, not stale naming.
12-6: Three-management-model comparison table added: Intune-managed workstation vs. MDE-managed workstation vs. Defender-for-Cloud server, compared across 11 dimensions (license, enrollment/identity, targeting, security vs. other config delivery, compliant-device CA, device-risk gate, app deployment, assurance surface, enforce/auto-remediate lever). Section broadened from the prior Intune-vs-MDE framing to cover all three.
12-6: New "Configuration Assurance for Non-Intune Devices" section: answers how settings delivered over the MDE and Defender-for-Cloud channels are kept and proven applied without a compliant-device CA gate: the preventive-gate → detective + self-healing shift, with the MDE device-risk signal flagged as no escape hatch (it too runs through a compliance policy). For MDE-managed workstations, separates what's free with MDE P2 (90-minute policy re-assertion + Tamper Protection + GPO refresh; per-setting status reporting; core MDVM configuration assessment / Secure Score for Devices) from the paid MDVM add-on (CIS/STIG Security Baselines Assessment, ≈$2/user/mo, GCC High via reseller; unneeded on servers, which include it via Defender for Servers P2). For Defender-for-Cloud servers, covers Machine-Configuration OS-baseline assessment + ApplyAndAutoCorrect self-heal, the regulatory-compliance dashboard, FIM, and secure-score recommendations. SSP framing: these controls satisfy CA.L2-3.12.3 continuous monitoring but are not an access gate. All mechanisms verified against Microsoft Learn.
12-6: Tenant-attach Exploit Protection coverage corrected: verified against Microsoft Learn that Exploit Protection is supported via Configuration Manager tenant attach for Windows Server, so it's no longer listed as a GPO-only gap: the ConfigMgr-managed server gap drops to LAPS, Local Group Membership, and Device Control. Added the GCC High caveat (tenant attach requires ConfigMgr current branch 2107+ for Azure US Government, a still-current Microsoft setup page wrongly says Azure Government isn't supported).
12-4 ↔ 12-6: Bidirectional cross-links between the OIB 21-policy list and the Defender delivery matrix (per-channel delivery, server forks, GPO fallback).
12-10: GPO-to-Intune server corrections.

Chapter 14: Information Protection (Implementation)

14-2 (Sensitivity Labels): encrypted-PDF processing limitation sourced: the "labeled PDFs go dark to search/DLP/eDiscovery until PDF support is enabled" behavior is now cited to Microsoft Learn rather than asserted.
14-5 (Info Protection Scanner): control identifiers switched to CMMC L2 prefix format in the on-prem CUI-discovery mapping; prose also corrected from a "NIST 800-171 Rev. 3" reference to CMMC framing for the GCC High track.
14-6 (Purview CAB Runbook): container-label enablement verification corrected: the EnableMIPLabels (Group.Unified) directory setting has no Entra portal screen, so the old "Groups → Settings" verify step was replaced with a Get-MgBetaDirectorySetting Graph check (cited to Microsoft Learn) plus an inline snippet.
14-6 (Purview CAB Runbook): DLP field-test gotchas added (alert deliverability + Teams licensing): (1) DLP incident-report emails are dropped by a mail-enabled security / M365 group unless "Allow external senders to email this group" is enabled, and even then a third-party secure-email gateway can block them (diagnose via Mail flow → Message trace); (2) DLP for Teams chat/channel messages (Priority 3) requires E5 per user: on E3 the Teams credential policy silently fails and validation V-3 never triggers. Both cited to Microsoft Learn; Prerequisite #4 corrected to split Exchange/SP/OneDrive (E3) from Teams (E5).
14-6 (Purview CAB Runbook): validation-plan corrections (encrypting-label + sensibility pass): the Commercial tabs of Layer 2 (L-3), Layer 3 (the 2×2, B-1/B-2/B-3), and Layer 4 (X-3) wrongly treated Confidential as an encrypting label (mirrored by tier position from the GCC High plan, where the tier-3 label is encrypted); corrected to use Restricted (the only encrypting label in the Commercial taxonomy) with the Required Test Sites mapping (B-1/B-2 → S-3 Test-Restricted) updated to match, and L-3 now verifying Confidential as marking-only. Also removed stale "(replaces V-4/V-6/V-8)" cross-references, corrected V-3 (Teams) to match its Alert-only / notifications-off policy (no block, no policy tip, E5 required), and tightened X-2/X-4 container-sharing wording (the tier-2 container restricts external sharing to existing guests, not a hard block).
14-7: Data Lifecycle & Retention (new page): Microsoft Purview Data Lifecycle Management and Records Management: retention policies vs. labels, disposition review and proof of disposition, a recommended CUI baseline, licensing, and the GCC High caveat, mapped to NIST 03.14.08 (Information Management and Retention).

Chapter 8: Identity Foundation

8-2 (Phishing-Resistant Auth): immediate-workaround guidance added to the AAGUID desktop-app limitation (field engagement): a new callout and decision-matrix row cover the same-hour fix (switch the affected policy's grant control from the custom strength to the built-in Phishing-resistant MFA strength), the two non-fixes (adding AAGUIDs matches nothing when the claim arrives zeroed; dropping to plain Require-MFA abandons phishing resistance), the why-not-abandon-custom-strengths clarification (issuer/OID binding and method combinations are unaffected), the design rule reserving AAGUID restriction for browser/mobile paths where the WebAuthn assertion reaches Entra directly, and a JSON-export note for escalation evidence.

Chapter 16: Threat Defense

Defender for Identity installer name clarified: noted that the sensor binary is still Azure ATP sensor Setup.exe (the product is now Defender for Identity), verified against current Microsoft Learn, not stale naming.

Chapter 17: SIEM Strategy

Audit-control mapping corrected: AU.L2-3.3.7 re-mapped to Time Stamps (UTC time source) and audit retention re-pointed to 3.3.1 in both the prose and the SIEM control table, matching the Appendix A fix.
Cost figures framed as field-observed: the ingestion mix, per-table volumes, and per-GB cost figures are now labeled as drawn from real engagements, illustrative of shape, not a tenant quote.

Appendix A: Compliance Controls

Completeness pass (prompted by external review): the control matrix was expanded from a selective subset to the full set: all 110 CMMC Level 2 (NIST 800-171 Rev. 2) practices and all 97 active Rev. 3 requirements. Previously-omitted controls are now listed and labeled rather than dropped: those with no Microsoft mapping are tagged Policy/process control, and Rev. 3-withdrawn requirements are called out per family so no number appears skipped.
Control accuracy corrections: 3.3.7 corrected from "Audit Retention" to "Time Stamps" (its actual NIST title; audit retention re-mapped to 3.3.1, create and retain); 3.3.3 added (Rev. 2 Review Logged Events / Rev. 3 Audit Record Generation); administrative controls no longer over-mapped to a product (3.1.4 → Entra Entitlement Management separation-of-duties; 3.2.2 and 3.12.2 reframed as policy/process with supporting tooling noted).
Reframed as an SSP input: a note now states the matrix feeds the System Security Plan rather than being it; inherited (Microsoft-managed) controls require an SSP narrative recorded in a Customer Responsibility Matrix (CRM) citing Microsoft's FedRAMP authorization.

Across multiple chapters

Minor touches (≤5 lines each): 11-2, 11-5, 13-1, 13-3, 14-1 / 14-3 / 14-4, 15, and the licensing matrix (Appendix C), folded here rather than itemized.
Book-wide clarity / conciseness pass: a structured audit flagged redundant restatements and tangents; 161 trims applied across 55 files: predominantly prose that re-walked a table or bullet list it just presented, plus a few "doesn't-apply" asides. Intentional cross-tab GCC High / Commercial content was preserved (not collapsed), and no technical claims, citations, callouts, code, or control mappings were changed.
Typographic cleanup: em dashes removed book-wide and replaced with standard punctuation (commas, colons, parentheses, periods); heading and link anchors affected by the change were reconciled so all cross-references still resolve.

v2026.05.31

Significant Updates

Identity & Conditional Access

Chapter 9: B004 Block Authentication Transfer: new policy closing the Storm-2372 QR-code / cross-device phishing pattern.

Firewall

Appendix D: AVD Firewall: rule set aligned row-by-row to Microsoft Learn citations (for CAB traceability) and expanded from field deny-log triage: now 29 rules / ~140 FQDNs covering previously-missed gaps including the cross-cloud MSAL instance-discovery probe, Azure Gov portal blade hosting, GCC High KMS explicit IPs, Defender MAPS commercial endpoints, OneDrive sync, and the legacy NCSI probe.

AVD (Runbook & Enclave)

Appendix D.1: Step 3 policy-binding verification gate + Bastion row tweak: catches the classic-rules-mode silent failure (deployed policy + unbound firewall = every rule ignored); Bastion architecture trade-off explicit, price softened.
Appendix D.1: Multi-Pool Variant + shared-services topology + multi-subnet firewall: supports >1 host pool with shared services; avdSubnetAddressSpace generalized from string to array; closes silent DSC failure when a new pool's subnet isn't listed.
Appendix D.1: Azure Backup + Recovery Services Vault: named mechanism for DFARS 252.204-7012(c)(1)(ii) VM-level forensic preservation; aligned with current Azure Backup Secure-by-Default soft-delete posture.
Chapter 11-6: OneDrive KFM removed from AVD scenarios: AVD session hosts are near-ephemeral; CUI lives in governed SharePoint sites, not in user OneDrive folders that would silently sync to a transient profile.
Chapter 11-7: CUI-AVD label restructured around the Purview five-tab wizard: closes site-label/file-label, mandatory-toggle-location, and email-inherits-attachment traps; tenant-wide co-authoring prompt and consequence-of-declining documented.

Devices & Endpoint Management

Chapter 11-2: BitLocker Auto-DE Autopilot intercept: closes a Windows 11 24H2 silent compliance gap (Intune Require BitLocker passes while Encryption Report flags algorithm mismatch).
Chapters 11 + 12: Update-MgDevice DeviceID-vs-ObjectID gotcha: Graph cmdlets name parameter -DeviceId but expect Object ID; the BitLocker recovery-key cmdlet is the inverse.
Chapter 12-3: Mobile four-tier framework (Tier 0 baseline + three managed tiers): Tier 0 unmanaged (blocked at CA), Tier 1 MAM, Tier 2 managed container, Tier 3 corporate; broker-app gotchas (Intune app vs Company Portal); Tier 1 vs Tier 2 CA grant comparison.
Chapter 12-5: Intune reporting + KQL alerting buildout: six new H3s including five ready-to-deploy Log Analytics alert rules (compliance regression, profile failure rate, privileged action, change-window violation, app deployment failure spike).
Chapter 12-6: MDE-for-Servers licensing matrix: user-tier MDE P2 doesn't cover servers; three valid server-OS paths (Defender for Servers P1/P2, Defender for Business Servers, standalone MDE for Server) with GCC High availability noted.
Chapter 12-6: MDE-channel delivery limits + GPO fallback: four Intune endpoint security profiles (LAPS, Local Group Membership, Exploit Protection, Device Control) assign-but-don't-enforce over the MDE channel; GPO alternatives mapped to CMMC controls; Windows Server isn't a supported Intune MDM enrollment target.
Chapter 12-9: Single-Device Remediation procedure: hybrid eight-step / cloud-only six-step for wedged devices, with profile preservation via stable ObjectID → SID mapping.
Chapter 11-8: Shared PC Mode field-test follow-ons: incremental refinements from lab testing plus a new command-prompt control mechanism.

Data Protection

Chapter 14-2: PDF Labeling: new H2 extending sensitivity-label coverage to PDFs; verification, enablement, and gotchas documented.
Chapter 14-6: Purview CAB validation-plan ordering correction: DLP rule matches require labeled content, so label-apply must precede the DLP test or false negatives result.
Chapter 14-6: SSN PII baseline added: new P10–P12 DLP policies (Exchange / OneDrive / SharePoint) using the high-confidence U.S. SSN SIT in Alert-only mode (SharePoint via Simulation) for a 30-day baseline-and-tune before any enforcement decision.
Chapter 14-6: Block-with-override gotcha closed: P4 Exchange external-share policy reframed from ambiguous "Alert + override" to explicit "Restrict access → Block everyone + business-justification override"; new info callout explains the override checkbox is silently a no-op without a paired Block action.

Monitoring, SIEM & Compliance

Chapter 17: Sentinel cost / retention / DFARS / M365 connector: 365-day-hot + 2-year-archive retention recommendation with named DoD CIO / M-Trends / DFARS / DCMA drivers; DFARS 252.204-7012 clause-by-clause coverage map; M365 connector workload coverage + omissions table.

Site Improvements

Algolia DocSearch added. Full-text site search via the Algolia DocSearch program. Search box appears in the navbar after the next deploy; the Algolia crawler is registered against docs.mindline.com (the public scope), so search results are constrained to public content. The private book.mindline.com build shows the same search box and returns the same public-result set: the asymmetry is by design (DocSearch's free program does not crawl authenticated sites). contextualSearch enabled for forward compatibility with future locales or versions; dedicated /search page provided for full-results view. The search-only API key is committed to docusaurus.config.ts (safe to embed in client JS by Algolia design); the admin key remains in the dashboard.

v2026.04.30

Covers Chapters 1, 5 (new), 6 (new), 9, 14, 17, 21, 22, 23 (new), 24, 28, 29 (new), 31, 35, 46, 49, 50, Appendix B, Appendix D, Phase 5 restructure, and two cross-phase renumberings.

New Chapters

Chapter 5: Shared Services and Conglomerate Tenants: One GCC High tenant serving a parent and multiple operating subsidiaries under CMMC Level 2. Decision framework for three defensible architectures (Unified Tenant, Individual Tenants with Shared AVD, Fully Segregated), segmentation via Information Barriers V2, Restricted Access Control, Address Book Policies, dynamic groups, and label encryption, plus the Shared Responsibility Matrix narrative a C3PAO expects.
Chapter 6: Migrating to GCC High: Migration-specific gotchas that the greenfield chapters do not cover: MFA re-registration across the cloud boundary, cross-cloud B2B off by default, CTAS rebuild on both sides, Cross-Cloud Meeting Join limits, Entra Connect sync switchover window, licensing differences between Volume License Office and M365 Apps, external collaboration tier decision table, and risks to call out during planning.
Chapter 23: AVD — Privileged Admin Workstation: Using managed identities and phishing-resistant AVD sessions for zero-credential admin operations. Solves the FIDO2 gap in Teams, SharePoint, and Exchange PowerShell modules.
Chapter 29: Open Intune Baseline Deployment: Carved out of the original Chapter 28 (Mobile & Endpoint Security). Gives the Open Intune Baseline its own home with a three-layer deployment framework (Layer 1 CMMC-mandatory, 21 policies; Layer 2 defense-in-depth, 33 policies; Layer 3 situational, 12 policies), the 8-step IntuneManagement tool import flow, GCC High–specific modifications (telemetry, FIPS, identity routing), the CMMC Control Mapping Matrix, the four OIB compliance policies, USB device control with SOC alerting, the four-tier Windows Update ring strategy, and Wi-Fi configuration with department-specific targeting.

Structural Changes

Two cross-phase chapter renumberings. The first renumbering (early in the cycle) restored sequential chapter numbers across phases after the two new scoping chapters were inserted. The second renumbering (late cycle) shifted every chapter from 29 onward by one position to slot in the new Open Intune Baseline Deployment chapter. Chapter IDs and URLs are driven by front-matter, so internal and external links continue to resolve unchanged through both passes.

Phase 5 renamed from "Monitoring" to "Microsoft 365 Security"

Threat Defense chapter split into two H2 sections:
- Microsoft 365 Security Configuration: SharePoint Admin Center (unmanaged device access, external sharing), Teams Admin Center (external access, guest access, meeting policies), and Defender for Office 365 policies (Safe Links, Safe Attachments, Impersonation Protection)
- Security Operations: Attack Simulation Training, Threat Explorer, AIR, Defender for Cloud Apps, Defender for Identity, Unified XDR Incidents View, Advanced Hunting, Secure Score
SharePoint unmanaged device access documented as the server-side prerequisite for the CA "Use app enforced restrictions" policy, cross-referenced from Conditional Access and the Purview CAB runbook
Threat Defense chapter title on the home page reconciled with the chapter heading (was "Microsoft Defender XDR")

Major Rewrites

Chapter 49: SIEM Strategy: full chapter restructure

New opening section "Why Sentinel for CMMC" motivating the chapter around the AU, IR, and SI control families and the four reasons Sentinel specifically (versus rolling your own log aggregation)
"Deployment at a Glance" two-phase overview with tables for the four workspace substeps and seven content-deployment steps
Step sequence restructured to a 7-step content-deployment flow; Step 3 renamed to "Enable CMMC 2.0 posture assessment"; Step 6 added for "Verify NIST 800-171 data arrival" with validation query and interpretation table
Demonstration Step 5 restructured into three artifact categories: plumbing-evidence portal screenshots first (Data connectors Connected filter, Content Hub Installed, Analytics Rule templates, Azure portal Log Analytics "Usage and estimated costs"), workbook narrative second, KQL evidence queries third
CMMC L2 Demo query pack with CMMC practice mappings: OfficeActivity overview, MIP Label Activity, DLP Policy Matches, External Sharing Events (SharePoint and Teams), sign-in and risky sign-in queries, each named, labelled "CMMC L2 Demo", and mapped to AU/IR/SI practices
Save Query dialog quirks documented as a five-item gotcha list: Category is a fixed picklist (use Labels for custom grouping), forward slashes blocked in names, Queries pane Source filter must be set to Query Packs, and the "workflow that works every time" recipe
CMMC workbook save procedure corrected for the Defender portal's read-only workbook viewer: "Open in Azure" → Edit → Done Editing
Identity & Access workbook downgraded from Tier 1 to Tier 2 with explicit UEBA 14–21 day maturation caveat; workbook tiers reorganized so client-demo pieces can be completed same-day during the 12–24h compliance data wait
OfficeActivity query corrections: ObjectId → OfficeObjectId, SiteUrl → Site_Url
Natural-pause admonition rewritten to explicitly list what the 12–24h wait blocks versus what proceeds immediately (workbook saves, demo queries, plumbing screenshots)

Chapter 22: AVD — Enclave in Existing Tenant

Replaced Custom Security Attributes with extensionAttribute15 (CSAs not supported on devices in any cloud)
Replaced authentication context (E5 requirement) with DLP-based data layer (E3-compatible)
CA policies renumbered: E001/E002/E002b replaced by P004, B009, B010, with optional B011/B012 for E5
DLP reduced from four policies to three: RMS encryption makes the sharing block policy redundant
Added E5 vs. E3 assessment: "don't buy E5 for this"
Sensitivity label renamed to CUI - AVD, merged file and site scopes into single label
Documented DLP admin exemption (site owners and Global Admins bypass DLP block actions)
UPN suffix convention changed from -cui to -secure
FCI user group renamed to AVD-Enclave-FCI-Users-MESG to make the mail-enabled security group requirement explicit in the name
New-user provisioning procedure expanded: AVD Host Pool Application Group assignment and Virtual Machine User Login RBAC role on the Resource Group, with note that group-level assignment at deployment time collapses these into a single group-add step
Dedicated CUI account authentication softened from "phishing-resistant only" to "phishing-resistant strongly recommended; Authenticator push permitted with compensating controls"

Chapter 24: Shared PC Mode

Admin profile deletion exemption via registry-based SID exclusions
New Admin Maintenance Procedure with full mechanism explanation: registry tattooing as the actual enforcement model, the Allowed* family at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ (AllowedNavigation, AllowedEnumeration, AllowedStorageLocations, plus the WCOS baseline variants), why Intune assignment removal alone does not lift the restrictions, and primary-source citations (van der Woude, Kieselbach, Microsoft Learn)
Three-script maintenance workflow with timestamped .reg backups: Remove-SharedPCTattoo.ps1 (open the window), Test-SharedPCMaintenanceState.ps1 (verify), Restore-SharedPCTattoo.ps1 (close the window). Runs entirely on the target machine: no Intune-side action required. Scripts are now downloadable from /scripts/sharedpc/ alongside the embedded code blocks, so readers can use canonical files instead of copy-pasting
Sample SharedPC tattoo artifact at /artifacts/sharedpc-sample-tattoo.zip: a sanitized capture of the real SharedPC CSP footprint (three .reg files plus a README), for exercising Restore-SharedPCTattoo.ps1 against a simulated tattoo without a live SharedPC-provisioned device. Domain user SID in the Persistence subkey was redacted; CLSID allowlists in AllowedNavigation / AllowedEnumeration are generic Microsoft shell extensions, unchanged from the capture
Script bug-fixes from field testing on a lab device: Remove gets an explicit exit 0 so automation can detect success; Test no longer silently exits 0 on failure (em-dash encoding issue that aborted the exit 1 branch), correctly forces array coercion on Get-Volume so single-drive boxes don't false-fail, and widens the AllowedStorageLocations check to walk all plausible parent locations (the value can live inside AllowedEnumeration, not just on the Explorer key); Restore runs reg.exe import inside a locally-scoped $ErrorActionPreference='Continue' scriptblock so native-command stderr doesn't terminate the script and $LASTEXITCODE isn't silently reset to -1 during an error-unwind, tolerates shpamsvc startup failures on partial-backup restores, and replaces the hard-coded sanity-check key list with a dynamic one parsed from the actual .reg files imported
Maintenance-window framing clarified: explicit note that the procedure opens a time-bounded window (MDM re-provisions on every 8-hour sync cycle) rather than a permanent change; decommissioning a device is a separate workflow that requires unassigning the Intune profile first
Allowed* family footnotes added: WCOS baseline allowlists are conditional (not present on every SharedPC profile; scripts handle missing keys defensively), and AllowedStorageLocations placement varies (can live on the Explorer key directly or as a child value inside AllowedEnumeration / other allowlist subkeys)
Customizing the Default User Experience: configure-and-copy default profile and Intune-policy-based delivery presented as two viable approaches; configure-and-copy explicitly supported by the admin-exemption mechanism for clients who continue to use it
Power Settings table corrected: missing System Sleep Timeout row added, duplicate Hard Disk row removed, categorization aligned with the actual Intune policy structure (Administrative Templates / Power Management subsections plus a separate Power section)
Terminology pass: "student" / "Student" references replaced with "user" / "shared machine user" throughout the chapter (section heading, table cells, bookmark and shortcut examples)

Significant Updates

Chapter 46: Purview CAB Runbook: major expansion

Phase A rewritten around a wizard-order sensitivity label creation table (GCC High and Commercial tabs): every wizard setting as a row, every label as a column, walk the wizard top to bottom
Step A-4 added: enabling co-authoring for encrypted files, including the irreversibility caution and the metadata-compatibility pre-check
Phase B rewritten around three DLP policy tables: credential alert policies (P0–3), sensitive/highly restricted label external sharing (P4–6), and restricted label external sharing (P7–9)
Incremental rollout model added: scope Exchange/OneDrive/Teams to EID_Sensitivity_Label_Test_Users and expand after validation; SharePoint uses Simulation mode because SharePoint DLP doesn't support user/group scoping
Policy modes rationalized: only SharePoint Credential (P2) and Teams Credential (P3) start in Simulation due to credential SIT false-positive risk; all other policies start Enforced
Sensitive info type corrected from the non-existent "Software Development Credentials" to the All credentials bundled SIT
DLP action text corrected to match the actual wizard (e.g., "Restrict access or encrypt the content → Block everyone except the content owner, last modifier, and site admin")
Incident report recipient configuration moved into the rule's Incident reports section (there is no separate global DLP alert destination setting)
Allowed-domains exception documented correctly as a rule exception (Exceptions → Recipient domain is), not a sub-option of Content is shared
EID_Sensitivity_Label_Restricted clarified as a Microsoft 365 Group that must be created in the Microsoft 365 admin center (not Entra or Intune); test group scoping DLP policies can be a plain security group

Chapter 9: Phishing-Resistant Authentication

Reframed from "required" to "strongly recommended and expected by C3PAOs"; Authenticator push permitted as fallback with number matching, additional context, CA sign-in frequency, and SSP documentation
Added warning covering MFA fatigue and AiTM attack risks specific to the push-only path

Chapter 14: Conditional Access

TAP issuance: role table distinguishing Authentication Admin, Privileged Authentication Admin, and Global Admin
TAP recovery requires custom "Phishing-resistant + TAP" auth strength (explicit dependency callout)
New rollout methodology for existing tenants (report-only → test group → expand) with EID naming convention
Travel exceptions: replaced user exclusion group with named location procedure
Break-glass accounts: added RMAU membership requirement
Excluded phishing-resistant users from standard MFA policies (A001, P001, P002)
Removed EID_Consultants from device compliance policies: not-in-group is sufficient
P006: Azure Management API only exists in tenants with Azure subscriptions
B008: corrected grant control from "authentication strength" to "multifactor authentication"
Cross-reference added on the app-enforced restrictions policy to the new SharePoint Admin Center configuration section
P005 (Require app protection policy) gains an explicit warning: Microsoft Edge is the only mobile browser that satisfies the policy on iOS and Android; Safari, Chrome, Firefox, and Samsung Internet are blocked at sign-in. Deployment guidance covers pushing Edge via Intune before enforcement and the Edge MAM account-add timing quirks to test for

Chapter 28: Mobile Device Management & App Protection (retitled and trimmed from "Mobile & Endpoint Security," OIB content extracted to new Chapter 29)

New "Mobile Enrollment and App Protection" section covering the three postures (Corporate MDM, BYOD MAM, BYOD Work Profile), broker app / Company Portal role matrix per scenario, corporate MDM enrollment flows (ADE, QR, Zero-Touch, Knox, afw#setup), BYOD MAM walkthroughs for iOS (Authenticator broker) and Android (Company Portal installed but not signed in), MAM vs. Work Profile decision table, and end-user communication templates
Play Integrity clarified: Google "Strong Integrity" enforcement is now live; baseline recommendation added

Chapter 31: Defender for Endpoint and the Endpoint Security baseline: substantial restructuring

Chapter renamed from "Defender for Endpoint" to "Defender for Endpoint and the Endpoint Security baseline" to reflect the actual scope. The chapter covers MDE-specific concerns (onboarding paths, custom-detection rules, Sentinel integration) AND the broader Endpoint Security baseline: the 12 Layer 1 policies that live in the Intune Endpoint Security blade or pair with it (BitLocker, Local Administrators, WHfB Configuration, Cloud Kerberos Trust, LAPS, Windows Firewall, Exploit Protection, Device Control / Removable Media; only ASR Rules, AV Configuration, AV Security Experience, and EDR Onboarding are Defender features per se). URL slug defender-for-endpoint preserved; all cross-references resolve unchanged.
MDE-attached workstations vs. servers: distinct onboarding paths, licensing, and management portals
Two-set policy architecture (was three-tier): one workstation Endpoint Security set covers both Intune-MDM-managed and MDE-managed workstations because the settings are identical for both populations; servers get their own set where the content actually differs
Workstation ES set: 9 OIB Settings Catalog imports (ASR L2, AV Configuration, AV Security Experience, BitLocker OS Disk, Local Administrators, Windows Firewall, WHfB Configuration, Cloud Kerberos Trust, Windows LAPS) plus 3 manually authored (EDR Onboarding [tenant-specific blob], Exploit Protection [Settings Catalog policy enforcing DEP/ASLR/SEHOP/CFG plus DisallowExploitProtectionOverride for tamper protection, replaces the legacy "golden machine XML export" workflow], Device Control / Removable Media [Reusable Settings + Device Control profile keyed to tenant-specific approved hardware IDs, replaces Custom XML]). The three Defender Antivirus Update Ring policies (Pilot/UAT/Production) are explicitly classified as Layer 2: operational risk management, not compliance-mandatory; CMMC 3.14.4 is satisfied by Defender's default automatic signature updates.
Server ES set collapsed from 6 required + 4 optional to 3 required + 1 optional. The genuinely-different server policies are AV Configuration (server-specific exclusions for SQL/IIS/Exchange/AD DS NTDS/SYSVOL paths, applying the workstation policy without exclusions risks AV scanning live database files mid-write), Local Administrators (Tier 1 server admin membership), and Firewall Rules (servers must allow inbound on service ports rather than blocking all inbound). The remaining six workstation policies (LAPS, Security Experience, ASR Rules, EDR Onboarding, Exploit Protection, Device Control / Removable Media) cover servers without forking: assign each to Servers-ES as a second target rather than authoring Svr - variants. Forking is documented as an exception with concrete triggers per policy. The optional server-only fork is BitLocker (TPM-only protector for unattended reboots, plus Fixed Data Drive encryption for any data volumes hosting CUI; skip on Azure VMs because of platform-layer encryption).
LAPS / LSP Layer 1 default flipped from (24H2+) to non-24H2+: manages the built-in Administrator account, universally compatible with Windows 10 and Windows 11. The (24H2+) variants (Automatic Account Management creating a custom managed admin + matched LSP variant disabling the built-in Administrator) are repositioned as optional advanced for uniform Win11 24H2+ fleets, deployed as a matched pair. The matched-pair coupling is preserved as an admonition: deploying (24H2+) LSP without (24H2+) LAPS leaves devices with no local admin account at all, recoverable only via WinRE console.
Cloud Kerberos Trust promoted Layer 3 → Layer 1. For the book's typical hybrid CMMC L2 audience, deploying WHfB Configuration without Cloud Kerberos Trust leaves users unable to access on-prem CUI repositories (Kerberos failure or NTLM fallback). The Layer 3 "situational" classification was practically misleading. Now Layer 1 with a "skip if cloud-only" caveat. Layer 1 baseline grows from 20 to 21 policies as a result; Layer 3 drops from 13 to 12.
Removable Media appendix substantial rewrite to Reusable Settings + two-rule Block-then-Allow pattern. Important correction. The prior single-rule "Block with Excluded Devices, Sid on Deny" model was structurally wrong: a Sid on a Deny entry scopes the deny to that user/group (denying them); putting the user/group you want to allow there inverts the targeting. Excluded Devices removes a drive from rule scope for every user, not just the bound user, defeating per-user binding entirely. The corrected pattern, matching Microsoft's documented walkthroughs: Rule A blocks all removable storage for everyone (no Sid on Deny + AuditDenied); Rule B allows approved drives scoped (via the Allow entry's Sid) to the right user (Pattern 3) or group (Pattern 2). For Patterns 2 and 3 the Allow entry is paired with a required AuditAllowed entry: CMMC 3.3.2 user-action traceability rather than relying on an out-of-band sign-out ledger. Three patterns documented: Pattern 1 (vendor/model class allowlist for non-CUI), Pattern 2 (per-drive pool scoped to an Entra security group; recommended for CMMC), Pattern 3 (per-drive bound to a specific user; strongest audit trail). Naming convention also updated: (XML) suffix dropped from the Removable Media policy name across this chapter, the verification matrix, and Chapter 35.
CMMC Control Mapping Matrix gap fix: added rows for Local Administrators (3.1.5) and Audit and Event Logging (3.3.1/3.3.2) to both the GCC High and Commercial / 800-171 Rev. 3 tabs. Both policies were listed in the Layer 1 baseline tables but were missing from the verification matrix; readers using the matrix as their CMMC audit checklist would have had two undocumented gaps.
Scope clarification admonition at the top of the chapter making explicit that Chapter 31 covers 12 Layer 1 policies (4 Defender for Endpoint features specifically: ASR, AV Configuration, Security Experience, EDR Onboarding, plus 8 other Endpoint Security baseline policies that share the same Intune blade or pair with it), with cross-link to Chapter 29 Layered Deployment Strategy for the full 21-policy Layer 1 list
Defender for Cloud vs. Defender portal vs. Intune: which manages what
Concise opening rewrite: removed two large comparison tables; added "Onboarding paths" table for the three device populations
Naming reconciled with the actual OIB GitHub catalog (e.g., Win - OIB - ES - Windows Firewall - D - Firewall Configuration, not Firewall Rules); Cloud Kerberos Trust is SC (Settings Catalog), not ES, but is now Layer 1 mandatory for hybrid; Exploit Protection and Device Control are now Settings Catalog / Reusable Settings policies (not custom XML)

Chapter 9: Phishing-Resistant Authentication: FIDO2/Passkey desktop-app limitation

New section "FIDO2/Passkey Limitation on Windows Desktop Apps" with explicit {#aaguid-desktop-limitation} anchor
Documents the symptom: WAM/PRT step-up flows on Windows desktop apps strip the WebAuthn aaguid field, producing an all-zeros AAGUID (00000000-0000-0000-0000-000000000000) that fails AAGUID-restricted Conditional Access auth strengths
Documents the mechanism, why Windows Hello for Business and PIV+CBA bypass the limitation, decision matrix for which auth method to use per app surface, validation procedure, and a sign-in log diagnostic KQL
Cross-link added from the Conditional Access chapter's AAGUID-restricted key allowlist to this section

Chapter 17: Provisioning with Windows Autopilot

Hybrid Join known issues: DNS resolution, connector timeout, pre-staging conflicts, VPN bootstrap, clock skew
Clarified netsh Wi-Fi as OOBE-only bootstrapping

Chapter 21: AVD — Dedicated Sovereign Tenant

Sentinel pricing added to all cost tables (full M365 connector set)
New "Executive summary — what this architecture delivers" section: business-level framing of what the enclave is (CMMC attestation anchor, workstation scope reduction, controlled access end-to-end, contained data) and what it is not (not a company-wide migration, not a substitute for MDM on daily drivers, not an automatic Level 2 pass)

Significant Additions

Chapter 1: CUI Data Flows & Business Applications

New "Identifying CUI: The COPR Framework" section added before "The Four CUI Flow Categories": Creation, Ownership, Possession, Regulation as the four questions to ask of any data element when determining whether it is CUI in your environment

Chapter 35: GPO-to-Intune Migration

New "Client Meeting: OIB Policies of Interest" section: ten topic-grouped tables covering every Open Intune Baseline policy with scope, plain-language description, and a Decision column for live meeting note-taking
Accompanying XLSX generator script (openpyxl) that produces a pre-filled meeting workbook with header styling, freeze panes, and highlighted decision cells
Per-client GPO migration partial gained an "OIB ↔ GPO-Replacement Overlap Zones" section identifying where new OIB and GPO-replacement policies overlap with existing settings (avoids duplicate enforcement); Kiosk single-app and multi-app policies removed from Environment GPOs since they didn't originate from OIB, GPO, or existing inventory
Per-client GPO note-taking XLSX generator script produces a 6-worksheet workbook (combined "All Policies" tab plus per-group tabs) covering ~58 policies across five client-specific groups, with autofilter, no merged cells, frozen header pane, wrapped text on Recommendation/Notes columns, and per-policy adoption guidance

Chapter 50: Audit Readiness: new H2 sections

Organizing Evidence for the Assessment: comparison of evidence-management approaches (FutureFeed, IntelliGRC, StrikeGraph) and the tradeoffs between CMMC-specific platforms and general-purpose GRC tools
Working with Your C3PAO: selection guidance (prohibition on C3PAOs offering consulting on the same engagement), and assessment etiquette covering the hot-wash window and the three-sentence script for responding to assessor findings in the moment

New Appendices

Appendix D.2: AVD Firewall Reference

Full Azure Firewall rule reference for AVD GCC High deployments: application and network rule collections organized by function tier (AVD control plane, Windows/Intune updates, M365 services, customer app allow-lists), priority model, deny-all terminator, and the KQL troubleshooting queries for Azure Firewall logs.
Rule set rewritten around Microsoft-maintained FQDN tags (WindowsVirtualDesktop, Office365, MicrosoftIntune, WindowsUpdate, WindowsDiagnostics, MicrosoftActiveProtectionService), all cloud-aware, so a GCC High firewall resolves the tags to sovereign .us endpoints automatically.
The Office365 tag consolidates Exchange, SharePoint, Teams signaling, and Microsoft identity endpoints (including login.microsoftonline.us, *.msftauth.net, *.aadcdn.msftauth.net) into a single rule. The WindowsVirtualDesktop tag consolidates the AVD platform surface into one rule. WindowsUpdate rolls Delivery Optimization and WSUS catalog in. Similar consolidations across Windows-Management and Defender-For-Endpoint.
≈16 application rules versus the prior ≈40+, with Microsoft handling endpoint maintenance going forward. No quarterly audit drift against hand-maintained published endpoint lists.
Priority 200 FSLogix-SMB network rule removed: AVD deployments in this book use personal (assigned) host pools, where FSLogix isn't used; the rule was dead code.
Priority 220 KMS-Activation network rule added (TCP 1688 to AzureCloud service tag), replacing the inline FQDN-based Windows activation reference in Priority 100.
Bicep template is the source of truth; output/avd-firewall.bicep kept in lockstep with the in-doc template. Deployment, post-deployment validation, rollback, and CAB-evidence procedures documented.
FQDN tag content gap pattern documented as a chapter principle. Microsoft FQDN tags do not reliably carry sovereign-cloud (.us) endpoints in GCC High. Discovered through Azure Firewall deny-log forensics during real deployments and remediated by pairing every fqdnTags: entry with explicit targetFqdns: fallbacks. Specific gaps documented: *.wvd.azure.us (AVD platform), crl.microsoft.com (CRL/OCSP), client.wns.windows.com (Windows Push Notification Service), *.events.data.microsoft.com (Windows diagnostic), ecs.office.com (Office365 platform), *.wosc.services.microsoft.com (Windows OneSettings), *.edge.skype.com (Office365 signaling), *.manage.microsoft.us (Intune management), *.attest.azure.us (Azure Attestation for Trusted Launch VMs), and *.pki.core.windows.net (Microsoft PKI on commercial namespace cross-cloud, #disable-next-line no-hardcoded-env-urls applied to suppress the Bicep linter false-positive). Pattern saved as a memory reference for future engagements.

Appendix B: Intune Baseline Configurations

"Why this curation exists" subsection added to the appendix index: five-source ecosystem table (Microsoft Security Baselines, Microsoft STIG-audit baseline, OIB, CISA SCuBA, DISA STIGs) explaining why no single Microsoft-published canonical GCC High baseline exists and why this appendix curates from OIB rather than pointing readers at four incompatible sources.
Removable Media appendix substantial rewrite to teach the Reusable Settings + two-rule Block-then-Allow pattern. The prior version's single-rule "Block + Excluded Devices, Sid on Deny" model was structurally wrong: see Chapter 31 entry for the correction. Three deployment patterns documented (class allowlist, group-scoped pool, per-user binding). Verification table extended to confirm AuditAllowed events for Patterns 2 and 3. The (XML) suffix on the Device Control policy name dropped throughout: it's a Settings Catalog / Reusable Settings construct now, not Custom XML.
Exploit Protection appendix rewrite to a Settings Catalog policy with explicit DEP / ASLR / SEHOP / CFG enforcement and DisallowExploitProtectionOverride for tamper protection. Replaces the prior "golden machine Export-ProcessMitigation XML upload" workflow, which produced an XML re-asserting Windows 11 defaults and added no actual hardening, security theater that satisfied no CMMC control beyond what the OS does on its own. Per-program EMET-style mitigations (Office, Acrobat, line-of-business apps) preserved as a "Going further" sidebar for clients with EMET-migration scenarios. Mitigation acronyms now expanded with one-line explanations of what each defends against.
Two new primary Layer 1 appendices for LAPS v3.1 and LSP v3.0, generated directly from the OIB v3.1 / v3.0 JSON via the same generator script that produced the original seven Layer 1 entries. Both are the new Layer 1 default (manage the built-in Administrator account, universally compatible with Windows 10 and 11). The (24H2+) v3.6 variants of each policy are preserved as advanced/optional reference within the same appendix files under explicit \{#section-7-advanced\} and \{#section-8-advanced\} anchors, Chapter 29's matched-pair note resolves directly to those sections.
Markdown heading conversion across all 18 appendices: raw HTML <h2 id="section-N"> headings replaced with Markdown ## name \{#section-N\} form. Docusaurus's broken-anchor checker only recognizes Markdown-derived anchor IDs; the previous raw-HTML pattern worked at runtime but failed static validation when cross-page links targeted those anchors. The generate_layer1.py script was updated in lockstep so future regenerations stay on the new convention.
Seven new Layer 1 entries generated to bring Appendix B into alignment with the 21-policy Layer 1 baseline introduced in Chapter 29. All seven ship with full settings tables; the generator uses two paths depending on policy type:
- Compliance policies (sidebar 12–15: Password, Device Security, Device Health, Defender for Endpoint): parsed directly from the OIB compliance-policy JSON; flat passwordRequired / requireSecureBoot / etc. property fields render to per-row entries with camelCase-to-title-case display names
- Settings Catalog policies (sidebar 16–18: Defender Antivirus AV Configuration, Windows Firewall Firewall Configuration, Audit and Event Logging): extracted from OIB's pre-rendered SETTINGSOUTPUT.md (the IntuneManager-resolved Markdown the OIB project ships in its repo). The JSON for these policies carries opaque device_vendor_msft_policy_config_* setting IDs only; the resolved display names and choice labels come from SETTINGSOUTPUT.md. The OIB-flavored Markdown is then converted to Docusaurus-flavored MDX via the standard 4-step transformation (class= → className=, colspan= → colSpan=, inline style='...' → JSX object form, drop any leading <style> block).
Generator script at docs/06-appendices/b-intune-baseline-configurations/assets/generate_layer1.py idempotently reproduces all seven entries from the OIB source-of-truth files. Re-run after pulling a new OIB version, or extend to cover Layer 2 by adding entries to the new_entries list.
Each new entry includes the standard *[CMMC Control Mapping Matrix](...)* back-link to Chapter 29 (the matrix moved with the OIB content during the Mobile/OIB chapter split).

Terminology

Legacy "Azure AD" references cleaned up where safe (branding references only, registry keys, API names, and UI labels left as-is)

Infrastructure

Docusaurus upgraded to 3.10 with future.v4 flag and MDX1 compat re-enabled
Rspack bundler disabled (dev mode crash): all other v4 performance features active
Phase 5 directory renamed on disk: 05-monitoring → 05-m365security; build scripts, print templates, and category labels updated accordingly
Full cross-phase chapter renumbering to restore sequential numbering (12 folders, ≈50 page files, ≈19 client-specific reference files); URLs preserved via front-matter id fields so internal links and external bookmarks continue to resolve
Second renumbering pass for the Chapter 29 (OIB Deployment) insertion: files 12-4 through 12-9 renamed to 12-5 through 12-10; sidebar_position bumped on each. URLs preserved via stable id fields. Print template imports updated for the new file paths in DevicePhase.tsx and 9 client templates; new OIBDeployment prop slot added to the device phase rendering pipeline
New build-tenantarchitecture.mts print pipeline for the conglomerate/tenant-architecture client deliverable
Anchor hygiene: Variable Stale Thresholds in the Entra Device Hygiene chapter promoted from a bolded paragraph to a proper H3 heading with explicit \{#variable-stale-thresholds\} anchor (Docusaurus's broken-anchor checker only validates heading-derived anchors, not arbitrary HTML id attributes)
KDP gutter fixes in docraptor.mts: tighter list containment (explicit ul/ol padding-left, li overflow-wrap), pre/code box-sizing: border-box so internal padding no longer overflows parent width, paragraph + list-item overflow-wrap: anywhere to avoid stranded-character wraps at the gutter edge, and gutter buffer bumped from 0.875" to 0.95" (well above KDP's 0.625" minimum for 301-500 page books). Addresses "insufficient gutter" warnings on the KDP previewer where lone characters or list bullets landed flush at the binding edge despite the gutter margin being correctly above the minimum.

v2026.03.31

Initial release.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.

Unreleased​

Significant Updates​

v2026.08.31​

New Sections​

Significant Updates​

CMMC Program Currency (July 2026 Suspension)​

Chapter 12: Device Operations​

Appendix B: Intune Baseline Configurations​

Appendix D.2: AVD Firewall Reference​

Appendix D.4: AVD East-West Segmentation​

Chapter 17: SIEM Strategy​

Book-wide​

v2026.08.03​

Major Rewrites​

New Sections​

Print Edition​

Significant Updates​

Chapter 8: Identity Foundation​

Chapter 11: Device Architecture​

Chapter 12: Device Operations​

Chapter 14: Information Protection (Implementation)​

Chapter 17: SIEM Strategy​

Appendix B: Intune Baseline Configurations​

Appendix D: AVD Firewall Reference​

Appendix D: AVD Runbook​

v2026.06.30​

New Sections​

Significant Updates​

Introduction​

Chapter 1: Scoping​

Chapter 8: Identity Foundation​

Chapter 9: Conditional Access​

Chapter 11: Device Architecture​

Chapter 12: Device Operations​

Chapter 14: Information Protection (Implementation)​

Chapter 8: Identity Foundation​

Chapter 16: Threat Defense​

Chapter 17: SIEM Strategy​

Appendix A: Compliance Controls​

Across multiple chapters​

v2026.05.31​

Significant Updates​

Identity & Conditional Access​

Firewall​

AVD (Runbook & Enclave)​

Devices & Endpoint Management​

Data Protection​

Monitoring, SIEM & Compliance​

Site Improvements​

v2026.04.30​

New Chapters​

Structural Changes​

Major Rewrites​

Significant Updates​

Significant Additions​

New Appendices​

Appendix B: Intune Baseline Configurations​

Terminology​

Infrastructure​

v2026.03.31​

📩 Don't Miss the Next Solution

Unreleased

Significant Updates

v2026.08.31

New Sections

Significant Updates

CMMC Program Currency (July 2026 Suspension)

Chapter 12: Device Operations

Appendix B: Intune Baseline Configurations

Appendix D.2: AVD Firewall Reference

Appendix D.4: AVD East-West Segmentation

Chapter 17: SIEM Strategy

Book-wide

v2026.08.03

Major Rewrites

New Sections

Print Edition

Significant Updates

Chapter 8: Identity Foundation

Chapter 11: Device Architecture

Chapter 12: Device Operations

Chapter 14: Information Protection (Implementation)

Chapter 17: SIEM Strategy

Appendix B: Intune Baseline Configurations

Appendix D: AVD Firewall Reference

Appendix D: AVD Runbook

v2026.06.30

New Sections

Significant Updates

Introduction

Chapter 1: Scoping

Chapter 8: Identity Foundation

Chapter 9: Conditional Access

Chapter 11: Device Architecture

Chapter 12: Device Operations

Chapter 14: Information Protection (Implementation)

Chapter 8: Identity Foundation

Chapter 16: Threat Defense

Chapter 17: SIEM Strategy

Appendix A: Compliance Controls

Across multiple chapters

v2026.05.31

Significant Updates

Identity & Conditional Access

Firewall

AVD (Runbook & Enclave)

Devices & Endpoint Management

Data Protection

Monitoring, SIEM & Compliance

Site Improvements

v2026.04.30

New Chapters

Structural Changes

Major Rewrites

Significant Updates

Significant Additions

New Appendices

Appendix B: Intune Baseline Configurations

Terminology

Infrastructure

v2026.03.31