Phase 1 — Modernization Mechanics

Identity, device, policy, and compliance modernization for GCC-Moderate M365

Section 1: Purpose and Scope

This document defines the modernization mechanics for Phase 1 of the Unified Infrastructure and Architecture Operations (UIAO) framework. Phase 1 focuses on the foundational operational transitions required to move a Microsoft 365 tenant from legacy on-premises management patterns to cloud-native governance under GCC-Moderate compliance. The modernization mechanics described herein establish the deterministic sequencing, technical procedures, governance controls, and gate criteria that govern every operational transition within Phase 1. Each section is designed to be self-contained — readable and actionable in isolation — while maintaining full reference-awareness across the document.

This document supersedes no prior version. It is the initial pre-release establishing the modernization mechanics baseline for UIAO Phase 1. The scope of this document covers: identity modernization, device identity transitions, OrgPath governance expansion (including device OrgPath), Group Policy to Intune conversion, Azure Arc enrollment for hybrid server management, boundary resolution considerations, SCuBA operationalization, drift detection and remediation, and modernization sequencing. Each domain is treated as a discrete modernization work stream with defined inputs, outputs, prerequisites, and gate criteria that integrate into the overall Phase 1 sequence.

This document operates within the UIAO Canon governance framework, where canon/ is the single source of truth for all artifacts. All content produced under Phase 1 traces provenance to canonical sources. Every artifact, policy, configuration baseline, and operational procedure referenced or produced by the mechanics in this document must comply with Canon governance rules: immutable history, documented ownership, provenance chains, and the UIAO metadata schema. Orphaned artifacts — those without provenance or ownership — are CI-blocking under UIAO Canon rules.

Section 2: Modernization Sequencing

The modernization sequence governs the order of operations for all Phase 1 work. This sequence is deterministic: each step has defined prerequisites that must be satisfied before execution begins, defined key actions that constitute the work, gate criteria that must be met before the step is considered complete, and defined outputs that feed downstream steps. Deviation from this sequence requires formal governance review and Canon Steward approval.

Table 1: Phase 1 Modernization Sequence

Sequence Step	Domain	Prerequisites	Key Actions	Gate Criteria	Outputs
1	Identity Foundation	Tenant access; Entra ID P1/P2 licensing confirmed; directory synchronization operational	Entra ID hygiene audit; orphaned account remediation; user lifecycle review; MFA enforcement via Conditional Access; passwordless readiness assessment; service account inventory	Zero orphaned accounts; 100% MFA registration; Conditional Access policies deployed and validated; legacy per-user MFA disabled; service account inventory complete	Identity Hygiene Report; MFA Enforcement Policy Set; Passwordless Readiness Assessment; Service Account Register
2	OrgPath Establishment	Step 1 complete; organizational structure data available (department, location, cost center); Entra ID P1 licensing for Administrative Units	Administrative Unit architecture design; AU creation; dynamic membership rule configuration; user-to-AU assignment validation; scoped RBAC role assignment; OrgPath governance documentation	All users assigned to correct AUs; dynamic membership rules validated; scoped RBAC assignments tested and confirmed; OrgPath architecture document published to canon/	OrgPath Architecture Document; AU Configuration Manifest; Scoped RBAC Assignment Register
3	Device OrgPath Extension	Step 2 complete; device inventory available; Graph API permissions configured for device-to-user correlation	Device-to-AU correlation script development (PowerShell); device AU creation; device assignment execution; scoped device administration validation; BitLocker/LAPS scoping confirmation	All managed devices correlated to owning user's AU; scoped device administration operational; BitLocker key recovery scoped to AU; LAPS administration scoped to AU	Device OrgPath Correlation Script; Device AU Assignment Report; Scoped Device Administration Validation Report
4	Device Identity Modernization	Step 3 complete; device inventory with join-type classification; application compatibility assessment initiated	Hybrid Join device inventory; Entra Join migration planning; Kerberos Cloud Trust assessment; Conditional Access device trust policy design; Autopilot profile configuration for new devices	Device identity transition plan published; Autopilot profiles deployed for new provisioning; Kerberos Cloud Trust evaluated; device trust Conditional Access policies staged	Device Identity Transition Plan; Autopilot Configuration Profiles; Device Trust Policy Set (staged)
5	Policy Conversion	Step 3 complete; GPO inventory exported as XML; Intune licensing confirmed; MDM enrollment verified for target devices	GPO inventory and rationalization; Group Policy Analytics import; compatibility analysis; Settings Catalog migration for supported settings; Proactive Remediations for unsupported settings; coexistence testing; policy ownership mapping	All active GPOs inventoried and classified; migration path determined for each GPO; Settings Catalog policies deployed to pilot groups; coexistence tested; policy ownership documented per OrgPath	GPO Inventory and Rationalization Report; Settings Catalog Policy Set; Proactive Remediation Script Library; Policy Ownership Register
6	Server Modernization	Step 3 complete; Azure subscription provisioned; Azure Arc resource group configured; Connected Machine Agent package available	Azure Arc enrollment for non-production servers; management capability validation; production server enrollment; Azure Update Manager configuration; Change Tracking activation; legacy agent decommission planning	All target servers Arc-enrolled; Azure Update Manager operational; Change Tracking reporting confirmed; management parity with legacy tools validated	Arc Enrollment Register; Azure Update Manager Configuration; Change Tracking Baseline; Legacy Agent Decommission Plan
7	SCuBA Baseline Operationalization	Steps 1–5 substantially complete; ScubaGear module installed; M365 API permissions granted; UIAO SCuBA orchestration layer configured	ScubaGear deployment; initial baseline assessment across all workloads; canonical desired-state definition; UIAO SCuBA orchestration integration; drift detection activation; SLA heatmap configuration	ScubaGear baseline assessment complete for all workloads; desired-state definitions published to canon/; UIAO SCuBA orchestration consuming ScubaGear outputs on schedule; drift detection operational	SCuBA Baseline Assessment Report (all workloads); Desired-State Definitions (canonical); UIAO SCuBA Orchestration Configuration; Drift Detection Activation Report
8	Drift Detection Activation	Step 7 complete; desired-state definitions published; remediation workflow defined; owner accountability chains established per OrgPath	Drift detection engine configuration; severity classification rules deployment; SLA timer integration; remediation workflow activation; escalation chain configuration; provenance recording integration	Continuous drift monitoring operational across all domains; SLA timers enforced; escalation workflows tested; provenance records generated for all drift events	Drift Detection Engine Configuration; SLA Matrix (operational); Escalation Chain Document; Provenance Recording Validation Report
9	Boundary Alignment	Ongoing — no hard prerequisite; initiated at Phase 1 start and runs continuously	Boundary intersection identification; assessment of M365 GCC-Moderate and Azure Commercial interactions; governance gap analysis; boundary documentation; resolution pathway mapping	All identified boundary intersections documented with assessment status, owner, and target resolution date; no unassessed boundary gaps remain	Boundary Assessment Register; Governance Gap Analysis; Boundary Resolution Roadmap (draft)

This sequence is not strictly linear. Steps 1–3 are sequential prerequisites — each must be completed before the next begins, as OrgPath establishment depends on identity hygiene, and device OrgPath depends on user OrgPath. However, Steps 4–6 may execute in parallel once OrgPath (Steps 1–3) is established, as device identity modernization, policy conversion, and server modernization are independent work streams that share OrgPath as a common dependency. Steps 7–8 activate once sufficient policy conversion (Step 5) is complete, as SCuBA baseline operationalization and drift detection require policies to be in their target state for meaningful assessment. Step 9 (Boundary Alignment) runs as a continuous background assessment throughout Phase 1, producing interim deliverables as boundary intersections are identified and assessed.

Section 3: Identity Modernization

Identity modernization is the foundational prerequisite for all subsequent Phase 1 work. No device identity transition, policy conversion, or governance scoping can proceed reliably until the identity layer is clean, modern, and governed. This section defines the identity modernization mechanics that must be executed and validated before OrgPath establishment (Section 4) can begin.

3.1 Entra ID User Lifecycle Hygiene

Entra ID user lifecycle hygiene ensures that every user object in the tenant is properly synchronized, actively governed, and accurately attributed. The hygiene assessment identifies and remediates: orphaned accounts (user objects with no active owner or business justification), stale accounts (accounts that have not authenticated within a defined inactivity threshold), synchronization errors (directory sync failures that leave objects in an inconsistent state), duplicate objects (multiple user objects representing the same identity), and attribute inconsistencies (missing or incorrect department, location, or cost center values that will impair OrgPath dynamic membership rules).

3.2 MFA Enforcement

Multi-Factor Authentication (MFA) enforcement must transition from legacy enforcement methods to Conditional Access-driven MFA. Legacy MFA patterns include per-user MFA (enabled/enforced directly on the user object), NPS Extension-based MFA for VPN and RADIUS authentication, and Azure MFA Server (on-premises). The target state is Conditional Access policies that enforce MFA based on risk signals, application sensitivity, network location, and device compliance — not as a blanket per-user toggle. Legacy per-user MFA must be disabled for all users once Conditional Access MFA policies are validated and operational.

3.3 Passwordless Readiness

Passwordless readiness assesses the organization's capability to adopt passwordless authentication methods. The three primary passwordless methods supported in Microsoft Entra ID are: Windows Hello for Business (biometric or PIN-based, device-bound credential), FIDO2 security keys (hardware-based, phishing-resistant, portable credential), and Microsoft Authenticator passwordless sign-in (phone-based, number-matching). Readiness assessment covers hardware compatibility (TPM 2.0 for WHfB, USB/NFC support for FIDO2), user training requirements, helpdesk impact, and rollback procedures.

3.4 Service Account Modernization

Service account modernization identifies all service accounts, shared mailboxes, and non-person entities that authenticate to M365 services and transitions them to modern identity patterns. Where applicable, service accounts should be replaced with Managed Identities (for Azure-hosted workloads) or workload identity federation (for external services). Service accounts that cannot be modernized must be documented, governed with strict Conditional Access policies, and registered in the Service Account Register with defined ownership and review cadence.

3.5 Authentication Method Registration

Authentication method registration enforcement ensures that all users have registered at least two modern authentication methods before policy enforcement gates close. The Authentication Methods Registration Campaign feature in Entra ID can prompt users to register additional methods. Registration completeness is a gate criterion for Step 1 — identity modernization cannot be marked complete until registration targets are met.

Table 2: Identity Modernization Checklist

Item	Current State Assessment	Target State	Dependency	Priority
Orphaned account remediation	[Assess: count of orphaned objects, last sign-in date analysis]	Zero orphaned accounts; all objects have documented ownership	Directory sync health; HR data feed accuracy	Critical
Stale account identification and disable	[Assess: accounts with no sign-in within 90 days]	Stale accounts disabled or justified; review cadence established	Sign-in log retention; business justification process	Critical
MFA — Conditional Access migration	[Assess: per-user MFA count; NPS Extension usage; legacy MFA Server status]	All MFA enforcement via Conditional Access; per-user MFA disabled; legacy MFA Server decommissioned	Conditional Access policy design; Entra ID P1 licensing	Critical
Authentication method registration	[Assess: percentage of users with ≥2 modern methods registered]	100% of active users registered with ≥2 modern authentication methods	Registration campaign configuration; user communication plan	High
Passwordless readiness assessment	[Assess: device TPM 2.0 inventory; FIDO2 hardware procurement status; pilot group identification]	Readiness report published; pilot group identified; hardware procurement initiated	Device inventory (TPM status); budget approval for FIDO2 keys	High
Service account inventory and modernization	[Assess: count of service accounts; authentication patterns; dependency mapping]	All service accounts inventoried; modernization path defined (Managed Identity / workload identity / governed legacy); ownership documented	Application owner identification; workload hosting architecture	High
Directory synchronization health	[Assess: sync error count; object mismatch rate; connector health]	Zero persistent sync errors; all objects consistent between on-premises AD and Entra ID	Entra Connect health; on-premises AD hygiene	Critical
Attribute completeness for OrgPath	[Assess: percentage of users with populated department, location, cost center attributes]	≥98% attribute completeness for OrgPath-critical attributes	HR data feed; attribute mapping rules in Entra Connect	High

Section 4: OrgPath Governance — Expanded for Devices

4.1 OrgPath Definition

OrgPath is the UIAO term for the organizational path governance model built on Microsoft Entra Administrative Units (AUs). OrgPath establishes the deterministic mapping of organizational structure to Entra Administrative Units, creating governance boundaries, scoped administration, and accountability chains that replace the legacy OU-based governance model from on-premises Active Directory. Where Active Directory OUs governed object placement and Group Policy inheritance through a hierarchical tree, OrgPath governs administrative scope and governance accountability through flat, role-scoped, audit-traceable Administrative Units in the cloud.

