How to Implement Privileged Access Management with CyberArk or BeyondTrust

CyberArk PAM consists of four core components: (1) Digital Vault: the encrypted credential store, runs as a hardened Windows Server with no internet access and restricted network connectivity; (2) Central Policy Manager (CPM): rotates passwords on a schedule or after checkout, communicates with managed systems directly; (3) Privileged Session Manager (PSM): acts as a proxy for RDP and SSH sessions, injects credentials, records sessions; (4) Password Vault Web Access (PVWA): the web portal where users request access, view sessions, and administrators manage policies. BeyondTrust's equivalent architecture: Password Safe (vault + rotation), Privileged Remote Access (session proxy + recording), and the BeyondInsight management console. In both systems, users never see plaintext credentials: they launch sessions through the PAM portal and the system handles authentication. This credential injection model is the core security control.

Start with a privileged account discovery scan before configuring anything. In CyberArk, the Discovery and Audit (DNA) tool scans Active Directory and Windows hosts to inventory: local administrator accounts, domain admin group members, service accounts, scheduled task credentials, and IIS application pool identities. In BeyondTrust, use the Smart Rules discovery feature with Active Directory connector to enumerate privileged accounts. Prioritize onboarding in this order: (1) Domain admin accounts: highest impact if compromised; (2) Local administrator accounts with identical passwords across servers (PtH attack surface); (3) Service accounts with interactive logon rights; (4) Application database credentials hard-coded in config files. Do not attempt to onboard everything at once. Start with 50-100 accounts, validate the rotation and session proxy workflow, then expand. Service account onboarding is the most complex because you must update every service, scheduled task, and application using that credential before rotating.

In CyberArk, create a Platform that defines rotation policy: password complexity (minimum 20 characters, mixed case, numbers, symbols), rotation interval (every 90 days or after each checkout), and the verification command (CyberArk attempts to authenticate with the new password after rotation to confirm success). For Windows local admin accounts, use the built-in 'WinDesktopLocalAccounts' platform. For domain service accounts, use 'WinDomain'. Configure the CPM connection component to reach the target systems: the CPM server needs network access to managed hosts on the appropriate port (445 for Windows, 22 for SSH). Create a Safe with a naming convention like SA-[Environment]-[Team] (e.g., SA-PROD-INFRA). Add the CPM as a Safe member with 'Access Safe without confirmation' enabled. Add the PSM as a member with 'Connect' permission. Add approver groups with 'Retrieve accounts' requiring dual control for high-privilege Safes.

CyberArk PSM acts as an RDP gateway: users connect to the PSM host, and PSM proxies the connection to the target server. Configure in PVWA: Administration > Configuration Options > Privileged Session Management. Set 'RecordAllConnections' to Yes. Session recordings are stored in the Vault and accessible via PVWA for audit playback. For SSH session recording, PSM for SSH (formerly known as OPM) installs as a bastion host that intercepts SSH connections. Configure AllowedTargetAddresses to restrict which hosts the PSM can proxy to: do not leave this unrestricted. In BeyondTrust Privileged Remote Access, configure the session recording storage location (on-premises storage or BeyondTrust Cloud) and enable 'Record All Sessions' in the Group Policy applied to privileged account connections. Test recording by connecting to a test account through the portal and verifying the recording appears in the session audit log within 60 seconds of session termination.

Just-in-time access eliminates standing membership in privileged groups. In CyberArk with Conjur or Privilege Cloud, configure JIT via the Access Request workflow: users submit a request for a specific account with business justification, approvers (on-call security, manager) receive email/Teams notification, approved requests grant time-limited checkout (30 min to 8 hours), and the account is automatically checked back in and rotated after the window expires. In BeyondTrust, configure Smart Rules to add users to privileged groups temporarily: create a Smart Rule with condition 'User is in [requestor group]' and action 'Add to domain group [DomainAdmins]' with a time-limited session policy. For Entra ID JIT, use Microsoft Entra Privileged Identity Management (PIM): assign eligible (not permanent) role assignments for Global Admin and privileged roles, require MFA and justification for activation, set maximum activation duration to 8 hours, and configure alerts for standing permanent assignments.

Service account onboarding requires a dependency mapping step first. Before rotating a service account password, identify every service, scheduled task, IIS app pool, COM+ application, and database connection string using that credential. PowerShell for Windows services: Get-WmiObject Win32_Service | Where-Object {$_.StartName -like '*svc_accountname*'} | Select Name, StartName, State. For scheduled tasks: Get-ScheduledTask | Where-Object {$_.Principal.UserId -like '*svc_accountname*'}. Create a rotation runbook: (1) Notify application team 48 hours before rotation; (2) CPM rotates the password in the vault; (3) PSM-based automation or a custom CPM plugin updates the service credential; (4) Services restart in dependency order; (5) Verify all dependent services are running; (6) If any service fails, CPM reconciles back to the previous password. The reconcile capability is why you should test service account rotation in a non-production environment first: a failed rotation without reconcile means manual password reset and potential outage.

CyberArk generates audit events for every vault operation. Forward to your SIEM via syslog or the CyberArk Syslog Integration. Key alert rules: (1) Direct logon to managed account bypassing PAM: if Event ID 4624 shows a privileged account logging in from a non-PSM IP, someone used the credential outside the vault (CPM should have rotated it, making this impossible unless the account was never properly onboarded); (2) Excessive checkout requests: a single user requesting 10+ accounts per hour; (3) Failed checkout attempts on high-privilege Safes; (4) CPM rotation failures: if CPM cannot rotate a credential, the password is potentially known to the last user who checked it out; (5) Session recording upload failures: gaps in session audit coverage. In BeyondTrust, configure BeyondInsight SIEM integration to forward all credential access events. Set up a weekly review of accounts where CPM reconciliation was triggered (password mismatch between vault and target system): these indicate out-of-band password changes that bypass PAM.