CyberArk Security Hardening Guide: Protecting the Vault That Protects You

A privileged access platform holds the keys to almost everything else, so an attacker who controls it no longer needs to break in anywhere. CyberArk deployments store domain admin, cloud and application credentials and broker privileged sessions. That makes the Vault, its component servers and the people who administer them tier 0 assets in their own right. This guide sets out a hardening baseline for CyberArk Privileged Access Manager Self-Hosted and Privilege Cloud as currently documented by the vendor, covering the Vault server, the PVWA, CPM and PSM components, built-in accounts, application credentials, logging and recovery. It is written for PAM engineers, identity architects and security operations teams who run or audit a CyberArk estate.

Key takeaways

• Treat the whole platform as tier 0. The Vault, PVWA, CPM, PSM and Privilege Cloud Connector hosts deserve the same isolation, patching and administrator controls as domain controllers.
• Keep the Vault out of the domain. The vendor's Digital Vault security requirements call for a dedicated, workgroup server, built from original media, with no third-party software and only the Vault port (1858 by default) open.
• Lock away the master credentials. The Master user, Administrator and the Recovery Private Key belong in physical safes in more than one location, with the Server Key held in an HSM where possible.
• The default Master Policy is a starting point, not a baseline. Dual control, exclusive access, one-time passwords and session isolation are inactive by default and need deliberate decisions per safe and platform.
• Application credentials are the soft underbelly. Credential files, provider API keys and workload authenticators need the same restriction and rotation as human admin accounts, and Vault logs must reach a SIEM over TLS.

How identity and access work in CyberArk

In a self-hosted deployment the core components are:

• Digital Vault: the encrypted store for credentials, session recordings and audit data. The vendor states that the Vault encrypts data with AES-256 using a unique key per object. Users and applications reach it over the Vault protocol on TCP 1858 by default.
• Password Vault Web Access (PVWA): the IIS-based web interface and REST API for users and administrators.
• Central Policy Manager (CPM): the service that verifies and rotates credentials on target systems, which means it holds connectivity to almost every privileged account you manage.
• Privileged Session Manager (PSM) and PSM for SSH: jump hosts that inject credentials into RDP, SSH, database and web sessions so the user never sees the password, and record the session.
• Privileged Threat Analytics (PTA): the analytics component that raises detections from Vault, session and Active Directory activity.

Access is organised into Safes (containers with per-member authorisations), platforms (rotation and connection settings per target type) and the Master Policy (organisation-wide rules with exceptions per platform).

In Privilege Cloud the Vault and PVWA are run by the vendor as a service. The customer runs Connector servers (CPM, PSM and the Secure Tunnel) on its own network, and user identity, MFA and roles are administered through the shared identity platform. The customer's hardening scope therefore shifts from the Vault host to the Connector hosts, the identity tenant and the role model. For workloads, Conjur (secrets for applications and pipelines) and Secrets Hub (synchronising secrets into cloud-native secret stores) add machine-to-machine authentication paths that must be hardened too. See the Privileged Access Management Guide for the wider PAM model.

Admin roles and privileged access

CyberArk ships with powerful predefined users and groups, each needing a deliberate owner and storage decision.

The vendor notes that all predefined users except Master are disabled after installation and must be activated before use, and that their passwords must be changed on activation.

In Privilege Cloud, the built-in roles include Privilege Cloud Administrators, Auditors, Safe Managers, Users, External Vendors, Session Risk Managers and Session Admin. Map each to a small, named identity provider group, keep Administrators to a handful of people, give auditors the Auditors role, and give SOC staff who suspend or terminate live sessions the Session Risk Managers role.

• Limit points of administration: the vendor's Security Fundamentals recommend few administrators with limited privileges, elevation through dual control or ticketing, administrative access through PSM, and MFA on every other administrative path.
• Set the Master Policy deliberately: the documented defaults are dual control inactive, exclusive check-in/check-out inactive, one-time password access inactive, reason for access active, password change every 90 days, verification every 7 days, session recording active, monitoring and isolation inactive, and audit retention 90 days. For tier 0 platforms, most organisations enable dual control, exclusive access, one-time passwords and session isolation through platform exceptions, and lengthen audit retention to meet their regulatory needs.

See the Privileged Session Management Guide.

Integrations, API tokens and service accounts

Every integration is an identity with standing access to the platform. These are the non-human identities that most often escape review.