4.2 OrgPath Architecture for Users

The user OrgPath architecture establishes Administrative Units as governance containers — not security boundaries, but administrative scoping boundaries that define who can manage whom. The architecture is governed by the following principles:

• Administrative Units as governance containers: Each AU represents a defined organizational scope (e.g., a department, a regional office, a business unit). Users are assigned to AUs based on their organizational attributes.

• Dynamic AU membership rules: Where possible, AU membership is driven by dynamic rules based on user attributes — department, location, cost center, or company name. Dynamic membership ensures that governance assignment is automatic and consistent as users move within the organization.

• Scoped RBAC: Role assignments are bounded to AU scope rather than tenant-wide. A Helpdesk Administrator scoped to an AU can reset passwords only for users within that AU. This eliminates the legacy pattern of tenant-wide administrative privilege.

• OrgPath hierarchy design principles: Flat-first (minimize nesting), role-scoped (design AUs around administrative need, not org chart vanity), and audit-traceable (every AU membership change is logged and provenance-tracked).

4.3 Device OrgPath Extension

Device OrgPath extends the same governance scoping model to device objects. This is the primary expansion in Phase 1 — establishing that devices are not ungoverned objects floating in the tenant, but are correlated to their owning user's Administrative Unit and subject to the same scoped administration model.

The device OrgPath correlation mechanism operates as follows:

• Device-to-user correlation via Graph API automation (PowerShell-first): The device OrgPath correlation script queries all Administrative Units, extracts user members from each AU, resolves each user's registered and owned devices via Microsoft Graph, and assigns those devices to the user's AU. This creates a deterministic user-to-device governance chain.

• Hybrid membership approach: Dynamic AU membership for devices is limited. The device attributes available for dynamic membership rules in Entra ID are significantly fewer than user attributes — devices lack department, cost center, and location attributes natively. Therefore, a hybrid approach is required: scripted assignment (PowerShell-based, scheduled) handles the primary correlation, supplemented by dynamic rules where device attributes permit (e.g., device OS, device trust type).

• Scoped device administration capabilities: Device OrgPath enables scoped BitLocker key recovery (administrators can recover keys only for devices in their AU), scoped Windows LAPS administration (local admin password retrieval bounded to AU), scoped device compliance reporting (compliance dashboards filtered by AU), and scoped Intune policy assignment (policies targeted to device groups derived from AU membership).

• Governance accountability: Device OrgPath ensures that the same administrator who manages a user also has scoped authority over that user's devices. This prevents cross-boundary administrative drift — the condition where device administration is disconnected from user governance, creating accountability gaps.

+———————————————————————-+

Figure 2.1 — Diagram showing OrgPath architecture with user AUs on the left, device correlation flow in the

Table 3: OrgPath Governance Model — Users and Devices

Governance Element	User OrgPath	Device OrgPath	Correlation Method	Automation Approach
Administrative Unit assignment	Users assigned to AUs based on department, location, cost center	Devices assigned to AU of owning/registered user	User attribute → AU (dynamic); Device → User → AU (scripted)	Dynamic membership rules (users); PowerShell Graph API script on scheduled cadence (devices)
Scoped RBAC	Helpdesk Admin, User Admin, Authentication Admin scoped to user AU	Intune Admin, BitLocker Recovery, LAPS Admin scoped to device AU	Same AU scope for user and device; correlated by ownership	Role assignments configured per AU; validated via scoped access testing
Membership maintenance	Dynamic rules auto-update as user attributes change	Scheduled script re-evaluates device-to-user correlation; adds/removes devices as ownership changes	User: attribute-driven (automatic); Device: ownership-driven (scripted)	Users: Entra dynamic membership engine; Devices: PowerShell runbook on 4-hour cadence
BitLocker key recovery	N/A (user-level operation)	Recovery scoped to devices within administrator's AU	Device AU membership determines recovery authorization	Entra AU-scoped Cloud Device Administrator role
Windows LAPS administration	N/A (device-level operation)	LAPS password retrieval scoped to devices within administrator's AU	Device AU membership determines LAPS access	Entra AU-scoped role with LAPS read permission
Compliance reporting	User compliance (MFA status, license assignment, risk level) filtered by AU	Device compliance (encryption, patching, OS version) filtered by AU	Reporting queries filtered by AU membership	PowerShell/Graph API reporting scripts with AU filter parameter
Governance accountability	User governance owner = AU-scoped administrator	Device governance owner = same AU-scoped administrator (via user correlation)	Single accountability chain: Admin → AU → User + Devices	OrgPath accountability register maintained in canon/

Section 5: Device Identity Modernization

Device identity modernization transitions the tenant's device trust model from legacy patterns to cloud-native defaults. This section covers the assessment, planning, and execution mechanics for moving devices from their current join types to the target cloud-native posture.

5.1 Current State Assessment

The device identity assessment produces a comprehensive inventory classified by join type: Hybrid Azure AD Joined (devices joined to both on-premises AD and Entra ID, managed via Group Policy and/or SCCM), domain-joined only (devices joined to on-premises AD but not registered in Entra ID — invisible to cloud governance), Entra ID Joined (cloud-native devices joined only to Entra ID, managed via Intune), and Entra Registered (BYOD devices registered for conditional access but not domain-joined). Each device must be classified, and the inventory must include management agent status (SCCM client, Intune MDM enrollment, co-management state), OS version and build, TPM version, and primary user assignment.

5.3 Migration Path

The transition from Hybrid Join to Entra Join is not a simple re-join operation. A device cannot be "un-hybrid-joined" and "re-Entra-joined" in place without disruption. The migration requires careful sequencing: authentication trust must be validated (the user can authenticate to all required resources without on-premises AD line-of-sight), policy coverage must be confirmed (all GPO settings have been migrated to Intune per Section 6), application compatibility must be tested (all applications function with cloud-only identity), and data/profile continuity must be planned (user profiles, data, and settings are preserved through the transition).

5.4 Kerberos Cloud Trust

For organizations maintaining Hybrid Join during the transition period, Kerberos Cloud Trust provides a modernized hybrid identity method. Kerberos Cloud Trust eliminates the synchronization delay and AD FS dependency of legacy key trust and certificate trust Hybrid Join methods. With Kerberos Cloud Trust, Windows Hello for Business authentication in Hybrid Join scenarios works by obtaining a Kerberos TGT from Entra ID rather than from a domain controller, significantly simplifying the infrastructure requirements.

5.5 Device Trust Model

Conditional Access policies must evaluate device compliance and device identity together. Device trust is not binary — it is a function of join type (Entra Joined, Hybrid Joined, Registered), compliance state (compliant, not compliant, not evaluated), and management enrollment (MDM-enrolled, co-managed, unmanaged). Conditional Access grant controls should require both device compliance and a specific join type for access to sensitive resources, creating a layered trust evaluation.

5.6 Autopilot Integration

All new device provisioning should default to Entra Join + Windows Autopilot, eliminating the need for on-premises imaging infrastructure (WDS, MDT, SCCM OSD). Autopilot profiles should be configured with the Enrollment Status Page (ESP) to ensure all policies and applications are installed before the user reaches the desktop. Autopilot pre-provisioning (white glove) should be evaluated for scenarios requiring IT-touch provisioning.

Table 4: Device Identity Transition Matrix

Current Join Type	Target Join Type	Migration Path	Key Risks	Prerequisites	Timeline Estimate
Hybrid Azure AD Joined	Entra ID Joined	Staged: validate app compatibility → confirm Intune policy coverage → migrate user profile → disjoin from on-premises AD → Entra Join (or wipe/reprovision via Autopilot)	Application dependency on on-premises AD (Kerberos); user profile/data loss during reprovisioning; GPO gap if Intune migration incomplete	Intune policy migration complete (Section 6); application compatibility tested; user data backup/migration plan; Autopilot profile configured	6–12 months (phased by department/location)
Domain-joined only (not Entra registered)	Entra ID Joined	Register in Entra ID first (Hybrid Join as interim) → then follow Hybrid-to-Entra path; or wipe and reprovision via Autopilot if device is eligible	Device is currently invisible to cloud governance; may have undocumented dependencies on on-premises resources; no Intune management agent present	Device must be inventoried and classified; MDM enrollment must be established; all dependencies documented	3–6 months (priority: gain cloud visibility first)
Entra Registered (BYOD)	Entra Registered (maintain) or Entra ID Joined (if corporate-owned)	If BYOD: maintain registration; enforce MAM policies. If misclassified corporate device: re-enroll as Entra Joined via Autopilot	User resistance to MDM enrollment on personal devices; data separation concerns; misclassified devices receiving incorrect policies	Device ownership classification (corporate vs. personal); MAM policy set; user communication plan	Ongoing (BYOD policy enforcement is continuous)
Entra ID Joined (already cloud-native)	Entra ID Joined (maintain)	No migration required; validate Intune policy coverage and compliance state; ensure Autopilot profile assignment for reprovisioning	Minimal — ensure no regression if legacy policies are decommissioned	Intune policy audit; compliance baseline validation	Validation only (1–2 weeks)

Section 6: GPO-to-Intune Conversion

The conversion of Group Policy Objects (GPOs) to Microsoft Intune policies is one of the most operationally intensive work streams in Phase 1. This section defines the mechanics for inventorying, rationalizing, migrating, and decommissioning GPOs in a governed, auditable manner.

6.1 GPO Inventory and Rationalization

Before any migration begins, every GPO linked in the on-premises Active Directory environment must be inventoried and assessed. The GPO inventory captures: GPO name, GUID, link location (OU/domain/site), link status (enabled/disabled), WMI filter (if any), security filtering, delegation, last modified date, and a setting-level breakdown. Rationalization is critical — many GPOs in legacy environments are stale (not modified in years), conflicting (multiple GPOs setting the same value differently), superseded (older GPOs overridden by newer ones), or orphaned (linked to empty OUs). The migration is an opportunity to rationalize, not lift-and-shift. Every GPO must be classified as: migrate, consolidate, deprecate, or defer.

6.2 Group Policy Analytics

Group Policy Analytics is Microsoft Intune's built-in tool for assessing GPO migration readiness. GPOs are exported from on-premises Active Directory as XML files (via Get-GPOReport -ReportType XML) and imported into the Intune admin center. Group Policy Analytics maps each setting in the GPO to its MDM/CSP equivalent in the Settings Catalog. The tool produces a compatibility percentage — the proportion of settings that have direct 1:1 MDM equivalents. Settings are classified as: Supported (direct MDM equivalent exists), Not Supported (no MDM equivalent), and Deprecated (the setting applies to an OS version no longer in scope).

6.3 Settings Catalog Migration

For settings with MDM equivalents, Group Policy Analytics can generate a Settings Catalog policy directly from the imported GPO. This is the preferred migration path. The Settings Catalog provides the broadest and most granular set of MDM configuration settings, organized by category. Settings Catalog policies are the modern replacement for legacy Intune configuration profiles and Administrative Templates (ADMX import). All new policy creation should use the Settings Catalog exclusively.

6.4 Unsupported Settings Remediation

Settings without MDM equivalents require individual evaluation:

• Intune compliance policies: Some GPO settings that enforce a configuration (e.g., minimum password length) have equivalents in Intune compliance policies rather than configuration profiles. The setting is not pushed but is evaluated — non-compliant devices are flagged.

• Proactive Remediations (Remediations): Settings that require local configuration not available via MDM can often be implemented as PowerShell-based Proactive Remediation scripts. A detection script checks the current state; a remediation script corrects drift. This is PowerShell-first and consistent with UIAO operational standards.

• Deprecation: Some GPO settings are obsolete — they configure features no longer present in modern Windows, or they enforce behaviors that are now default. These settings are deprecated and documented. They are not migrated.

6.5 Coexistence Management

During the transition period, devices may receive settings from both GPO (via on-premises AD domain membership) and Intune (via MDM enrollment). The MDM Wins Over GP policy (available since Windows 10 1803) ensures that for enrolled devices, Intune-delivered settings take precedence when a conflict exists. This policy must be explicitly enabled and tested. Without it, the "last writer wins" behavior can cause unpredictable configuration states. Coexistence testing must validate: setting delivery from both sources, conflict resolution behavior, user experience (no setting flicker or prompt storms), and compliance reporting accuracy.

6.6 Policy Ownership Mapping

Every migrated policy must have a documented owner mapped to the OrgPath governance model. The owner is the individual accountable for the policy's lifecycle: creation, modification, compliance monitoring, and decommission. Unowned policies are governance orphans and are CI-blocking under UIAO Canon rules. Ownership is recorded in the Policy Ownership Register, stored in canon/, and validated during governance reviews.

