Which single TCP port do all CyberArk PAM components use to communicate with the Digital Vault?

Correct: b. Every component — PVWA, CPM, PSM, PSMP, PTA, DR Vault — reaches the Vault on 1858 via the proprietary Vault protocol. 443 is PVWA's client port, 3389 is PSM's RDP client port, 9004 is the HSM path — none of them is how components talk to the Vault.

You're at a Mumbai bank. A user runs ssh alice@root@10.20.30.5@psmp.bank.local and gets an authentication failure at the PSMP. The PSMP service is up. What do you check first?

Correct: a. PSMP fails fast at the authorization layer: the Vault user must have List, Use and Retrieve on the Safe before any credential is fetched on 1858 . (b/c) misread it as a target/OS issue. (d) confuses the HSM path with the target connection.

During a DR drill you set FailoverMode=Yes and promoted the Pune DR Vault. The Mumbai Primary is now restored. How do you safely fail back?

Correct: c. Clean failback means demoting DR: stop its server, reset FailoverMode=No , strip the stale timestamp lines so PADR re-syncs from the Primary, restart PADR, confirm in PADR.log . (a) corrupts state, (b) is overkill, (d) breaks the Vault protocol.

After moving the Server Key to an HSM at a Pune fintech, the Vault fails to start the next morning. No hardware was changed overnight. What's the most likely cause?

Correct: b. With the Server Key on the HSM, Vault startup hard-depends on HSM reachability. A blocked 9004 or a stopped HSM service stops the boot by design — safe, not a bug. (a/c/d) don't gate Server Key decryption.

A three-site Satellite Vault shows "last replicated 6 hours ago", but the replication service is running and logs no errors. How do you find the root cause?

Correct: b. The classic silent-stall signature is NTP drift plus binlog timestamps — the replica asks for logs "from the future." Confirm NTP, the 1858 / 5671 paths, and PADR.log . (a) hides the symptom, (c/d) touch unrelated keys.

A CISO asks whether their on-prem EPV v12.6 deployment is exposed to CVE-2025-49827. How do you answer?

Correct: d. Precision matters: the CVE is a Conjur/Secrets-Manager IAM-authenticator bypass, a different product line and version range than a v12.6 EPV. Verify no Conjur auth is in play and patch on the CISA-KEV cadence. (a) is alarmist, (b) is false, (c) is unrelated to the CVE.

A team proposes installing the PVWA web server on the same physical machine as the Vault "to save cost." Evaluate this.

Correct: c. Co-location puts executable web code on the storage host — the exact thing Vaulting Technology® forbids. It also makes hardening impossible. The cost "saving" buys a Critical audit finding. (a/b/d) all rationalise the violation.

A bank wants to store the CyberArk Recovery Private Key (Master CD) on the encrypted file server used for general IT backups. Evaluate and recommend.

Correct: d. The Master CD private key bypasses every other control, so it must live offline under split-knowledge / dual-custody, never on networked backup infrastructure. Encryption-at-rest (a), logging (b), and a separate folder (c) don't change that it's reachable over the network.

CyberArk Digital Vault — EPV Architecture & the 7 Security Layers

Q: You're at an Indian IT-services firm. A freshly deployed PVWA server ( 172.16.2.50 ) shows "VaultConnectivity FAILED". The Vault service is running and netstat on the Vault shows 1858 LISTENING. What do you check first?

Correct: b. The Vault is listening (you confirmed LISTEN state), so the Vault is fine. The break is in the path: a new component IP almost always means the network firewall or host ACL doesn't yet allow 1858 from it. (a/c) are blind reinstalls. (d) breaks every other component — the Vault listens on 1858 by design.

Q: You're a CyberArk admin at a Bengaluru BPO. A colleague wants to install the corporate EDR agent on the Vault server "for visibility". What do you tell them?

Correct: c. CyberArk's standard is explicit: nothing but the Vault software runs on that OS. Visibility comes from native syslog forwarding configured in DBParm.ini (or PTA as intermediary), not from an agent that widens the attack surface and may break hardening. (a/b/d) all put foreign code on the credential host.

