Skip to main content
This is not an official U.S. federal government website. The Federal Modernization Workbook is independent technical analysis. It does not represent the position of, and has not been reviewed or endorsed by, any federal agency.

Project plan · Sample · Project

Privileged Access & Administrative Identity: Just-in-Time by Tier

A sample project plan for Book 04’s privileged model: emergency access first, then PIM self-request with approval for one role class, then every tier, with the decisions that set each gate

A sample PMP-style project plan for the Privileged Access & Administrative Identity project, built from Book 04, Chapters 04 to 10 and Appendix B: a work breakdown from the privilege inventory to every tier under just-in-time elevation, a computed critical path, a gate per phase with its approver and criteria, and the decisions (tier model, approvers, break-glass custody, PAW enforcement, review cadence) with owners and decide-by weeks.
NoteA sample plan, not a commitment

This is an illustrative plan built from the workbook’s books, in the form a project manager would baseline: a work breakdown, a schedule network, a computed critical path, decision points, gates and risks. The durations are illustrative, sized to the books’ roadmap weeks. Replace them with the agency’s own estimates, then baseline the result. The plan names roles, not people, and no specific agency.

Plan at a glance

Plan at a glance
Plan type Project: Inventory, foundation, a just-in-time pilot, every tier, and the evidence and residual risk
Built from Book 04
Sponsor Executive sponsor and CIO; CISO
Plan manager Project lead, with the four domain leads: privileged roles, non-human identity, break-glass and separation of duties
Duration 39 weeks (195 working days), computed from the network
Work 28 tasks, 5 gates, 7 decision points, 5 milestones from other plans
Critical path 3 of 45 items; 1 more within 5 days of it
Calendar Week 1 = the program’s Phase 0 approval; five working days a week

This plan builds the privileged half of Book 04: the privilege tiers in Chapter 04, the administrator policies in the Conditional Access library, PIM self-request with approval in Chapter 08 and Appendix B, the reviews in Chapter 09, and the repository and evidence in Chapter 10. It follows the charter: inventory, elevate just-in-time for one role class, reduce, govern the exceptions, evidence. It feeds the program master schedule: the emergency access accounts it builds and the phishing-resistant registration it opens to Tier 0 administrators are G1 criteria, and its pilot feeds the program’s PIM milestone in Phase 2 without being the same thing. This plan’s pilot takes one role class to just-in-time elevation, at its Gate 2 (end of week 14). The program’s pilot goes further: its P2.5 (milestone M-026) makes every role a pilot administrator holds eligible, in week 11 (Book 00, Chapter 06). The link is shown under Links to other plans (X-P25).

Schedule

Gantt chart of the Privileged Access & Administrative Identity plan over 39 weeks, grouped by phase. Critical-path tasks are red bars, other tasks are blue bars with a grey line showing their float, gates are violet diamonds, decisions are amber diamonds and milestones from other plans are green diamonds. The tables below give every date and float.

The schedule as a Gantt chart: 39 weeks, with the critical path in red.

Critical path

This project runs ahead of the program, as Book 00, Chapter 06 intends, so what binds it early is the program’s gates, not its own finish. The program’s G1 (end of week 8) needs the emergency access accounts and phishing-resistant registration for Tier 0 administrators: they’re done with ten working days to spare. The program’s G2 (end of week 16) needs just-in-time elevation in use for the pilot class, this plan’s Gate 2: it lands with twelve days to spare. Those margins, shown under Links to other plans, are the numbers to track; the float on the early decisions is measured to this plan’s finish and overstates their slack. Read them against G1: the tier model, the break-glass custody and the approvers have to be settled by week 4.

The computed critical path is the tail: the program’s G3, then retiring the access-related Group Policy settings the library has replaced, then naming the residual standing privilege in the system security plan and taking it to the authorizing official. Inside the foundation, the order is fixed. Emergency access comes first, then the activation policy, then the role settings, because switching on approval before the emergency accounts exist is the one sequence that locks the agency out.

The critical path, in order. Each item has zero total float: a day lost on any of them is a day lost at the finish.

The critical path
# ID Item Owner or approver When
1 A4.1 Access-related GPO settings (smart-card logon, logon rights) retired where the library policy is enforced Identity engineering wk 37–38
2 A4.2 Residual standing privilege named in the system security plan; residual risk to the authorizing official ISSO wk 39
3 AG4 Gate 4 — Residual privilege owned CISO end of wk 39

