CyberArk Vault Admin Guide: Onboard an Account, Rotate It and Record the Session

Quick Answer: A CyberArk vault admin’s core loop is this: design the safe and its membership, attach the right platform to the account, onboard the credential so the Central Policy Manager owns it, prove rotation with change and verify, know how to recover with reconcile, route interactive access through Privileged Session Manager for recording, and keep the Master Policy tight enough to satisfy an auditor without breaking the application. This tutorial walks that loop end to end in the order you would actually do it on a non-production vault.

The CyberArk Vault Admin Object Model: What Each Thing Owns

Half of all vault administration mistakes come from confusing two objects that look similar on screen. It is worth ten minutes to get the model straight, because everything later depends on it.

With that model in place, the tutorial below is deliberately sequenced the way a careful admin does it: safe first, then platform, then the account, then rotation, then session access, then policy. Doing it in another order is how people end up with 400 accounts in a default safe nobody owns.

Step 1: Design the Safe Before You Touch an Account

Safes are the security boundary, so design them deliberately rather than by accident. The pattern that survives audits is one safe per application or per administrative domain, not one safe per team and definitely not a shared “misc” safe. Inside each safe, decide three membership groups up front: an owners group who administer the safe itself, a users group who may consume the credentials, and the Password Manager user — the identity CPM acts as, which needs the rights to change and update account content.

The permissions you will grant as safe membership, and what each one actually means, are worth memorising because they appear in every audit conversation:

The two rules that keep you out of trouble: never grant “retrieve accounts” to a users group by default — use, subject to dual control, is usually enough; and never let the users group manage safe members, or your access model is decorative.

Step 2: Pick the Platform, Because It Decides Everything Later

The platform attached to an account is the policy CPM follows: password composition, rotation and verification behaviour, and the reconciliation mechanism. Choose it before onboarding, not after. A Windows domain service account, a Unix SSH account, a database administrative user, a network device enable password and a local Windows administrator each behave differently on their target systems, and each needs a platform whose rules the target will accept.

Two practical points. Platform settings refine the Master Policy but cannot contradict it, so if your Master Policy forbids something, no amount of platform tuning will fix it — you change the narrowest thing that solves the problem. And where a legacy application genuinely cannot tolerate rotation, do not quietly stop rotating: onboard it with an agreed exception, a documented owner and a review date. Silent exceptions are what audit findings are made of.

Step 3: Onboard the Account

Onboarding is where the abstract becomes real. In prose, the sequence on a non-production vault looks like this:

1. Create the account record in the correct safe, with the target system’s address, the username, and the platform you chose. At this stage nothing has been discovered or changed on the target.
2. Establish the initial password. Two routes: import the existing password (for an account someone else already set), or let the platform’s provisioning mechanism create it. Importing is the common path for brownfield estates, and it is the moment you must be certain the value you import is actually the live one.
3. Confirm CPM association. Verify the account shows the platform and the Password Manager user, and that the safe membership gives that user the update and change rights it needs. Most “onboarding failed” tickets are a missing membership rather than a product fault.
4. Run a change, then a verify. Force a rotation and then a verification, and confirm both succeed in the account’s history. Only after this passes should the account be considered under management — an onboarded account that has never successfully rotated is an untested assumption.
5. Hand the consumer its access. Either the users group gets “use” rights, or the application retrieves the credential at runtime from the Central Credential Provider with its application identity — IP allow-listing at minimum, plus certificate-based authentication on serious estates.

Step 4: Rotation — Change, Verify, Reconcile

These three operations are the heart of the job, and the part interviewers and incidents both test you on. Change replaces the password: a new value is set on the target and stored in the vault. Verify checks that the stored value still matches what is live, and changes nothing — it is how you detect drift. Reconcile recovers control: used when the vault’s copy is not authoritative, it uses a privileged reconciliation credential to reset the password on the target and bring the account back under management. The lifecycle looks like this:

ONBOARD (import or create)
   |
   v
+------------------- CPM owns the account --------------------+
|                                                              |
|  CHANGE ---- new password set on target, stored in vault     |
|     |                                                        |
|     +--> VERIFY ---- vault copy == live?  yes: healthy       |
|     |                              no: drift detected        |
|     |                                                        |
|  [scheduled: change on expiry, verify on interval]           |
|                                                              |
|  RECONCILE -- vault does NOT know the live password          |
|               (out-of-band change, DR restore, app rotated   |
|               it too) -> reset via reconciliation account,   |
|               then the next scheduled CHANGE works again     |
+--------------------------------------------------------------+

Interactive human access:  PSM injects the credential -> session recorded
Application access:        CCP brokers retrieval by AppID/safe/object

The operational habit worth building: read the failure from the component log rather than the ticket. A failed change tells you the reason — target unreachable, password rejected by policy, account locked — and the reason decides whether you fix membership, adjust the platform, or reconcile.

Step 5: Route Humans Through PSM

