IIQ CyberArk Effective Safe-Access Bridge

A nightly job that resolves CyberArk's nested Safe group membership into flat, per-person target permissions in IdentityIQ, so PAM certifiers review the people behind a Safe instead of a group name.

Date: 2026-08-01 Type: Integration Theme: Protect + Identify Platform: SailPoint IdentityIQ Status: Idea

What it is

A read-only bridge that pulls Safe and Safe Member data from CyberArk PAS's PVWA REST API every night, walks any CyberArk group nesting it finds, and writes a flat CSV that IIQ's own PAM Application already knows how to ingest through its DelimitedFileTargetCollector. It doesn't touch provisioning and doesn't replace IIQ's native SCIM connector to CyberArk. It fills the one gap that connector leaves: turning a Safe Member entry that points at a CyberArk group into the actual list of people inside that group.

Who it serves

The IAM engineer who owns the weekly PAM certification pipeline, and the compliance analyst who has to defend that certification to a SOX auditor asking "who reviewed access to this Safe, and did they actually see who has it."

The IIQ pain it addresses

IIQ's PAM module doesn't treat Safe access as a normal entitlement. It's stored as a target permission on a PAM container, populated through Unstructured Target Data aggregation, and a certification campaign only shows it when "Include Target Permissions" is turned on in the campaign definition. That distinction is confusing enough that it shows up as a live question on the SailPoint Developer Community, where the answer confirms the mechanism and points at the "Include Target Permissions" workaround.

That workaround gets you the direct Safe Member list. It doesn't resolve a Safe Member entry that's actually a CyberArk group. CyberArk supports nesting a group inside a Safe's member list the same way Active Directory nests groups inside groups, and IIQ's standard target aggregation doesn't walk that chain. So a certifier reviewing PROD-DB-ORACLE-FINANCE sees an entry called DBA-ONCALL-EAST and either has to go look it up in CyberArk directly or, more often, just approves it. The people actually inside that group never appear as line items in the certification.

How it works

A scheduled job authenticates to CyberArk's PVWA REST API as a service account with Auditor rights, lists every Safe matching the naming convention already configured on the IIQ PAM Application, pulls each Safe's member list, and recurses into any group members up to a configured depth (default 3, tuned to this org's deepest observed CyberArk group nesting). It flattens the result into one CSV row per (identity, safe, permission level), tagging each row direct or group:<name> so the origin of the access stays visible. The CSV lands in the path IIQ's Target Aggregation task already reads for that Application. IIQ's own scheduled task picks it up an hour later, and the following Monday's PAM certification campaign runs against the resolved data.

If the service account loses read rights on a given Safe mid-run, that Safe is skipped and logged to an error report rather than failing the whole night's run; the rest of the Safes still update, and the affected Safe's target permissions in IIQ hold at their last good state until the permission issue is fixed. See sequence.md for both paths in full.

What's in this folder

• integration-spec.md — the full contract: systems, auth, endpoints, payload shapes, error model, sequencing, and operational assumptions.
• sequence.md — the happy-path call sequence plus a Safe-permission-revoked failure case.
• sample-request.json — the CyberArk PVWA Logon request the bridge sends before pulling Safe data.
• sample-response.json — the matching CyberArk session-token response.

How to run / read it

Read integration-spec.md first for the full contract, then sequence.md for how a run actually plays out, then the sample request/response pair for the one HTTP call this integration makes against CyberArk. The IIQ-side half of the contract is a scheduled file read, not an HTTP call, and its CSV row shape is documented in integration-spec.md §6.4.

Estimated impact

No hard number here without CyberArk's own Safe Member export to measure against. But the shape of the problem is worth stating plainly: at an org running roughly 600 to 900 in-scope Safes, even a small fraction of Safe Member entries pointing at CyberArk groups instead of people (the SailPoint Developer Community thread that grounds this idea describes exactly this pattern) means dozens of Safes where today's certification data shows nothing but a group name. This doesn't save certifier time; it adds real line items to review. What it removes is the blind spot a SOX auditor finds during an access-review walkthrough, when they ask a certifier to explain who they actually approved and the honest answer is "a group, I didn't check who's in it."

Why this fits an IIQ shop with 500+ connectors

PAM is one connector type among hundreds, but it's the one an auditor asks about first. A shop running CyberArk at the scale this idea assumes can't reconcile Safe-to-group membership by hand every certification cycle, and shouldn't need to touch the existing native PAM/SCIM connector's provisioning path to fix a read-side data gap. The bridge is additive and read-only by design: it bolts onto the Target Aggregation mechanism IIQ already uses for this Application, so it doesn't require reworking how the other 499 connectors in the environment are wired.

Sources

• 8.4 IdentityIQ Privileged Account Management — PAM module's Application/Target model referenced in §The IIQ pain it addresses
• 8.4 IdentityIQ Certifications and Access Reviews — "Include Target Permissions" campaign option referenced in §The IIQ pain it addresses
• 8.4 IdentityIQ Application Management — TargetSource / Unstructured Target Data aggregation model used in §How it works
• https://developer.sailpoint.com/discuss/t/cyberark-safe-certification/50827 — SailPoint Developer Community thread confirming PAM container permissions aren't traditional entitlements and describing the direct-vs-effective-access certification gap this idea closes
• https://documentation.sailpoint.com/identityiq_84/help/pam/pamiiqoverview.html — official IIQ PAM module overview confirming the SCIM-based integration model and the division of labor between IIQ and the PAM vendor