The CyberArk platform, module by module
CyberArk is not one product. It is a platform of modules, each solving a different part of privileged access, and the most common question we get is which of them an environment actually needs. This page walks through what the Vault and Privilege Cloud, Privileged Session Manager, Endpoint Privilege Manager and Conjur each do, and where each one fits.



Which modules an environment actually needs
Looking for the engagement — scoping, licensing and a managed handover — rather than the modules? That is CyberArk implementation and delivery. The portfolio now sits under Palo Alto Networks and carries the IDIRA name; the components are unchanged. Chasing a specific error message? See error fixes.
Most CyberArk conversations start with "we bought CyberArk" and stall on "now what do we turn on?". The platform spans credential vaulting, session control, endpoint privilege and application secrets, and turning all of it on at once is the fastest route to a program that never finishes.
The usual order is the vault first, then session management, then endpoint privilege, then secrets. Not because of a methodology, but because each one depends on the last being stable. What follows is what each module does and the question it answers. How they go in, and in what order for your estate, is on the PAM implementation page.
- Users still running as admin on their own machineEPM
- Admins holding the real credential during a privileged sessionPSM
- Secrets hard-coded in code, config files, and environment variablesConjur
- Privileged accounts with no safe structure or rotation policyPrivilege Cloud
- Vault infrastructure that has to stay in your own tenancySelf-hosted Vault
Buying all of it at once is the fastest way to a deployment that never finishes.
The modules
CyberArk Privilege Cloud
The SaaS-hosted version of the CyberArk vault. CyberArk runs the vault infrastructure and you consume it as a service, so there is no hardware to stand up and no vault estate to maintain.
The practical difference from self-hosted is where the operational burden sits. With Privilege Cloud, CyberArk carries the platform availability, patching and upgrades; you carry the safe structure, the policy and the onboarding. Organizations choose it when they have no appetite for running vault infrastructure, and choose self-hosted when compliance, latency or data sovereignty says the vault has to stay inside their own boundary.
CyberArk Vault, CPM and PVWA: the self-hosted core
The self-hosted core is three components working together. The Vault is the encrypted store itself, hardened and deliberately isolated from everything else. The Central Policy Manager (CPM) is what actually changes passwords on target systems on a schedule — the piece that makes rotation real rather than theoretical. The Password Vault Web Access (PVWA) is the interface users and administrators work through.
Two decisions made at the start determine whether this is manageable in year two: the safe structure and ownership model, and the rotation policy agreed before the first account is onboarded. Most rotation failures in practice are CPM connectivity or plug-in problems rather than policy problems.
CyberArk PSM: Privileged Session Manager
PSM brokers privileged sessions so the administrator never holds the real credential. The connection is proxied, isolated from the endpoint, and recorded in full.
Three things follow from that. You get an audit trail of every privileged session, not just a log line saying one happened. You get a kill switch, because a live session can be terminated centrally. And you get a way to give third parties and remote administrators access without VPN plus a shared password, which is usually the real reason it gets bought.
CyberArk EPM: Endpoint Privilege Manager
EPM removes standing local administrator rights from endpoints and servers, and grants elevation only for approved actions. It closes the gap most privileged access programs leave open: the user still running as admin on their own machine.
It also contains ransomware, by stopping unapproved executables from running with privilege — which is the difference between one compromised laptop and a compromised estate. The thing that decides whether an EPM rollout succeeds is running it audit-first: watching what would break for a period before enforcing anything, so the exceptions are known rather than discovered through a help-desk queue.
CyberArk Conjur: secrets management
Conjur is the secrets engine inside CyberArk Secrets Manager. It pulls application, DevOps and machine-to-machine credentials out of code, configuration files and environment variables, and issues them at runtime with rotation and policy attached.
If developers are hard-coding API keys or keeping secrets in a repository, this is the module that fixes it. The reason it usually comes last is that it needs developer buy-in in a way the other modules do not: it changes how applications get their credentials, so it lands better once the rest of the platform has proved itself. It is also how service account management gets done properly at scale.
Other modules you may hear named
Cloud Entitlements Manager (CEM) for cloud permission right-sizing, Dynamic Privileged Access (DPA) for just-in-time access to cloud infrastructure, and On-Demand Privileges Manager for controlled elevation on Unix and Linux. Each solves a narrower problem than the five above, and each is worth a conversation rather than a page.
How the modules fit together
| Module | The question it answers | Depends on |
|---|---|---|
| Vault / Privilege Cloud | Where do the credentials live, and who can take one out? | Nothing — this is the foundation |
| CPM | Do the passwords actually change? | The vault |
| PSM | Can an admin work without ever seeing the credential? | The vault |
| EPM | Does anyone still have standing local admin? | Independent — can run alongside or before |
| Conjur | Where do applications get their secrets? | Usually the vault, plus developer adoption |
Vault, CPM, and PVWA run in your own data center or cloud tenancy, and you own the infrastructure.
- Chosen for compliance, latency, or sovereignty reasons
- Safe structure and ownership designed up front
- Rotation policy set before a single account is onboarded
- Hardened to the controls you report against
CyberArk runs the vault infrastructure and you consume it as a service.
- No hardware to stand up
- No vault estate to maintain
- Tenant provisioned and integrated with your directory
- Accounts onboarded in controlled waves
The capability is the same either way. Where it runs is a compliance and latency decision, not a product one.
CyberArk modules, answered
CyberArk Endpoint Privilege Manager removes standing local-admin rights from laptops and servers and grants elevation only for approved actions. It is the module that closes the gap most privileged access programs leave open: users who still run as admin on their own machine. It also blocks ransomware by stopping unapproved executables from running with privilege.
The same core capability with a different hosting model. The self-hosted Vault, with CPM and PVWA, runs in your own data center or cloud tenancy and you own the infrastructure. Privilege Cloud is the SaaS version: CyberArk runs the vault infrastructure and you consume it as a service. The choice is usually decided by compliance, latency and whether you want to operate vault infrastructure at all.
Privileged Session Manager brokers privileged sessions so administrators never hold the actual credential. The connection is proxied, isolated from the endpoint and fully recorded, which gives you an audit trail and a kill switch for every privileged session. It is also how secure remote and third-party access is done properly, without VPNs and shared passwords.
Conjur is the secrets-management engine inside CyberArk's Secrets Manager offering. It takes application, DevOps and machine-to-machine credentials out of code, config files and environment variables, and issues them at runtime with rotation and policy.
The Central Policy Manager: the component that actually connects to target systems and changes passwords on a schedule. Without it, a vault is a secure place to keep credentials that never rotate.
No, and buying all of it at once is how programs stall. Most environments start with the vault, or Privilege Cloud, plus PSM to get privileged credentials and sessions under control, then add EPM for endpoint least privilege and Conjur for secrets once the foundation is stable.
Whichever matches where your privileged risk actually sits. If shared admin passwords are the problem, the vault. If admins connect to production from their own laptops, PSM. If everyone has local admin, EPM. If developers are hard-coding secrets, Conjur. A module chosen against the risk lands; a module chosen from a price list sits unconfigured.
Go deeper

CyberArk vs Delinea: What Changes Once You Actually Deploy Them
Most CyberArk and Delinea comparisons are written by CyberArk or by Delinea. Here is the version from people who deploy privileged access for a living.
Oct 14, 2026
AI Agents Are Privileged Users: How to Govern Agent Identities With the PAM You Already Run
An AI agent is a service account that makes its own decisions. Most of what you need to control it already exists — and the part that is genuinely new is smaller than the marketing suggests.
Sep 30, 2026
What Is PAM (Privileged Access Management)? A Plain-English Guide
PAM secures the accounts with the most system power. Here's what privileged access management does and why attackers go after these credentials first.
Jul 28, 2026Not sure which CyberArk modules you need?
Tell us where your privileged risk sits and what you already own. A free consultation maps it to the right modules, with certified engineers on the call.