CyberArk Vault Architecture: How a Credential Request Actually Flows

TL;DR — CyberArk’s core split is simple: the Digital Vault is the system of record, PVWA is the web/API front door, CPM changes passwords on target systems, and PSM brokers privileged sessions without handing raw credentials to users. If you are debugging a failed credential retrieval, first identify whether the failure is at the API/auth layer (PVWA), policy/authorization layer (Vault), password freshness layer (CPM), or session brokering layer (PSM). Reading time: ~7 min

What it is and where it sits

CyberArk vault architecture is not one monolith. Think of it as four cooperating roles around privileged secrets and sessions:

• Digital Vault: authoritative storage and policy enforcement for privileged accounts and related metadata.
• PVWA: the HTTP(S) portal and API tier users, automation, and browsers talk to.
• CPM: the component that logs into target systems and rotates or verifies passwords.
• PSM: the session proxy/jump layer that launches RDP/SSH/etc. sessions without exposing the credential directly to the requester.

What it replaces in a typical shop:

• Shared admin passwords in wikis, password managers, or CI variables.
• Direct RDP/SSH to production hosts using long-lived human-known credentials.
• Ad hoc rotation scripts with no central audit trail.

Where it sits in a request flow:

• Humans hit PVWA in a browser or via REST API.
• Automation also hits PVWA API.
• PVWA asks the Digital Vault whether the caller can see/use/retrieve the account.
• If the caller wants a live session, PVWA hands off to PSM.
• Independently, CPM talks to the target machine/database/network device to rotate the password and writes the new value back to the Digital Vault.

[User / CI job / script]
          |
          | HTTPS (login, search account, retrieve/use credential)
          v
       [PVWA]
          |
          | internal request / policy check / secret fetch
          v
   [Digital Vault] <------------------- [CPM]
          ^                                  |
          |                                  | change/verify password on target
          |                                  v
       [PSM] ------------------------> [Target server / DB / device]
          |
          | proxied RDP/SSH/SQL session
          v
      [End session recording / audit]

The key architectural point: PVWA does not replace the Vault. It is the access layer. Likewise, PSM does not store the password of record; it consumes a secret or access policy to broker a session. And CPM is not in the user request path most of the time, but its health determines whether the password in the Vault is actually valid on the target.

How it actually works

Walk one realistic example: a deployment script needs the current password for a Windows service account stored in CyberArk, and later an admin opens an RDP session to the same host through PSM.

Step 1: Authenticate to PVWA

Your script authenticates to PVWA over HTTPS and gets a session token. Exact auth methods vary by deployment, but the shape is usually “POST credentials, receive token/cookie, use it on later calls.”

curl -sk -X POST "https://pvwa.example.com/PasswordVault/API/Auth/CyberArk/Logon" \
  -H "Content-Type: application/json" \
  -d '{"username":"build-bot","password":"REDACTED"}'

Typical success shape:

"eyJ0eXAiOiJKV1QiLCJhbGciOi..."

Typical failure shape when auth backend or path is wrong:

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=utf-8

Or a redirect loop/misconfigured reverse proxy:

curl -k -I "https://pvwa.example.com/PasswordVault/API/Auth/CyberArk/Logon"

HTTP/1.1 302 Found
Location: /PasswordVault/v10/logon
Set-Cookie: ARRAffinity=...

If your API client does not follow redirects, you will see confusing auth failures even though the site works in a browser. Use -L for diagnosis, but fix the proxy/base-path config rather than depending on redirects.

Step 2: Search for the account via PVWA

The script asks PVWA for the account object, usually by safe/account name/platform/address filters.

TOKEN="eyJ0eXAiOiJKV1QiLCJhbGciOi..."
curl -sk "https://pvwa.example.com/PasswordVault/API/Accounts?search=svc_deploy_prod" \
  -H "Authorization: $TOKEN"

Representative response shape:

{
  "value": [
    {
      "id": "23_17",
      "name": "svc_deploy_prod",
      "address": "app01.prod.example.com",
      "userName": "svc_deploy_prod",
      "safeName": "Unix-Prod",
      "platformId": "WinServerLocal"
    }
  ]
}

PVWA is doing two things here: exposing a search API and asking the Vault what this caller is allowed to know. If the account exists but the caller lacks Safe permissions, the result is often indistinguishable from “not found” at the API layer. That is by design.

Step 3: Retrieve or use the credential

If policy allows password retrieval, the script requests the secret for that account ID.

curl -sk -X POST "https://pvwa.example.com/PasswordVault/API/Accounts/23_17/Password/Retrieve" \
  -H "Authorization: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason":"CI deploy to prod"}'

Representative success:

{"password":"REDACTED-SECRET-VALUE"}

Representative policy denial:

{
  "ErrorCode": "CAWS00001E",
  "ErrorMessage": "Access is denied"
}

At this point the Digital Vault is the source of truth. PVWA is not inventing or caching a password independently; it is enforcing workflow and authorization around a Vault-stored object.

Important edge case: the Vault can return a password that is stale on the target if CPM is unhealthy or a previous rotation failed after updating one side but not the other. That is why “retrieval succeeded” does not prove “login to target will succeed.”

Step 4: CPM keeps the secret valid on the target

Separately from the user request, CPM runs according to platform policy: verify password, change password, reconcile if drift is detected.