• Component credential files: PVWA, CPM, PSM and providers authenticate to the Vault with credential files created by the CreateCredFile utility. Restrict each with the documented parameters: /AppType, /ExePath, /IpAddress, /Hostname, /OSUsername, /EntropyFile, and on Windows /DPAPIMachineProtection and /DPAPIUserProtection. The vendor notes that the address, hostname, OS user and DPAPI restrictions cannot be used in a cluster, so clustered components need compensating controls such as file system permissions and monitoring.
• Conjur workload authentication: the Conjur JWT authenticator guidelines recommend binding each workload to its host identity with token-app-property (optionally narrowed by identity-path), setting issuer and audience, using an https jwks-uri, and enforcing claims with enforced-claims. Old signing keys stay trusted in memory until Conjur servers restart, so restart after rotating keys.
• Vendor and support access: external vendor access should use the External Vendors role or a dedicated remote access path with recording, never shared Vault accounts. The BeyondTrust breach, where a stolen API key for a remote support SaaS service let attackers reset local account passwords on customer instances, is a reminder that PAM and remote access platforms are themselves attractive targets.

See the Service Account Security Guide and the Secrets Management Guide.

Logging and detection

The vendor recommends sending application and infrastructure logs to a SIEM and alerting on excessive authentication failures and on Administrator or Master logins. The Vault forwards events over syslog, configured in DBParm.ini:

PTA documents 13 detections, each with an event type ID, including Suspected credentials theft (21), Unmanaged privileged account (22), Excessive access to privileged accounts in the Vault (24), Privileged access to the Vault from irregular IP (25), Active dormant Vault user (26), Service account logged on interactively (52), Suspicious password change (55) and Suspicious multiple authentication failures to the Vault (57). Build SOC playbooks for each, starting with credential theft.

• Alert on: any Master or Administrator logon; Master Policy, platform or Vault Admins changes; tier 0 retrievals outside a ticket; PSM sessions to tier 0 targets without recording; changes to credential files.
• Watch for tampering: attackers who reach the platform try to stop logging and alerting, mapped in ATT&CK v20 as T1685 Disable or Modify Tools. Alert when a component stops sending events.

See the ITDR Guide.

Metrics that show the hardening is working

• Hardening drift: number of component servers failing a CYBRHardeningCheck test after each upgrade (target: zero).
• Standing admin count: members of Vault Admins and Privilege Cloud Administrators (target: a small fixed number with named owners).
• Restricted application credentials: percentage of credential files and provider applications with at least two binding restrictions (address, OS user, path or certificate).
• Tier 0 workflow coverage: percentage of tier 0 accounts under dual control, exclusive access and isolated, recorded sessions.
• Recovery test age: days since the last successful DR Vault failover and break-glass test.

Hardening baseline

Digital Vault server (Self-Hosted)

The vendor's Digital Vault security requirements are strict, and deviations are where real-world risk accumulates:

1. Dedicated platform: install on a dedicated physical machine, from a clean OS built from original Microsoft media rather than the corporate image.
2. Workgroup only: the Vault server must not be a member of any enterprise domain. Use unique local OS credentials.
3. No third-party software: the requirements exclude anti-virus and remote management tools.
4. Vault-managed firewall: the Vault software manages the Windows firewall exclusively and permits only the Vault port. Keep DNS disabled except where syslog to a SIEM or RADIUS authentication need it, and if so use TLS for syslog and a strong RADIUS shared secret.
5. Patching: harden with CAVaultHarden at install and apply Microsoft security updates regularly; the vendor recommends its integrated WSUS procedure.
6. Credentials: the documented requirement is a server administrator password that expires every 30 days, at least 15 characters with mixed case, a number and a special character, stored in a physical safe, with service user credentials rotated annually or when an administrator who knows them leaves.
7. Keys: store the Server Key separately from the Vault file system, ideally in an integrated HSM, keep the Recovery Private Key in a physical safe, and keep the Operator Key off the same media as the data.

Component servers: PVWA, CPM and PSM

The vendor describes PVWA, CPM and PSM as highly sensitive servers needing tier 0 security, with access limited, no non-vendor software, unneeded Windows services disabled and application allowlisting. Each component has a hardening script that must be re-run after every upgrade, using the package that matches the installed version.

The vendor's open-source CYBRHardeningCheck tool tests settings such as Vault_DomainJoined, Vault_WindowsFirewall, PVWA_IIS_SSL_TLS_Settings, PVWA_AnonymousAuthentication, CPM_EnableFIPSCryptography, RunApplocker and HardenRDS.

