CyberArk vs JumpServer A direct comparison, no sales call required
Deployment effort, protocol coverage, three-year cost, and what a migration actually involves, including the cases where CyberArk is still the better choice.
What it takes to get to the first login
CyberArk PAM Self-Hosted is an enterprise platform assembled from separate server roles: PVWA for the web console, CPM for credential rotation, PSM and PSM for SSH for session brokering, the Digital Vault, Conjur for secrets, and a SQL Server instance behind them. Typical deployments run 6 to 12 weeks and usually involve a certified partner.2
That architecture is not waste. It is what lets CyberArk isolate the vault from the session tier and sell each capability separately. The cost shows up in operations: more hosts to patch, more versions to track, and a change board for every upgrade.
JumpServer ships as a single Docker Compose stack. One command brings up the application containers plus MySQL and Redis; directory sync, asset import, and the first recorded session usually fit inside the first hour.
Bars are not on a shared scale. CyberArk phases are typical ranges for a 500–2,000 asset deployment; the JumpServer bar represents the same four steps end to end.
CyberArk PAM Self-Hosted
7+ rolesWindows Server roles, each patched and upgraded on its own cadence.
JumpServer
1 stackLinux only. One file, one upgrade command, one version to track.
Full comparison, row by row
Grouped by the questions buyers actually ask. Where a capability is out of scope for JumpServer, the cell says so.
| Capability | CyberArk | JumpServer |
|---|---|---|
| Deployment & operations | ||
| Time to first production login | 6–12 weeks, usually partner-led 2 | ~30 minutes, self-service |
| Server roles to operate | 7+ Windows roles plus a SQL Server instance | One Compose stack (app containers + MySQL + Redis) |
| Platform prerequisites | Windows Server, Microsoft SQL Server | Any Linux host, MySQL or PostgreSQL, Redis |
| Additional OS / database licences | Windows Server and SQL Server licensing on top of PAM | None |
| High availability | Active/passive vault cluster, vendor-designed | Active-standby (Standard+), full HA cluster (Ultimate) |
| Upgrade mechanics | Versioned runbooks; vendor-assisted for major versions | Pull the new image, run ./jmsctl.sh upgrade |
| Authentication & authorisation | ||
| Directory integration | Active Directory, LDAP | Active Directory, LDAP, with scheduled sync |
| Single sign-on | SAML 2.0, OIDC | SAML 2.0, OIDC, OAuth2, CAS |
| Multi-factor authentication | TOTP, RADIUS, PKI / smart card | TOTP, Passkey / WebAuthn, RADIUS (Enterprise) |
| Approval workflow | Dual control, access request workflows | Ticket-based approval and JIT access (Enterprise) |
| Command-level control | PSM command filters | Command ACL per user, asset, and protocol |
| Credential rotation | CPM policies with plugin-based rotation | Scheduled rotation for managed accounts and SSH keys |
| Session & audit | ||
| Session recording coverage | SSH, RDP, database sessions | SSH, RDP, VNC, databases, Kubernetes, web assets |
| Recording storage | Digital Vault, policy-based retention | Local disk or object storage, policy-based retention |
| SIEM integration | Syslog / CEF forwarding to SIEM | REST API export; SIEM connector built on your side |
| Audit evidence ownership | Vendor audit reports plus your local logs | All evidence stays in your environment |
| Protocols & targets | ||
| SSH / Telnet | ✓ | ✓ |
| RDP / VNC | ✓ | ✓ |
| Databases | Through PSM | Native proxy: MySQL, Oracle, SQL Server, PostgreSQL, Redis, MongoDB, ClickHouse |
| Kubernetes | Conjur secrets integration | Native K8s asset, pod exec, fully recorded |
| Web applications | PSM for Web Apps (isolated browser) | Web asset type with remote browser |
| Machine secrets (app-to-app) | Conjur / Secrets Manager | — out of scope |
| Commercial | ||
| Licence model | Quote-based, per asset plus modules | GPL-3.0 Community free to 5,000 assets; Enterprise tiered by asset count |
| Source code | Closed | Public on GitHub |
| Where data lives | Your datacenter (self-hosted) or CyberArk cloud (Privilege Cloud) | Your infrastructure only; no vendor plane |
| Published pricing | No | Community free; Enterprise tier structure published, price on quote |
| Support | 24×7 vendor support, tier-dependent SLA | Community forum and GitHub; Enterprise adds email and ticket SLA |
Based on vendor documentation and hands-on deployments as of November 2026. If you believe a row is wrong, tell us and we will correct it: [email protected].
What three years actually costs
CyberArk does not publish list pricing. The ranges below reflect what mid-market buyers report paying in 2025–2026; your quote will move with asset count, modules, and region.1
The licence is the visible line. The rest of the bill arrives as implementation services, annual maintenance, Windows and SQL Server licensing, and the staff time to run seven server roles. For a 500-asset deployment, first-year spend commonly lands between $110,000 and $200,000 once services are included.
JumpServer Community Edition carries no licence fee up to 5,000 assets. Enterprise Edition adds multi-tenancy, enterprise SSO, and SLA support on a scale-based subscription. The calculator below lets you put your own numbers in, rather than trusting ours.
Three-year cost estimate
Adjust the four inputs. Nothing is sent anywhere.
Use your own quote if you have one.
- Licence
- $90,000
- Maintenance
- $19,800
- Implementation
- $75,000
Assumptions: maintenance runs at the percentage you set, applied to the annual licence for every year; implementation is one-time. Infrastructure, staff time, training, and Windows/SQL Server licensing are excluded on both sides. JumpServer Community Edition is free to 5,000 assets; above that, Enterprise Edition applies. This is an estimate, not a quote.
Costs that rarely appear in the first slide
- Windows Server and SQL Server licensing for the CyberArk tier, which is separate from the PAM subscription.
- Partner implementation days, frequently larger than the first-year licence itself.
- Training and certification, because day-2 operations on seven roles is a specialist skill.
- Upgrade project time. Major version upgrades on CyberArk are planned work, not a maintenance window.
- Switching cost in the other direction: if you are already standardised on CyberArk, migration effort can exceed three years of licence savings.
Sources & assumptions
- CyberArk does not publish list pricing. The $30,000+/year and $50,000–200,000 implementation ranges are indicative, compiled from customer-reported quotes for 200–2,000 asset deployments in 2025–2026. They are not a CyberArk price list and not an offer.
- Deployment durations assume a vendor-led or partner-led rollout with three to seven integrations. Smaller scopes with a single identity provider can finish closer to four weeks.
- Capability statements reflect vendor documentation and hands-on deployments as of November 2026. Product roadmaps change; verify anything contractual with the vendor directly.
What a migration actually involves
The blocker is rarely the platform. It is the permission model, the rotation scripts, and the question of who owns access during the parallel run. Here is the honest version.
| What you have | How it moves | Effort |
|---|---|---|
| Assets: servers, databases, K8s | CSV or REST API import into the asset tree | Low |
| Users and groups | LDAP/AD sync, then map to JumpServer roles | Low |
| Safes and permission sets | Rebuilt as asset nodes plus permission rules | Medium — this is the real work |
| Managed credentials | Re-entered, then rotated on first use | Medium |
| CPM rotation scripts | Rebuilt as rotation policies per platform | Medium |
| Custom PSM connectors | Re-validated against native protocol support | High, if you depend on one |
| Historical session recordings | Not migrated. Keep CyberArk read-only for the retention period | None |
Inventory and mapping
Export every safe, account, and role assignment. Map each safe to a JumpServer asset node and decide which policies you are deliberately dropping. Pick one pilot group with mixed protocols.
Output: asset and user CSVs, a scope document, a named pilot group.
Deploy and integrate
Bring up the stack, connect LDAP/AD and SSO, enforce MFA, import assets, and rebuild the pilot group's permissions. Record one session per protocol and check the replay quality before going further.
Output: staging environment with the pilot group working end to end.
Parallel run
Run both systems. CyberArk keeps serving production access while the pilot group uses JumpServer daily. Collect the gaps: a legacy thick-client app, an unusual protocol, an approval chain nobody documented.
Output: signed-off coverage list and a rollback point per wave.
Cut over in waves
Move one group at a time, revoke CyberArk access for that group only after a clean week of use, and keep the old platform read-only until the retention window closes.
Output: decommission date, archive plan, post-migration review.
Planning estimate, not a quote
Excludes internal change management and security review. Permission complexity moves these numbers more than asset count does.
Pre-migration checklist
Twelve things to gather before you touch a server.
- 01Export the full safe and account inventory from PVWA.
- 02Export users and groups with role assignments.
- 03Map every safe to a JumpServer asset node.
- 04List every integration: SIEM, ticketing, HSM, PAM-to-PAM.
- 05Record retention and legal-hold rules for old recordings.
- 06Confirm which protocols the pilot group uses daily.
- 07Prepare the asset CSV: name, IP, platform, protocol, node.
- 08Prepare the user CSV: username, email, source, role.
- 09Define approval policy per asset group, with an SLA.
- 10Agree the parallel-run window and success criteria.
- 11Agree the rollback point for each migration wave.
- 12Fix the CyberArk read-only retention period.
Where CyberArk is still the better choice
A comparison page that claims a clean sweep is not worth reading. These are the three cases where we would tell you to stay.
Machine identity at scale
Conjur issues short-lived credentials to applications, CI/CD pipelines, and cloud workloads. JumpServer governs human access to infrastructure; it is not a secrets manager for service accounts.
Endpoint privilege management
CyberArk EPM strips local admin from Windows and macOS endpoints. That is a different product category, and it is entirely outside JumpServer's scope.
Large, already-standardised programmes
With thousands of accounts, a certified partner bench, and procurement precedent, switching cost can exceed three years of licence savings. Staying is a legitimate answer.
JumpServer fits when
- Access is infrastructure-first: SSH, RDP, databases, Kubernetes.
- Self-hosting is mandatory and no vendor plane is acceptable.
- You want to deploy without a partner and upgrade without a project.
- Audit evidence must stay in your own environment.
CyberArk fits when
- You need endpoint privilege management on user workstations.
- Applications need a secrets manager, not just human access.
- A regulator or insurer expects a named PAM vendor with local support.
- You are mid-contract with deep custom integration already paid for.
On this page
Evaluate without a sales call
Community Edition is free to 5,000 assets. Enterprise adds SSO, multi-tenancy, and SLA support.
Start 14-day Enterprise trial Talk to the migration team500,000+ global deployments
30,000+ GitHub stars
3,000+ enterprise customers
Also comparing? See JumpServer vs BeyondTrust and JumpServer vs Teleport.
“We completed our CyberArk migration in two weeks and removed $80,000 a year of licence and maintenance spend. The permission mapping took longer than the platform did.”
Customer stories from teams running JumpServer in production, including regulated and multi-site environments.
Read customer storiesMigration questions, answered
Will I lose historical audit data when migrating from CyberArk?
No. Session recordings cannot be imported into JumpServer, so keep your CyberArk instance running read-only for as long as your retention policy requires. Assets, users, and permissions are imported via CSV or the REST API, and every session recorded after cutover lives in JumpServer.
Does JumpServer support CyberArk PSM session recording?
Yes. JumpServer records sessions natively for SSH, RDP, VNC, database protocols, Kubernetes, and web assets, with replay and search built in. There is no separate recording module to license. The feature matrix lists the exact coverage.
Can both systems run in parallel during migration?
Yes, and we recommend it. A 30 to 60 day parallel window lets you verify protocol coverage with a pilot group while CyberArk keeps serving production access. The two systems share no components, so there is no coordination overhead beyond your own change process.
What does not migrate automatically?
Session recordings, CPM rotation scripts, custom PSM connectors, and the safe hierarchy itself. Recordings stay in CyberArk for the retention period; safes are rebuilt as JumpServer asset nodes and permission sets. See what moves and what does not for the full table and a planning estimate.
How long does a typical migration take?
For 500 to 2,000 assets, plan 6 to 10 weeks: two weeks of inventory and mapping, two weeks of deployment and integration, a 30 to 60 day parallel run, then cutover in waves. Most of the effort sits in permission mapping, not in the platform itself.
Does JumpServer support dual control and approval workflows?
JumpServer Enterprise supports ticket-based approval with configurable approvers and just-in-time access, plus command-level ACLs. Dual control on individual password retrievals is a CyberArk CPM pattern; in JumpServer the equivalent is an approval policy on the account, which you configure per asset group.
Is JumpServer a secrets manager like CyberArk Conjur?
No. JumpServer manages human access to infrastructure: servers, databases, Kubernetes, and network devices. Machine-to-machine secrets for applications and CI/CD pipelines are outside its scope, which is one of the cases listed under where CyberArk is still the better choice.
How does the Palo Alto Networks acquisition affect CyberArk customers?
Palo Alto Networks completed the acquisition on 11 February 2026, after announcing the deal on 30 July 2025. Existing contracts and support commitments continue, but roadmap priorities, bundling, and pricing are now decided by the new owner. For a multi-year commitment, that is a planning risk worth pricing in rather than a reason to panic.
Run the comparison on your own numbers
Deploy Community Edition in 30 minutes, or start a 14-day Enterprise trial with the migration checklist included.