Chapter 10 — Execution Plan
Chapter 10 — Execution Plan
Designate the source, prove the pipe, automate the lifecycle, then derive access.
The one phase model this site uses, 0 to 6, with each phase’s work and exit gate. The program at a glance. Roles. The open verification register.
Sequencing principle
Each phase’s gate is the next phase’s precondition. The order isn’t optional: deriving access from attributes nobody has agreed to trust is how fragmented truth gets rebuilt with better tooling. One caveat governs the whole program: the source must be correct, not just designated. A drifted HR feed produces drifted access faster than any ticket queue could, so data quality at the source is Phase 1 work, not a later clean-up. A phase that can’t pass its gate stops the plan, not the standard.
Phase 0 — Program alignment
Directed by the Federal HR 2.0 memo’s preparation actions: executing it is compliance, not overhead (Chapter 02).
- Name the agency’s integrated project team point of contact and the working-group points of contact.
- Inventory integration points, interfacing systems and data flows. The identity provisioning feed is one of them.
- Identify legacy identity-relevant data to retain, and define how to preserve what doesn’t migrate.
- Confirm the pause on any competing Core HCM modernization.
Gate: the integration-point inventory is signed by the ISSO and submitted to the agency’s HR 2.0 team.
Phase 2 — Pipeline build and test
- Build the middleware: transform, validation, sequencing and the provenance writer, hosted in-boundary (Chapter 04).
- Configure the API-driven provisioning apps and grant the client only
SynchronizationData-User.UploadandProvisioningLog.Read.All. - Define the joiner, mover and leaver workflows and their triggers (Chapter 06), including the custom task extensions for device retirement and CMS revocation (Chapter 07).
- Prove the chain end to end in a test tenant with canned feed payloads and a sandbox extract.
- Size the throttling envelope: batches toward 50 operations per call, the daily call budget against the tenant cap.
Gate: joiner, mover and leaver each run end to end in the test tenant with a provenance record and a workflow run; the leaver run includes a device retire and a test-CA certificate revocation.
Phase 3 — Hybrid go-live (pilot)
- Deploy at least two provisioning agents under a gMSA with OU-scoped rights (Chapter 04) and map SCIM to AD attributes.
- Run the initial full sync with scoping filters; reconcile mismatches before enabling deltas. Enable delta feeds immediately after the initial sync, with monitoring and alerting.
- Run the pilot cohort in shadow mode first: the pipeline computes what it would do, and the output is compared with the directory’s actual state. Then let it act.
Gate: thirty days in which every pipeline-versus-directory difference is explained and fixed at the right end; a full joiner/mover/leaver cycle on the pilot cohort closes with evidence; zero unmatched-record creations.
Phase 4 — Lifecycle automation and attribute-derived access
- Turn causation on for covered populations, leaver first, because revocation is where the risk and the evidence value are. Measure the separation-to-revocation interval from day one (Chapter 09).
- Route exceptions (emergency terminations, litigation holds) through defined manual entries into the same workflows and the same evidence.
- Validate rehire and conversion matching against history before it acts.
- Convert hand-maintained groups to rules for dynamic membership, group by group, with a shadow comparison before each cutover (Chapter 08). Re-base access packages so approvals route to the supervisor of record.
- Inventory OU-bound policy for retirement in Phase 5.
Gate: zero missed leavers across a full pay-period cycle, with separation-to-revocation measured in hours; day-one readiness demonstrated; the account-creation ticket queue retired for covered populations; for covered applications, every entitlement resolves to a rule, an attribute and a worker record; a test reorganization in HR propagates to groups and approvals with zero manual directory changes.
Phase 5 — Cutover to cloud-mastered populations
- Align the cutover with the agency’s Core HCM onboarding: the provisioning feed must be ready when the agency’s interconnections go live (Chapter 02).
- As populations become cloud-mastered, retarget their provisioning from the AD app to the Entra app — a configuration change per population, evidence-gated — with the AD leg dormant but intact until nothing remains synced.
- Retire OU-bound policy deliberately, and retire EHRI- and eOPF-shaped integrations as the program decommissions those systems, not before.
Gate: cloud-mastered populations run the full lifecycle cloud-native with evidence; no AD writes for migrated populations; the rollback path tested once.
Phase 6 — Sustained posture
- Drift detection runs continuously (Chapter 09); the five lifecycle metrics are reported on the ConMon cadence.
- Code lists, rules and workflows change only through change control, with the same shadow-then-act discipline.
- Annual re-validation of the authority map, the schema and the verification register.
Gate (recurring): metrics within thresholds for each reporting period; every high-severity drift finding closed or on a dated plan.
The program at a glance
| Phase | Output | Gate |
|---|---|---|
| 0 — Program alignment | Integration-point inventory; named points of contact | Inventory signed and submitted |
| 1 — Attribute authority and schema | Signed authority map and schema; source data fixed; correlation baseline | ≥ 99% match key on pilot; every enabled account correlated or excepted |
| 2 — Pipeline build and test | Middleware, apps, workflows, extensions in a test tenant | End-to-end J/M/L with evidence, including device and certificate steps |
| 3 — Hybrid go-live (pilot) | Agents, initial sync, deltas, shadow mode | 30 days of explained differences; zero unmatched creations |
| 4 — Lifecycle automation and derived access | Leaver-first automation; dynamic groups; re-based access packages | Zero missed leavers; test reorganization with zero manual changes |
| 5 — Cutover to cloud-mastered | Per-population retarget; OU policy retired | Cloud-native lifecycle with evidence; rollback tested |
| 6 — Sustained posture | Continuous drift detection and metrics | Recurring thresholds met |
Phases 1 and 2 produce no visible change for end users, which is exactly why estates skip them, automate against unverified data in month one, and spend year two explaining to an assessor why the automation deprovisioned a regional director.
Roles
| Role | Owns |
|---|---|
| Agency HR 2.0 integrated project team point of contact | Phase 0 actions, the interface inventory, the onboarding schedule |
| Identity engineering | Middleware, provisioning apps, agents, mappings, workflows, extensions |
| Oracle HCM administrator | Extracts, feed enablement, REST access, sandbox data |
| PIV / credentialing office | The CMS, issuance and revocation, the CMS side of the leaver extension |
| Endpoint management | Intune device actions and certificate profiles |
| ISSO | Phase gates, evidence review, the security assessment (Appendix B) |
| Service desk | Exceptions and failed-task follow-up |
Open verification register
| Item | Why it matters | Status |
|---|---|---|
| Post-award interface requirements for Core HCM | May constrain or enrich the feed contract | Open; check at engagement time |
| eOPF and EHRI decommission schedule | Times the retirement of EHRI-shaped integrations | Open; the memo says “eventually” |
| Native Oracle HCM connector for Entra | Would become an optimization inside the architecture | Watch |
| Agency onboarding schedule movement | The interconnection go-live is the deadline | Watch program communications |
| Extension-attribute carriers free and mappable | Phase 1 gate | Check per tenant |
| PIV issuing CA CRL sizes and delta CRLs | Revocation latency and CBA availability (Chapter 07) | Check per issuing CA |
| Licensing and the Phase 2 gate | Closed. Microsoft Entra ID Governance for Government is available in GCC, GCC High and DoD;1 GCC tenants run in Azure Global, the worldwide Entra service.2 Confirm licenses in-tenant as usual |
Footnotes
Microsoft Learn, “Microsoft Entra ID Governance licensing fundamentals,” https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals (accessed Oct 19, 2026).↩︎
Microsoft Learn, “Understand Microsoft Entra certificate-based authentication certificate revocation list” (FAQ: CRL size limits for “Azure Global includes GCC”), https://learn.microsoft.com/en-us/entra/identity/authentication/concept-certificate-based-authentication-certificate-revocation-list (accessed Oct 19, 2026).↩︎