Skip to main content

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 (targeting v2026.07.31)

In progress. These changes are merged but not yet cut as a release; this section may still grow before v2026.07.31 ships.

Major Rewrites

  • Dual-track rendering pass (Chapters 11, 12, and Appendix B): the device chapters now render as two clean tracks. GCC High readers see CMMC-framed content (control IDs, C3PAO/assessor language, sovereign-endpoint caveats); Commercial readers see the same technical guidance framed against NIST SP 800-171 Rev. 3 with the GCC High-only material removed rather than caveated. Implemented via gcch-only / comm-only scope gating across 11-1, 11-2, 11-5, 11-8, 12-1, 12-3, 12-4, 12-5, 12-6, 12-9, and all 18 Appendix B policy pages (the Appendix B page generator generate_layer1.py was updated so regenerated pages keep the paired CMMC / NIST 800-171 control-mapping links). Includes Commercial-native variants of the Autopilot generation table, the OIB import-issues table, the MDE server licensing and recommendation matrices, the MDVM add-on decision table, and the "why Intune diagnostics" framing ("what a reviewer asks" vs. "what an assessor asks").

New Sections

  • Device Management Strategy (11-1): when moving device management to Intune is actually required versus when GPO/MECM remains fine. Names the five capabilities only Intune provides: the device-compliance signal Conditional Access consumes, management of Entra-joined devices (no domain, no GPO), removing authentication dependence on domain-controller line of sight, real MDM/MAM for iOS/Android and BYOD, and touchless Autopilot provisioning. A companion list covers what AD consolidation (M&A) adds to the case: one-time profile migration keyed to Entra identity (with the ms-DS-ConsistencyGuid source-anchor recommendation), doing the GPO review once, and network-topology independence. The Hybrid Join framing in the same chapter was softened 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; inbound channels are ingest-only, so microphone redirection is "functionally the keyboard of KVM" and no more places the endpoint in scope than typing CUI does; screen sharing stays blocked by Screen Capture Protection (recipients see protected frames while audio flows). Adds an SC.L2-3.13.12 row to the control-mapping table: Teams in GCC High provides no remote activation of a participant's mic or camera, and Windows surfaces a persistent in-use indicator. The Chapter 10 screen-capture-protection scoping question and an 11-7 cross-link were updated to match.

  • 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 (find it by SID: Get-LocalUser | Where-Object { $_.SID.Value.EndsWith('-500') }) and that name goes in the row-13 policy alongside WLapsAdmin. Validate one device before assigning row 14: LAPS policy landed in the registry, the account exists (a transient 65000 error on row 13 is expected and self-heals), and the password is retrievable in the portal; only then flip the built-in Administrator off.

  • 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 showing Managed by: MDE while delivering no policy. (1) Registration never completed: SCP / Entra Connect misconfiguration, diagnosed via the HKLM\SOFTWARE\Microsoft\SenseCM\EnrollmentStatus error codes (36/37 = Entra Connect, 38/41 = DNS, 18 = certificate from another tenant). (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, sign-ins fail with AADSTS50155, and the fix is sync scope first, then dsregcmd /debug /leave and re-register (deleted device objects cannot be restored). In either state only the GPO half and sensor-based assessment still operate: treat the device as unmanaged for evidence purposes. Related refinements in the same chapter: the OS (client vs. server) is what distinguishes the two Managed by: MDE models in inventory; a hybrid-joined MDE-managed workstation can still be identity-gated via the Require Microsoft Entra hybrid joined device grant (proving it's corporate, not that it's healthy); and devices inactive >30 days drop out of exposure-score/secure-score data, so a spun-down machine's posture evidence goes stale.

Significant Updates

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

Chapter 11: Device Architecture

  • 11-3 (Cloud-Only): MDM enrollment URL verification added to the Phase 2 checklist, with the GCC High trap documented in place: the sovereign .us discovery/terms-of-use/compliance URLs, and the warning not to click "Restore default MDM URLs" (it can reset a GCC High tenant to the commercial .com endpoints and fail enrollment with 0x80192efd), cited to the US Government endpoints page on Learn. 11-2's Autopilot Step 1 now points here instead of duplicating the URL list. The 11-3/11-4 "Critical Sovereign Check" callouts were renamed "Critical Cloud Check" (the failure is symmetric: a Commercial device pointing at .us is enrolling in the wrong cloud too).

Chapter 12: Device Operations

  • 12-6 (Defender for Endpoint): "Onboard Defender for Endpoint after Entra hybrid join completes" section added for the GPO onboarding race: MDE onboarded before Entra hybrid join completes leaves a synthetic Entra device object (blank Join Type, managementType = MicrosoftSense) that fails Microsoft's documented self-removal, and Conditional Access then resolves against it (AADSTS53001 DeviceNotDomainJoined / AADSTS53000 DeviceNotCompliant). Includes the MDE-Onboarding-Gate.ps1 wrapper (defers onboarding until dsregcmd shows hybrid join complete, checks the documented OnboardingState = 1 registry flag on both ends, event-logs stuck devices) plus remediation for already-duplicated fleets. 12-9's identification table gained the matching MDE-synthetic discriminator row and a cross-link.
  • 12-9 (Entra Device Hygiene): the hybrid rejoin procedure is now nine numbered steps. The pre-state capture (dsregcmd /status to a file, plus a manage-bde check that the BitLocker recovery key is escrowed) previously sat above the list as an unnumbered "Step 0" in a code block, so the heading promised eight steps while the reader had nine things to do. It is now Step 1 with its commands nested under it, and the remaining steps renumbered to 2 through 9. Capturing the baseline before anything is destroyed is what makes the Step 8 verification meaningful, so it reads as an action, not a preamble.

Chapter 14: Information Protection (Implementation)

  • 14-8 (Copilot Data Readiness): guardrail set updated for the RSS retirement. Restricted Access Control (RAC) is now presented as the durable governance boundary (gates a site to up to 10 designated groups; a user needs both the site permission and group membership, so it isn't another sharing path), Restricted Content Discovery as the temporary hide-from-Copilot control, and Restricted SharePoint Search as retiring (new enablement blocked starting July 31, 2026: use RCD instead). Licensing tables corrected on both tabs: a single Microsoft 365 Copilot license in the tenant unlocks the SharePoint Advanced Management feature set (confirmed for GCC High and DoD on Learn), so the SharePoint Premium add-on is needed only in tenants with no Copilot licenses. The 11-7 enclave licensing table carries the same SAM note.

Chapter 17: SIEM Strategy

  • Sentinel workspace setup is now create-or-reuse, matching the AVD runbook's Step 5 model. If the tenant already has a Log Analytics workspace (e.g., law-avd-usgovva), the chapter now says to enable Sentinel on it instead of creating law-sentinel-prod-usgovva, with the rationale (analytics rules only see the Sentinel-enabled workspace; the Defender for Servers ingestion benefit requires servers and Sentinel on the same workspace; 90-day vs 31-day hot retention) and the honest trade-off (Sentinel pricing applies to operational tables in the enabled workspace). Previously the chapter unconditionally created a second workspace, producing exactly the split-workspace state its own cost note warns about.
  • Workspace setup gained substep 5: connect the workspace to the Defender portal (field-found in a live GCC High deployment): Sentinel's menus, including Content hub, appear in the Defender portal only after System → Settings → Microsoft Sentinel → Connect a workspace, and Microsoft's "auto-onboarded in many cases" claim did not hold in the field. The chapter now documents the connect step, the unconnected-tenant symptom (the "Connect a workspace" home-page banner and no Sentinel navigation), and the Azure-portal equivalent path that works in the meantime.
  • Content-deployment navigation flipped to Azure-portal-primary. Field deployments confirmed the Defender portal's Sentinel menus render only for accounts with directly assigned Azure RBAC (Microsoft states GDAP/Azure Lighthouse delegation is not supported for Sentinel data there), which reliably blanks the experience for partner-delivered engagements even on a connected, healthy workspace. All step-by-step paths now run through Azure portal → Microsoft Sentinel → [workspace]; the Defender-portal connect step remains as required plumbing for Defender XDR incident/alert sync, and a note records the Azure-portal retirement date (March 31, 2027) so tenant-member readers plan the surface transition.

Appendix D: AVD Runbook

  • Pooled multi-session variant documented end-to-end (prompted by a live deployment): a new "Variant: Pooled Multi-Session Host Pool" section maps all 15 runbook steps to the pooled case (reuse 1–6 and the workspace; new Pooled host pool with depth-first load balancing and a broker-enforced max session limit; multi-session gallery image; skip per-user pinning and compute-level backup; re-apply RDP properties and SSO per pool). The 11-6 Host Pool Model section gained the decision framework ("When pooled multi-session is the right call": scale and sparse-use triggers, with the ride-along costs: the FSLogix-at-host-#2 threshold, the shared-OS isolation narrative, host-pool-type immutability, and an Intune verify-before-fleet gate), and the Chapter 10 architecture-principles table now points to it. Includes the two-identical-SessionDesktop-icons field gotcha and its Update-AzWvdDesktop -FriendlyName fix.
  • Virtual Machine User Login must be an Active, permanent assignment (not PIM-eligible): new callout from a live deployment. 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." Pick Active + Permanent on the Assignment type tab (which only appears when PIM for Azure resources is licensed); reserve PIM elevation for Owner/Contributor/VM Administrator Login.
  • 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 (PIV/CBA and FIDO2 desktop step-up failure) and reproducible in the sign-in logs, grounded in the cited Microsoft architecture pages.
  • 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 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: ObjectIdOfficeObjectId, SiteUrlSite_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-monitoring05-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.