When people talk about “CyberArk vs BeyondTrust,” they usually go straight to feature checklists or licensing. I think it is more useful to start with how CyberArk actually thinks about privileged access.

At its core, CyberArk is built around three ideas: Safes to logically contain secrets, CPM (Central Policy Manager) to manage passwords, and PSM (Privileged Session Manager) to control how humans connect to systems. All of this is wrapped around a hardened vault.

Safes: The Core Abstraction In CyberArk

In CyberArk, a Safe is the primary container for privileged data. It holds accounts, passwords, SSH keys, and other secrets, and access is granted at the Safe level rather than on individual accounts. Most environments end up with Safes aligned to business boundaries: a Safe per application, per infrastructure tier, or per team. For example, you might have SAFE_SQL_PROD_APP1 for a production database, SAFE_WINDOWS_DOMAIN_ADMINS for AD admins, or SAFE_UNIX_ENGINEERING for a Linux team.

Once a user has access to a Safe, they can request or view passwords (if policy allows), launch PSM sessions using those accounts, and trigger workflows such as dual control or approval steps. Governance is applied to the Safe, and everything else hangs off that structure, which is why Safe design is one of the most important early decisions in a CyberArk deployment.

How Access Works Day To Day

In daily operations, CyberArk generally exposes three ways to reach a privileged account.

The first is classic password retrieval. An admin signs into the CyberArk web portal, navigates to a Safe, selects an account, and requests the password. Depending on policy, they may need an approved ticket or manager approval, and the password is only visible for a short window, with copy-only access and full audit logging.

The second is a PSM session launch. Instead of ever seeing a password, the user clicks “Connect.” CyberArk routes the request to a PSM server, which logs into the target system using the stored credentials. The user connects to PSM, PSM connects to the server, and the admin only sees the session not the secret behind it. This model works for RDP to Windows, SSH to Linux or Unix, web admin portals, database tools, and even thick clients.

The third path is programmatic access. Scripts, applications, and automation tools use the CyberArk REST API or plugins (AIM, CredHub, Conjur, etc.) to retrieve credentials at runtime. Instead of hardcoding passwords or storing them in config files, the code calls CyberArk on demand.

In mature deployments, humans primarily use PSM-based access, services consume credentials through APIs, and direct password reveals are reserved for break-glass scenarios or rare edge cases.

Onboarding Accounts: Users, Admins, and Service Accounts

CyberArk onboarding usually starts with Safe design. You decide which teams, applications, and environments get dedicated Safes, who owns them, and who approves access. Those Safes are then mapped back to RBAC roles in your identity provider so membership can be driven through IAM instead of manual user assignments.

Next comes platform design. A CyberArk platform is essentially a policy template that defines how a certain type of account should be managed: password complexity, rotation schedule, which protocol to use for connectivity (RDP, SSH, database protocol), and what “check, change, reconcile” looks like. You typically end up with different platforms for domain admins, local admins, SQL logins, Linux root/sudo accounts, and any service accounts that require special handling.

Human administrator accounts are then added into the right Safes and assigned the correct platform. Safe owners and approvers are configured, and PSM connectors are enabled so admins can launch sessions without touching passwords. This is where you begin to separate “who is allowed to use the account” from “who is allowed to see the password.”

Service and application accounts follow a similar pattern but with more plumbing. You identify accounts backing Windows services, scheduled tasks, app pools, and application level logins to databases or middleware. Those accounts are onboarded into Safes, connected to the right platform, and wired into change workflows so that when CPM rotates the password, the downstream service configurations are updated through scripts, plugins, or API calls. CyberArk wants you thinking in terms of governed Safes and platforms, not “a big bucket of passwords.”

CPM: How CyberArk Actually Manages Passwords

The Central Policy Manager (CPM) is the engine that turns high-level policy into real password changes. It verifies whether the stored credential is still valid on the target system, performs the actual password change, and reconciles mismatches when someone has changed a password outside of CyberArk.

Technically, CPM runs as a Windows service and uses platform-specific connectors to reach systems: LDAP, Kerberos, WinRM, and SMB for Windows and AD; SSH for Unix and Linux; native drivers for databases; and custom scripts for anything weird or legacy. It executes password changes based on time intervals, usage counts, or immediately after checkout or a PSM session, depending on how the platform is configured.

You can think of CPM as the “password transportation” layer. It writes the new password into the vault, and from there that secret is consumed through PSM sessions, password checkout, or API calls. The admin never needs to know how the password moved; they just see that it works and rotates on schedule.

PSM: The Real Power of CyberArk

If CPM is the password brain, PSM is the hands and eyes. Privileged Session Manager is essentially a hardened jump host tier that brokers all privileged connections, drawing credentials directly from Safes and enforcing policy in real time.

When an admin launches an RDP session, PSM can connect directly to a Windows server or to an existing jump box, while still hiding the password. For SSH, PSM provides controlled, audited access to Linux, Unix, and appliances without ever exposing the underlying key or password. For web applications, PSM can launch a browser to internal admin UIs or cloud consoles and inject credentials, MFA codes, or tokens as part of a defined login flow.

Database and thick-client tooling fit into the same pattern. Whether someone is using SQL Server Management Studio, Toad, pgAdmin, or a legacy fat client, the PSM plugin framework can be used to launch the app, inject credentials from the Safe, and handle pop-ups or multiple prompts along the way. The value is that all of this happens natively inside the PSM ecosystem; you are not constantly building custom glue just to get RDP, SSH, and critical admin tools behind strong controls.

CyberArk Reference Architecture: Vault, CPM, and PSM Working Together

In a modern CyberArk SaaS deployment, the vault and control plane live in CyberArk’s cloud. The core UI, policy configuration, Safe management, user roles, and reporting are all hosted there, with authentication flowing through your IdP and SSO.

CPM servers are placed close to your targets: in your data center for on-prem workloads and in IaaS environments like AWS or Azure for cloud workloads. They initiate outbound connections from your network to the SaaS service and down to your systems, and you can segment CPMs by environment (prod vs non-prod), network zone (DMZ vs internal), or technology stack.

PSM servers sit where admins can easily reach them—often in an internal admin network or a bastion subnet in the cloud. Admins connect to PSM through the web portal or an RDP client, select a system and account, and click “Connect.” PSM then reaches into your internal or cloud networks using a credential that CPM manages and rotates behind the scenes. The entire workflow is logged, recorded, and governed at the Safe and role level.

The end result is a clean separation of duties: the SaaS vault holds governance, policy, and secrets; CPM handles password automation, rotation, and reconciliation; and PSM delivers just-in-time access, session governance, and detailed audit trails for every privileged action.