Near-critical. These items have 5 working days of float or less. Track them weekly: once their float is spent, they join the critical path.

Near-critical items
ID Item Float When
A4.3 Monthly evidence package assembled and its metrics signed off 5 d wk 37–38

Decision points

Each decision is a zero-duration milestone in the network. Decide by is its late finish: the last week it can be made without moving the plan’s finish. A decision with zero float sits on the critical path, so the meeting that makes it should be booked before the plan is baselined. Decision rights follow Book 01, Chapter 09.

Decision points, by decide-by date
ID Decision Decides Needed by Decide by Float Options If it’s late
D-A2 Emergency access credentials and custody CISO A1.1 end of wk 7 32 d Passkey (FIDO2) security keys or certificate-based authentication, different from the normal administrator methods; in either case retrieved only under dual custody by two senior administrators Step 0 can’t close, so no role can be made eligible and no approval switched on
D-A1 Privilege tier model CISO AG0, D-A3, D-A6 end of wk 9 36 d The program’s four tiers as published (T0 control plane, T1 management plane, T2 scoped operations, read-only); the same boundaries with hour counts adapted to the agency’s role inventory No role’s settings can be written, and the PIM build waits
D-A3 Approvers for PIM activation, by tier CISO A1.4 end of wk 9 36 d The security office as PIM-Approvers-T0, outside the Tier 0 population; a governed group outside the Tier 1 population as PIM-Approvers-T1; for each Tier 2 role, approval or a documented risk acceptance Approval can’t be switched on without the lockout risk, and the role settings wait
D-A4 Write path for access as code Identity engineering A1.6 end of wk 10 27 d Microsoft365DSC for every object class (the program’s reference); Terraform azuread for the classes it covers, with Graph PowerShell for PIM role settings, access reviews and Lifecycle Workflows Role settings can’t be held as code, and the drift baseline waits
D-A5 First role class under just-in-time elevation CISO A2.1 end of wk 11 47 d Tier 0 control-plane roles; Tier 1 management-plane roles The pilot has no scope, and the program’s Phase 2 PIM milestone waits
D-A7 PAW enforcement for the administrator persona CISO A2.6 end of wk 14 12 d Enforce CA004 and CA025 for every administrator; enforce with a time-bound exclusion group for administrators whose PAW isn’t issued; keep report-only and fix the causes first Privileged roles stay usable from any device, and the pilot gate waits
D-A6 Access review cadence for privileged roles CISO A2.7 end of wk 14 62 d Monthly for Tier 0 and quarterly for every other privileged role (the program’s design); another organization-defined frequency, which AC-6(7) leaves to the agency Reviews can’t be scheduled, and the pilot gate’s first-review criterion fails

Gates

A gate opens the work that names it as a predecessor, which is usually the next phase but not always. The approver signs it against the criteria, from evidence in the repository.

Gates
Gate When Approver Criteria
Gate 0 — Privilege inventoried end of wk 2 CISO Standing administrative privilege inventoried and classified by tier; app registrations listed with their owners and credentials; emergency access accounts located; tier model approved
Gate 1 — Foundation ready end of wk 9 CISO Emergency access accounts tested; PIM-Activation-c1 On; an approver group named on every role that requires approval; role settings in the repository and reviewed; logs exported beyond 30 days
Gate 2 — Just-in-time in use for the pilot class end of wk 14 CISO Every human assignment in the pilot class eligible; only the emergency accounts and documented service principals standing; validation tests pass; the first review closed with removals applied; every elevation evidenced in the workspace
Gate 3 — Every tier just-in-time end of wk 25 CISO Every human privileged assignment eligible; requester and approver distinct for Tier 0 changes; non-human privileged identities in scope have two named owners; reviews running on the approved cadence; a Tier 0 drift handled as an incident
Gate 4 — Residual privilege owned end of wk 39 CISO Residual standing privilege named with a rationale and accepted by the authorizing official; evidence for every elevation in the period; exception register current; the replaced access-related GPO settings retired

Work breakdown and schedule

Every row, by phase. Float is total float in working days; bold rows are on the critical path. Each row links to the chapter it comes from.

Phase 0 — Inventory

