CyberArk PAM Self-Hosted to Privilege Cloud (Idira PAM SaaS)
Cohash moves CyberArk PAM Self-Hosted vaults to the SaaS product Palo Alto Networks now sells as Idira Privileged Access Management, formerly Privilege Cloud. We inventory safes, platforms, custom CPM plugins, connection components and integrations, rebuild CPM and PSM as connector servers, rehearse the vault transfer and re-point every integration before cut-over.
- 01Customization and integration inventory
- 02Tenant, identity and network
- 03Connector servers
- 04Pilot transfer
- 05Waves and integration re-pointing
- 06Decommission
The story
Told without the client's name or anything that could identify them.
An insurer's PAM team ran CyberArk PAM Self-Hosted 14.0, and patching the vault, DR vault and PVWA was taking more of their week than onboarding accounts. With 14.0 support ending in January 2027, the next step was either another upgrade to 15.2 or a move to Idira PAM SaaS, and they chose SaaS. We started with an inventory of safes, platforms, custom plugins and every system calling the vault, mining vault logs for callers nobody had listed, and got firewall requests moving early. After a timed pilot, vault data moved in waves, CPM and PSM became connector servers, and the self-hosted vault was retired once every integration passed.
why it was urgentPalo Alto Networks closed its CyberArk acquisition on 11 February 2026 and launched Idira in May, with a four-phase self-hosted to SaaS migration program. Self-hosted 14.0 LTS reaches default end of support in January 2027 and 15.0 in December 2027, so the next upgrade forces a choice between 15.2 and SaaS.
- openPAM Self-Hosted 14.0 is what you run, and the January 2027 support date is on someone's risk register.
- recurringVault, DR vault and PVWA patching take more of the PAM team's time than onboarding accounts.
- blockedYour account team keeps steering renewal conversations toward Idira SaaS.
- openNobody has a full list of the Credential Provider applications and scripts hitting the vault.
The estate, before and after
Before: a self-hosted vault with consumers nobody had listed
Admins used PVWA, and applications and scripts fetched credentials from the vault directly, some of them unlisted. The PAM team patched the vault, DR vault, PVWA, CPM and PSM servers themselves.
Read the diagram as text
- PAM admins → PVWA: sign in
- Credential Provider apps → Vault and DR vault: credential fetch
- SIEM and ITSM → PVWA: ticket validation
- CPM → Windows servers: rotate
- CPM → Databases: rotate
- PSM → Windows servers: sessions
- PSM → Linux and Unix: sessions
After: Idira PAM SaaS with connector servers on-premises
The vault now runs as an Idira PAM tenant, with sign-in federated from Entra ID or Okta. Connector servers in each network segment run CPM and PSM and connect outbound to the tenant, so rotation and sessions still reach internal targets.
Read the diagram as text
- Entra ID or Okta → Idira PAM tenant: federated sign-in
- Credential Provider apps → Idira PAM tenant: credential fetch
- SIEM and ITSM → Idira PAM tenant: ticket validation
- Idira PAM tenant → Audit and recordings: recordings
- Connector servers → Idira PAM tenant: outbound registration
- Connector servers → Windows servers: rotate · sessions
- Connector servers → Linux and Unix: sessions
- Connector servers → Databases: rotate
How we run it, phase by phase.
6 phases take you from CyberArk PAM Self-Hosted (Vault, PVWA, CPM, PSM) to Idira PAM (formerly Privilege Cloud). Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Customization and integration inventory
List safes, platforms, custom CPM plugins, PSM connection components, PVWA extensions and every system that calls the vault, from SIEM and ITSM to Credential Provider applications. Each item gets a decision: move as-is, rebuild, or retire.
- phase 02
Tenant, identity and network
Provision the tenant, federate sign-in from Entra ID or Okta with MFA, and get firewall approvals for outbound connectivity from connector servers. Network changes are usually the slowest item, so they start first.
- phase 03
Connector servers
Build connector servers in each network segment and install CPM, PSM and the connector components. Test reach to Windows, Linux and database targets before any vault data moves.
- phase 04
Pilot transfer
Move a pilot set of safes with real platforms, verify rotation and PSM sessions per platform type, and time the full sequence of freeze, transfer, registration and checks.
- phase 05
Waves and integration re-pointing
Transfer the remaining vault data through DR vault replication, re-register CPM and PSM, and re-point integrations, with Credential Provider applications tested first because a failed fetch is an outage.
- phase 06
Decommission
Keep the self-hosted vault read-only and its CPM paused until every integration passes. Retire servers only after the audit team confirms they can pull the history they need.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
No vault, DR vault or PVWA servers to patch
The vault runs as Idira PAM SaaS. CPM and PSM became connector servers that register to the tenant, so rotation and sessions still reach on-premises targets.
- result 02
Admins sign in through Entra ID or Okta with MFA
We federated tenant sign-in from the existing identity provider. Nobody maintains MFA and access rules on a self-hosted PVWA any more.
- result 03
Every vault consumer was found and re-pointed
The inventory and vault logs gave us the list of Credential Provider applications, scripts, SIEM and ITSM integrations. We re-pointed each one to the tenant and signed it off one system at a time, starting with Credential Provider apps.
- result 04
Only one system rotates each password
We paused the self-hosted CPM and checked it at every wave. It stayed installed, but it never rotated an account the tenant was also rotating.
- result 05
Audit history survived the move
Session recordings and audit records have a confirmed retention plan and region. We didn't retire the old vault until the audit team confirmed they could pull the history they need.
Risks we plan for
-
Custom plugins that don't carry over
Most of the cost sits in custom CPM plugins and PSM connection components. If the SaaS tenant doesn't support one, it needs a rebuild or a retirement decision before anyone sets a schedule.
-
Two systems rotating one account
A self-hosted CPM left running after transfer can rotate the same password the tenant does, and services get locked out. We pause the old CPM, keep it installed, and check it at every wave.
-
Hidden vault consumers
Scripts and applications that call the old PVWA API or Credential Provider break silently at cut-over. Logs from the self-hosted vault are mined to find callers nobody listed.
-
Audit history gaps
Somebody has to confirm where session recordings and audit records will live, and for how long, before the old vault is switched off.
Where AI helps, and where it needs guardrails
Palo Alto Networks built the Idira launch around zero standing privilege, just-in-time access and controls for machine identities and AI agents, and those features ship SaaS-first. We keep agents out of the cut-over itself. Once it's done, agent credentials get their own safes with owners and short rotation. Any assistant that reads vault data goes through a read-only MCP tool with a scoped token. It never gets a shared PVWA admin account.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Inventory of safes, platforms, plugins, connection components and vault consumers, with a decision on each
yours to keep - design02
Connector server design per network segment, with firewall requests
yours to keep - report03
Pilot report with rotation and session results per platform type
yours to keep - runbook04
Cut-over runbook with go or no-go tests and a rollback path
yours to keep - document05
Integration re-pointing checklist signed off per system
yours to keep - plan06
Retention plan for audit records and session recordings
yours to keep
Platforms and services on this move
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Connector
- The integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Is Privilege Cloud the same product as Idira PAM?
In practice, yes. Palo Alto Networks' migration page now calls the SaaS offering Idira Privileged Access Management, part of the Idira Identity Security Platform. Older CyberArk community articles still say Privilege Cloud. Look at the product name on your quote so the licenses and features line up.
02Do CPM and PSM still run in our network after the move?
Yes. They become connector servers that register to the tenant, so rotation and sessions still reach on-premises targets. You stop running the vault, DR vault and PVWA, not every server.
03How long does the migration take?
It depends on vault size, the number of custom plugins and connection components, how many network sites need connector servers and how many integrations call the vault. The data transfer is usually the short part. Integration testing and firewall approvals take longer.
04Should we upgrade to 15.2 first?
Only if the migration can't finish before your current version's support ends. Upgrading to 15.2 and then migrating a year later means paying for two projects, so we compare dates before recommending either.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case studye0b4de40 - 01Palo Alto Networks: Completes acquisition of CyberArk (11 Feb 2026)paloaltonetworks.com ↗
- 02Palo Alto Networks press release: Introducing Idira (12 May 2026)paloaltonetworks.com ↗
- 03Palo Alto Networks: Idira PAM SaaS migration (four phases)paloaltonetworks.com ↗
- 04Idira Docs: End-of-life policy for self-hosted productsdocs.cyberark.com ↗
- 05CyberArk Community: Preparing for your Privilege Cloud migration Jump Startcommunity.cyberark.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it