The interview question that trips up 70% of candidates

Senior PAM interview: "Your Digital Vault sits behind its own hardened firewall. So can you just put it on the normal server VLAN to keep networking simple?"
Wrong answers: "Sure, the firewall protects it anyway", "The Vault protocol is encrypted so the VLAN doesn't matter". Right answer: No. CyberArk's security standard requires the Vault in a dedicated, isolated network segment reachable only by the component servers (PVWA, CPM, PSM, PSMP). Even though the Vault protocol on TCP 1858 rejects unauthenticated traffic, exposing 1858 to 800 workstations is a Critical audit failure. That distinction — defence-in-depth vs "the firewall will save me" — is exactly what separates a Defender from a Guardian-level architect.

💡 The RBI bank-locker-room analogy

Picture the main locker room inside an RBI-grade bank vault complex. The bank building is your corporate network — many rooms, many staff. The vault room itself has one small chit-window that speaks one language: hand a slip, the clerk verifies you, hands one document back. Nobody walks inside the vault room. That window is TCP 1858 and the language is the Vault protocol.

The master key to the room is sealed in a tamper-evident cover inside a separate physical safe — that's the HSM holding the Server Key. Even the head cashier can't take it home; it never leaves the safe and is only used by the vault mechanism itself. That single picture explains why the Vault is hardened, why one port matters, and why the key lives in hardware. Hold it as you read.

4 terms you'll be tested on before we begin

🏛

Digital Vault (EPV)

tap to flip

The hardened Windows server running the proprietary Storage Engine. Stores every credential, Safe and audit log. After install it owns the Windows firewall and answers only on TCP 1858. So: the one box you isolate above all others.

🔌

Vault protocol 1858

tap to flip

Every component — PVWA, CPM, PSM, PSMP, PTA, DR Vault — talks to the Vault only on TCP 1858, encrypted and SHA2-512 integrity-hashed. So: if a component "can't reach the Vault", you check 1858 first, always.

🔑

Server Key on HSM

tap to flip

The AES-256 master key encrypting all Safe Keys. On a PKCS#11 HSM it is non-exportable. So: steal the Vault disk image and you still can't decrypt anything — the master key never left the hardware.

🌀

PADR / DR Vault

tap to flip

The service on the DR Vault that replicates metadata + Safe files from the Primary, driven by PADR.ini. Auto-promotes after 5 failed heartbeats. So: your second datacentre stays warm and audit-ready, not cold.

Before you read — predict these 3 (no grading, just guess)

1. Which single TCP port carries ALL Vault traffic? 2. Where should the Server Key physically live in a bank deployment? 3. If the HSM goes offline overnight, what happens to the Vault at startup?

Hold your three guesses. By the end of this lesson you'll know if your instinct matched a Guardian's.

① The 7 security layers — the patented onion around the Vault

CyberArk's Vaulting Technology® wraps the credential store in seven independent layers. Defeat one and the next still holds. This is why a single misconfiguration rarely equals a breach — but it absolutely equals an audit finding.

Scenario — Priya Sharma, Senior Security Architect at a Mumbai private bank

Priya runs a Mumbai-HQ private bank with a Pune DR site. Her IS-audit checklist maps almost one-to-one onto these seven layers: isolated Vault VLAN (firewall + isolation), Vault protocol only (encrypted channel), MFA into PVWA (strong auth), Safe permissions (granular access), HSM Server Key (file encryption), the tamper-proof trail (visual audit), and dual control on the crown-jewel Safes. She doesn't memorise the layers — she designs to them.

Figure 1 — The 7-layer security onion. From the outer firewall + isolation ring to dual control, every layer is independent. The Storage Engine core is reachable only through the Single Data Access Channel.

Colour keyuntrusted / attackertrusted / vaultedpolicy / decision pointkey insightallowed

Common mistake — "the firewall protects it, so the VLAN is fine"

