> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CyberArk EPM

> Connect Serval to your CyberArk Endpoint Privilege Manager (EPM) SaaS tenant for endpoint visibility and remediation workflows - sets, computers, policies, endpoint events, admin audit, endpoint offboarding, and just-in-time elevation.

## 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

| Capability                  | Description                                                                                                              |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Set and endpoint visibility | List EPM sets and the computers in each set - names, platforms, agent versions, and status.                              |
| Policy visibility           | List a set's policies and their activation state before making changes.                                                  |
| Endpoint event search       | Search aggregated endpoint events (elevations, blocks, threat detections) over a recent window.                          |
| Admin audit                 | Pull the tenant-wide administrator audit trail, including everything Serval itself performs.                             |
| Endpoint offboarding        | Delete stale or decommissioned endpoint records from a set.                                                              |
| JIT elevation               | Create a time-boxed policy that makes one user a local administrator on one computer, with auditing and a justification. |

## Prerequisites

Before connecting, make sure your tenant meets these requirements:

<Steps>
  <Step title="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:

    | Region        | Login host               |
    | ------------- | ------------------------ |
    | United States | `login.epm.cyberark.com` |
    | Europe        | `eu.epm.cyberark.com`    |
    | India         | `in.epm.cyberark.com`    |
    | Australia     | `au.epm.cyberark.com`    |
    | Canada        | `ca.epm.cyberark.com`    |
    | Japan         | `jp.epm.cyberark.com`    |

    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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

## Connect in Serval

<Steps>
  <Step title="Select CyberArk EPM">
    In Serval, open your team's integrations page and select **CyberArk EPM**.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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).
  </Step>
</Steps>

<Note>
  **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.
</Note>

## 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.

<Tip>
  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.
</Tip>

## Installable workflows

The integration ships with installable workflows (names indicative):

| Workflow                | Type  |
| ----------------------- | ----- |
| List EPM Sets           | Read  |
| Search EPM Computers    | Read  |
| List EPM Policies       | Read  |
| Search EPM Events       | Read  |
| Get EPM Admin Audit     | Read  |
| Delete EPM Endpoint     | Write |
| Grant EPM JIT Elevation | Write |

<Note>
  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.
</Note>

## Gotchas and troubleshooting

<AccordionGroup>
  <Accordion title="EPM has no vaulted secrets - by design and by product">
    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.
  </Accordion>

  <Accordion title="Use a dedicated service user - shared accounts cause flaky auth">
    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.
  </Accordion>

  <Accordion title="Expired service-account password">
    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.
  </Accordion>

  <Accordion title="Your tenant's API host is discovered, not configured">
    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.
  </Accordion>

  <Accordion title="Session idle timeout is tenant-configurable">
    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.
  </Accordion>

  <Accordion title="Rate limits on policy and event APIs">
    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.
  </Accordion>

  <Accordion title="Version compatibility (25.6.x vs the 26.x Central Idira console)">
    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.
  </Accordion>

  <Accordion title="Verify the JIT elevation workflow against your tenant version">
    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.
  </Accordion>
</AccordionGroup>

***

Need help? Contact **[support@serval.com](mailto:support@serval.com)** for assistance with your CyberArk EPM integration.