Most privileged access management programmes have a vault and a discovery report, but no agreed plan that says which accounts go in first, who signs them off and what "done" means for each wave. This template gives [Organisation] a fillable onboarding plan: the wave structure, the order accounts are vaulted within each wave, the owner sign-off record, the change and rollback steps for rotation, and the exit criteria that close a wave. It assumes discovery has already run. What counts as privileged, where to look and how to triage results are covered in the Privileged Account Discovery and Onboarding Guide; this page turns that into a plan a PAM lead can put in front of a steering group. It is written for PAM leads, IAM engineers, platform owners and change managers. Replace every [bracketed] placeholder and delete the guidance notes in italics before issue.
How to use this template
- Start from the discovery output: section 3 needs a reconciled inventory, one row per privileged account with a proposed owner and a tier. If you do not have one, run discovery first.
- Fill sections 1 to 4 before the steering group: scope, roles, the inventory baseline and the wave plan are what the group approves. Sections 5 to 9 are run during delivery.
- One wave at a time: do not open wave 2 until wave 1 meets its exit criteria in section 8. Overlapping waves is how service account rotation outages happen.
- Keep the sign-off record live: the account-level owner sign-off in section 6 is the evidence auditors ask for. Store it with the plan, not in individual tickets.
- Owner and review: [PAM Lead], reviewed at every wave close and at least every [90] days, and re-baselined when a merger, new cloud tenant or new platform adds accounts.
1. Purpose and scope
1.1 This plan sets the order, ownership and acceptance criteria for bringing [Organisation]'s privileged accounts under management in [PAM platform]. "Under management" means, for each account: credential held in the vault or replaced by a managed alternative, rotation enabled at the agreed interval, access through check-out or just-in-time elevation, and sessions logged where the tier requires it.
1.2 In scope: [Active Directory forests and domains], [Microsoft Entra ID tenant(s)], [AWS organisation], [Azure subscriptions], [Google Cloud organisation], [Linux and Unix estate], [network devices], [databases], [SaaS platforms with admin roles], [CI/CD and automation], and privileged non-human identities (service accounts, access keys, API tokens) across all of these.
1.3 Out of scope for this plan: [standard user accounts], [customer identities], [list any platform deferred to a later plan, with the reason and target date].
1.4 Programme dates: start [date], wave 1 target close [date], full plan target close [date].
2. Roles and sign-off authority
| Role | Named person and deputy | Responsibilities in this plan |
|---|---|---|
| Sponsor | [CISO] | Approves the plan and the wave order; resolves owner disputes; accepts residual risk for deferred accounts |
| PAM Lead | [Name] | Owns this document; runs waves; reports metrics in section 9 |
| PAM Engineer(s) | [Names] | Onboards accounts, configures rotation and connectors, runs rollback |
| Account Owner | [Per account, section 3] | Confirms the account is needed, its consumers and its rotation window; signs off each step in section 6 |
| Platform Owner | [AD, cloud, Linux, database, network, SaaS owners] | Grants the PAM platform the rights it needs on the target; approves changes on that platform |
| Change Manager | [Name] | Schedules rotation changes; holds the rollback record |
| SOC Lead | [Name] | Confirms alerts and session logs from onboarded accounts reach the SIEM |
2.1 Nobody signs off their own account: where the PAM Engineer is also the Account Owner, the Platform Owner signs instead.
2.2 Unclaimed accounts: an account with no owner after [10] working days is escalated to the Sponsor, who either assigns an owner or approves disabling it, with a documented re-enable route.
3. Inventory baseline
3.1 The baseline is a frozen export of the reconciled discovery inventory taken on [date], held at [location]. New accounts found after the freeze go to a "late discovery" list and are assigned to the next open wave.
3.2 Each row carries these fields:
| Field | Example value | Why it matters for onboarding |
|---|---|---|
| Account ID and platform | [svc-backup01, CORP domain] | Unique key used in every later section |
| Class | [Tier 0 directory, cloud control plane, local admin, service account, SaaS admin, emergency] | Decides the wave (section 4) |
| Human or non-human | [Non-human] | Non-human accounts need consumer mapping before rotation |
| Proposed owner | [Name, team] | Who signs section 6 |
| Last used | [Date from logs or credential report] | Unused accounts go to clean-up, not the vault |
| Consumers | [Services, scheduled tasks, scripts, applications, pipelines] | Every consumer must be updated or switched to vault retrieval before rotation |
| Target pattern | [Vault and rotate, JIT elevation, gMSA, workload identity, Windows LAPS, remove] | Not every account should be vaulted; some should be replaced |
| Rotation window | [Sunday 02:00 to 04:00] | Agreed with the owner, used for the change ticket |
| Wave and status | [Wave 1, Onboarded] | Drives the section 9 metrics |
3.3 Clean-up before onboarding. Accounts with no use in [90] days, duplicate admin accounts and standing members of groups that should be empty are removed or disabled before their wave starts, after owner confirmation. Removing an account is a bigger risk reduction than vaulting it, and it keeps the vault from inheriting the mess.
4. Wave plan
4.1 Waves are ordered by blast radius, not by platform. Microsoft's rapid modernisation plan for privileged access follows the same logic: it puts emergency access accounts, privileged role management and the identification of privileged accounts first, and asks for separate admin accounts with no shared use.
| Wave | Accounts | Target pattern | Entry condition | Target dates |
|---|---|---|---|---|
| 0. Foundations | PAM platform admins, vault recovery credentials, break-glass accounts | Vault admins on separate admin accounts with phishing-resistant MFA; break-glass held outside the vault with split custody | Plan approved | [dates] |
| 1. Tier 0 and control plane | Domain and Enterprise Admins, Entra Global Administrator and Privileged Role Administrator, IdP super admins, AWS root and admin IAM users, Azure Owner and User Access Administrator, Google Cloud organisation admins | Named admin accounts, just-in-time elevation, sessions brokered and recorded; root and built-in accounts vaulted with split custody | Wave 0 closed; privileged workstations available for Tier 0 admins | [dates] |
| 2. Credentials that unlock many systems | Hypervisor and vCenter, backup, EDR and MDM console, CI/CD admins; Windows and Linux local admin and root | Vault with rotation; Windows LAPS for local administrator passwords | Wave 1 closed | [dates] |
| 3. Privileged service accounts and NHIs | Service accounts in admin groups, access keys with admin rights, admin API tokens, automation accounts | Replace with gMSA or workload identity where possible; otherwise vault with consumer retrieval and staged rotation | Wave 2 closed; consumer mapping complete for each account | [dates] |
| 4. Application and SaaS admins | ERP, HR, finance, SaaS tenant admins, database admin logins | Vault or SSO-enforced named admin accounts; session logging where the application supports it | Wave 3 closed | [dates] |
| 5. Breadth and steady state | Network devices, remaining local accounts, late discovery list | As per class | Wave 4 closed | [dates] |
4.2 Wave size. A wave holds no more accounts than the team can onboard, test and support in [6] weeks. Split a class across sub-waves (for example 3a for Windows service accounts, 3b for cloud access keys) rather than enlarging a wave.
4.3 Emergency accounts are always wave 0 and are never placed behind a dependency on the vault they are meant to recover. See the Break Glass Access Procedure Template.
5. Vaulting order within a wave
Within each wave, onboard in this order. Each step is a gate: the next step does not start for an account until the previous one is signed off in section 6.
- Grant the PAM platform its rights: the Platform Owner creates the reconcile or connector account with the minimum rights needed to reset passwords on the target, and that account is itself vaulted first.
- Vault without rotation: store the current credential in [Safe or folder name, per wave and platform], with access limited to the owner group. Confirm check-out works and is logged.
- Switch human access to check-out or elevation: remove direct knowledge of the password. For named admin accounts, remove standing group membership and require just-in-time elevation. Microsoft's rapid modernisation plan sets a key result of 100% of applicable privileged roles using its Privileged Identity Management service, which is a usable target for any JIT tooling.
- Update consumers (non-human accounts only): change every service, task, script or pipeline listed in section 3 to retrieve the credential from the vault, or replace the account with a gMSA or workload identity. The Account Owner confirms the consumer list is complete.
- First managed rotation, under change: rotate once in the agreed window with the owner on call. Test every consumer. Keep the previous credential retrievable for the rollback period in section 7.
- Enable scheduled rotation: set the interval in section 5.1. For local administrator accounts on Windows, Windows LAPS rotates each device's password and backs it up to Microsoft Entra ID or Active Directory; hybrid-joined devices use one or the other, not both.
- Turn on session controls and alerts: session recording for Tier 0 and Tier 1 accounts, SIEM forwarding of check-out, rotation failure and direct-logon events.
- Remove fallbacks: delete copies of the credential in password managers, spreadsheets, scripts and runbooks. Run a secret scan for the old value where possible.
5.1 Rotation intervals:
| Class | Rotation interval | Rotate after check-out |
|---|---|---|
| Tier 0 shared and built-in accounts | [Every 24 hours] | [Yes] |
| Local administrator (Windows LAPS or vault) | [30 days] | [Yes, via post-authentication action or vault policy] |
| Interactive shared admin accounts | [7 days] | [Yes] |
| Service accounts with vault retrieval | [30 to 90 days] | [No] |
| Access keys and API tokens | [90 days or replace with short-lived credentials] | [No] |
6. Owner sign-off record
6.1 One row per account. The owner initials and dates each column; the PAM Engineer cannot tick a column for an account they own.
| Account ID | Need confirmed | Consumers confirmed | Vaulted | Access switched | First rotation passed | Scheduled rotation on | Fallbacks removed | Owner |
|---|---|---|---|---|---|---|---|---|
| [svc-backup01] | [date, initials] | [date] | [date] | [date] | [date, change ref] | [date] | [date] | [Name] |
| [aws-mgmt-root] | [date] | [n/a for human account] | [date] | [date] | [date] | [date] | [date] | [Name] |
6.2 Exceptions. An account that cannot reach "scheduled rotation on" (for example an embedded credential in a vendor appliance) is recorded in the exception register with the compensating control, the risk owner's acceptance and an expiry date no later than [12] months. Microsoft's guidance for legacy authentication exceptions uses the same pattern: review every 90 days and fix within one year of approval.
7. Change, testing and rollback
- Pilot first: each new platform connector is tested on [3] non-production accounts before any production account in the wave.
- Change ticket per batch: first rotations run under a standard change listing the accounts, the window, the consumers to test and the rollback owner.
- Rollback: if a consumer fails, restore the previous credential version from the vault within [30] minutes, record the failure, and return the account to step 4 of section 5. Do not disable rotation for the whole wave because one account failed.
- Rollback period: previous credential versions are retained for [14] days after first rotation.
- Freeze periods: no first rotations during [year-end, peak trading, major releases].
8. Wave exit criteria
A wave closes when the Sponsor signs that all of the following hold:
- Every account in the wave is either fully signed off in section 6, removed, or in the exception register with an expiry date.
- No rotation failure is open for more than [5] working days.
- Check-out, rotation and session events from the wave's platforms are visible in the SIEM and the SOC Lead has confirmed at least one test alert.
- A re-run of discovery on the wave's platforms finds no new unmanaged accounts of the wave's classes, or they are on the late discovery list.
- Lessons from the wave are recorded and the next wave's plan updated.
9. Reporting and metrics
| Metric | Definition | Target |
|---|---|---|
| Coverage by wave | Accounts fully signed off divided by accounts in the wave baseline (after clean-up) | [100% at wave close, excluding approved exceptions] |
| Tier 0 coverage | Wave 1 accounts under management divided by all Tier 0 and control plane accounts found | [100%] |
| Accounts removed | Accounts disabled or deleted at clean-up | [Reported, no target] |
| Rotation success rate | Successful scheduled rotations divided by attempted, per week | [Above 98%] |
| Unowned accounts | Accounts with no signed owner after the escalation deadline | [0] |
| Open exceptions | Exception register entries, and how many are past expiry | [0 past expiry] |
9.1 The PAM Lead reports these to the Sponsor every [2] weeks during a wave and monthly in steady state.
Implementation guidance
Why waves by blast radius. Attackers use valid privileged accounts to move and persist (ATT&CK T1078.002 Domain Accounts, T1078.003 Local Accounts, T1078.004 Cloud Accounts), and a shared local administrator password across many machines is what makes pass the hash (T1550.002) cheap. Waves 1 and 2 target exactly those accounts, so they cut most risk soonest. Platform-by-platform onboarding looks tidy on a Gantt chart but often leaves domain admins and cloud root until late.
Small versus large organisations. A team with a few hundred privileged accounts can merge waves 0 and 1, and waves 4 and 5, and run the whole plan in two or three quarters. A large estate should split wave 3 by platform and assign a named engineer per sub-wave, because consumer mapping for service accounts is the slowest work in the plan. Where the vault licence or connector does not reach a platform, record the platform as deferred in 1.3 rather than leaving it silently off the baseline.
Common failure patterns.
- Rotating before mapping consumers: one hard-coded service account password breaks overnight batch jobs and the business asks for rotation to be turned off everywhere. Step 4 of section 5 exists to stop this.
- Vaulting without rotating: the password is in the vault but everyone still knows it, so coverage looks good and risk is unchanged. Count an account only when "scheduled rotation on" and "fallbacks removed" are signed.
- No owner, no wave close: accounts without owners sit in "in progress" for months. Enforce the 2.2 escalation.
- Exceptions without expiry: the exception register becomes the permanent home for difficult accounts. Every entry needs a date and a risk owner.
- Vault admins as the weak point: onboarding everyone else while vault administrators sign in from ordinary laptops with standing rights. Wave 0 fixes this first.
Framework mapping. NIST SP 800-53 Rev. 5 AC-2 Account Management, AC-6 Least Privilege, AC-6(5) Privileged Accounts, IA-5 Authenticator Management and IA-2(1) Multi-factor Authentication to Privileged Accounts; NIST CSF 2.0 PR.AA-01 and PR.AA-05; ISO/IEC 27001:2022 Annex A 8.2 Privileged access rights; CIS Controls v8.1 Safeguard 5.1 (inventory of accounts) and Safeguard 5.4 (administrator privileges restricted to dedicated administrator accounts). After the plan closes, use the Privileged access management (PAM) vault health check to confirm coverage holds.
References. Microsoft: Privileged access security rapid modernization plan · Microsoft: Windows LAPS overview · NIST: SP 800-53 Rev. 5 · NIST: Cybersecurity Framework 2.0 · CIS: Critical Security Controls v8.1 · MITRE ATT&CK: T1078 Valid Accounts
Related NHI Mgmt Group resources: Privileged Account Discovery and Onboarding Guide · Privileged access management (PAM) vault health check · Credential Vaulting vs Just-in-Time Elevation · Local Administrator Password Solution (LAPS) Guide · Privileged Access Management Guide