+———————————————————————-+

Figure 2.2 — Flowchart showing GPO-to-Intune conversion pipeline: GPO Export (XML via Get-GPOReport) → Group

Table 5: GPO Migration Decision Matrix

GPO Category	MDM Support Status	Migration Path	Intune Policy Type	Owner	Priority
Security baselines (password policy, lockout, audit)	Supported — full Settings Catalog equivalents	Settings Catalog migration via Group Policy Analytics	Settings Catalog — Security Baseline	[Security Team Lead — per OrgPath]	Critical
BitLocker / encryption configuration	Supported — Endpoint Security Disk Encryption profile	Endpoint Security profile creation; retire GPO BitLocker settings	Endpoint Security — Disk Encryption	[Security Team Lead — per OrgPath]	Critical
Windows Update / WSUS targeting	Supported — Windows Update for Business (WUfB) via Settings Catalog + Update Rings	WUfB deployment ring configuration; decommission WSUS targeting GPOs	Settings Catalog — Windows Update for Business; Update Rings	[Infrastructure Lead — per OrgPath]	High
Drive mappings / login scripts	Not Supported — no MDM equivalent for drive mapping GPOs	Proactive Remediation (PowerShell script) or migration to SharePoint Online / OneDrive Known Folder Move	Proactive Remediation script; or deprecation if migrating to cloud storage	[Endpoint Lead — per OrgPath]	Medium
Printer deployment (GPP Printers)	Partially Supported — Universal Print provides cloud printing; legacy printer GPOs have no MDM equivalent	Migrate to Universal Print where supported; Proactive Remediation for remaining printers	Universal Print configuration; Proactive Remediation script	[Endpoint Lead — per OrgPath]	Medium
Internet Explorer / Edge legacy settings	Deprecated — IE mode settings available via Settings Catalog; legacy IE GPOs are obsolete	Deprecate IE-specific GPOs; migrate Edge settings to Settings Catalog; configure IE mode site list if required	Settings Catalog — Microsoft Edge	[Endpoint Lead — per OrgPath]	Low
Desktop customization (wallpaper, Start Menu, taskbar)	Supported — Settings Catalog equivalents for most settings	Settings Catalog migration; validate user experience parity	Settings Catalog — Experience / Start	[Endpoint Lead — per OrgPath]	Low
Software installation (GPO-based MSI deployment)	Not Supported — Intune uses Win32 App / LOB app deployment, not GPO-based MSI	Repackage as Win32 apps for Intune deployment; or migrate to Winget / Intune Store apps	Intune Win32 App; Microsoft Store App	[Application Lead — per OrgPath]	High

Section 7: Azure Arc Enrollment

Azure Arc extends the Azure management plane to on-premises and multi-cloud servers, providing a unified management experience for servers that cannot — or should not — migrate to Azure-hosted infrastructure. Azure Arc is the modernization path for hybrid server management, replacing legacy management tools with a cloud-native control plane.

7.1 Enrollment Mechanics

Azure Arc enrollment installs the Azure Connected Machine Agent on target servers. This agent establishes a persistent outbound HTTPS connection to Azure Resource Manager (ARM). Upon successful enrollment, each server receives an Azure resource ID, is placed in a designated Resource Group, and becomes visible in the Azure portal alongside cloud-native resources. Arc-enrolled servers can be tagged, governed by Azure Policy, monitored by Azure Monitor, and managed through Azure-native tooling — all without migrating the workload off-premises.

7.2 GCC-Moderate Boundary Considerations

Important — Boundary Clarification Azure Arc enrollment operates in Commercial Cloud (Azure), not within the M365 GCC-Moderate boundary. GCC-Moderate applies to Microsoft 365 SaaS services only and does not include Azure services. Azure Arc is a governance bridge — it extends cloud management capabilities to on-premises servers without creating a boundary violation. This distinction is canonical and is further addressed in Section 8 (Boundary Resolution).

7.3 Management Capabilities Enabled by Arc

Azure Arc enrollment activates the following management capabilities for on-premises servers:

• Azure Update Manager: Centralized patch assessment and deployment, replacing legacy WSUS/SCCM patching workflows. Update Manager provides compliance dashboards, scheduled patching windows, and pre/post-patching scripts.

• Azure Change Tracking and Inventory: Monitors changes to files, registry, software inventory, and Windows services on Arc-enrolled servers. Change Tracking provides audit trail and drift detection for server configurations.

• Windows Admin Center in Azure: Remote server management through the Azure portal — no VPN or direct RDP required. Provides event log access, process management, registry editing, and performance monitoring.

• Azure Policy for server configuration: Guest Configuration policies (now called Machine Configuration) evaluate and enforce configuration baselines on Arc-enrolled servers using PowerShell DSC. Policies can audit or enforce settings.

• Microsoft Defender for Servers integration: Arc enrollment is a prerequisite for onboarding on-premises servers to Microsoft Defender for Servers (Plan 1 or Plan 2), enabling threat detection, vulnerability assessment, and endpoint detection and response (EDR).

7.4 Modernization from SCCM/MECM

For organizations currently using System Center Configuration Manager (SCCM / MECM) for server management, Azure Arc provides the modern equivalent management plane. The migration from SCCM to Arc-based management follows a parallel rationalization model to the GPO-to-Intune conversion described in Section 6: inventory existing SCCM management functions, map each function to its Arc/Azure equivalent, execute migration in phases, validate management parity, and decommission legacy agents.

7.5 Arc Enrollment Sequencing

Servers should be enrolled in Azure Arc in phases, not bulk-enrolled. The phased approach validates management capabilities, identifies compatibility issues, and establishes operational confidence before production enrollment.

Table 6: Azure Arc Enrollment Phases

Phase	Server Scope	Prerequisites	Management Capabilities Activated	Validation Criteria	Rollback Plan
Phase A — Non-Production	Development and test servers (5–10 servers); representative OS versions and roles	Azure subscription provisioned; Resource Group created; network connectivity validated (outbound HTTPS to Azure endpoints); Connected Machine Agent package tested	Azure Update Manager (assessment only); Change Tracking; Windows Admin Center; Azure Policy (audit mode); Azure Monitor agent	All target servers reporting in Azure portal; Update Manager assessment data populated; Change Tracking baseline established; no agent stability issues over 14-day observation period	Uninstall Connected Machine Agent; remove Azure resource record; restore to pre-enrollment state. No production impact — non-production scope only.
Phase B — Production Pilot	10–25 production servers; selected critical roles (file server, application server, database server); representative of production estate	Phase A complete and validated; production network firewall rules confirmed; change management approval obtained; monitoring alerts configured	Azure Update Manager (assessment + scheduled patching); Change Tracking; Windows Admin Center; Azure Policy (audit + selected enforcement); Defender for Servers onboarding (Plan 1)	Patching executed successfully via Update Manager; Change Tracking alerts validated; Azure Policy compliance reporting accurate; Defender for Servers alerts generating correctly; no production service disruption	Uninstall Connected Machine Agent from affected servers; revert to legacy patching (WSUS/SCCM); restore monitoring to legacy tooling. Incident review before proceeding.
Phase C — Production Expansion	All remaining production servers; full server estate enrollment	Phase B complete and validated over 30-day observation; legacy agent decommission plan approved; operational runbooks updated for Arc-based management	Full management suite: Update Manager, Change Tracking, Windows Admin Center, Azure Policy (enforcement), Defender for Servers, Azure Monitor (full telemetry)	100% server estate enrolled and reporting; Update Manager compliance ≥95%; Change Tracking operational; Azure Policy compliance baselines met; legacy management agents decommissioned from Phase A/B servers	Phase-specific rollback: unenroll servers by batch; legacy agents remain installed until full validation. Rollback scope limited to current batch.

Section 8: Boundary Resolution — Potential and In Progress

Warning — Active Assessment Boundary resolution is POTENTIAL and IN PROGRESS — not resolved or determined. This section documents the current state of boundary assessment, identifies known intersections, and establishes the framework for resolution. No boundary decisions documented herein should be treated as finalized. This corrects any earlier interpretation that treated boundary resolution as a settled matter.

8.1 Boundary Definition

The GCC-Moderate boundary applies to Microsoft 365 SaaS services only. This includes: Exchange Online, SharePoint Online, OneDrive for Business, Microsoft Teams, Power Platform (Power BI, Power Apps, Power Automate), Microsoft Intune, Microsoft Entra ID (as the identity provider for M365), and Microsoft Defender for Office 365. Azure services — including Azure Arc, Azure Policy, Azure Monitor, Azure Update Manager, and all Azure IaaS/PaaS offerings — operate in Commercial Cloud governed by FedRAMP. This distinction is canonical.

UIAO operates in Commercial Cloud as governed by FedRAMP unless specifically noted. Amazon Connect Contact Center is an explicit exception running in Commercial Cloud outside the Microsoft ecosystem. This boundary definition will remain in effect until formally revised through UIAO Canon governance processes.

8.2 Boundary Resolution Scope

Boundary resolution refers to the ongoing assessment of where governance boundaries intersect, overlap, or create gaps between M365 GCC-Moderate services and Azure Commercial services. This is an active area of assessment — a continuous work stream throughout Phase 1 (Sequence Step 9) — not a deliverable with a single completion date.

8.3 Key Boundary Questions Under Assessment

The following boundary intersection questions are actively under assessment. None are resolved as of this pre-release:

• Device identity intersection: How does device identity in Entra ID (GCC-Moderate) interact with Azure Arc-enrolled servers (Commercial)? When Entra ID is the identity authority for both M365 access and Azure resource management, where does the governance boundary lie for device objects that exist in both contexts?

• Conditional Access policy span: How do Conditional Access policies that evaluate device compliance (assessed via Intune in GCC-Moderate) interact with Azure resource access (Commercial)? Can a single Conditional Access policy coherently span both environments without creating compliance ambiguity?

• SCuBA and Azure Policy alignment: How does SCuBA baseline enforcement in M365 (GCC-Moderate) relate to Azure Policy enforcement on Arc-enrolled servers (Commercial)? Are there governance gaps where a configuration assessed by SCuBA has dependencies on Azure Policy, or vice versa?

• Data residency and telemetry flow: What telemetry, diagnostic, and management data flows between GCC-Moderate M365 services and Azure Commercial services? Are there data residency implications for organizations subject to data sovereignty requirements?

• Licensing and entitlement boundaries: Do M365 GCC-Moderate license entitlements (e.g., Intune, Defender) extend cleanly to Azure Commercial services (e.g., Defender for Servers via Arc), or are separate Azure entitlements required?

8.4 Boundary Documentation Requirements

Every identified boundary intersection must be documented in the Boundary Assessment Register with the following attributes: intersection description, services involved (M365 and Azure), current assessment status (Identified / Under Assessment / Assessed / Resolved), responsible owner, target resolution date, and notes. The Boundary Assessment Register is maintained in canon/ and reviewed during governance cycles.

Table 7: Boundary Assessment Status

Boundary Intersection	Services Involved	Current Assessment Status	Responsible Owner	Target Resolution Date	Notes
Entra ID device identity — M365 vs. Azure resource access	Microsoft Entra ID (GCC-Moderate); Azure Resource Manager (Commercial)	Under Assessment	[Identity Lead — TBD per OrgPath]	[TBD — target Revision 1.0]	Entra ID serves as identity provider for both M365 and Azure; governance boundary for device objects spanning both contexts is not yet defined
Conditional Access policy scope across M365 and Azure	Microsoft Entra Conditional Access (GCC-Moderate); Azure Resource Manager (Commercial)	Identified	[Security Lead — TBD per OrgPath]	[TBD — target Revision 1.0]	Conditional Access policies can target Azure management as a cloud app; compliance coherence across boundaries requires validation
SCuBA baseline enforcement vs. Azure Policy enforcement	CISA ScubaGear / UIAO SCuBA (M365 GCC-Moderate); Azure Policy / Machine Configuration (Azure Commercial)	Identified	[Compliance Lead — TBD per OrgPath]	[TBD — target Revision 1.0]	Separate enforcement engines; need to assess whether governance gaps exist at the intersection
Telemetry and diagnostic data flow between M365 GCC-Moderate and Azure Commercial	M365 Diagnostic Data (GCC-Moderate); Azure Monitor / Log Analytics (Commercial)	Identified	[Infrastructure Lead — TBD per OrgPath]	[TBD — target Revision 1.0]	Data residency implications for organizations routing M365 telemetry to Azure Commercial Log Analytics workspaces
Licensing entitlement boundaries — M365 GCC-Moderate vs. Azure Commercial	M365 E3/E5 GCC-Moderate licensing; Azure consumption licensing (Commercial)	Under Assessment	[Licensing/Finance Lead — TBD per OrgPath]	[TBD — target Revision 1.0]	Determining which Defender, Intune, and management entitlements cross the boundary and which require separate Azure SKUs
Amazon Connect Contact Center — non-Microsoft exception	Amazon Connect (AWS Commercial); M365 GCC-Moderate (identity/directory integration, if any)	Under Assessment	[Contact Center Lead — TBD per OrgPath]	[TBD — target Revision 1.0]	Explicit exception — Amazon Connect runs in Commercial Cloud outside the Microsoft ecosystem; integration points with M365/Entra ID require boundary documentation

