Integrate with CyberArk

Follow this step-by-step guide to allow SlashID to monitor and protect your CyberArk deployment. The integration inventories your privileged credentials — which accounts are vaulted, who can reach each Safe, and which of them CyberArk is actually rotating rather than merely storing.

One CyberArk connection covers two products:

• Privilege Cloud / PAM Self-Hosted (the Vault) — users, groups, Safes, accounts, account groups, platforms, application identities (AAM/AIM AppIDs), discovered accounts, and LDAP directory integrations.
• CyberArk Identity — users, roles, applications, and policy sets. Available on SaaS deployments only.

SlashID never reads your secrets

The integration inventories credentials; it does not retrieve them. SlashID never calls Password/Retrieve, Secret/Retrieve, or the legacy Credentials endpoint. This is not only a privacy position: on platforms configured for one-time passwords or exclusive access, a retrieve is a checkout and triggers a CPM rotation of a live credential. Because SlashID never reads a secret, it also never stores a hash or a truncated value for a CyberArk account.

Before starting

Before starting, ensure you have:

• The ability to create a service user with read-only authorizations in your CyberArk deployment.
• For Privilege Cloud: your tenant subdomain, and permission to create an ISPSS service user in the Identity Administration portal.
• For PAM Self-Hosted: the HTTPS URL of your PVWA instance, and which logon module the service user authenticates against (CyberArk, LDAP, or RADIUS).

IP allowlisting

If your endpoint or tenant restricts traffic by source IP, allow connections from SlashID's egress IPs published at https://cdn.slashid.com/egress.json. The list is global and stable; the syncToken field changes whenever the IPs change, so you can use it to detect drift.

The file follows the JAFAR draft format (A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients), the same convention major cloud providers use to publish their IP ranges.

Self-hosted PVWA must be publicly reachable

SlashID's connection scanner runs in the cloud and has no route into a private network. Its outbound transport also refuses to dial private, loopback, and link-local addresses. A PVWA that is only reachable inside your corporate network cannot be integrated — expose it behind a public HTTPS endpoint restricted to the egress IPs above, or use Privilege Cloud.

Choose your deployment topology

The two topologies take different credentials and produce different halves of the graph. Pick the one that matches your deployment:

	Privilege Cloud (SaaS)	PAM Self-Hosted
Credentials	Tenant subdomain, client ID, client secret	PVWA base URL, username, password, authentication method
Vault plane (users, Safes, accounts, platforms)	✅	✅
CyberArk Identity plane (Identity users, roles, apps, policies)	✅	❌ — the Identity plane does not exist outside ISPSS
Audit event stream	✅ (optional)	❌ — self-hosted ships audit over syslog, which SlashID does not ingest

Step 1 (SaaS): Create an ISPSS service user

Skip to Step 2 if you run PAM Self-Hosted.

1. In the CyberArk Identity Administration portal, go to Settings → Users and create a new service user (an OAuth confidential client), for example slashid-integration@<your-tenant>.
2. Note the generated client ID and client secret.
3. Add the user to the Privilege Cloud Users role so it can call the Privilege Cloud REST API, then grant the Vault authorizations in Step 3.

danger

Store the client secret securely — CyberArk displays it once. You will paste it into the SlashID Console in Step 4.

Your subdomain is the acme in https://acme.privilegecloud.cyberark.cloud. Enter just that word in the SlashID Console, not the full URL — SlashID derives the ISPSS token endpoint and the audit endpoint from it.

Step 2 (Self-Hosted): Create a PVWA service user

Skip this step if you run Privilege Cloud.

1. In the PVWA, go to Administration → User Management → Users → Add User.
2. Create a dedicated user (e.g. slashid_integration) and choose the authentication method it will use — CyberArk for a Vault-local password, LDAP for a directory-projected user, or RADIUS.
3. Grant the Vault authorizations in Step 3.

Step 3: Grant read-only authorizations

The service user needs list and read metadata authorizations only. It never needs "Retrieve accounts", "Use accounts", or any write authorization.

Required

The sync cannot run without these.

Authorization / access	What SlashID syncs
Audit users (Vault-level)	Vault users and groups
Membership of the Safes you want in scope, with List accounts	Safes, accounts, and Safe membership — the access graph

Grant Safe membership with List accounts and View Safe Members on every Safe you want covered. Safes the service user is not a member of are invisible to the API and simply do not appear.

Recommended

The sync degrades gracefully without these — each returns a warning and an empty result rather than failing the connection — but they unlock significant coverage.