Phase 0 — Inventory
ID Item Type Owner or approver Days Predecessors When Float
A0.1 Active directory-role assignments inventoried and classified by tier Task Identity engineering 8 — wk 1–2 36 d
A0.2 Azure privileged role assignments and subscription owners inventoried Task Identity engineering 5 — wk 1 50 d
A0.3 App registrations, owners, credentials and granted permissions inventoried, read-only; automation on the protected permissions found Task Identity engineering 8 — wk 1–2 47 d
A0.4 Existing emergency access accounts located and checked against the standard Task Identity engineering 3 — wk 1 32 d
D-A1 Privilege tier model Decision CISO — A0.1 end of wk 2 36 d
AG0 Gate 0 — Privilege inventoried Gate CISO — A0.1, A0.2, A0.3, A0.4, D-A1 end of wk 2 47 d
X-G0 Program G0 — Ready to Plan External Steward (backup: executive sponsor; program) — — end of wk 4 10 d

Phase 1 — Foundation: emergency access and the activation gate

Phase 1 — Foundation: emergency access and the activation gate
ID Item Type Owner or approver Days Predecessors When Float
D-A2 Emergency access credentials and custody Decision CISO — A0.4 end of wk 1 32 d
A1.1 Two emergency accounts built to the standard, excluded by one group, alerted and tested Task Identity engineering 5 D-A2, X-G0 wk 5 15 d
A1.2 Phishing-resistant MFA registered for every eligible administrator, Tier 0 first (the program’s G1 criterion covers Tier 0 administrators only) Task Identity engineering 10 X-G0 wk 5–6 10 d
A1.3 Audit and sign-in logs exported to the workspace at 365-day retention Task Identity engineering 5 X-G0 wk 5 30 d
D-A3 Approvers for PIM activation, by tier Decision CISO — D-A1 end of wk 2 36 d
A1.4 Approver groups built, at least two approvers per tier Task Identity engineering 3 D-A3, X-G0 wk 5 24 d
A1.5 Authentication context c1 and its policy PIM-Activation-c1 built and turned On Task Identity engineering 3 A1.1, A1.2 wk 7 14 d
D-A4 Write path for access as code Decision Identity engineering — X-G0 end of wk 4 27 d
D-A5 First role class under just-in-time elevation Decision CISO — AG0 end of wk 2 47 d
D-A6 Access review cadence for privileged roles Decision CISO — D-A1 end of wk 2 62 d
A1.6 Role settings for every tier written as code from Appendix B and reviewed Task Identity engineering 8 D-A4, A1.4, A1.5 wk 7–9 14 d
AG1 Gate 1 — Foundation ready Gate CISO — A1.6, A1.3 end of wk 9 14 d
X-G1 Program G1 — Foundation Complete External Steward (program) — A1.1, A1.2 end of wk 8 fixed date

Phase 2 — Just-in-time pilot for one role class

Phase 2 — Just-in-time pilot for one role class
ID Item Type Owner or approver Days Predecessors When Float
A2.1 Pilot class’s role settings applied; PRV role-assignable groups hold the eligible assignments Task Identity engineering 5 AG1, X-G1, D-A5 wk 9–10 14 d
A2.2 Standing assignments in the pilot class converted: eligible first, activation confirmed, active removed Task Identity engineering 10 A2.1 wk 10–12 14 d
X-P25 PIM for every pilot administrator (program P2.5, M-026) External Platform teams (program) — — end of wk 11 fixed date
A2.3 Protected actions with context c2 on the Conditional Access permissions Task Identity engineering 5 A2.1, A0.3 wk 10–11 26 d
A2.4 Notifications and PIM alerts routed; the assigned-outside-PIM alert reaches the SIEM Task Security operations 3 A2.1 wk 10 28 d
A2.5 Administrator policies (CA003 to CA005, CA025 to CA027) in report-only, then piloted on the identity team Task Identity engineering 15 X-G1 wk 9–11 12 d
D-A7 PAW enforcement for the administrator persona Decision CISO — A2.5 end of wk 11 12 d
A2.6 Administrator policies enforced ring by ring, an emergency sign-in tested before and after Task Identity engineering 10 D-A7 wk 12–13 12 d
A2.7 First monthly review of Tier 0 eligibility and PRV-T0 membership closed Task Identity governance officer 10 A2.2, D-A6 wk 12–14 14 d
A2.8 Validation test plan run for the pilot class Task ISSO 3 A2.2, A2.3, A2.4, A2.6 wk 14 12 d
AG2 Gate 2 — Just-in-time in use for the pilot class Gate CISO — A2.7, A2.8 end of wk 14 12 d
X-G2 Program G2 — Pilot Clean External Steward and executive sponsor (co-signed; program) — AG2 end of wk 16 fixed date