Section 9: SCuBA Operationalization

This section defines the operationalization mechanics for CISA SCuBA (Secure Cloud Business Applications) baselines through the ScubaGear assessment tool and the UIAO SCuBA orchestration layer.

9.1 ScubaGear Overview

ScubaGear is CISA's open-source PowerShell module that assesses Microsoft 365 tenant configuration against SCuBA Secure Configuration Baselines. ScubaGear queries M365 APIs (Microsoft Graph, Exchange Online PowerShell, SharePoint Online PowerShell, Teams PowerShell), collects the tenant's current configuration state, compares each setting against OPA (Open Policy Agent) / Rego policy definitions, and generates compliance reports in HTML, JSON, and CSV formats. ScubaGear is a point-in-time assessment tool — it evaluates the current state at the time of execution and does not provide continuous monitoring.

9.2 Baseline Coverage

ScubaGear assesses the following M365 workloads against SCuBA baselines:

• Entra ID (AAD): Authentication methods, Conditional Access, MFA enforcement, admin role management, guest access, legacy authentication blocking

• Exchange Online: Mail flow rules, transport encryption, external forwarding controls, audit logging, anti-phishing/anti-spam policies, DMARC/DKIM/SPF

• SharePoint Online: Sharing settings, access controls, site creation policies, external collaboration governance

• Microsoft Teams: Meeting policies, messaging policies, external access, guest access, app permission policies

• Power BI: Tenant settings, export controls, external sharing, embed controls

• Power Platform: Environment creation controls, DLP policies, connector restrictions, tenant isolation

Baselines are mapped to NIST SP 800-53 security controls and MITRE ATT&CK techniques, providing dual-framework traceability for compliance and threat-informed defense.

9.3 UIAO SCuBA Orchestration Layer

UIAO SCuBA sits above ScubaGear as the governance orchestration layer. It is complementary, not competitive — UIAO SCuBA does not replace ScubaGear; it consumes ScubaGear's outputs and adds governance-grade capabilities that ScubaGear does not provide natively. The UIAO SCuBA orchestration layer provides:

• Continuous drift detection: ScubaGear provides point-in-time assessment. UIAO SCuBA schedules ScubaGear execution on a defined cadence, compares results against canonical desired-state baselines stored in canon/, and detects drift between the desired state and the assessed state.

• Remediation orchestration with SLA enforcement: Detected drift is classified by severity, assigned to an owner via OrgPath, and placed on an SLA timer. UIAO SCuBA tracks remediation progress, escalates when SLAs are at risk, and validates that remediation resolves the drift.

• Machine-trackable governance provenance: Every assessment, drift detection, remediation action, and resolution is recorded as a machine-trackable provenance event in canon/. This creates an auditable chain of evidence for compliance demonstrations.

• Owner accountability tracking: UIAO SCuBA correlates drifted settings to their responsible owner (via OrgPath and the Policy Ownership Register). Owner reliability metrics — remediation speed, SLA adherence, repeat drift rates — are tracked and surfaced in SLA heatmaps.

9.4 Operationalization Sequence

The SCuBA operationalization follows a defined sequence integrated with the overall Phase 1 modernization (Sequence Step 7).

Table 8: SCuBA Operationalization Sequence

Step	Action	Tool/Method	Output	Owner	SLA
1	Deploy ScubaGear module in M365 tenant; validate API permissions and authentication	PowerShell — Install-Module ScubaGear; configure service principal with required Graph/Exchange/SharePoint/Teams permissions	ScubaGear module installed and authenticated; test execution validated against single workload	Canon Steward	Complete within 5 business days of Step 7 initiation
2	Execute initial baseline assessment across all supported workloads (Entra ID, EXO, SPO, Teams, Power BI, Power Platform)	PowerShell — Invoke-SCuBA (all products); generate HTML/JSON/CSV reports	Initial SCuBA Baseline Assessment Report (all workloads); JSON output files for programmatic consumption	Canon Steward	Complete within 3 business days of Step 1 completion
3	Establish canonical desired-state definitions in canon/ governance repository; document all accepted deviations with justification	Manual review of ScubaGear output; canonical definition authoring in YAML/JSON; accepted deviation documentation with risk acceptance signature	Canonical Desired-State Definitions (per workload); Accepted Deviation Register with justifications	Canon Steward + Workload Owners	Complete within 10 business days of Step 2 completion
4	Configure UIAO SCuBA orchestration to consume ScubaGear JSON/CSV outputs on a scheduled cadence	PowerShell automation — scheduled task or Azure Automation runbook executing ScubaGear; UIAO SCuBA orchestration layer consuming outputs and comparing against canonical definitions	UIAO SCuBA Orchestration Configuration; scheduled execution cadence defined (recommended: weekly minimum)	Canon Steward	Complete within 5 business days of Step 3 completion
5	Activate drift detection and remediation workflows; configure severity classification, SLA timers, and escalation chains	UIAO Drift Engine configuration (PowerShell); SLA classification rules; OrgPath-based owner assignment; escalation workflow definition	Drift Detection Activation Report; SLA Timer Configuration; Escalation Chain Document	Canon Steward + OrgPath-scoped Admins	Complete within 5 business days of Step 4 completion
6	Establish SLA heatmaps and owner reliability metrics; configure governance dashboard outputs	PowerShell reporting scripts generating heatmap data; canonical dashboard rendering pipeline (target: Revision 1.0)	SLA Heatmap (initial); Owner Reliability Metrics Baseline; Dashboard Configuration (draft)	Canon Steward	Initial heatmap within 30 days of Step 5 activation; ongoing refinement

9.5 PowerShell-First Execution

All ScubaGear execution and UIAO SCuBA orchestration uses PowerShell as the primary execution framework, consistent with UIAO's PowerShell-first operational model. ScubaGear is natively a PowerShell module. UIAO SCuBA orchestration scripts are authored in PowerShell 7.x, leveraging Microsoft Graph PowerShell SDK, Exchange Online Management module, and native PowerShell scheduling capabilities. No GUI-dependent or portal-dependent execution paths are permitted for production operations — all execution must be scriptable, repeatable, and auditable.

Section 10: Drift Detection and Remediation

10.1 Drift Definition

Configuration drift occurs when the live state of a tenant, device, or policy deviates from its canonical desired state. Drift is the primary operational risk in modernized environments because it is silent (no alert fires unless detection is active), cumulative (small deviations compound over time), and often invisible until audit or incident exposes the gap. In legacy environments, drift was managed reactively — discovered during audits, incident investigations, or compliance reviews. The UIAO modernization model replaces reactive drift discovery with continuous, proactive drift detection.

10.2 Microsoft Unified Tenant Configuration Management (UTCM)

Unified Tenant Configuration Management (UTCM), now in public preview, introduces native desired-state monitoring via Microsoft Graph. UTCM allows administrators to define what the configuration state should be (the desired state) and Microsoft Graph evaluates the live configuration against that definition on a periodic basis. Drifts — deviations from the desired state — are surfaced automatically. UTCM is a significant platform advancement because it shifts M365 configuration management from imperative ("set this value") to declarative ("this value should be X; alert me if it changes").

10.3 UIAO Drift Detection Model

UIAO extends UTCM and ScubaGear with a governance-grade drift detection framework that adds accountability, SLA enforcement, and provenance tracking. The UIAO drift detection model includes:

• Canonical desired-state definitions stored in the governance repository (canon/). These definitions are the authoritative source of truth for what every configuration should be. They are versioned, immutable (history preserved), and owned.

• Automated drift detection via scheduled PowerShell execution. Detection sources include UTCM (Graph-based), ScubaGear (M365 workload assessment), Azure Policy (Arc-managed servers), and custom PowerShell detection scripts for configurations not covered by the above.

• Drift classification — every detected drift is classified by severity: Critical, High, Medium, or Low. Classification drives SLA-bound remediation timelines.

• Owner accountability — every drift is assigned to the owner of the drifted artifact, resolved via OrgPath and the ownership registers maintained in canon/. The owner is accountable for remediation within SLA.

• Escalation workflows — unresolved drifts escalate through defined chains. Escalation triggers are time-based (SLA percentage consumed) and severity-based (Critical drifts escalate faster).

• Governance provenance — every drift detection event, remediation action, validation check, and resolution is machine-tracked as a provenance record in canon/. This creates the auditable evidence chain required for compliance demonstrations.

10.4 Drift Detection Domains

The UIAO drift detection framework monitors the following domains:

• Identity configuration: Conditional Access policies, MFA enforcement settings, authentication method policies, named locations, admin role assignments

• Device compliance: Encryption status (BitLocker), patching currency, OS version/build, compliance policy evaluation results, management enrollment status

• Policy configuration: Intune Settings Catalog policies, security baselines, endpoint protection profiles, Windows Update for Business rings

• Collaboration settings: Teams meeting and messaging policies, SharePoint sharing and access control settings, Exchange Online transport rules and anti-phishing configurations

• SCuBA baselines: All workloads assessed by ScubaGear (Entra ID, Exchange Online, SharePoint Online, Teams, Power BI, Power Platform)

• Server configuration: Arc-managed servers via Azure Policy / Machine Configuration; patch compliance via Azure Update Manager; change tracking alerts

10.5 Remediation Workflow

The UIAO remediation workflow follows a deterministic sequence: Detect (drift identified by detection source) → Classify (severity assigned per classification matrix) → Assign Owner (resolved via OrgPath and ownership registers) → SLA Timer Starts (clock begins at classification) → Remediate (owner executes corrective action — automated or manual) → Validate (detection source re-evaluates to confirm drift is resolved) → Close (drift record closed with resolution details) → Provenance Record (full event chain written to canon/).

+———————————————————————-+

