Skip to main content

​
About CyberArk EPM

The CyberArk EPM integration connects Serval to your CyberArk Endpoint Privilege Manager SaaS tenant through its REST API. It powers endpoint privilege workflows: listing sets, computers, and policies; searching endpoint events (elevation requests, blocked launches, threat detections); pulling the administrator audit trail; offboarding stale endpoint records; and granting time-boxed just-in-time (JIT) local-admin elevation with a recorded justification. EPM holds no vaulted secrets. Unlike CyberArk PAM, there is no credential vault behind this API - the surface is endpoint management and security telemetry only, so there is no path through Serval (or through EPM itself) to any stored credential value. The sensitive write is policy creation: a JIT elevation policy makes a user a local administrator, which is why write workflows default to installer approval. Authentication: Username and password for a dedicated EPM service account. Serval signs in against your regional EPM login host, caches the short-lived session token, and attaches it to every proxied request - workflow code never sees the password or the token. Data sync: On demand only. There is no background sync of computers, policies, or events - Serval calls your tenant only when a workflow or health check runs.

​
What the CyberArk EPM integration enables

​
Prerequisites

Before connecting, make sure your tenant meets these requirements:
1

Know your regional EPM login host

Serval signs in against the regional dispatcher for your tenant. Pick the one that matches where your EPM tenant is hosted:After sign-in, EPM reports back your tenant’s real API host (the ManagerURL, e.g. na111.epm.cyberark.com); Serval discovers and stores it automatically - you never enter it.
2

Create a DEDICATED EPM service user for Serval

Create an EPM user that only Serval uses. This is not just least-privilege hygiene: EPM can invalidate an existing session when the same user signs in again, so an account shared with a person or another tool causes intermittent authentication failures on both sides. One integration connection per API user.
3

Grant the service user only what your workflows need

Scope the account to the sets Serval should manage. Read workflows need set/computer/policy/event visibility; the offboarding and JIT elevation workflows additionally need endpoint-management and policy-creation rights.

​
Connect in Serval

1

Select CyberArk EPM

In Serval, open your team’s integrations page and select CyberArk EPM.
2

Choose the EPM Login Host (required)

Pick your tenant’s regional login host from the dropdown (see the table above). A wrong region fails at sign-in.
3

Enter the Username and Password (required)

Enter the dedicated service account’s username and password. Serval stores the password encrypted and uses it only inside the proxy to authenticate.
4

Optionally set the Application ID

A free-form identifier recorded in EPM’s admin audit for every action Serval performs. Defaults to Serval - change it only if your audit conventions require a specific value.
5

Save and verify

Submit the form. Serval performs a live sign-in immediately: it validates the credentials, rejects an expired password, and discovers your tenant’s API host. Then the health checks run (below).
Session behavior: EPM session tokens expire on an idle timeout your tenant controls (“Timeout for inactive session” under Administration > Account Configuration) - there is no documented default and no refresh endpoint. Serval caches each token for a conservative 4 minutes and signs in again as needed, so the service account authenticates regularly during active workflow use.

​
Verifying the connection

Four health checks run after you connect:
  1. Test Connection - signs in and lists sets. Failure usually means the wrong region was selected, the credentials are wrong, the service account’s password is expired (reset it in EPM and update the integration), or the account is shared and another sign-in invalidated Serval’s session.
  2. List Sets - confirms the service account can see at least the sets Serval should manage. Zero visible sets means the account has no set access yet.
  3. List Computers - confirms endpoint-read access on the first visible set. Reports clearly (rather than erroring) if no sets are visible.
  4. List Policies - confirms policy-read access on the first visible set.
If Test Connection fails outright, fix the region and credentials first. If it passes but a later check fails, authentication is fine and the service account is just missing EPM permissions - adjust its set access and roles.

​
Installable workflows

The integration ships with installable workflows (names indicative):
Write workflows default to installer approval: when a help-desk conversation or automation reaches a write step, the workflow pauses for sign-off from the installing team before the change is made in EPM.

​
Gotchas and troubleshooting

EPM is an endpoint privilege manager, not a credential vault: nothing in this integration (or in EPM’s own API) reads stored credential values. The sensitive operation is instead policy creation - a JIT elevation policy grants local-admin rights - which is why it requires installer approval.
EPM can invalidate an existing session when the same user signs in again. If a person or another tool shares Serval’s account, each sign-in can kill the other side’s session, which shows up as intermittent 401s on both sides. Create one EPM user exclusively for Serval, and one per integration connection.
EPM reports an expired password at sign-in (IsPasswordExpired), and Serval treats it as a hard failure - connecting and every later sign-in will fail until an EPM admin resets the password and you update the integration’s credentials.
Serval learns your tenant’s real API host (the ManagerURL) from the sign-in response and pins it. In the rare case CyberArk moves your tenant to a different host, workflows fail with a clear “reconnect the integration” error - edit and re-save the integration’s settings to re-discover the new host. Serval never silently switches hosts.
The token lifetime follows your tenant’s “Timeout for inactive session” setting (Administration > Account Configuration). Serval’s 4-minute cache is deliberately conservative so it works under any plausible setting; you do not need to tune anything, but very short tenant timeouts increase sign-in frequency.
The policy APIs allow 10 calls per 2 minutes on EPM 25.6.x (30 per minute on 26.x) - avoid tight polling loops over policies. Event and audit searches return at most 1000 records per page; Serval’s event workflow additionally caps results at 100 aggregated records per run.
The integration works on both EPM generations without any version selection: authentication is identical, and API paths omit the optional version segment so each call binds to your tenant server’s own version. All built-in workflows and health checks use only APIs documented on both generations (the classic Computers listing and the Policies/Server family). The modern Endpoints APIs - available only on 26.x tenants migrated to the Central Idira console - are exposed for custom workflows on migrated tenants, and are annotated as such in the API reference.
The policy-creation body shape (field names, duration units, accepted policy types) varies between EPM versions. Test Grant EPM JIT Elevation against your tenant - ideally on a test computer - before relying on it in production, and check the created policy in the EPM console matches your expectations.
Need help? Contact support@serval.com for assistance with your CyberArk EPM integration.