Phase 3 — Every tier

Phase 3 — Every tier
ID Item Type Owner or approver Days Predecessors When Float
A3.1 Remaining tiers converted to eligible, tier by tier Task Identity engineering 30 AG2, X-G2 wk 17–22 65 d
A3.2 Azure privileged roles eligible through PIM; three subscription owners at most Task Identity engineering 15 A3.1 (SS) +5 d wk 18–20 90 d
A3.3 PRV group membership published as access packages with approval, expiry and review Task Identity engineering 15 AG2, X-G2 wk 17–19 80 d
A3.4 Non-human privileged identities: two named owners each, credentials off secrets, over-consented apps swept Task Identity governance officer 40 AG2, X-G2 wk 17–24 70 d
A3.5 Help desk privileged access group narrowed to a custom assignment role Task Identity governance officer 5 A3.1 wk 23 75 d
A3.6 Change control in force: two people per change, a security approver for Tier 0 objects, drift every six hours Task Identity engineering 15 AG2 wk 14–17 102 d
A3.7 First quarterly review cycle closed for Tier 1, Tier 2 and read-only roles Task Identity governance officer 15 A3.1, A3.3 wk 23–25 65 d
AG3 Gate 3 — Every tier just-in-time Gate CISO — A3.2, A3.4, A3.5, A3.6, A3.7 end of wk 25 65 d
X-G3 Program G3 — Rollout Complete External Executive sponsor and steering committee (program) — — end of wk 36 0

Phase 4 — Evidence and residual risk

Phase 4 — Evidence and residual risk
ID Item Type Owner or approver Days Predecessors When Float
A4.1 Access-related GPO settings (smart-card logon, logon rights) retired where the library policy is enforced Task Identity engineering 10 X-G3, A2.6 wk 37–38 0
A4.2 Residual standing privilege named in the system security plan; residual risk to the authorizing official Task ISSO 5 AG3, A4.1 wk 39 0
A4.3 Monthly evidence package assembled and its metrics signed off Task Identity governance officer 10 A3.6, X-G3 wk 37–38 5 d
AG4 Gate 4 — Residual privilege owned Gate CISO — A4.2, A4.3 end of wk 39 0

Responsibility

Who owns what in this plan. Each row has one owner; consulted and informed parties follow the decision matrix.

Ownership
Owner or approver Tasks Decisions Gates
Identity engineering 20 1 —
CISO — 6 5
Identity governance officer 5 — —
ISSO 2 — —
Executive sponsor and steering committee (program) 1 — —
Platform teams (program) 1 — —
Security operations 1 — —
Steward (backup: executive sponsor; program) 1 — —
Steward (program) 1 — —
Steward and executive sponsor (co-signed; program) 1 — —

Assumptions

  • Every user with an eligible or time-bound assignment, every approver and every reviewer is licensed for Microsoft Entra ID P2 or Entra ID Governance (Chapter 08).
  • Privileged access workstations are built by the endpoint project as Tier 0 devices with their own compliance policy (Book 05, Chapter 08) and labeled through the device role attribute.
  • The tier boundaries are the program’s design; the hour counts and review cadences are a starting posture the agency adapts (Chapter 04).
  • Two standing exceptions remain by design: the emergency access accounts and service principals that can’t perform an activation (Chapter 08).
  • Durations are illustrative. Replace them with the agency’s own estimates once the role inventory is in.

Schedule risks

Schedule risks
Risk Effect on the schedule Response
Approval is switched on before the emergency access accounts exist The documented tenant lockout: no active administrator can approve or recover Build and test the emergency accounts first (Step 0), and name the approver group on every role (Chapter 08)
The P2 or Governance subscription lapses Eligible assignments and PIM settings are removed; time-bound active assignments become permanent Treat license expiry as a configuration-management event; keep the role inventory exported as code so it can be restored (Chapter 08)
Approver groups can’t cover real operating hours Requests expire after 24 hours; operators push back on just-in-time for critical roles Size each approver group for the agency’s hours; make the emergency procedure, not a workaround, the answer when approvers are unavailable (Chapter 08)
Automation breaks when protected actions are turned on Azure PowerShell fails on protected actions; the pilot slips while scripts are rewritten Inventory the automation that touches those permissions in Phase 0, and move it to Microsoft Graph PowerShell first (Chapter 08)

