CyberArk PAM Self-Hosted version upgrades
Cohash upgrades CyberArk PAM Self-Hosted to current releases, usually 15.2, the Long-Term Support release supported to July 2029. We test the DR vault first, upgrade Vault, PVWA, CPM, PSM and PSMP in the documented order, retest rotation for every platform type and every connection component, and check each REST API integration. The upgrade is rehearsed in a test environment before production.
- 01Component and version inventory
- 02DR and backup proof
- 03Rehearsal
- 04Connection components and platforms
- 05Production upgrade and checks
The story
Told without the client's name or anything that could identify them.
An enterprise security team ran CyberArk PAM Self-Hosted 14.0, with the January 2027 end-of-support date on the risk register and no project behind it. The DR vault hadn't been failed over since the previous upgrade, and custom connection components sat on PSM servers with nobody sure of their versions. We inventoried every component and proved DR failover and a backup restore before touching production. After a logged rehearsal in a test environment, the team upgraded to 15.2 LTS in CyberArk's documented order, retested rotation, sessions and REST integrations, and moved its automation off stored passwords.
why it was urgentTwo CyberArk dates drive most of these projects. Under its end-of-life policy, 14.0 LTS reaches default end of support in January 2027, and 15.0, a Standard-Term release, follows in December 2027. The current LTS is 15.2. It gets development and support to July 2029, and paid extended support runs to July 2031.
- openThe vault runs 14.0 or older and the January 2027 date has no project behind it.
- recurringThe DR vault hasn't been failed over since the last upgrade.
- blockedCustom connection components were copied onto PSM servers years ago and nobody knows their versions.
- openScripts call the REST API with a stored user password because that was the only option when they were written.
The estate, before and after
Before: PAM Self-Hosted 14.0 with an untested DR vault
Admins and scripts reached the vault through PVWA, the scripts using stored user passwords. CPM rotated credentials and PSM brokered sessions through connection components whose versions nobody knew. The DR vault hadn't been failed over since the last upgrade.
Read the diagram as text
- PAM admins → PVWA: sign in
- Automation scripts → PVWA: stored password
- PAM admins → PSM: connect
- Vault 14.0 LTS → DR vault: replication
- CPM → Windows and Linux servers: rotate
- CPM → Databases: rotate
- PSM → Windows and Linux servers: sessions
After: PAM Self-Hosted 15.2 LTS with OAuth2 automation
Everything, the vault included, runs 15.2 LTS, and we've failed the DR vault over and back. Automation and AI agents reach the REST API through scoped OAuth2 clients. PSM's connection components come from the Marketplace.
Read the diagram as text
- PAM admins → PVWA: sign in
- Automation and AI agents → PVWA: OAuth2 token
- PAM admins → PSM and PSMP: connect
- Vault 15.2 LTS → DR vault: replication
- CPM → Windows and Linux servers: rotate
- CPM → Databases: rotate
- PSM and PSMP → Windows and Linux servers: sessions
- CPM → Retest matrix: test results
How we run it, phase by phase.
5 phases take you from PAM Self-Hosted 13.x, 14.0 or 15.0 to PAM Self-Hosted 15.2 LTS. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Component and version inventory
Write down the versions of Vault, DR vault, PVWA, CPM, PSM, PSMP, PTA and the HTML5 gateway. Add custom plugins and connection components. Then read the upgrade considerations and release notes for every version between yours and 15.2.
- phase 02
DR and backup proof
Fail over to the DR vault and back, and restore a backup to a test vault. A rollback plan that depends on an untested DR vault isn't a plan.
- phase 03
Rehearsal
We build a test environment from production configuration and upgrade it in the documented order. DR vault and primary vault go first, then PVWA, CPM and PSM. Every manual step gets logged with how long it took.
- phase 04
Connection components and platforms
15.0 moved several connection components out of the PSM package and onto the Marketplace and changed the database credentials framework for some platforms. Each affected component and platform is reinstalled or reconfigured and retested.
- phase 05
Production upgrade and checks
Follow the order you rehearsed, within the agreed window. Then verify. Rotate a sample of accounts on each platform, open a session through every connection component, and run every REST API integration.
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
The vault runs 15.2 LTS, supported to July 2029
We upgraded Vault, DR vault, PVWA, CPM, PSM and PSMP in the documented order. The team isn't sitting on a release that runs out of support in a few months any more.
- result 02
DR failover is a tested procedure
We failed over to the DR vault and back, and restored a backup to a test vault, all before the upgrade began. So the rollback plan rests on things the team has actually seen work.
- result 03
Connection components were reinstalled and retested
15.0 dropped some components from the PSM package. We installed them from the Marketplace and launched a session through every one. What passed is in the retest matrix, by platform and component.
- result 04
Automation calls the REST API with OAuth2 clients
We moved the scripts off stored user passwords and onto OAuth2 clients, with narrow scopes and their own audit trail. AI agents reading vault data follow the same model, through read-only tools.
- result 05
The next upgrade starts from a runbook
The rehearsal log has every manual step and how long it took, and the production runbook spells out the rollback criteria. The next version change won't depend on anyone's memory.
Risks we plan for
-
Skipping intermediate steps
Some version jumps need intermediate releases or prerequisites. The path is taken from CyberArk's upgrade documentation for your exact build, not assumed.
-
Connection components that disappear
15.0 took some components out of the PSM package. If nobody installs them from the Marketplace, they just stop, and an admin finds out the moment they click Connect.
-
Landing on a short-lived release
15.0 is Standard-Term, with development ending in December 2026. Teams that stop there face another upgrade within a year.
-
Extended support as a crutch
Extended support is paid, and the development period stays the same. It buys time. It doesn't buy fixes beyond the policy.
Where AI helps, and where it needs guardrails
A secondary source reproducing CyberArk's notice says 15.0 added OAuth2 authentication for the REST APIs. We use the upgrade to get automation off stored user passwords, along with any AI agent that reads or requests vault data, and onto OAuth2 clients with narrow scopes and an audit trail of their own. Agents never get vault admin rights. MCP tools that wrap the API stay read-only unless a person approves a change.
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
Component version inventory with the supported upgrade path
yours to keep - tests02
DR failover and backup restore test results
yours to keep - tests03
Rehearsal log with timings and manual steps
yours to keep - tests04
Connection component and platform retest matrix
yours to keep - runbook05
Production runbook with rollback criteria
yours to keep
Platforms and services on this move
Services involved
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
01Should we upgrade or move to SaaS?
It depends on hosting rules, the number of custom plugins and connection components, and how much vault upkeep costs your team today. We compare both. If SaaS is likely within a year, a second self-hosted upgrade may not be worth it.
02Can we go straight from 13.x to 15.2?
Sometimes you can. It depends on your exact build and components. Before we commit to a date we read CyberArk's upgrade documentation for every version in between and plan whatever intermediate steps it calls for.
03How long is the outage?
It depends on vault size, the number of component servers and whether DR replication is current. The rehearsal gives you a measured number, which is why it comes first.
04Do you support the platform after the upgrade?
We can. Vault operations, CPM troubleshooting and connection component changes can stay with us, or your team takes the runbooks.
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 studyNasdaq Calypso upgrade to V19
Upgrading Nasdaq Calypso to V19, with server consolidation, properties moved to the database, the WebUI and deployment changes tested on your own trades.
read the case study728d49b5 - 01Idira Docs: End-of-life policy for self-hosted productsdocs.cyberark.com ↗
- 0251sec (secondary): CyberArk PAM Self-Hosted v15 resources and release noticeblog.51sec.org ↗
- 03Palo Alto Networks: Completes acquisition of CyberArk (11 Feb 2026)paloaltonetworks.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