Figure 2.3 — Diagram showing the UIAO Drift Detection and Remediation Workflow: Detection Sources (UTCM via

Table 9: Drift Classification and SLA Matrix

Drift Severity	Definition	SLA for Remediation	Escalation Trigger	Example
Critical	Drift that creates an immediate security exposure, disables a core security control, or violates a compliance requirement with enforcement consequences	4 hours	Escalate to Canon Steward at 2 hours if unresolved; escalate to organizational leadership at 4 hours if unresolved	Conditional Access policy requiring MFA for all users is disabled or modified to exclude groups; ScubaGear detects external forwarding enabled in Exchange Online; BitLocker enforcement policy removed from compliance baseline
High	Drift that weakens a security control, degrades compliance posture, or affects a governance-critical configuration without creating immediate exposure	24 hours	Escalate to Canon Steward at 12 hours if unresolved; escalate to organizational leadership at 24 hours if unresolved	Authentication method policy modified to allow less secure methods; SharePoint sharing settings changed from "specific people" to "anyone with the link"; Intune security baseline policy settings modified from deployed state
Medium	Drift that deviates from desired state but does not create direct security or compliance impact; may affect operational consistency or governance hygiene	72 hours (3 business days)	Escalate to Canon Steward at 48 hours if unresolved	Teams meeting policy modified to change recording default; Power BI tenant setting changed from desired state; Windows Update ring deferral period modified from canonical definition
Low	Drift from desired state in non-security, non-compliance configurations; cosmetic, preference, or optimization settings	5 business days	Included in weekly drift summary report; escalation only if unresolved for 2 consecutive reporting cycles	Desktop wallpaper policy modified; Start Menu layout policy adjusted; non-security Intune configuration profile setting changed from desired state

Section 11: Governance Integration and Next Steps

11.1 Canon Governance Framework Integration

All modernization mechanics defined in this document operate within the UIAO Canon governance framework. Canon is the governing principle that ensures every artifact, decision, configuration, and operational action is traceable, owned, and auditable. The following Canon governance rules apply to all Phase 1 outputs:

• Provenance to canon/: Every artifact produced by Phase 1 work — policies, configurations, scripts, reports, assessment results, and documentation — must trace provenance to canon/, the single source of truth. Artifacts without provenance are considered unverified and are CI-blocking.

• Documented ownership: Every artifact must have a documented owner. Ownership is recorded in the relevant register (Policy Ownership Register, Device OrgPath Register, Boundary Assessment Register, etc.) and is mapped to OrgPath. Orphaned artifacts — those without provenance or ownership — are CI-blocking under UIAO Canon rules.

• UIAO metadata schema compliance: All artifacts must comply with the UIAO metadata schema, which defines required fields (ID, title, owner, status, created date, updated date, classification, provenance chain) and optional fields (superseded_by, related_to, boundary).

• Immutable history: Canon governance requires immutable history. Once an artifact is committed to canon/, its history is preserved. Modifications create new versions; they do not overwrite prior versions. This ensures auditability and rollback capability.

• Deprecation protocol: Artifacts are never deleted from canon/. When an artifact is superseded, its status is changed to DEPRECATED with a superseded_by pointer to the replacement artifact. This maintains provenance continuity and prevents broken reference chains.

11.2 Canon Stewardship

The Canon Steward (Michael Stratton) is the governance authority responsible for the integrity of canon/, the enforcement of governance rules, and the resolution of governance disputes. Canon Stewardship responsibilities within Phase 1 include: approving canonical desired-state definitions, validating ownership assignments, reviewing boundary assessment findings, approving drift SLA classifications, and maintaining the integrity of all governance registers.

11.3 Next Steps — Revision 0.x to Revision 1.0

This pre-release (Revision 0.x) establishes the modernization mechanics baseline for UIAO Phase 1. It defines the sequencing, technical procedures, governance controls, and gate criteria for all Phase 1 work streams. Revision 1.0 will incorporate the following advancements:

• Feedback incorporation from stakeholder review of this pre-release

• Resolution of open boundary assessment items (Section 8, Table 7)

• Finalization of SLA targets based on operational baseline data

• Establishment of the operational dashboard rendering pipeline (SCuBA heatmaps, drift dashboards, compliance scorecards)

• Integration of UTCM public preview findings as the feature matures toward general availability

• Detailed PowerShell script specifications for OrgPath device correlation, ScubaGear orchestration, and drift remediation automation

• Completed OrgPath architecture diagrams (replacing DIAG-001, DIAG-002, DIAG-003 placeholders)

Table 10: Revision 0.x → 1.0 Gap Tracker

Section	Open Items	Required Input	Target Resolution	Status
Section 2 — Modernization Sequencing	Parallel execution dependencies between Steps 4–6 require validation; gate criteria need quantitative thresholds	Stakeholder review; operational baseline data from initial Phase 1 execution	Revision 1.0	Open
Section 3 — Identity Modernization	Current state assessment columns in Table 2 are placeholder; need populated data from initial audit	Entra ID audit execution; orphaned account scan; MFA registration report	Revision 1.0	Open
Section 4 — OrgPath Governance	DIAG-001 placeholder requires architectural diagram; device correlation script requires specification document	OrgPath architecture design finalization; PowerShell script authoring and testing	Revision 1.0	Open
Section 5 — Device Identity Modernization	Timeline estimates in Table 4 are preliminary; application compatibility assessment methodology needs definition	Device inventory with join-type classification; application dependency mapping	Revision 1.0	Open
Section 6 — GPO-to-Intune Conversion	DIAG-002 placeholder requires conversion pipeline flowchart; GPO inventory data not yet available; policy ownership assignments pending OrgPath establishment	GPO export and Group Policy Analytics import; OrgPath finalization; owner nomination from stakeholders	Revision 1.0	Open
Section 7 — Azure Arc Enrollment	Server inventory and scope definition for Phase A; Azure subscription and Resource Group provisioning; network connectivity validation	Server estate inventory; Azure subscription access; firewall rule assessment for Arc endpoints	Revision 1.0	Open
Section 8 — Boundary Resolution	All boundary intersections in Table 7 are under assessment or identified — none resolved; responsible owners are TBD pending OrgPath	OrgPath establishment (for owner assignment); Microsoft documentation review; architecture review with Microsoft account team	Revision 1.0 (initial resolution targets; some items may extend beyond)	Open
Section 9 — SCuBA Operationalization	ScubaGear deployment not yet executed; canonical desired-state definitions not yet authored; UIAO SCuBA orchestration layer in design phase	ScubaGear module installation; initial assessment execution; desired-state definition authoring; orchestration architecture finalization	Revision 1.0	Open
Section 10 — Drift Detection and Remediation	DIAG-003 placeholder requires workflow diagram; SLA timers are proposed — need validation against operational reality; UTCM integration dependent on preview maturation	Operational baseline data from initial drift detection cycles; UTCM preview evaluation; stakeholder agreement on SLA targets	Revision 1.0	Open
Section 11 — Governance Integration	Dashboard rendering pipeline not yet defined; governance register templates need finalization; Canon Stewardship delegation model for scale	Dashboard architecture design; register template authoring; delegation policy drafting	Revision 1.0	Open

Revision History

Version	Date	Description	Author
0.x	April 24, 2026	Initial pre-release — establishes the modernization mechanics baseline for UIAO Phase 1. All sections are first drafts. No prior version superseded.	Michael Stratton, Canon Steward

— End of Document —

UIAO_PHASE1_MOD_MECH | Version 0.x | Classification: Controlled | GCC-Moderate

---

Appendix A — AD-to-Entra Identity Translation (Restored Detail)

Why this appendix exists. Phase 1 Rev 0.x compressed the full AD-to-Entra crosswalk into a short Identity Modernization section. The source v1.0 detail is restored below for ISSO/AO reference. Note: as stated in the Editorial Note above, AD→Entra sync is treated as an existing operational baseline; the content below describes the governance and modernization layered on top of that baseline (Cloud Sync migration, attribute mapping, lifecycle governance).

Section 3 — AD-to-Entra Identity Translation

Identity translation is the process of mapping every object in the legacy Active Directory environment to its cloud-native counterpart in Microsoft Entra ID. This section covers the synchronization architecture that moves objects between the two directories, the object-level translation matrix that defines what each AD object becomes in Entra ID, the attribute mapping that preserves data fidelity, and the identity lifecycle governance model that replaces AD OU-based delegation with cloud-native Entra ID Governance constructs.

3.1 Synchronization Architecture

The UIAO currently operates Microsoft Entra Connect Sync (formerly Azure AD Connect) to synchronize identity objects from on-premises Active Directory to Microsoft Entra ID. Entra Connect Sync is a server-based application that runs on a dedicated Windows Server, maintains a local SQL database of object state, and performs periodic synchronization cycles (default: 30 minutes). While Entra Connect Sync has served reliably as the synchronization backbone, it introduces architectural risks that the modernization program must address.

Entra Connect Sync operates as a single-server deployment with an optional staging server for failover. The active server holds the only writable copy of the synchronization configuration. If the active server fails, manual intervention is required to promote the staging server — there is no automatic failover. Configuration is stored locally on the server, not in the cloud, making it opaque to cloud-based governance and audit. The version currently deployed must be upgraded to version 2.5.79.0 or later before September 30, 2026, as Microsoft has mandated minimum version requirements that retire older builds.

The strategic direction is Microsoft Entra Cloud Sync. Cloud Sync represents a fundamental architectural shift: synchronization configuration is stored in Entra ID itself, not on a local server. Multiple lightweight provisioning agents can be deployed across the on-premises environment, providing automatic failover without manual intervention. The agents are auto-updating, reducing maintenance overhead. Cloud Sync supports attribute-level scoping, expression-based transformations, and on-demand provisioning for testing.

The migration path from Connect Sync to Cloud Sync is not a lift-and-shift. The two systems handle certain scenarios differently — Cloud Sync does not yet support device writeback, Exchange hybrid writeback in all configurations, or synchronization of objects larger than 150,000 per domain in certain topologies. The migration requires a careful parallel-deployment phase where Cloud Sync handles the majority of synchronization while Connect Sync retains responsibility for any unsupported scenarios, followed by a full cutover once feature parity is confirmed for the UIAO's specific environment.

3.2 Object Translation Matrix

Table 3 defines the object-level translation from AD to Entra ID. Each row identifies an AD object type, its key attributes, the corresponding Entra ID object type, and the synchronization method used to create and maintain the mapping.

Table 3: AD Object-to-Entra Object Translation Matrix

AD Object Type	AD Key Attributes	Entra ID Object Type	Entra Attributes (Mapped)	Sync Method	OrgPath Mapping	Governance Notes
User Account	sAMAccountName, UPN, distinguishedName, memberOf, department	User	userPrincipalName, displayName, department, extensionAttribute1 (OrgPath)	Cloud Sync (strategic); Connect Sync (current)	Derived from OU path; written to extensionAttribute1	UPN must match routable domain. Immutable ID anchored to ms-DS-ConsistencyGuid.
Security Group	sAMAccountName, member, groupType	Security Group (synced) or Dynamic Group (new)	displayName, members, groupTypes, membershipRule	Cloud Sync (synced groups); Manual (dynamic groups)	Group naming convention includes OrgPath prefix (e.g., SG-EAST-IT-Security-Read)	Synced groups retain static membership. New groups should be dynamic where possible.
Distribution Group	sAMAccountName, member, mail	Mail-enabled Security Group or Microsoft 365 Group	displayName, members, mail, proxyAddresses	Cloud Sync / Exchange Hybrid	OrgPath prefix in displayName	Evaluate migration to M365 Groups for Teams/SharePoint integration.
Computer Object (Workstation)	sAMAccountName, dNSHostName, operatingSystem, distinguishedName	Device (Entra Joined or Hybrid Entra Joined)	displayName, deviceId, operatingSystem, deviceCategory	Hybrid Join auto-registration; Autopilot for Entra Join	Device category maps to OrgPath device taxonomy	Target state: Entra Joined (cloud-native). See Section 5.
Computer Object (Server)	sAMAccountName, dNSHostName, operatingSystem, servicePrincipalName	Azure Arc-enabled Server	resourceName, osType, tags (including OrgPath tag)	Arc agent enrollment (scripted/GPO/ConfigMgr)	Azure resource tag: OrgPath=[value]	Servers are NOT managed by Intune. See Section 5.3.
Service Account	sAMAccountName, servicePrincipalName, userAccountControl	Managed Identity (system or user-assigned) or App Registration	appId, servicePrincipalId, managedIdentityResourceId	Manual migration	OrgPath tag on App Registration	Eliminate password-based service accounts. Target: Managed Identity or Workload Identity Federation.
Contact	mail, displayName, targetAddress	Contact (Org-external) or Guest User (B2B)	mail, displayName, userType=Guest	Cloud Sync (contacts); Manual (B2B guests)	OrgPath: HQ/External/Contacts	Evaluate B2B Guest for collaboration scenarios.
Organizational Unit	distinguishedName, name, description	Administrative Unit	displayName, description, membershipType (dynamic/assigned)	Manual creation based on OrgPath registry	AU scoped to OrgPath prefix (e.g., AU-EAST-IT)	Not a 1:1 mapping. AUs consolidate multiple OUs. See Section 2.

3.3 Attribute Mapping and Custom Extensions

Attribute mapping defines how individual data fields on AD objects translate to their Entra ID equivalents. While many attributes have direct 1:1 mappings (e.g., displayName to displayName), others require transformation, concatenation, or routing to custom extension attributes. Table 4 documents the critical attribute mappings that affect identity resolution, OrgPath fidelity, and downstream service integration.

Table 4: Critical Attribute Mapping — AD to Entra ID

AD Attribute	Entra ID Attribute	Sync Direction	Transformation Rule	OrgPath Relevance
sAMAccountName	onPremisesSamAccountName	AD → Entra	Direct mapping. Read-only in Entra for synced users.	None (identifier only)
userPrincipalName	userPrincipalName	AD → Entra	Must use routable UPN suffix (e.g., @agency.gov, not @agency.local). Suffix transformation applied if AD UPN uses non-routable domain.	None (identifier only)
distinguishedName	onPremisesDistinguishedName	AD → Entra	Direct mapping. Read-only. Source for OrgPath derivation.	Primary — OrgPath is derived from the OU components of the distinguishedName.
memberOf	memberOf (synced groups)	AD → Entra	Group memberships sync if groups are in sync scope. Dynamic groups in Entra are additive.	Indirect — dynamic groups use OrgPath attribute for membership rules.
department	department	AD → Entra	Direct mapping.	Supplementary — used to validate OrgPath department segment.
physicalDeliveryOfficeName	officeLocation	AD → Entra	Direct mapping.	Supplementary — used to validate OrgPath region segment.
extensionAttribute1	onPremisesExtensionAttributes.extensionAttribute1	AD → Entra	Direct mapping. This is the OrgPath carrier attribute.	Critical — carries the OrgPath value.
extensionAttribute2–15	onPremisesExtensionAttributes.extensionAttribute2–15	AD → Entra	Direct mapping. Available for additional metadata.	Reserved for future OrgPath extensions (e.g., cost center, project code).
manager	manager	AD → Entra	Reference resolution — maps AD DN to Entra objectId.	Used in access reviews and entitlement management delegation.
directReports	directReports	AD → Entra	Computed from manager attribute. Read-only.	Used in reporting and delegation chain validation.
msDS-cloudExtensionAttribute1–20	Custom Security Attributes (Entra ID P1/P2)	AD → Entra (manual)	Not synced automatically. Requires custom sync rule or Graph API script.	Alternative OrgPath carrier for cloud-native-only attributes.

3.4 Identity Lifecycle Governance

In legacy Active Directory, identity lifecycle management — the processes of creating, modifying, and removing user accounts — is governed by OU-based delegation, manual provisioning workflows, and scripted automation. An administrator with delegated control over an OU can create users, modify attributes, and disable accounts within that container. This model is inherently manual, difficult to audit at scale, and dependent on the administrator's knowledge of which OU an object should reside in.

The modernized model replaces OU-based delegation with Entra ID Governance, a suite of cloud-native identity lifecycle services that automate and enforce governance at every stage of the identity lifecycle:

• Joiner: When a new employee is onboarded, an access package in Entra ID Governance Entitlement Management is assigned based on role and OrgPath. The access package bundles group memberships, application assignments, and SharePoint site access into a single request-and-approval workflow. The OrgPath attribute is set during provisioning and triggers dynamic group membership and AU placement automatically.

• Mover: When an employee changes roles or departments, the OrgPath attribute is updated through a governed change process. Dynamic group memberships recalculate automatically. The employee's existing access package is revoked and a new access package matching the new role is assigned. Access reviews are triggered to verify that the mover's access is appropriate for the new position.

• Leaver: When an employee departs, the identity lifecycle workflow disables the account, revokes all access packages, removes dynamic group memberships (by clearing the OrgPath attribute), and initiates the data retention and litigation-hold procedures defined by policy. After the retention period, the account is hard-deleted.

Entra ID Governance Access Reviews provide the periodic certification mechanism that replaces the informal "OU audit" of the legacy model. Access reviews can be scoped to Administrative Units (which align to OrgPath prefixes), ensuring that reviewers only certify access for users within their organizational scope. Reviews can run on defined schedules (quarterly, semi-annually) and produce machine-readable attestation records that integrate into the UIAO SCuBA governance provenance chain described in Section 6.

+———————————+

{fig-alt=“Left Side”On-Premises Active Directory”:** Two domain controller server icons labeled “DC-01” and “DC-02” with a shared cylinder icon labeled “AD Database”.” width=“720”}

service.  |
  |
Visual Style: White |
background. Blue (#2b5797) for |
legacy components. Green |
(#2e7d32) for modern/strategic |
components. Black (#1a1a1a) |
text. Labeled arrows for all |
data flows. A legend in the |
bottom-right corner explains |
color coding. |

+———————————+

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

---

Appendix B — Boundary Workarounds and Network Visibility (Restored Detail)

Why this appendix exists. Phase 1 Rev 0.x §8 framed boundary resolution as “Potential and In Progress” without the operational detail of the original §8. The detail below — including the Cisco ThousandEyes for Government FedRAMP-Moderate authorized monitoring path — is restored as Phase 1 reference for network architects and security operations.

Section 8 — Boundary Workarounds and Network Visibility

GCC-Moderate M365 environments provide compliance isolation within Microsoft's government cloud boundary, but this isolation can create operational visibility gaps that must be addressed to maintain service quality, troubleshoot performance issues, and validate network path integrity. This section describes the visibility gap, the tools available to close it, and the monitoring architecture that respects the GCC-Moderate boundary while providing actionable intelligence.

8.1 The GCC-Moderate Visibility Gap

Traditional enterprise monitoring stacks are designed for commercial cloud endpoints and commercial internet routing. GCC-Moderate M365 services operate on dedicated infrastructure with government-specific endpoints (e.g., *.gcc.teams.microsoft.com, *.protection.office365.us for certain services) and routing that may differ from commercial M365. This creates several visibility gaps:

• Network Path Opacity: Standard traceroute and path analysis tools may not accurately map the route from user locations to GCC-Moderate service endpoints, particularly when traffic traverses Microsoft's government cloud backbone.

• Service Performance Correlation: Without end-to-end visibility, it is difficult to determine whether a user-reported performance issue originates in the local network, the ISP, the internet exchange, or the M365 service itself.

• Synthetic Monitoring Gaps: Commercial synthetic monitoring services may not have test agents positioned to accurately measure latency and availability for GCC-Moderate endpoints.

• User Experience Telemetry: Native M365 telemetry (Network Connectivity Test, Service Health Dashboard) provides service-side visibility but limited client-side and network-path visibility.

8.2 ThousandEyes for Government

Cisco ThousandEyes for Government achieved FedRAMP Moderate authorization in March 2026, hosted on AWS GovCloud (US). This authorization enables federal agencies operating in GCC-Moderate environments to deploy ThousandEyes for comprehensive network visibility without violating boundary requirements. ThousandEyes for Government provides:

• End-to-End Network Path Visualization: Layer 3 hop-by-hop path traces from user locations to M365 service endpoints, including ASN identification, latency per hop, and packet loss detection.

• Synthetic Monitoring: Scheduled synthetic tests against M365 service URLs (Exchange Online, SharePoint, Teams) that measure availability, response time, and SSL negotiation performance from multiple vantage points.

• Real User Monitoring (RUM): Endpoint Agents installed on managed employee devices capture real user experience data — page load times, DNS resolution times, and TCP connection times — for M365 web applications.

• Enterprise Agent Deployment: Dedicated Enterprise Agents deployed in key network locations (headquarters, branch offices, data centers, call centers) provide continuous monitoring from fixed vantage points.

• ISP and Provider Correlation: ThousandEyes correlates network path data with known ISP outages, peering changes, and BGP route modifications, enabling rapid root cause identification for network-related service degradation.

• Microsoft Collaboration: ThousandEyes provides a direct data-sharing capability with Microsoft 365 technical operations teams, enabling collaborative troubleshooting when issues are identified within Microsoft's network.

Table 13 compares the network visibility tools available for GCC-Moderate environments.

Table 13: Network Visibility Tools for GCC-Moderate Environments

Tool / Capability	FedRAMP Status	Deployment Model	M365 Visibility	Network Path Analysis	User Experience Monitoring	GCC-Moderate Compatible
ThousandEyes for Government	FedRAMP Moderate (March 2026)	SaaS (AWS GovCloud) + Enterprise Agents + Endpoint Agents	Full — synthetic tests + RUM for M365 endpoints	Yes — hop-by-hop Layer 3 path analysis with ASN correlation	Yes — Endpoint Agent captures real user metrics	Yes
Microsoft 365 Service Health Dashboard	FedRAMP Moderate (part of M365 GCC)	Native M365 portal (admin.microsoft.com)	Service-side health status and known issues	No — no client-side or network path visibility	No — service health only	Yes
Microsoft Network Connectivity Test	FedRAMP Moderate (part of M365 GCC)	Web-based test tool (connectivity.office.com)	Point-in-time connectivity and latency test to nearest M365 service front door	Limited — basic latency measurement, no full path trace	No — point-in-time only	Yes
Azure Network Watcher	FedRAMP Moderate (Azure Government)	Azure PaaS service	Limited to Azure-hosted resources; not M365 SaaS	Yes — for Azure VNet traffic; not for M365 SaaS paths	No	Yes (Azure Gov)
Defender for Cloud Apps (MCAS)	FedRAMP Moderate (part of M365 GCC)	Native M365 SaaS	Application usage analytics and shadow IT discovery	No — application-layer visibility only	Limited — user activity analytics, not performance	Yes
Custom Synthetic Monitors	Depends on hosting (must use FedRAMP-authorized infrastructure)	Self-hosted scripts on managed infrastructure	Custom — depends on implementation	Custom — basic ping/traceroute/curl tests	No — infrastructure-level only	Conditional — must be hosted on authorized infrastructure

8.3 Boundary-Aware Monitoring Architecture

The monitoring architecture for the UIAO's GCC-Moderate environment is designed to maximize network visibility while respecting boundary constraints. The architecture follows three principles: (1) all monitoring data remains within FedRAMP-authorized boundaries, (2) monitoring agents are deployed on managed devices and managed infrastructure only, and (3) monitoring data is integrated with the existing SIEM/SOAR platform for correlation with security events.

Agent Placement Strategy: ThousandEyes Enterprise Agents are deployed at each major network egress point — headquarters, regional offices, and the data center. Enterprise Agents run continuous synthetic tests against M365 service URLs and provide fixed-vantage-point baselines for latency, availability, and path stability. ThousandEyes Endpoint Agents are deployed on managed employee devices (via Intune application deployment) to capture real user experience data from the user's actual network location — including remote workers on home networks and mobile users on cellular connections.

Synthetic Test Configuration: Synthetic tests are configured for critical M365 endpoints: Exchange Online (outlook.office365.com), SharePoint Online (agency.sharepoint.com), Teams (teams.microsoft.com), and the Entra ID authentication endpoint (login.microsoftonline.com). Tests run at 5-minute intervals from Enterprise Agents and capture DNS resolution time, TCP connect time, SSL handshake time, HTTP response time, and full page load time. Alerting thresholds are defined based on baseline performance data collected during the first 30 days of monitoring.

SIEM Integration: ThousandEyes for Government supports data export via webhooks and REST API. Network performance alerts and path change notifications are forwarded to the UIAO's SIEM platform for correlation with security events. A network performance degradation alert that coincides with a Conditional Access policy change or a ScubaGear finding may indicate a causal relationship that requires joint investigation by the Network and Security teams.

Escalation Workflow: When ThousandEyes detects sustained performance degradation (latency increase > 50% above baseline for > 15 minutes) or path changes that route traffic through unexpected ASNs, an automated alert triggers the network operations escalation workflow. If the issue is localized to the organization's network, the Network Team remediates. If the issue is within Microsoft's network, the ThousandEyes data-sharing capability is used to open a collaborative troubleshooting session with Microsoft support.

+———————————+

{fig-alt=“Left Side”User Locations”:** Three location icons arranged vertically: (1) “HQ Office” with a building icon and two sub-icons: “Enterprise Agent” (server) and “Endpoint Agents on Managed Devices” (laptops).” width=“720”}

Visual Style: White |
background. Blue (#2b5797) for |
ThousandEyes components. Green |
(#2e7d32) for M365 boundary. |
Orange (#cc7a00) for alert |
paths. Gray for network |
infrastructure. Dashed lines |
for the GCC-Moderate boundary. |
Solid lines for data flows. |

+———————————+

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

---

Appendix C — Wave 0–7 Hybrid-Safe Modernization Sequencing (Restored Detail)

Why this appendix exists. The §2 nine-step deterministic sequence is the authoritative Phase 1 sequencing plan. The original Phase 1 v1.0 document carried a complementary Wave 0–7 narrative that maps the nine deterministic steps onto an 8-wave timeline with rollback windows, validation criteria, and durations per wave. That narrative is preserved here for AO/3PAO review and historical comparison. Where Appendix C and the §2 table diverge, the §2 table is authoritative.

Section 9 — Hybrid-Safe Modernization Sequencing

Modernization is not a parallel effort where all workstreams execute simultaneously — it is a sequenced, dependency-aware progression where each wave establishes the prerequisites for subsequent waves. This section defines the sequencing principles, the wave sequence with detailed prerequisites and validation criteria, and the critical-path dependency chain that governs advancement through the program.

9.1 Sequencing Principles

Five principles govern the modernization sequence. These principles are non-negotiable — violation of any principle requires CISO and AO approval and must be documented as a risk acceptance.

9. Never Break Authentication: Identity synchronization (Entra Connect Sync or Cloud Sync) must be fully operational and validated before any device migration begins. If a device is Entra Joined but the user's identity is not properly synced to Entra ID, the user cannot authenticate. Authentication is the single most critical dependency in the entire modernization chain.

10. Policy Parity Before Cutover: Intune policies must achieve functional parity with the GPO settings they replace before Group Policy processing is disabled on any device. "Functional parity" does not mean 1:1 identical settings — it means the security and operational outcomes are equivalent. If a GPO enforces a minimum password length of 14 characters and the Intune policy enforces the same, that is parity. If the Intune policy also adds complexity requirements that the GPO did not have, that is acceptable enhancement.

11. Compliance Continuity: Devices must never exist in an ungoverned state. Before any device is enrolled in Intune (for clients) or Azure Arc (for servers), the compliance policies, configuration profiles, and security baselines that will govern it must be created, tested, and assigned to the target device group. A device that enrolls into Intune with no assigned compliance policy is an ungoverned device — it will be reported as "compliant" by default, creating a false positive in the compliance posture.

12. Reversibility Windows: Each migration wave includes a documented rollback procedure with a defined rollback window. During the rollback window (typically 5 business days after wave completion), the migration can be reversed if critical issues are discovered. After the rollback window closes, reversal requires a new change control request and is treated as a new migration activity.

13. Evidence-Based Advancement: Advancement from one wave to the next requires documented evidence that all validation criteria for the current wave have been met. Validation evidence is reviewed by the ISSO and approved by the AO before wave advancement. No wave begins without formal approval.

9.2 Modernization Wave Sequence

Table 14 defines the eight modernization waves, from foundation activities through legacy decommission. Each wave includes scope, prerequisites, key activities, validation criteria, estimated duration, and rollback procedures.

Table 14: Modernization Wave Sequence

Wave	Wave Name	Scope	Prerequisites	Key Activities	Validation Criteria	Duration (Est.)	Rollback Procedure
0	Foundation	Sync infrastructure, OrgPath deployment, baseline scan	Entra tenant provisioned; M365 licenses assigned; administrative access confirmed	Upgrade Entra Connect Sync to minimum version; deploy Cloud Sync agents (parallel); populate extensionAttribute1 (OrgPath) on all AD user and computer objects; execute initial ScubaGear baseline scan	Cloud Sync agents healthy; OrgPath populated on ≥95% of objects; ScubaGear scan completes without errors	4–6 weeks	Revert to Connect Sync only; clear extensionAttribute1 values if causing issues
1	Identity Parity	Entra ID governance constructs — AUs, dynamic groups, CA policies, access packages	Wave 0 complete; OrgPath validated	Create Administrative Units aligned to OrgPath prefixes; create dynamic security groups with OrgPath membership rules; deploy Conditional Access policies (report-only mode); configure Entitlement Management access packages	All AUs populated correctly; dynamic group memberships match expected counts (±2%); CA policies in report-only show expected behavior; access packages tested with pilot users	6–8 weeks	Delete AUs and dynamic groups; disable CA policies; remove access packages
2	Policy Translation	GPO analysis, Settings Catalog policy creation, coexistence configuration	Wave 1 complete; dynamic groups available for policy targeting	Export and analyze all GPOs via Group Policy Analytics; rationalize GPO estate; create Intune Settings Catalog policies for Phase A settings; enable MDM Wins Over GP on pilot devices; validate policy application	Group Policy Analytics reports generated; rationalization reduces setting count by ≥20%; Intune policies applied to pilot devices without conflicts; MDM Wins Over GP confirmed operational	8–10 weeks	Disable MDM Wins Over GP; unassign Intune policies from pilot devices; GPO remains authoritative
3	Pilot Device Migration	50–100 client devices migrated from Hybrid Entra Joined to Entra Joined	Wave 2 complete; Autopilot profiles configured; KFM + Windows Backup enabled; app catalog complete in Intune	Select pilot devices across 3–4 OrgPath segments; execute Autopilot wipe-and-reload; validate user experience, app availability, policy application, and compliance status; measure re-provisioning duration	100% of pilot devices Entra Joined; all assigned apps installed; compliance policies reporting compliant; user satisfaction survey ≥80% positive; mean re-provisioning time ≤3 hours	4–6 weeks	Re-image pilot devices to domain-joined state; re-apply GPO
4	Server Arc Enrollment	Pilot server Arc onboarding (20–30 servers across representative roles)	Wave 1 complete; Azure subscription provisioned; Azure Policy definitions created; monitoring workspace configured	Install Arc agent on pilot servers; assign Azure Policy baselines; configure Azure Monitor Agent; validate compliance state and monitoring data; test Azure Update Manager patching	All pilot servers visible in Azure portal; Azure Policy compliance state reporting; monitoring data flowing to Log Analytics; one successful patch cycle via Update Manager	4–6 weeks	Uninstall Arc agent; servers revert to AD/GPO/SCCM management
5	Broad Device Migration	Ring-based client device migration: 10% → 25% → 50% → 100%	Wave 3 complete and validated; Wave 3 lessons learned incorporated	Execute ring-based migration using Autopilot; deploy by OrgPath segment; monitor compliance, app installation, and user satisfaction per ring; advance rings per validation criteria	Per-ring: ≥98% of devices Entra Joined; compliance policies compliant; app installation success ≥95%; helpdesk ticket rate ≤5% of migrated devices per ring	16–24 weeks (all rings)	Per ring: re-image failed devices to domain-joined state. Rollback of completed rings requires new change request.
6	SCuBA Operationalization	UIAO SCuBA pipeline activation, drift detection, SLA enforcement	Wave 0 (ScubaGear baseline) complete; UIAO SCuBA platform deployed	Activate automated ScubaGear scheduling; configure UIAO SCuBA ingestion and delta analysis; establish desired-state registry; configure owner routing and SLA timers; generate first compliance trend report	Automated scans executing on schedule; delta analysis producing accurate new/resolved/persistent categorization; owner routing tested; SLA timers functional; first trend report reviewed by ISSO	6–8 weeks (initial); ongoing	Revert to manual ScubaGear execution; UIAO SCuBA pipeline suspended
7	Legacy Decommission	AD dependency removal for fully migrated OrgPath segments	All devices in target OrgPath segments migrated (Wave 5 complete for segment); all policies migrated to Intune; Arc enrollment complete for servers	Remove GPO links for migrated OUs; disable AD computer objects for migrated devices; migrate Connect Sync to Cloud Sync (full cutover); decommission ADFS (if applicable); archive legacy AD configuration	No active GPO links for migrated OUs; no active computer objects for migrated devices; Cloud Sync operating as sole sync engine; ADFS decommissioned (if applicable); legacy configuration archived	8–12 weeks per segment	Re-enable GPO links; re-enable computer objects; re-activate Connect Sync if Cloud Sync issues

9.3 Dependency Chain

The modernization waves are connected by a dependency chain that defines which waves must complete before others can begin. Understanding this chain is critical for project planning, resource allocation, and risk management.

Sequential Dependencies (Critical Path): Waves 0, 1, and 2 are strictly sequential — each builds on the outputs of its predecessor. Wave 0 produces the sync infrastructure and OrgPath attributes that Wave 1 consumes to create Administrative Units and dynamic groups. Wave 1 produces the dynamic groups that Wave 2 uses for Intune policy targeting. This sequence forms the critical path through the first half of the program.

Wave 3 (Pilot Device Migration) depends on Wave 2 completing successfully. Without Intune policies in place and validated, migrating devices to Entra Joined would leave them ungoverned — violating Principle 3 (Compliance Continuity).

Wave 4 (Server Arc Enrollment) runs in parallel with Waves 3 and 5. It depends only on Wave 1 (for Entra ID governance constructs and OrgPath tags) and the Azure subscription provisioning. Server Arc enrollment does not depend on the GPO migration (Wave 2) or client device migration (Wave 3) because servers use Azure Policy, not Intune.

Wave 5 (Broad Device Migration) depends on Wave 3 (pilot validation). The pilot wave validates the migration methodology, user experience, and operational procedures that Wave 5 will execute at scale. No broad migration begins without successful pilot completion.

Wave 6 (SCuBA Operationalization) can begin after Wave 0 produces the first ScubaGear baseline scan. However, full operationalization — including drift detection for Intune policies and Arc-managed servers — reaches maturity only after Waves 2–5 are complete and the modernized configuration is established as the canonical desired state.

Wave 7 (Legacy Decommission) is the terminal wave. It begins on a per-segment basis only after all devices and users in a given OrgPath segment have completed their migration (Waves 3–5 complete for that segment). Wave 7 is the final step in transitioning ownership from AD/GPO to Entra ID/Intune/Arc and cannot be reversed without significant effort.

+———————————+

Figure 2.6 — Diagram 7: Modernization Wave Dependency and Timeline** Dimensions: 6

Policy Waves. Green = Device |
Waves. Purple = Compliance |
Waves. Gray = Decommission. |
Solid arrow = Sequential |
dependency. Dashed arrow = |
Parallel path.  |
  |
Visual Style: White |
background. Clean horizontal |
bars. Week numbers on top axis. |
Wave names on left axis. Arrows |
with directional arrowheads |
showing dependency flow. |

+———————————+

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

---

Appendix D — Governance, RACI, and Artifact Traceability (Restored Detail)

Why this appendix exists. Rev 0.x §11 covers Governance Integration at a high level. The original Phase 1 v1.0 §10 carried the explicit RACI matrix (CIO / CISO / ISSO / AO / 3PAO / IT Ops / Identity Team / Endpoint Team) and the artifact-traceability taxonomy (MDR / PCW / DML / SSR / DDF / WAA). Both are restored below; this is the canonical form for Phase 1 governance-of-modernization.

Section 10 — Governance and Accountability

Governance ensures that every modernization activity is authorized, documented, and auditable. This section defines the RACI matrix for Phase 1 activities, the artifact traceability model, and the success criteria that determine whether the modernization program has achieved its objectives.

10.1 RACI Matrix

Table 15 defines the responsibility assignment for each major Phase 1 activity across the eight key stakeholder roles. Values: R (Responsible — performs the work), A (Accountable — owns the outcome), C (Consulted — provides input), I (Informed — notified of results).

Table 15: Phase 1 Modernization RACI Matrix

Activity	CIO	CISO	ISSO	AO	3PAO	IT Ops	Identity Team	Endpoint Team
OrgPath Schema Design	A	C	C	I	I	C	R	C
Identity Sync Migration	I	C	C	I	I	C	R	I
GPO Analysis	I	C	R	I	I	C	C	R
Intune Policy Creation	I	A	C	I	I	C	C	R
Device Migration	I	I	C	I	I	R	C	R
Arc Enrollment	I	C	C	I	I	R	C	I
SCuBA Pipeline	I	A	R	C	C	C	C	C
Drift Detection	I	A	R	I	C	C	C	C
Network Monitoring	I	C	C	I	I	R	I	C
Wave Advancement Approval	A	C	R	A	C	I	I	I

10.2 Artifact Traceability

Every modernization action must produce a traceable governance artifact. Artifacts are the evidentiary backbone of the modernization program — they enable after-the-fact audit, prove compliance with approved procedures, and provide the historical record necessary for future assessment cycles (including 3PAO assessments). The following artifact types are defined for Phase 1:

• Migration Decision Records (MDR): Document the rationale for each major migration decision, including alternatives considered, risk assessment, and approval authority. MDRs are produced for: sync engine selection (Connect Sync vs. Cloud Sync), GPO rationalization decisions (settings removed or modified), device migration methodology (Autopilot configuration), and wave advancement approvals.

• Policy Conversion Worksheets (PCW): Document the mapping from each GPO setting to its Intune equivalent, including transformation logic, testing results, and validation evidence. One PCW is produced per GPO or per logical group of related GPOs.

• Device Migration Logs (DML): Document each device migration event, including: device name, OrgPath, current state, target state, migration method, start time, end time, success/failure, and any issues encountered. DMLs are aggregated per wave for reporting.

• SCuBA Scan Reports (SSR): The raw ScubaGear outputs (HTML, JSON, CSV) produced by each scheduled scan, stored with timestamp and scan configuration metadata.

• Drift Detection Findings (DDF): Individual finding records produced by UIAO SCuBA, each with: finding ID, detection timestamp, drift category, severity, owner, remediation actions, verification scan result, and closure timestamp.

• Wave Advancement Approvals (WAA): Formal approval documents signed by the ISSO and AO confirming that all validation criteria for a wave have been met and authorizing advancement to the next wave.

All artifacts follow the UIAO metadata schema: document_id (unique identifier), title (descriptive name), version (semantic versioning), status (draft, review, approved, archived), classification (Controlled), owner (responsible individual), created_at (ISO 8601 timestamp), updated_at (ISO 8601 timestamp), and boundary (GCC-Moderate M365). Artifacts are stored in the UIAO Canon repository and are indexed for retrieval by artifact type, wave number, OrgPath segment, and date range.

10.3 Success Criteria

Table 16 defines the measurable success criteria for the Phase 1 Modernization Program. These metrics are tracked continuously and reported to the CIO, CISO, and AO on a monthly basis.

Table 16: Phase 1 Modernization Success Criteria

Metric	Target Value	Measurement Method	Reporting Frequency	Owner
OrgPath Coverage — Users	100% of active user objects have a valid OrgPath value	Scheduled validation script comparing extensionAttribute1 against OrgPath registry	Weekly	Identity Team Lead
OrgPath Coverage — Devices	100% of managed devices have an assigned device category aligned to OrgPath taxonomy	Intune device inventory report + Arc resource tag audit	Weekly	Endpoint Team Lead
Entra Cloud Sync Migration	Cloud Sync operating as sole sync engine (Connect Sync decommissioned)	Entra Cloud Sync provisioning logs; Connect Sync service status	Monthly	Identity Team Lead
GPO Migration Percentage	≥ 95% of rationalized GPO settings migrated to Intune	Policy Conversion Worksheet completion tracking	Monthly	Endpoint Team Lead
Device Entra Join Percentage (per wave)	Wave 3: 100% of pilot (50–100); Wave 5: 100% per ring completion	Entra ID device registration report filtered by join type	Weekly (during active waves)	Endpoint Team Lead
Arc Enrollment — Servers	100% of in-scope servers enrolled in Azure Arc	Azure Arc resource inventory vs. AD server computer object count	Monthly	IT Operations Lead
SCuBA Compliance Score — Entra ID	≥ 95% of controls passing	ScubaGear assessment output — Entra ID baseline	Daily	Identity Team Lead
SCuBA Compliance Score — Exchange Online	≥ 95% of controls passing	ScubaGear assessment output — Exchange Online baseline	Daily	Messaging Team Lead
SCuBA Compliance Score — All Baselines	≥ 90% of controls passing across all six baselines	ScubaGear assessment output — aggregate	Weekly	ISSO
Drift Detection — Operational Status	UIAO SCuBA pipeline operating 24/7 with automated scheduling	Pipeline health monitoring; scan execution logs	Daily (automated)	ISSO
Mean Time to Detect Drift (MTTD)	≤ 24 hours for policy drift; ≤ 8 hours for identity drift; ≤ 8 hours for device drift	UIAO SCuBA finding timestamps — detection time vs. change time (from audit logs)	Monthly	ISSO
Mean Time to Remediate Drift (MTTR)	Critical: ≤ 4 hours; High: ≤ 24 hours; Medium: ≤ 5 business days	UIAO SCuBA finding lifecycle — detection timestamp to closure timestamp	Monthly	ISSO

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

---

Appendix A — Glossary

Term	Definition
3PAO	Third-Party Assessment Organization. An independent organization accredited to perform FedRAMP security assessments on cloud service offerings.
Administrative Unit (AU)	An Entra ID construct that provides scoped administrative delegation. Administrative Units contain users, groups, or devices and allow role assignments that are limited to the objects within the AU, rather than the entire tenant.
AO	Authorizing Official. The senior federal official who formally assumes responsibility for operating an information system at an acceptable level of risk. The AO authorizes systems to operate and approves risk acceptance decisions.
Azure Arc	A Microsoft Azure service that projects on-premises, multi-cloud, and edge servers into Azure Resource Manager, enabling Azure management services (Azure Policy, Azure Monitor, Defender for Cloud, Update Manager) on non-Azure infrastructure.
Compliance Policy	An Intune policy that defines the minimum security configuration requirements a device must meet to be considered compliant. Non-compliant devices can be blocked from organizational resources via Conditional Access integration.
Conditional Access	An Entra ID capability that enforces access control decisions based on signals such as user identity, device compliance, location, risk level, and application sensitivity. Conditional Access policies are the primary access control mechanism in the cloud-native model.
Configuration Drift	Any unauthorized or untracked deviation of a system, service, or tenant configuration from its canonical desired state. Drift can be caused by manual changes, automated processes, or synchronization failures.
Configuration Profile	An Intune policy that configures specific device settings such as Wi-Fi, VPN, email, certificates, or Windows features. Configuration profiles are the cloud-native replacement for many Group Policy settings.
Desired State	The canonical, approved configuration of a system, service, or tenant as defined in the UIAO governance registry. The desired state serves as the reference against which drift is measured.
Dynamic Group	An Entra ID security group whose membership is automatically calculated based on attribute-based rules (e.g., user.department -eq "IT" or device.deviceCategory -eq "Laptop"). Dynamic groups eliminate manual group membership management.
Entra Cloud Sync	The strategic Microsoft identity synchronization service that uses lightweight, auto-updating provisioning agents with cloud-managed configuration. Cloud Sync supports multi-agent deployment for automatic failover and stores configuration in Entra ID.
Entra Connect Sync	The legacy Microsoft identity synchronization application (formerly Azure AD Connect) that runs on a dedicated Windows Server. Connect Sync uses a single-server architecture with optional staging mode for failover and stores configuration locally.
FedRAMP	Federal Risk and Authorization Management Program. A U.S. government program that provides a standardized approach for security assessment, authorization, and continuous monitoring of cloud products and services.
GCC-Moderate	Government Community Cloud at the Moderate impact level. A Microsoft 365 cloud environment that meets FedRAMP Moderate requirements, providing compliance isolation for federal and government workloads. In this document, GCC-Moderate applies to M365 SaaS services only.
Group Policy Analytics	A feature in Microsoft Intune that imports GPO XML reports and generates MDM compatibility analysis, showing which GPO settings have direct Intune equivalents and which do not.
ISSO	Information System Security Officer. The individual responsible for ensuring the operational security of an information system, including compliance monitoring, vulnerability management, and security incident response.
Known Folder Move (KFM)	A OneDrive for Business feature that redirects the Windows Desktop, Documents, and Pictures folders to OneDrive, providing automatic cloud backup and enabling seamless data preservation during device migration.
MDM Wins Over GP	A Windows policy setting (ControlPolicyConflict/MDMWinsOverGP) that resolves conflicts between Group Policy and MDM policy in favor of the MDM setting. This is a global toggle required during the hybrid coexistence period.
OrgPath	A structured string attribute (format: Region/Division/Department/Function) that encodes organizational hierarchy into a single value carried on user and device objects in Entra ID. OrgPath enables dynamic group membership, Administrative Unit scoping, and policy targeting.
OrgTree	The complete hierarchical taxonomy of all valid OrgPath values for the UIAO, maintained as a controlled vocabulary in the UIAO Canon. The OrgTree defines the organizational structure that the OrgPath attribute references.
SCuBA	Secure Cloud Business Applications. A CISA initiative that provides security configuration baselines for Microsoft 365 services, along with the ScubaGear assessment tool to verify compliance.
ScubaGear	A CISA-developed open-source PowerShell assessment tool that evaluates Microsoft 365 tenant configuration against SCuBA baseline documents using the Open Policy Agent (OPA) engine with Rego security policies.
Settings Catalog	The strategic Intune mechanism for granular policy configuration. The Settings Catalog provides a searchable, filterable interface to thousands of individually configurable settings across Windows, macOS, iOS/iPadOS, and Android.
UIAO SCuBA	The UIAO's governance orchestration layer that sits above CISA ScubaGear. UIAO SCuBA provides continuous drift detection, desired-state management, remediation tracking with SLA enforcement, and machine-trackable governance provenance.
Windows Autopilot	A cloud-native Windows device provisioning service that enables zero-touch deployment. Autopilot uses the device's hardware hash to automatically configure Entra ID join, Intune enrollment, and application installation during the Out-of-Box Experience (OOBE).

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

---

Appendix B — Reference Architecture Summary

Table 17 provides a single-page summary of all architectural components referenced in this document, their purpose, GCC-Moderate scope, ownership, and current status as of this document's publication date.

Table 17: Reference Architecture Summary

Component	Purpose	GCC-Moderate Scope	Owner	Status
Microsoft Entra ID	Cloud-native identity provider; shared identity authority for all modernized services	Core M365 SaaS — GCC-Moderate tenant	Identity Team	Operational
Microsoft Entra Cloud Sync	Strategic identity synchronization from on-premises AD to Entra ID	Provisioning agents on-premises; configuration in GCC-Moderate Entra	Identity Team	Deploying (Wave 0)
Microsoft Entra Connect Sync	Legacy identity synchronization (active until Cloud Sync cutover)	On-premises server; syncs to GCC-Moderate Entra	Identity Team	Operational — Planned Decommission (Wave 7)
Microsoft Intune	Client endpoint management — compliance, configuration, app deployment, endpoint security	Core M365 SaaS — GCC-Moderate tenant	Endpoint Team	Operational — Expanding (Waves 2–5)
Azure Arc	Server infrastructure projection into Azure Resource Manager for cloud-native management	Arc agents on-premises; management plane in Azure Government	IT Operations	Deploying (Wave 4)
Conditional Access	Risk-based access control — enforces MFA, device compliance, location, and risk signals	Core M365 SaaS — GCC-Moderate tenant	Identity Team	Operational — Expanding (Wave 1)
Administrative Units	Scoped delegation of administrative roles aligned to OrgPath taxonomy	Core M365 SaaS — GCC-Moderate Entra	Identity Team	Deploying (Wave 1)
Dynamic Security Groups	Attribute-based group membership using OrgPath values for policy targeting	Core M365 SaaS — GCC-Moderate Entra	Identity Team	Deploying (Wave 1)
Entra ID Governance	Access packages, entitlement management, and access reviews for identity lifecycle	Core M365 SaaS — GCC-Moderate Entra (P2 license required)	Identity Team	Deploying (Wave 1)
Settings Catalog	Granular Intune policy configuration — strategic replacement for device configuration profiles	Core M365 SaaS — GCC-Moderate Intune	Endpoint Team	Deploying (Wave 2)
Windows Autopilot	Zero-touch device provisioning for Entra Joined devices	Core M365 SaaS — GCC-Moderate Intune	Endpoint Team	Configuring (Wave 3)
Windows Update for Business	Cloud-managed Windows patching with update rings and feature update targeting	Core M365 SaaS — GCC-Moderate Intune	Endpoint Team	Deploying (Wave 2)
CISA ScubaGear	Open-source M365 baseline assessment tool using OPA/Rego policy evaluation	PowerShell tool executed against GCC-Moderate tenant APIs	ISSO	Operational (Wave 0+)
UIAO SCuBA	Governance orchestration layer — drift detection, remediation tracking, provenance	Internal platform consuming ScubaGear outputs from GCC-Moderate scans	ISSO	Deploying (Wave 6)
Azure Policy	Compliance enforcement for Azure Arc-enrolled servers	Azure Government subscription aligned to GCC-Moderate tenant	IT Operations	Configuring (Wave 4)
Azure Monitor / Log Analytics	Centralized monitoring and log aggregation for Arc-enrolled servers	Azure Government subscription	IT Operations	Configuring (Wave 4)
Microsoft Defender for Cloud	Cloud security posture management and workload protection for Arc servers	Azure Government subscription	ISSO	Configuring (Wave 4)
ThousandEyes for Government	Network visibility — path analysis, synthetic monitoring, real user monitoring	FedRAMP Moderate SaaS (AWS GovCloud); agents on managed infrastructure	IT Operations	Evaluating — Deployment Planned
Universal Print	Cloud-managed print service replacing legacy GPO-deployed printer connections	Core M365 SaaS — GCC-Moderate tenant	Endpoint Team	Evaluating (Wave 5)
OrgPath Registry	Controlled vocabulary of all valid OrgPath values, maintained in the UIAO Canon	Internal governance artifact	Identity Team	Deploying (Wave 0)

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

End of Document

UIAO Modernization Program — Phase 1: Modernization Mechanics

Version 1.0 | April 2026 | Controlled

UIAO Modernization Program — Phase 1: Modernization Mechanics | Controlled | April 2026

---

Appendix F — Phase 1 Needs-Input Register

The following items remain marked as needing further input or stakeholder review before this document exits DRAFT status:

1. Production OrgTree values. Region/Division/Department/Function tokens used throughout this document are illustrative samples. The production set must be derived from the Assessment Phase forest analysis and published to src/uiao/canon/ with a UIAO_NNN allocation.
2. Per-wave durations. Appendix C carries the original v1.0 duration estimates (e.g., “4–6 weeks” for Wave 0). These are first-pass planning numbers and require validation against the agency’s actual change-management calendar and resourcing.
3. Diagram placeholders. The original v1.0 carried six PlantUML diagram placeholders (DIAG-001 through DIAG-006, including the GCC-Moderate Network Visibility Architecture in Appendix B). None are yet rendered. They should be authored under docs/figures/phase1/ and referenced from this document via Quarto.
4. Identity Translation table fill-in. Where the original §3 table marked specific attribute mappings, several rows depended on agency-specific schema extensions. Those rows are retained verbatim and need agency review.
5. Network Visibility tool selection. Appendix B presents ThousandEyes for Government as the primary recommendation. Final selection requires procurement validation and AO concurrence on the FedRAMP-Moderate (March 2026) authorization status.
6. RACI customization. Appendix D’s RACI matrix lists eight stakeholder columns. Agencies with a different role taxonomy (e.g., no separate Identity Team) should adjust before adoption.