CyberArk vault architecture: how Digital Vault, PVWA, CPM, and PSM fit together

TL;DR — CyberArk’s core architecture is easiest to understand if you treat the Digital Vault as the system of record, PVWA as the policy/API front door, CPM as the password-changing worker, and PSM as the session broker/recorder. For most troubleshooting, start by asking: did the request fail at policy/API (PVWA), secret retrieval from the Vault, password lifecycle in CPM, or session brokering in PSM? Reading time: ~7 min

What it is and where it sits

CyberArk’s classic PAM architecture splits responsibilities on purpose:

• Digital Vault stores privileged credentials and related metadata as the authoritative backend.
• PVWA is the web/API layer users, automation, and admins typically hit first.
• CPM is the component that logs into target systems and changes passwords/keys on schedule or on demand.
• PSM is the jump/broker layer for interactive privileged sessions so users do not need direct network access or raw credentials.

If you are a developer, the useful mental model is: PVWA is the control plane entry point; the Vault is the durable secret store; CPM and PSM are execution-plane workers.

What it replaces in a typical enterprise flow:

• Shared admin passwords in wikis, password managers, or ticket comments
• Direct RDP/SSH access from engineer laptops to production servers
• Ad hoc rotation scripts in Jenkins/cron
• “Break glass” credentials that never rotate because nobody trusts the process

Where it sits in a request/data flow:

• Human users usually authenticate to PVWA in a browser.
• Automation may call PVWA APIs to retrieve credentials or request access.
• PVWA checks authorization and asks the Digital Vault for account data.
• If the request is for an interactive session, PVWA hands off to PSM.
• If the account needs reconciliation/rotation, PVWA or policy triggers CPM, which updates both the target system and the Vault record.

[User / CI job / API client]
           |
           v
        [PVWA]
        / |  \
       /  |   \
      v   v    v
 [Digital Vault] [PSM] [CPM]
      ^             |
      |             v
      +---------[Target system]

A practical distinction that matters in design reviews: credential retrieval and session brokering are different flows. If your team says “CyberArk access is broken,” you need to ask whether they mean “I can’t fetch a password” or “I can’t launch an RDP/SSH session through PSM.” Those fail in different places.

How it actually works

Walk one realistic example: a production engineer needs temporary SSH access to a Linux host whose root credential is managed by CyberArk. The engineer does not see the root password; they launch a session through PSM.

Step 1: User hits PVWA

The engineer signs into PVWA through the enterprise auth method configured in that environment. From the app’s point of view, PVWA now has an authenticated user identity and can evaluate entitlement to a specific account object stored in the Vault.

At this point, common failure modes are basic web/authn issues, not Vault issues. For example, if a reverse proxy in front of PVWA is misconfigured, you may see redirect loops or wrong scheme handling:

curl -I https://pvwa.example.com/PasswordVault/

HTTP/1.1 302 Found
Location: http://pvwa.example.com/PasswordVault/
Set-Cookie: ASP.NET_SessionId=...

That Location: http://... on an HTTPS site usually means the upstream app or proxy headers are wrong. If users report repeated login prompts, fix the proxy/TLS termination path before blaming the Vault.

Step 2: PVWA authorizes the request against Vault-backed objects

PVWA looks up the requested account’s metadata in the Digital Vault: safe membership, platform policy, whether access requires approval, whether exclusive access/check-out is enabled, and whether the account is in a valid state.

Conceptually, the decision is:

1. Is the user authenticated?
2. Is the user allowed to use this account object?
3. Is the account currently available for use?
4. Is the requested access mode “show/copy credential” or “connect via PSM”?

If the account is marked for managed sessions only, PVWA should route the user to PSM instead of exposing the secret.

Step 3: PVWA asks the Digital Vault for the credential material

The Digital Vault is the source of truth. PVWA does not become the long-term store; it retrieves what it needs to satisfy the request. For a PSM launch, that may be enough to build a connection package without ever rendering the password to the user.

If the Vault is unavailable or the account object is inconsistent, the user-facing symptom often appears in PVWA as a generic failure: account not available, connection component launch failure, or retrieval denied. The root cause may still be Vault-side connectivity or object state.

Step 4: PVWA hands off to PSM for session brokering

For SSH/RDP/DB sessions, PSM is the component that actually brokers the connection. It uses the stored credential from the Vault-backed request path to connect to the target system on the user’s behalf.

The important architecture point: the user’s workstation connects to PSM, and PSM connects to the target. That gives you isolation, session control, and recording.

User browser/PVWA -> PSM launcher -> PSM host -> target Linux server:22
                                         |
                                         +-> session recording / policy enforcement

If the target host is unreachable from PSM, the user may think “CyberArk is down” when the real issue is network pathing from the PSM subnet.

Useful diagnostics from the PSM side look like ordinary network checks:

nc -vz app-prod-01.example.net 22

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 10.42.18.27:22.
Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.