• Protect the administrative path to component servers: manage PVWA, CPM and PSM hosts through PSM itself or a privileged access workstation, never from general-purpose admin laptops. The LastPass breach showed how a keylogger on one engineer's home computer captured the master password to a vault holding cloud and backup keys.
• Remove single points of failure: pair PVWA and PSM behind a load balancer and keep at least one DR or Satellite Vault in a different location or region.

Rolling out the baseline safely

1. Inventory and assess: list every component host, its version, domain membership and who can log on to it. Run CYBRHardeningCheck to get a baseline.
2. Fix the break-glass first: verify the location and custody of the Master CD, Administrator password, Recovery Private Key and Server Key. Test that two named people can actually use them.
3. Harden in a pilot ring: apply component hardening and GPOs to one PSM and one CPM in a maintenance window. Confirm services start, sessions connect and no unexpected AppLocker blocks appear before moving on.
4. Tighten access: reduce Vault Admins, apply Master Policy exceptions for tier 0 platforms, and add restrictions to credential files and provider applications one application at a time, starting with read-only test calls.
5. Turn on detection: switch syslog to TLS, confirm the SIEM parses the events you alert on, and enable PTA playbooks.
6. Roll back cleanly: keep the previous GPO or INF export and a pre-change snapshot of DBParm.ini and platform settings, so a failed change can be reverted within the window. Never roll back by removing hardening from a whole OU, and re-run hardening after every upgrade as a release gate.

Small teams running Privilege Cloud can focus on identity tenant MFA, the role model, Connector hosts and application credentials. Large self-hosted estates also own the Vault host, HSM, DR Vault and PSM fleets, and need a dedicated PAM platform owner.

Common misconfigurations

• Vault joined to the domain or carrying agents: joining the Vault to Active Directory, or adding anti-virus and remote management agents, contradicts the vendor's requirements and links the Vault's fate to the domain it is meant to protect.
• Master and Administrator credentials in a digital password manager or one safe: break-glass material kept in a single location, or in a tool that itself depends on the PAM platform, fails in exactly the scenario it exists for.
• Master Policy left at defaults for tier 0: without dual control, exclusive access or isolated sessions, a single stolen PVWA login can retrieve domain admin passwords. Phishing-resistant MFA for PVWA users matters too; see the Phishing-Resistant MFA Guide.
• Unrestricted credential files and application IDs: a copied credential file with no address, OS user or DPAPI binding works from any machine (T1552.001 Credentials In Files).
• Hardening lost on upgrade: PSM and CPM hardening that is not re-run after upgrades, or a domain GPO that overrides the PSM GPO, silently reopens RDP redirection and unapproved executables.

Framework mapping

In CIS Controls v8.1 the baseline supports Control 5 (Account Management, including restricting administrator privileges to dedicated accounts), Control 6 (Access Control Management, including MFA for administrative access) and Control 8 (Audit Log Management). In ISO/IEC 27001:2022 Annex A it supports A.8.2 Privileged access rights, A.8.5 Secure authentication, A.8.9 Configuration management and A.8.15 Logging.

Practitioner checklist

• Confirm every Vault server is a dedicated workgroup host, with only the Vault port open and no third-party software.
• Verify custody of the Master CD, Administrator password, Recovery Private Key and Server Key in physical safes in more than one location, and test break-glass access.
• Reduce Vault Admins and Privilege Cloud Administrators to named individuals with MFA, and review membership quarterly.
• Apply Master Policy exceptions for tier 0 platforms: dual control, exclusive access, one-time passwords and isolated, recorded sessions.
• Run component hardening and CYBRHardeningCheck after every install and upgrade, and fix drift before go-live.
• Bind every credential file and provider application with address, OS user, path, DPAPI or certificate restrictions.
• Harden Conjur JWT authenticators with token-app-property, issuer, audience and enforced-claims.
• Send Vault syslog over TLS to a SIEM and alert on Master and Administrator logons, policy changes and PTA detections.
• Test DR Vault failover and the recovery plan at least annually.

Standards and references

• CyberArk Docs: Digital Vault Security Requirements
• CyberArk Docs: Security Fundamentals
• CyberArk Docs: PSM hardening
• CyberArk Docs: CPM hardening description
• CyberArk Docs: CreateCredFile utility
• CyberArk Docs: What detections does PTA report?
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Credentials In Files

Related NHI Mgmt Group resources: Privileged Access Management Guide · PAM Maturity Model · HashiCorp Vault Guide · Okta Security Hardening Guide