With rotation working, the next control is how people use the credential. A PSM connection means the administrator never sees the password: they request access through the portal, the session is proxied — RDP, SSH and others depending on platform — and the credential is injected at connection time. The session is recorded and can carry a time limit, an approval step and an observation capability.

Three things to configure and then test rather than assume: that the platform is actually set to enforce proxied sessions rather than merely allow them; that recordings are written to the vault and can be replayed in the player by someone who was not in the session; and that the recording retention matches what your auditors promised. A PSM deployment that records beautifully and retains for thirty days when the policy says a year is worse than no deployment, because it fails on the day it is needed.

Step 6: Read the Master Policy Out Loud and Change It Deliberately

The last step is the one juniors avoid, and the one seniors live in. The Master Policy sets the estate-wide baseline; the areas you will actually touch early in a PAM role:

The discipline is this: change the narrowest object that solves the problem (account, then platform, then safe), and touch the Master Policy only when the requirement is estate-wide. A Master Policy relaxation travels to every account you have, and that is exactly how an exception for one broken application becomes an audit finding six months later.

What Actually Happens at Work: The Reconcile That Nobody Had Practised

A Chennai shared-services team onboarded 1,200 Unix service accounts over a quarter, in a hurry, with rotation verified on a sample of about fifty. Everything ran green for two months. Then a storage migration briefly orphaned a home directory, and an account’s password on the target diverged from the vault — the classic drift condition. The scheduled change failed at 02:10. So did the retry. The ticket went to the on-call vault admin, who was three weeks into the job.

He knew the vocabulary. What he had never done — because the lab had only ever taught him the happy path — was run a reconcile on an account whose target he had not touched before, with a platform whose reconciliation account nobody could find documentation for. He spent forty minutes restarting CPM components, which of course changed nothing, because the failure was at the target, not in the vault. The application using that account began failing logins at 02:40.

Relief came from an engineer on the next shift who had done this before: identify the reconciliation account for the platform, use it to reset the target password, run reconcile to bring the account back under management, force a change, verify, done — about twelve minutes of work once you have done it once. The process fixes were the real story: every onboarded account now needed a proven reconcile before it counted as onboarded, and the runbook carried the exact steps with the platform’s reconciliation credential location filled in rather than described.

If you take one thing from this tutorial, make it that practice: on your lab vault, deliberately change a password out of band, watch the verify fail, and reconcile it back yourself. The happy path is what the certification teaches; the recovery path is what the job is.

Honest Trade-Offs: Where Vault Administration Gets Unpleasant

Three things no tutorial can soften. Dual control will lock you out at the worst moment — plan a pre-approved emergency path in daylight, with logging and post-incident review, rather than improvising at midnight. Recording consumes real storage, and estates that enable keystroke-level observation everywhere discover the cost at the first quarterly bill; scope it to the highest-risk platforms. Onboarding is never finished — discovery is continuous, because the estate grows new privileged accounts faster than most teams decommission old ones, and an exception report with a named owner per exception is the only thing that keeps it honest.

Pay for the people who can do all this comfortably sits at ₹9–18 LPA mid-level and ₹18–32 LPA senior in India for 2026, with architects above that; the bands these sit against are in our IAM salary India 2026 guide. If you are coming from an IAM or governance background rather than systems administration, the identity governance and administration guide covers the vocabulary you will be expected to converse in, and the cloud certification ROI ranking covers how to weigh the CCA fee against other credentials while you are building the skill.

Training Resources

Everything above is a lab exercise in SkilBrill CyberArk Training — safe design and membership, platform selection, onboarding, CPM rotation and recovery, PSM session management and Master Policy tuning — with deliberate failure-and-recovery drills, career support and placement assistance.

FAQ

How do you onboard an account in the CyberArk vault?

Create the account record in the correct safe with its address, username and platform; establish the initial password by import or provisioning; confirm the Password Manager user has the rights it needs; then force a change and a verify to prove CPM owns it before anyone consumes it.

What is the difference between change, verify and reconcile?

Change replaces the password on the target and stores the new value. Verify checks that the stored value still matches the live one and changes nothing. Reconcile recovers control of an account whose password the vault does not know, using a privileged reconciliation credential to reset it on the target.

Why is a safe the security boundary in CyberArk?

Because permissions are granted on the safe, not the account: every safe member’s rights apply to all accounts inside that safe. An account with a perfect password policy is still exposed if it sits in a safe with a broad users group, which is why safe design matters more than account settings.

How does PSM record a privileged session?

The administrator connects through the portal without ever seeing the credential; PSM proxies the connection, injects the password at connection time, and writes a recording of the session to the vault, which can be replayed later, time-limited and observed live where configured.

What should I check first when a password change fails?

The component log for the exact failure reason, then in order: whether the target account is locked, whether the safe membership grants the Password Manager user the rights it needs, whether the platform’s password rules are something the target rejects, and whether the account’s address and platform are correct. If the vault’s copy has drifted, reconcile rather than forcing another change.

Written by SkilBrill Training Institute

October 17, 2026 · 13 min read