Baseline and change control

  • Baseline the plan when its first gate is approved: the YAML file, as merged, is the baseline.
  • Report weekly, green, yellow or red, against the baseline (Book 01, Chapter 12). Report float, not percent complete: a task’s float says how much slip the plan can still absorb.
  • Change the plan only through a reviewed pull request that edits the YAML and regenerates this page, so every change to a date or a dependency has an author, a reviewer and a reason.
  • Re-baseline at each gate, after the approver signs it, and whenever a critical-path decision is made late.

Download and adapt

Downloads
File Use it for
privileged-access.xml Microsoft Project desktop (open the XML file; it keeps the dependencies, milestones and owners). The dates start on a placeholder Monday: change the project start date.
privileged-access.csv Excel or any other scheduling tool: every row with its dependencies, early and late dates and float
privileged-access-azure-boards.csv Azure DevOps Boards: an Epic per phase and a Feature per task, gate and decision, with dates and tags (see below)
privileged-access-dependencies.csv · add-azure-boards-links.ps1 The plan’s predecessor links, and a script that adds them in Azure Boards after the import
privileged-access-jira.csv Jira: an Epic per phase and a Task per task, gate and decision, with dates, labels and Blocks links (see below)
privileged-access.yaml The source. Edit the durations, owners and dependencies, then run python scripts/project_plans/build.py to recompute the critical path and regenerate this page, the chart and the downloads.
TipImporting this plan into Azure DevOps Boards
  1. In the project, select Boards > Queries > Import work items, choose privileged-access-azure-boards.csv, check the results and select Save items. It creates one Epic per phase with a Feature under it for each task, gate and decision, with start and target dates, which is what Delivery Plans show. Epic and Feature exist in the Agile, Scrum and CMMI processes; in the Basic process, change Feature to Issue in the file first.
  2. The import can’t create dependency links or assign people. To add the predecessor links, sign in with az login, add the CLI extension with az extension add --name azure-devops, and run ./add-azure-boards-links.ps1 -Organization https://dev.azure.com/<org> -Project <project> -Plan privileged-access beside privileged-access-dependencies.csv. It finds the imported items by their fmw-id- tags and links each one to its predecessors.
  3. Assign people in Boards: each item carries its owner role as an Owner - … tag, and critical-path items carry Critical path. Azure Boards links don’t hold lag or start-to-start timing; each item’s description keeps them.

The dates count from the plan’s placeholder start; shift them when you set the real start. The script hasn’t been run against a live organization yet: test it on a scratch project first.

TipImporting this plan into Jira
  1. Run the CSV importer (in Jira Cloud, Settings > System > External system import > CSV) with privileged-access-jira.csv. On the second step, set Date format in import file to yyyy-MM-dd.
  2. Map the columns: Work item ID to Work item ID, Work type to Work type, Parent to Parent, Summary, Description and every Labels column to their fields, Start date to the Start date field, Due date to Due date, and every Blocks column to the Blocks link type. Each phase becomes an Epic with a Task under it for each task, gate and decision; each Blocks column makes that row’s item block the item it names, which carries the plan’s dependencies.
  3. Assign people in Jira: each item carries its owner role as an owner-… label, and critical-path items carry critical-path. Jira links don’t hold lag or start-to-start timing; each description keeps them.

Test the import on a scratch project with a few rows first: the importer doesn’t remove duplicate links and Jira has no bulk delete for them. If the Blocks links don’t come through on your site, import the items first and add the links from the plan’s dependency list in a second pass, as Atlassian recommends. The dates count from the plan’s placeholder start.

TipOpening this plan in Project or Planner
  • Microsoft Project desktop opens the XML file directly, with every dependency, milestone and owner.
  • Microsoft Planner has no file import of its own: it doesn’t read XML, CSV or Excel. To bring this plan into a Planner premium plan, open the XML file in Project desktop, save it as an .mpp file, and import that through the Project Power App. Tasks, durations, dependencies and milestones come across; resources and baselines don’t, so assign owners again in Planner.
  • Without Project desktop, the CSV can feed a Power Automate flow that creates the tasks one by one, but dependencies in a premium plan need Microsoft’s Project schedule APIs, so that’s a build, not an import.
  • In a government cloud tenant, check that premium plans are available before relying on Planner for this schedule: Microsoft notes that converting a basic plan to a premium plan isn’t available in GCC.

Project for the web was retired on August 1, 2025, and Project Online on September 30, 2026; Planner is their successor. Project desktop is unaffected.

Back to top