Migrating a privileged access management vault means moving the credentials to the most sensitive accounts in the organisation, and the systems that rotate and broker them, from one platform to another without a period in which those credentials are exposed, unmanaged or managed by two systems that fight each other. Organisations change PAM platforms when a product reaches end of life, when they move from self-hosted to a hosted service, after a merger, or when the old vault cannot handle cloud, DevOps or machine credentials. A PAM migration is not an export and import: the safest migrations rotate every credential as it moves, so the export file and the old vault stop being worth stealing. This playbook covers what moves, the copy versus re-rotate decision, rotation ownership, sessions and recordings, the identities the vault itself depends on, and decommissioning the old vault. It is vendor-neutral and based on NIST SP 800-53, the NCSC secure system administration principles and the OWASP Secrets Management Cheat Sheet. A first-time rollout is covered in the Privileged access management (PAM) vault rollout playbook, and protecting the platform in Securing the PAM Vault Itself.
Key takeaways
- Rotate on the way in. Onboard each account to the new vault by setting a new credential, so anything exported from the old vault is already stale.
- One rotation owner per account. Two vaults rotating the same account produce lockouts and an unknown current password; switch rotation off in the source as each account moves.
- Dependencies decide the order. Service account passwords are used by services, tasks and application pools; move rotation only when every dependency is known and updated by the new platform.
- Keep the old evidence. Session recordings, approval history and audit logs from the old vault are audit and incident evidence; archive them before shutdown.
- The export is the crown jewels. Any bulk export, the migration account and the old vault's master keys need the strongest controls in the project and a destruction date.
What a PAM vault migration actually moves
| Object | Migration approach | Watch for |
|---|---|---|
| Managed privileged accounts (domain, local, database, network, cloud) | Onboard to the target and rotate on onboarding | Accounts that cannot be rotated (vendor-managed, embedded, change-frozen) |
| Service account passwords and their dependencies | Rebuild the dependency list; move rotation only with dependency updates | Services, scheduled tasks and app pools missed by discovery |
| SSH keys and certificates | Issue new keys or move to short-lived certificates; remove old public keys from authorized_keys | Old public keys left authorised on hundreds of hosts |
| Application and DevOps secrets brokered by the vault | Re-point applications to the target's retrieval interface with new application identities | Hard-coded vault addresses, static API keys used to fetch secrets |
| Safes, folders and access policies | Translate by intent and review membership | Broad groups added years ago and never reviewed |
| Approval workflows and just-in-time rules | Recreate and test with real requesters | Workflows silently missing, giving standing access by default |
| Session management (proxies, recording policies) | Recreate connection components and recording rules; test protocols | Targets reachable directly while the new proxy is configured |
| Session recordings, audit logs, approval history | Archive in a readable format with a retention date | Recordings only playable in the old product |
| Integrations (directory, SIEM, ticketing, MFA, discovery) | New integration credentials on the target; revoke source ones | Integration API keys left valid on a retired platform |
| Break-glass accounts and emergency procedures | Re-establish outside both vaults and test | Break-glass credentials stored only in the vault being retired |
Copy or re-rotate: choosing the transfer method
| Method | How it works | Choose it when | Trade-off |
|---|---|---|---|
| Rotate on onboarding | Target vault is given the account and sets a new credential at onboarding | The target can reach and change the account, and dependencies are known | Safest; requires connectivity and dependency mapping before each wave |
| Copy, then rotate | Current credential is transferred, verified, then rotated by the target within a short, fixed window | Accounts with many dependencies that need a verification step first | Export exists briefly; rotation must not slip |
| Copy only | Credential transferred and left unchanged | Accounts that genuinely cannot be rotated | Old vault and export remain worth stealing; needs compensating controls and an exception record |
| Replace the pattern | Retire the standing credential in favour of just-in-time elevation, short-lived certificates or workload identity | The account exists only to hold standing privilege | More design work; removes the credential instead of moving it |
The OWASP Secrets Management Cheat Sheet recommends storing metadata for each secret (type, purpose, owner, intended consumers, contact point and rotation history) and warns that missing metadata increases lock-in. That metadata is what makes rotate-on-onboarding possible; where it is missing, collect it as part of the wave rather than copying the secret blind. The cheat sheet also recommends multi-step rotation (create, set, test, finish), which is the right pattern for the first rotation by the new vault. Replacing standing accounts is covered in the JIT Access Guide.
If a bulk export is unavoidable
- Encrypt and limit it: export in the smallest batches possible, encrypted to a key held only by the target import process, never as plaintext files or spreadsheets.
- Use two people (our recommendation): one to run the export and one to witness and verify destruction of every intermediate copy.
- Rotate everything exported: set a fixed window (our recommendation: within 7 days of import) by which every exported credential has been rotated by the target.
Rotation ownership and dependencies
- Discover dependencies: for each service account, list every service, scheduled task, application pool, configuration file and remote system that uses its password. The Service Account Inventory Template gives a structure.
- Disable source rotation: turn off automatic rotation and verification in the old vault for that account before the target takes over, so only one system ever changes it.
- Hand over: the target rotates the password and updates every dependency in the same operation, then verifies the account logs on.
- Prove ownership: run a second rotation from the target a few days later. If anything breaks, a dependency was missed.
- Mark the source record: set the account to read-only or delete it in the old vault so administrators stop using it.
The manual equivalent is described in Rotating a Windows or Linux Service Account Password.
Sessions, recordings and evidence
- Keep the path closed during cutover: if targets are normally reachable only through the PAM proxy, do not open direct access while the new proxy is configured. Move targets between proxies in waves with firewall rules updated per wave.
- Recreate recording policy: confirm which protocols and targets are recorded on the target and that recordings are stored, indexed and protected from deletion (NIST SP 800-53 AU-9).
- Archive old recordings: export them in a format that can still be played after the old product is gone, with the retention period your policy or regulator requires. See the Privileged Session Management Guide.
- Keep approval history: who requested, who approved, when and why. Auditors will ask for the period before the migration too.
The NCSC secure system administration principles ask organisations to use privileged access management to control who can administer, where, when, why and how, and to log and audit all administration activity. A migration that leaves a gap in either, even for a week, is a gap an assessor will find.
Where identity fits
The vault is the system that manages privileged identities, but it also runs on identities of its own, and the migration adds more.
- Migration account: read access to every secret in the source and write access in the target. Create it for the project, restrict it to the migration host, require MFA where interactive, alert on any use outside migration windows and delete it at the end.
- Rotation and discovery accounts: the target needs its own domain, database and cloud accounts to change passwords and discover accounts. Create new ones rather than reusing the source vault's, then disable the source's.
- Application identities: applications that fetch secrets need new identities on the target. The OWASP cheat sheet recommends platform identities (such as Kubernetes service accounts or cloud IAM roles) over static bootstrap credentials. See the Privileged access management (PAM) vault integration security guide.
- Vault administrators: separate platform administrators from safe owners and auditors (NIST SP 800-53 AC-5), and administer only from privileged access workstations; see the Privileged Access Workstations Guide.
- Break-glass: the OWASP cheat sheet advises backing up break-glass credentials in a secondary system and testing them routinely, and storing the secrets solution's own root credentials in a separate secondary solution. Re-establish this for the target before cutover. See the Break-Glass Account Guide.
The phased playbook
- Inventory: accounts by platform and type, rotation status, dependencies, safes and their members, workflows, session policies, integrations and every credential the old vault itself uses.
- Clean up first: remove orphaned and unused accounts, and review safe membership (NIST SP 800-53 AC-6(7), review of user privileges). Do not migrate debt.
- Build and harden the target: admin roles, MFA, break-glass, backup and restore, logging to the SIEM, and network restrictions, before any credential is loaded.
- Pilot: move one platform type (for example a group of Linux servers) end to end: onboarding with rotation, a session through the new proxy with recording, an approval workflow, a restore from backup and a rollback.
- Migrate in waves: lowest-risk platforms first; domain administrators, cloud root and tier-zero accounts last, with extra review. Disable source rotation per account as the target takes over.
- Move applications and integrations: re-point secret retrieval and integrations with new identities, then revoke the source ones.
- Freeze the source: read-only mode, no new accounts, no check-outs except under emergency procedure, alerts on any use.
- Decommission: archive logs, recordings and approval history; destroy exports; revoke every credential the old vault held for itself; destroy its master keys and sanitise storage following NIST SP 800-88 Rev. 2.
Rollback: per account, rollback means re-enabling rotation in the source after setting the account to a known credential from the target, never letting both systems rotate. Keep the source able to manage accounts until the final wave is signed off. After source keys are destroyed there is no rollback, so that is the last step.
Small and large organisations: a small estate with a few hundred accounts can often onboard everything with rotation in a few weeks. Large estates with thousands of service accounts and application integrations should expect dependency discovery to take longer than the technical migration, and should run both vaults side by side for months with strict per-account ownership.
Detection and measurement
| Metric or signal | Why it matters | Target (our recommendation) |
|---|---|---|
| Share of migrated accounts rotated by the target since onboarding | Proves exported or copied credentials are stale | 100%, except recorded exceptions |
| Accounts with rotation enabled in both vaults | Rotation conflicts and lockouts | Zero |
| Rotation and verification failures on the target | Missed dependencies or connectivity | Investigated within one day |
| Check-outs or logons through the old vault after freeze | Administrators or apps still using the source | Zero outside emergency procedure |
| Migration account use outside approved windows | Misuse of an all-secrets credential | Zero; alert on any |
| Privileged logons to targets not brokered by either vault | Direct access opened during cutover | Zero unexplained |
The OWASP cheat sheet lists what to log for a secrets system: who requested which secret and for what system, approvals and rejections, use, expiry, attempts to reuse expired secrets, authentication and authorisation errors, updates and administrative actions. Send both vaults' logs to the same place during the migration and protect them from tampering.
Common failure patterns
- Copy without rotation: the export file, the old vault and its backups all still hold valid privileged credentials after the move.
- Dual rotation: both vaults rotate a service account, the services hold a third password, and production fails at the next restart.
- Integration keys left alive: API keys the old platform used, or that others used to reach it, stay valid. The BeyondTrust breach showed how a single stolen API key for a privileged remote access service could lead to a major incident; retired platforms' keys deserve the same urgency.
- Break-glass stored in the old vault: the emergency credentials disappear with the platform they were meant to back up.
- Recordings lost: session recordings that only the old product can play are deleted with it, leaving no evidence for an investigation into the pre-migration period.
- Direct access during cutover: firewall rules opened "temporarily" so administrators can work while the new proxy is built, and never closed.
Framework mapping
| Activity | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | MITRE ATT&CK |
|---|---|---|---|
| Privileged account inventory and clean-up | AC-2, AC-6(5), AC-6(7) | PR.AA-05 | T1078 |
| Rotation on onboarding | IA-5, IA-5(1) | PR.AA-01 | T1555 |
| Separation of vault roles | AC-5 | PR.AA-05 | |
| Session brokering and recording | AC-17, AU-9 | PR.IR-01 | |
| Migration change control | CM-3 | PR.PS-01 | |
| Log, recording and history retention | AU-2, AU-11 | DE.CM-09 | |
| Backup of the target vault | CP-9 | PR.DS-11 |
T1555 (Credentials from Password Stores) is the technique that makes a vault and its export a prime target; T1078 (Valid Accounts) is what an attacker does with any credential the migration fails to rotate.
Practitioner checklist
- Clean up orphaned accounts and review safe membership before migrating anything.
- Rotate every credential on onboarding to the target, or record a time-boxed exception.
- Map service account dependencies before moving rotation, and run a second proving rotation.
- Never let two vaults rotate the same account.
- Encrypt, minimise, witness and destroy any bulk export.
- Create new rotation, discovery, integration and application identities on the target; revoke the source ones.
- Re-establish and test break-glass outside both vaults before cutover.
- Archive recordings, approval history and audit logs in a format readable without the old product.
- Keep targets reachable only through a broker during cutover.
- Destroy the old vault's master keys and sanitise storage as the final step.
Standards and references
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- NCSC: Secure system administration
- OWASP: Secrets Management Cheat Sheet
- NIST: SP 800-88 Rev. 2, Guidelines for Media Sanitization
- MITRE ATT&CK: Credentials from Password Stores
- MITRE ATT&CK: Valid Accounts
Related NHI Mgmt Group resources: Privileged access management (PAM) vault day-2 operations runbook · Privileged access management (PAM) vault health check · Microsoft Identity Manager and MIM PAM · Secrets manager migration playbook · Password manager (enterprise) migration playbook