An architect at a Pune fintech put the Vault on the general server VLAN to simplify routing. A pen-test found TCP 1858 reachable from 800 workstations. The hardened firewall rejected the unauthenticated attempts — but the design violated CyberArk's security standard (Vault must sit in a dedicated, isolated segment). Result: a Critical audit finding and a two-week remediation. Layer 1 isn't optional just because Layer 2 exists.

Pause & Predict

A junior says "the audit trail is fine, our Vault Master User reviews and edits it weekly." What's wrong with that sentence?

The word "edits." The Vault audit trail is cryptographically tamper-proof — no user, including the Master User, can modify it. If someone claims they edit it, either they mean a different log or your control is broken. Reviewing is fine; editing is impossible by design, and that immutability is exactly what regulators want.

Pause & Predict A vendor demo turns off the firewall layer to "make testing easier" and says the other six layers still protect the Vault. Why is that reasoning dangerous?

Answer: The 7 layers are defence-in-depth, not interchangeable. Each layer is independent and removing the outer firewall + isolation layer widens the attack surface that every inner layer (single data-access channel, authentication, encryption, dual control, immutable audit) was sized against. The strength of the onion is that an attacker must defeat all layers — drop one and you've quietly converted "must beat seven" into "must beat six," which is exactly the assumption attackers look for.

② The component map — PVWA, CPM, PSM, PSMP, PTA on TCP 1858

The Vault stores; the components do the work. Think of a busy passport seva kendra: different counters, one secure record room behind them. Every counter queues at the same window (1858) just like everyone else — no counter bypasses it.

Scenario — Amit Verma, CyberArk Admin at an Indian IT-services firm

Amit manages 15,000 devices across India, US and UK on CyberArk PAM Self-Hosted. When a session "breaks", his first question is never "which component is buggy?" — it's "can that component reach the Vault on 1858?" Nine times out of ten, the answer is no, and the fix is a firewall ACL, not a reinstall.

Here's who does what, and on which port the client side faces the user — but every one of them reaches the Vault on 1858:

PVWA (Password Vault Web Access) — the web reception on TCP 443. Users log in here, request and show credentials. It's the front desk.
CPM (Central Policy Manager) — the rotation engine. Changes and reconciles passwords before they expire. Never touches the user; talks only to targets and the Vault.
PSM (Privileged Session Manager) — proxies Windows RDP on TCP 3389 (or 443 via the HTML5 gateway). Fetches the credential from the Vault, injects it, and records the session as video — the user never sees the password.
PSMP (PSM for SSH) — the Linux/Unix equivalent on TCP 22.
PTA (Privileged Threat Analytics) — the CCTV-analytics brain that watches behaviour and raises anomalies.

Figure 2 — Full component architecture. The Vault sits at the centre; PVWA/CPM/PSM/PSMP/PTA are spokes. Client-facing ports differ, but the connection to the Vault is always TCP 1858.

PSMP is the one people fumble in interviews. It installs a second, CyberArk-owned sshd on TCP 22 and shifts the OS-native sshd to 2222. The user connects with a stacked syntax, PSMP authenticates them, fetches the target credential from the Vault on 1858, opens a fresh outbound SSH session to the target, and records every keystroke.

PSMP — connect to a Linux target through the SSH proxy

# Syntax: ssh <vaultuser>@<targetuser>@<targethost>@<psmp-host>
# PSMP at psmp.bank.local (172.16.3.20). Vault user = priya.sharma
ssh priya.sharma@root@10.20.30.5@psmp.bank.local

Expected output

CyberArk Privileged Session Manager for SSH
Authentication required.
priya.sharma@psmp.bank.local's password: ********
Connecting to root@10.20.30.5 via CyberArk PSMP...
Session recording started (ID: 5a4f8c12-...)
[root@linuxprod01 ~]#

Recreated for clarity🗄️ The exact screen a Vault admin uses to see the tree of Safes and one Safe's properties — PrivateArk Client → Safes → Safe Properties. Your console matches this layout.