Concrete mental model:

1. CPM reads the managed account and platform policy from the Vault.
2. CPM logs into the target host/device/db using the current credential or a reconcile account.
3. CPM changes the target password.
4. CPM writes the new password back to the Vault.
5. Audit records are updated.

Failure modes matter here:

• Target unreachable: network ACL/DNS/firewall issue.
• Password changed manually on target: verify fails; reconcile may fix it if configured.
• Vault updated but target change failed, or vice versa: now you have drift.

This is the component to suspect when users say, “CyberArk gave me a password, but it doesn’t work.”

Step 5: PSM brokers a session instead of exposing the password

Now an admin wants RDP to app01.prod.example.com but policy says “connect via PSM.” The user still starts from PVWA, selects the account, and chooses connect. The session is launched through PSM, which obtains the credential under policy and injects it into the target connection.

The user gets an RDP/SSH session; the raw password is typically not shown to them. PSM can also record the session for audit.

Mechanically, this changes the trust boundary:

• Without PSM: user knows the password and can reuse it anywhere reachable.
• With PSM: user gets a mediated session to an approved target/protocol path.

That is why PSM is not just “another jump host.” It is tied to Vault policy and account use controls.

When to use it (and when not to)

You probably do not need this if your real problem is just “my app needs database credentials.” CyberArk PAM architecture shines for privileged account governance, human admin access, rotation workflows, and audited session control. It is often overkill for ordinary application secret distribution.

Trade-offs

• Centralized control and audit → costs operational complexity. You now run multiple moving parts with dependencies between them.
• Password rotation with CPM → costs fragility at the edge. Legacy targets, odd login prompts, and network restrictions create constant exceptions.
• PSM session isolation → costs latency and UX friction. Interactive sessions can feel slower, and protocol quirks surface through the proxy.
• Strong authorization around secret retrieval → costs API integration work. Scripts must handle auth tokens, permission scopes, and non-obvious error codes.
• Reduced password exposure → costs vendor/process lock-in. Teams build operational habits around safes, platforms, and brokered access patterns.
• Compliance-friendly evidence → costs money and admin time. This is not the cheapest or lightest way to store a password.

The practical takeaway: every benefit comes from introducing mediation. Mediation is good for control and bad for simplicity.

In practice

Example 1: Minimal API flow to log in, find an account, and retrieve a password

#!/usr/bin/env bash
set -euo pipefail

PVWA_BASE="https://pvwa.example.com/PasswordVault/API"
USER="build-bot"
PASS="${CYBERARK_PASSWORD:?set CYBERARK_PASSWORD}"
SEARCH="svc_deploy_prod"

TOKEN=$(curl -sk -X POST "$PVWA_BASE/Auth/CyberArk/Logon" \
  -H "Content-Type: application/json" \
  -d "{\"username\":\"$USER\",\"password\":\"$PASS\"}" | tr -d '"')

ACCOUNT_ID=$(curl -sk "$PVWA_BASE/Accounts?search=$SEARCH" \
  -H "Authorization: $TOKEN" | jq -r '.value[0].id')

curl -sk -X POST "$PVWA_BASE/Accounts/$ACCOUNT_ID/Password/Retrieve" \
  -H "Authorization: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"reason":"CI deploy to prod"}'

What it does: authenticates, searches, and retrieves one password. Gotcha: many failures collapse into null from jq because the API returned an error object instead of .value; always inspect the raw body before assuming the account does not exist.

Example 2: Diagnose PVWA reverse-proxy/base-path problems before blaming CyberArk

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

    ssl_certificate /etc/letsencrypt/live/pvwa.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pvwa.example.com/privkey.pem;

    location / {
        proxy_pass https://pvwa-internal.example.net;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

What it does: forwards external HTTPS to the internal PVWA host. Gotcha: if PVWA is published under a subpath and the proxy strips or rewrites /PasswordVault incorrectly, API clients often get 302 or 404 on auth endpoints while browsers appear to “sort of work.” Verify with:

curl -k -I https://pvwa.example.com/PasswordVault/API/Accounts

Representative bad output:

HTTP/1.1 302 Found
Location: /PasswordVault/v10/Accounts

If your automation depends on exact API paths, fix the publishing path rather than chasing auth settings.

⚠️ Rotating or reconciling a privileged account can break production services immediately if that account is hardcoded anywhere, cached by a service, or reused outside the managed target. Before enabling CPM on an existing account, inventory every consumer and perform one supervised rotation in a maintenance window.

Example 3: Fast connectivity triage from the CPM/PSM side

nc -vz app01.prod.example.com 3389
nc -vz db01.prod.example.com 1433

Typical output:

Connection to app01.prod.example.com 3389 port [tcp/ms-wbt-server] succeeded!
nc: connect to db01.prod.example.com port 1433 (tcp) failed: Connection timed out

What it does: confirms whether the broker/rotation component can even reach the target port. Gotcha: a successful API retrieval from PVWA tells you nothing about CPM/PSM network reachability; treat them as separate failure domains.

Further reading

• CyberArk Privileged Access Security Implementation Guide
• CyberArk REST API documentation for PVWA
• CyberArk CPM Administrator Guide
• CyberArk PSM Administrator Guide
• The "Reverse Proxy" and "HTTP Redirections" sections of the MDN HTTP docs

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