And the failure shape:

nc -vz app-prod-01.example.net 22

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connection timed out.

That is not a Vault problem. It is a routing, firewall, or target availability problem between PSM and the endpoint.

Step 5: Session runs; password may later be rotated by CPM

After the session, the account may be rotated according to policy or after check-in/check-out semantics, depending on how that platform/account is configured in your environment. CPM is the worker that performs the change on the target system and then updates the stored credential in the Digital Vault.

This is the part many developers miss: CPM is not in the hot path of every retrieval. It is in the hot path of password lifecycle operations: verify, change, reconcile.

If CPM cannot log into the target to rotate the password, you get drift:

• Vault thinks the password should be one value
• Target system still has another value
• Future PSM launches or credential retrievals fail even though authorization is correct

That is why “access denied” to the target after a successful PVWA launch often points to CPM drift, not user permissions.

When to use it (and when not to)

Use this architecture when you need separation between secret storage, access policy, rotation, and session control.

You probably don’t need the full CyberArk-style split if your actual requirement is simply “my Kubernetes workload needs a database password.” That is usually a machine secret distribution problem, not a privileged human access problem.

Trade-offs

Every benefit here has a cost.

• Benefit: strong control over privileged credentials
  Cost: operational complexity. You now run multiple tightly-coupled components with network, policy, and lifecycle dependencies.

• Benefit: passwords can be hidden from users
  Cost: session path dependency on PSM. If PSM capacity, connectivity, or launcher integration is broken, admins are blocked.

• Benefit: automatic rotation via CPM reduces long-lived secrets
  Cost: target-specific fragility. Password changes fail when target APIs, login prompts, sudo policies, or host reachability drift.

• Benefit: centralized audit trail
  Cost: storage, retention planning, and review burden. Session recordings and logs are only useful if someone can search and retain them correctly.

• Benefit: separation of duties
  Cost: slower change velocity. Simple “just give me the password” workflows become approval, policy, and platform configuration work.

• Benefit: reduced credential sprawl
  Cost: vendor/process lock-in. Once account onboarding, rotation logic, and operator workflows depend on the platform, migration is expensive.

Latency is usually acceptable for humans but noticeable in automation if every call goes through policy checks and retrieval APIs. For CI/CD, test whether your pipeline is doing one lookup per job or dozens per step.

In practice

Example 1: Quick PVWA reachability and redirect sanity check

curl -k -I https://pvwa.example.com/PasswordVault/ && echo $? 

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: ASP.NET_SessionId=abc123...; path=/; secure; HttpOnly
X-Frame-Options: SAMEORIGIN

This checks that the PVWA entry point is reachable and not obviously redirecting to the wrong scheme/host. The gotcha: curl exit code 0 only means the HTTP exchange succeeded at the transport level; a 302 to http:// or a 401 still means your user flow is broken.

Example 2: Test whether PSM can actually reach the target port

nc -vz db-admin-01.internal.example 3389; echo $?

Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 10.60.4.15:3389.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.
0

This validates the network leg that matters for brokered sessions: PSM to target, not your laptop to target. The gotcha: a successful TCP connect does not prove credentials are valid; it only rules out one class of “PSM launch failed” problems.

Example 3: Reverse proxy headers in front of PVWA

server {
    listen 443 ssl http2;
    server_name pvwa.example.com;

    ssl_certificate /etc/ssl/certs/pvwa.fullchain.pem;
    ssl_certificate_key /etc/ssl/private/pvwa.key;

    location / {
        proxy_pass http://pvwa_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

This is the kind of proxy config that prevents PVWA from generating http:// redirects when TLS terminates at nginx. The gotcha: if your upstream app is not configured to trust forwarded headers, setting them here may not be enough; verify with curl -I and inspect the Location header.

⚠️ If you trigger password rotation tests against a real managed account, you can lock out production access or desynchronize the stored secret from the target. Run verification/change tests only against a non-critical account or during a maintenance window.

Example 4: API client pattern for credential retrieval troubleshooting

curl -sS -D /tmp/pvwa.headers -o /tmp/pvwa.body \
  -H 'Content-Type: application/json' \
  -X POST https://pvwa.example.com/PasswordVault/API/Auth/CyberArk/Logon \
  --data '{"username":"svc_ci","password":"REDACTED"}' ; echo $?

0

This captures headers and body separately so you can distinguish transport success from application failure. The gotcha: a successful auth call does not prove the account retrieval or PSM launch path works; those invoke different policy and backend checks.

Further reading

• CyberArk Privileged Access Security Solution Installation Guide
• CyberArk Privileged Vault Web Access Implementation Guide
• CyberArk Central Policy Manager Administrator Guide
• CyberArk Privileged Session Manager Administrator Guide
• The "Proxying and Load Balancing" section of nginx documentation

This article was written by an AI system and published pending human review. Verify anything you intend to act on.