PrivateArk Client — VAULT01 (TCP 1858)

CCyberArk · PrivateArk Administrative Client/ Safes / PSMRecordings

PROD-Linux

DOM-Admins

DB-Oracle

PSMRecordings

VaultInternal

Safe Properties — PSMRecordings Update

Managing CPMPasswordManager

Number of saved versions5

Object Level Access ControlEnabled2

Safe size limit (MB)10240

MembersPSMAppUsers, Auditors, Vault Admins1

① Nothing reaches a Safe except through the Vault on TCP 1858 — the firewall, auth, encryption and access-control layers all sit in front of this tree. ② OLAC = even Safe members only see the objects they're explicitly granted.

Quick check · Q1 of 10

You're at an Indian IT-services firm. A freshly deployed PVWA server (172.16.2.50) shows "VaultConnectivity FAILED". The Vault service is running and netstat on the Vault shows 1858 LISTENING. What do you check first?

a) Reinstall PVWA from scratch b) Whether the perimeter firewall / Vault host ACL permits TCP 1858 from 172.16.2.50 — a new component IP not yet in the allow-list is the classic cause. Add the rule and retest Test-NetConnection c) Restart the whole Vault server d) Change the Vault listening port to 443

Correct: b. The Vault is listening (you confirmed LISTEN state), so the Vault is fine. The break is in the path: a new component IP almost always means the network firewall or host ACL doesn't yet allow 1858 from it. (a/c) are blind reinstalls. (d) breaks every other component — the Vault listens on 1858 by design.

Quick check · component map

An auditor watches an admin RDP into a Windows server through CyberArk and asks: "Did that admin just type the local Administrator password?" Based on how PSM works in the component map, what's the correct answer?

a) Yes — PVWA shows the admin the password on port 443, then they paste it into the RDP prompt b) No — PSM brokers the session and injects the credential into the RDP connection; the admin never sees or types it, and the whole session is recorded. The Vault still hands the secret to PSM over TCP 1858 c) No — CPM logs the admin in, because CPM owns the rotated password d) Yes — the admin reads it from PTA, the analytics brain

Correct: b. PSM (and PSMP for SSH) is a session proxy: it pulls the credential from the Vault over 1858 and injects it straight into the RDP/SSH connection, so the human never sees the secret and every keystroke is recorded. (a) describes "show password," which PSM exists to avoid. (c) CPM only rotates passwords — it doesn't broker sessions. (d) PTA is detection/analytics, not a credential source.

③ The Server Key + HSM — the three-tier key hierarchy

CyberArk never encrypts a stored password with one key. It uses a three-tier hierarchy, exactly like a joint-family jewellery system: each ornament has its own small box, all boxes for one branch sit in a larger locker, all lockers live inside the bank's main vault.