Authorization / access	What SlashID syncs	What is lost without it
Read access to platforms	Platform policies	Rotation, session-isolation, dual-control, and one-time-password posture for every account
Read access to account groups	Account groups and their members	The shared-secret relationship: which accounts CPM keeps on the same password
Vault Admins membership	Discovered accounts	The inventory of privileged accounts discovery found but nobody onboarded
Manage Users or equivalent read on AAM applications	AAM/AIM application identities (AppIDs) and their authentication restrictions	Which non-human callers can consume vaulted credentials, and whether they are authenticated
Read access to LDAP directories	Directory integrations	Which Vault users and groups are projected from a corporate directory rather than local
CyberArk Identity read access (SaaS)	Identity users, roles, applications, and policy sets	The entire Identity plane, and the link from an Identity user to their Vault user

note

SlashID issues read-only requests throughout. No CyberArk object is created, updated, or deleted, and no secret is ever retrieved.

Step 4: Create your CyberArk ↔ SlashID Integration

Open the SlashID Console integrations page and create a new CyberArk connection.

SlashID Console field	Description	Example
Name of the connection	Arbitrary name for this connection	CyberArk Production
Authoritative status	Whether CyberArk identities are the primary source of truth when reconciling identities across providers	Secondary
Deployment	Privilege Cloud (SaaS) or PAM Self-Hosted	Privilege Cloud (SaaS)
Tenant subdomain	(SaaS) The subdomain only, not a full URL	acme
Service user client ID	(SaaS) The ISPSS service user's client ID	slashid-integration@acme
Service user client secret	(SaaS) The ISPSS service user's secret	—
PVWA base URL	(Self-Hosted) The HTTPS URL of your PVWA	https://pvwa.example.com
Username	(Self-Hosted) The PVWA service user	slashid_integration
Password	(Self-Hosted) The PVWA service user's password	—
Authentication method	(Self-Hosted) Which PVWA logon module to authenticate against	CyberArk
Audit stream API key	Optional, SaaS only. Enables the SIEM audit event stream	—

Optional: enable the audit event stream

Supplying an audit stream API key turns on near-real-time ingestion of CyberArk's SIEM audit events — privileged retrievals, Safe membership changes, CPM failures, and administrative actions — alongside the periodic sync.

The key is optional in the strict sense: without it the sync still runs in full, and the event poller reports no events rather than failing the connection. The stream is unavailable on self-hosted deployments, which emit audit over syslog.

note

CyberArk's audit service retains roughly seven days of events. SlashID resumes from its last watermark on every sync; if a connection is paused for longer than the retention window, the events in the gap are not recoverable from the API.

Verification

Once connected, SlashID runs a preflight check that authenticates and confirms each authorization independently, reporting the optional ones as skipped rather than failed. After the first sync completes you will see:

• CyberArk Vault users and Vault groups, and — on SaaS — Identity users and Identity roles, in the Identities view.
• Safes, platforms, account groups, discovered accounts, directories, and Identity policies in the Resources view.
• Vaulted accounts as credentials, each linked to its Safe and governed platform.
• Safe membership as access edges carrying the exact CyberArk permission names, so you can see who holds ManageSafe or RetrieveAccounts on which Safe.

Troubleshooting

Authentication failed : For SaaS, confirm the subdomain is the bare tenant name rather than a URL, and that the client ID and secret belong to a service user in the Privilege Cloud Users role. For self-hosted, confirm the selected authentication method matches how the user is defined in the Vault — a CyberArk user cannot log on through the LDAP module.

403 Forbidden on users or Safes : The service user is missing Audit users, or is not a member of any Safe. The preflight check names the specific call that was refused.

No accounts appear, but Safes do : The service user is a member of the Safes but lacks List accounts on them. Safe membership alone does not imply visibility of the accounts inside, especially when object-level access control (OLAC) is enabled on the Safe.

Discovered accounts are missing : /DiscoveredAccounts requires Vault Admins membership. Without it the sync succeeds and reports the endpoint as unavailable.

AAM applications are missing : The AIM/Credential Provider component is not licensed on this deployment, or the service user cannot read application definitions. This is a soft failure; the rest of the sync is unaffected.

No Identity users, roles, or applications : The Identity plane exists only on Privilege Cloud. On a self-hosted connection SlashID skips it deliberately.

Connection fails with an unreachable-host error (self-hosted) : The PVWA URL resolves to a private, loopback, or link-local address. SlashID's scanner refuses to dial those. Expose the PVWA on a publicly resolvable HTTPS endpoint restricted to the egress IPs listed above.