Vaulting passwords is where most PAM programs start, and plenty of them stop there. That leaves most of the value, and most of the protection, on the table. Here are five things your PAM tool should be doing on top of just storing passwords.
What's inside
Discovery scans find privileged accounts and show you where each one is used across your environment.
A scan against Active Directory, your Windows and Linux servers, and your cloud platforms can reveal local admin accounts, members of privileged groups (even ones reached through nested groups), and accounts with admin-level rights that don't appear in any admin group. Knowing where each account lives is what lets you build the dependency list you need before changing a single password.
New servers, vendor accounts, new users, and one-off service accounts keep appearing and need vaulting as part of daily operations. Keep running scheduled discovery scans against each environment so nothing privileged slips past unmanaged.
Windows services
Service logons nobody documented
Scheduled tasks
Jobs still using the old credential
IIS app pools
Application identities tied to accounts
The dependency list
Built before you change any password
Most teams leave rotation off for service accounts, because the last time one was changed, an app went down.
That outage usually happens because the password was also stored in Windows services, scheduled tasks, or IIS app pools nobody knew about. Those are the dependencies that were never found, so they were never updated.
Once those dependencies are discovered and linked to the account, the CPM (Central Policy Manager) pushes the new password to every one of them during rotation, and restarts the affected services if needed. Rotation stops being the thing that breaks your weekend.
Rotation breaks an app
The password is also stored in services, tasks, or app pools nobody knew about.
Dependencies found & linked
Each one is tied back to the account in the vault.
CPM updates each one
New password pushed everywhere it's used; services restarted if needed.
With session isolation through PSM, credentials never touch the user's machine, and every privileged session is recorded.
When you hand a user a password, they usually copy it. That puts it in their clipboard, where malware or a keylogger can grab it. Their login can also leave credential hashes behind for an attacker to reuse later. PSM injects the credential on the admin's behalf, so none of that ever lands on their machine.
In more mature environments, firewall rules or Group Policy restrict RDP and SSH so servers only accept those connections from PSM. Even if an attacker compromised a workstation or grabbed a password, they can't go straight to a server. They'd have to pass through PSM: MFA, any required approvals, and a recorded session.
The clipboard problem
Copying a password puts it where malware waits.
Leftover hashes
Logins can leave reusable credential hashes behind.
Injected, not typed
PSM supplies the credential on the admin's behalf.
One way in
Servers accept RDP/SSH only from PSM: MFA, approvals, recording.
Vaulting a domain admin password protects the password, but the account behind it still holds full permissions around the clock.
If an attacker pulls that account's hash off a server an admin logged into last week, they can use it whenever they like. Standing access is the part that keeps working against you long after the password is safely stored.
With Just-in-Time access, the account only holds elevated permissions during an approved window (two hours for a patching task, for example), and those permissions are removed the moment the window closes. A stolen credential used outside that window has nothing to give.
Vaulted, but still admin
The password is protected; the account still has full permissions 24/7.
With JIT access
Elevated permissions exist only during an approved window.
Outside the window
A stolen credential has no elevated permissions to hand over.
The vault knows who checked out which account, and when. That's a baseline you can compare against.
CyberArk's Privileged Threat Analytics (PTA) alerts you when activity doesn't line up. Think: a domain admin logging into a server without checking the password out of the vault, a DCSync attempt pulling password hashes from a domain controller, or an account being used from a machine it's never touched before.
For some of these events, PTA responds on its own, rotating the password or suspending the session. That matters most when the alert comes in during off hours and nobody is awake to act on it.
Out-of-band access
A domain admin logs in without checking the password out.
DCSync attempt
Pulling password hashes from a domain controller.
New machine
An account used from a device it's never been used on.
Put them together and the gaps close: you know where every privileged account lives, rotation stops breaking things, and no credential stands around waiting to be stolen.
Your PAM tool shouldn't be an expensive password manager. Depending on your license, session isolation and recording, discovery, threat analytics, and dependency-aware rotation may already be included. For anything that isn't, weigh the cost against the risk it would reduce in your environment. If you'd like help sorting out what you already own and what's worth adding, reach out. We'll build a plan to get it all working for you.