Object Key — unique per stored object, AES-256. (the small jewellery box)
Safe Key — encrypts every Object Key in one Safe. (the branch's locker)
Server Key — AES-256 symmetric, encrypts all Safe Keys. Belongs on an HSM as a non-exportable key. (the bank's main vault key)

Alongside sits the Recovery Key — an RSA-2048 pair whose private half (the Master CD) stays offline in a physical safe for catastrophic recovery only.

Scenario — Priya designs the Server Key for the Mumbai bank

Priya's threat model is the rogue sysadmin. Her answer: offload the Server Key to an Entrust nShield (or Thales Luna) HSM in a FIPS 140-2 Level 3 config, non-exportable. Now even if someone clones the Vault's disk, they cannot decrypt a single Safe without the HSM. The Operator CD's private Recovery Key sits in the bank's physical vault at the IS-head's branch — split custody, two people, two locations.

Figure 3 — Three-tier key hierarchy. Object → Safe → Server Key, with the Server Key held non-exportable on an HSM. The offline Recovery Key is the separate break-glass path.

On the Vault host — generate the Server Key on the HSM (service stopped first)

# Run from C:\Program Files (x86)\PrivateArk\Server\ as admin
.\CAVaultManager.exe GenerateKeyOnHSM /ServerKey

Expected output

CyberArk CAVaultManager utility
Connecting to HSM device...
Generating Server Key on HSM...
Server Key was successfully generated on HSM device (KeyID=HSM#1)
Please record this KeyID and update ServerKey parameter in DBParm.ini

Common mistake — HSM offline = Vault won't boot

The Vault decrypts Safe Keys using the Server Key. If that key lives on the HSM and the HSM is unreachable at startup — network path down, TCP 9004 blocked, HSM service stopped — the Vault refuses to start. This is correct, safe behaviour, not a bug. Restore HSM connectivity first, then start the PrivateArk Server service. Plan HSM HA accordingly.

Pause & Predict

A thief steals the Object Key for one account from a backup. How many passwords can they decrypt?

Zero on its own — and at most that one object even with more. An Object Key is itself wrapped by the Safe Key, which is wrapped by the Server Key on the HSM. Without the higher tiers the stolen key is useless ciphertext. That's the whole point of the three-tier joint-family-jewellery model: one stolen box opens nothing.

Pause & Predict Your security lead asks: "If we put the Server Key on an HSM, why do we also keep the Recovery Key's private half offline on a Master CD in a physical safe?" What's the reason?

Answer: They solve different failure modes. The Server Key (AES-256, on the HSM, non-exportable) protects day-to-day operation — it wraps the Safe Keys that wrap the Object Keys. The Recovery Key is an RSA-2048 pair for catastrophic recovery; its private half stays offline precisely so that even a total HSM/Server-Key loss doesn't mean the vaulted data is gone forever. One key keeps the vault running; the other is the break-glass that survives the vault itself being destroyed.

④ Hardening — why nothing else runs on the Vault OS

The Vault OS runs the Digital Vault software and nothing else. No antivirus, no SIEM agent, no monitoring tool. CyberArk's CAVaultHarden utility locks the box down: disables unneeded services, hands the Windows firewall to the Vault, and permits only 1858 inbound (plus whitelisted outbound like the HSM on 9004).

Scenario — the architect who exposed the Vault and failed the audit

A different architect "simplified" two things at once: he dropped the Vault on the corporate LAN and installed a Splunk syslog-forwarder agent on the Vault OS to ship audit events. Both broke the standard. The forwarder agent is third-party software on the credential host (forbidden), and the LAN placement exposed 1858. The audit verdict: Critical. The correct path — native syslog forwarding configured in DBParm.ini, Vault in an isolated VLAN — was a one-line config, not an agent.

Figure 4 — Hardening cheat-sheet. The card every Vault build is graded against. The orange panel is the upgrade gotcha that silently kills 1858 on VMware.

Common mistake — post-hardening silent network failure on VMware

After an upgrade, Amit's team re-ran CAVaultHarden on a vSphere Vault. All components reported "VaultConnectivity FAILED" even though 1858 showed LISTEN. Root cause: the virtual NIC was classified by Windows as a Public profile, and hardening sets the Public-profile registry keys AllowLocalPolicyMerge and AllowLocalIPsecPolicyMerge to 0 — so the Vault's own 1858 rule never activated. Fix: set both to 1 under HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile, reboot, and reclassify the vNIC to Private before future hardening runs.

Quick check · Q2 of 10

You're a CyberArk admin at a Bengaluru BPO. A colleague wants to install the corporate EDR agent on the Vault server "for visibility". What do you tell them?

a) Sure, EDR everywhere is good practice b) Only if it's a lightweight agent c) No — the Vault OS must run only the Digital Vault software. Any third-party agent expands attack surface and can collide with CAVaultHarden rules. Get visibility by forwarding Vault audit events natively via DBParm.ini syslog to the SIEM, or via PTA d) Install it but disable real-time scanning

Correct: c. CyberArk's standard is explicit: nothing but the Vault software runs on that OS. Visibility comes from native syslog forwarding configured in DBParm.ini (or PTA as intermediary), not from an agent that widens the attack surface and may break hardening. (a/b/d) all put foreign code on the credential host.

▶ Watch a credential travel the Vault protocol

Priya clicks "Connect" in PVWA → PSM fetches the password from the Vault on 1858 → injects it → records the session. She never sees the password. Press Play.

① 11:02:00Priya logs into PVWA over TCP 443 with MFA, finds the root@10.20.30.5 account, clicks Connect.

▼

② 11:02:01PVWA checks her Safe permissions, then hands the session to PSM. No password has left the Vault yet.

▼

② 11:02:02PSM opens a Vault-protocol request on TCP 1858. The Vault decrypts: Server Key (HSM) → Safe Key → Object Key, returns the secret encrypted in transit.

▼

④ 11:02:03PSM injects the credential straight into the RDP session to 10.20.30.5. Priya's screen shows a logged-in desktop — never the password.

▼

⑤ 11:02:04PSM records the session as video into the Vault; the tamper-proof audit trail logs "priya.sharma connected to root@10.20.30.5". PTA watches for anomalies.

Press Play to watch a privileged session created without the user ever seeing the password.

⚡ Vault XP

0 XP

⑤ HA / DR — PADR replication and silent failover

One Vault is a single point of failure. CyberArk's answer for Priya's two-datacentre bank is a Primary→DR Vault pair driven by the PADR service. The DR Vault in Pune replicates from the Mumbai Primary, stays warm, and auto-promotes if the Primary disappears.

Scenario — Priya's Mumbai→Pune DR design

Primary Vault in Mumbai (10.10.5.10), DR Vault in Pune, both in identically isolated VLANs. PADR on the DR side replicates every hour. If the DR PADR service fails its heartbeat to the Primary 5 times in a row (~5 minutes), it auto-promotes Pune to active. Priya runs this as a quarterly drill: promote DR, redirect components, verify PrivateArk login, then fail back cleanly.

Figure 5 — HA/DR replication. PADR pulls metadata and Safe files from Mumbai to Pune over 1858. Five failed heartbeats trigger silent auto-failover. Same Server Key on both sides is mandatory.

PADR.ini on the DR Vault — key replication / failover parameters

# C:\Program Files (x86)\PrivateArk\PADR\Conf\PADR.ini
[Main]
PrimaryVaultIP=10.10.5.10
VaultPort=1858
NumRetries=5
ReplicateInterval=3600      ; seconds between replication cycles (1 hr)
FailoverMode=No             ; set to Yes ONLY during failover

Expected output — PADR.log after FailoverMode=Yes + service restart

[2026-05-31 03:15:00] Primary Vault unreachable after 5 retries
[2026-05-31 03:15:00] Initiating DR Vault promotion (FailoverMode=Yes)
[2026-05-31 03:15:05] DR Vault is now active. Starting PrivateArk Server.
[2026-05-31 03:15:10] Vault service started. DR Vault is now PRIMARY.

Common mistake — Server Key mismatch during HSM migration

A team migrating the Server Key to an HSM re-encrypted the DR Vault first and set ServerKey=HSM#1 there, leaving the Primary on the old file key. Replication broke instantly — the DR Vault could no longer decrypt objects encrypted with the old key. Rotations failed silently for 4 hours. The correct sequence: stop Primary, run ChangeServerKeys on Primary, update Primary's DBParm.ini, start Primary, then repeat on DR. Both sides must reference the same Server Key generation.

Pause & Predict

A Satellite/DR Vault dashboard shows "healthy", but credentials rotated in the last hour aren't replicating. The replication service is running with no errors. What's your first suspect?

NTP drift. PADR's binlog incremental replication uses timestamps to decide what's "missing." A few minutes of clock drift makes the replica request logs "from the future," and replication silently stalls while the dashboard still looks green. Compare PADR.log timestamps against NTP stratum, resync NTP, then force a full replication. Also confirm 1858 (and 5671 for Satellite RabbitMQ) are open.

🤖 Ask the AI Tutor

Tap any question — instant context-aware answer.

Deeper questions → chat.techclick.in.

The aha — why this whole architecture exists

Every layer, port and key serves one promise: a human is granted access without ever holding the credential. PSM injects it, the Vault stores it, the HSM seals it, the trail proves it, and DR keeps it surviving. That's why exposing 1858 or running an agent on the OS is so serious — it cracks the promise, not just a setting.

Teach a friend in one line: "The CyberArk Vault is a bank locker room with one chit-window (TCP 1858), one master key locked in hardware (Server Key on HSM), and a tamper-proof CCTV log — and PSM hands you the room without ever giving you the key."

Pause & Predict Priya builds the Pune DR Vault by generating a fresh Server Key on a second HSM "for extra security." She then can't get PADR replication to work. What did she get wrong?

Answer: Both Vaults must reference the same Server Key generation. The DR Vault replicates the Primary's Safe files and metadata over TCP 1858, and those are encrypted under the Primary's Server Key — a different key on the Pune side can't decrypt them, so replication breaks. A second HSM is fine, but it has to hold the same Server Key (HSM#1's key mirrored), not a new one. Separately, failover is automatic: if PADR misses ~5 heartbeats in a row (~5 minutes), Pune auto-promotes to active — which is exactly why the keys must already match before that ever happens.

The 5 mistakes that cost candidates the Vault-architecture interview

Mistake 1 — Vault on the corporate LAN

"The firewall protects it anyway." Standard requires a dedicated isolated VLAN reachable only by components. LAN placement = Critical audit finding.

Mistake 2 — Third-party software on the Vault OS

AV / SIEM agent / monitoring on the credential host breaks the standard and collides with CAVaultHarden. Use native DBParm.ini syslog instead.

Mistake 3 — PVWA co-located on the Vault box

"To save a server." Running IIS/.NET on the credential store violates code-data isolation and blocks hardening. PVWA goes on its own dedicated server.

Mistake 4 — Server Key mismatch during DR/HSM migration

Re-encrypt the Primary first, never the DR alone. Both Vaults must reference the same Server Key generation or replication breaks silently.

Mistake 5 — Recovery Key on a network file server

The Master CD private key is the last-resort decryptor. It belongs on removable media in a physical safe with dual custody — never on backup infrastructure.

Choose your next lane

Lane A — Defender (PAM-DEF) track: drill Safe creation, account onboarding, CPM rotation and PSM session retrieval. You're aiming at the 90-minute multiple-choice exam.

Lane B — Guardian (CDE-PAM) track: design Primary-DR vs Cluster vs Distributed for given RPO/RTO, HSM integration strategy, and the 120-minute lab challenge. Needs Defender + Sentry first.

Pick one and let it shape which questions below you study hardest.

Next up — CyberArk Safes, Permissions & Master Policy

You now know where credentials live and how they're sealed. Next: who can reach them. Safe design, the permission matrix (List/Use/Retrieve/Add/Update), dual control and the Master Policy — access control done right.

Next lesson →Practice PAM-DEF MCQs

CyberArk Digital Vault — EPV Architecture & the 7 Security Layers Nobody Draws

Pick where to start — jump straight to it

The 7 layers

Component map

Server Key + HSM

HA / DR replication

The interview question that trips up 70% of candidates

💡 The RBI bank-locker-room analogy

4 terms you'll be tested on before we begin

① The 7 security layers — the patented onion around the Vault

② The component map — PVWA, CPM, PSM, PSMP, PTA on TCP 1858

③ The Server Key + HSM — the three-tier key hierarchy

④ Hardening — why nothing else runs on the Vault OS

▶ Watch a credential travel the Vault protocol

⑤ HA / DR — PADR replication and silent failover

🤖 Ask the AI Tutor

The 5 mistakes that cost candidates the Vault-architecture interview

📝 Check your understanding — 10 questions, 70% to pass

Next up — CyberArk Safes, Permissions & Master Policy

Sources cited inline