wif.tax

CyberArk (Palo Alto Networks)

C Identity Security Platform APIs (Privilege Cloud, Secrets Hub, shared services)

Automation against CyberArk's platform APIs (Privilege Cloud, Secrets Hub, Identity) runs as an Identity service user that trades its username and password, used as an OAuth client secret, for a short-lived token; no federation path is documented. Passwords can be set to never expire. Going out, Secrets Hub syncs into AWS, Azure, GCP and HashiCorp Vault with no stored secret.

Docs: docs.cyberark.com · Checked 2026-10-22 · source YAML · dispute via PR

Inbound C

How a workload running anywhere authenticates to this product.

An Identity service user flagged as an OAuth confidential client calls the tenant's OAuth2 client-credentials endpoint with its login name and password as client_id and client_secret, and gets a short-lived bearer token accepted by the platform service APIs (Privilege Cloud, Secrets Hub, SIA, Identity). The official SDK offers only Identity user or service-user authentication.

Graded on the platform service APIs, which every automation of Privilege Cloud, Secrets Hub or Identity must use. The token is short-lived but bootstrapped from a long-lived service-user password acting as a client secret (static root, C). The detailed token page on api-docs.cyberark.com redirects through a login flow and could not be saved; its search snippet shows a POST to /oauth2/platformtoken with grant_type=client_credentials and the service user's login and password, consistent with the Identity docs quoted. Identity's "Federate with an external IdP" pages (SAML, OIDC) are for human sign-in; no token exchange, JWT bearer or cloud workload identity path for API clients is documented. The Secrets Manager SaaS API is the exception: it federates any JWT issuer (see `cyberark-conjur-cloud`), but its tokens do not reach these platform APIs. Moves to A or B if the OAuth server accepts a federated JWT (RFC 7523 or 8693) from an external issuer for service users.

Outbound Arequires Secrets Hub (separately licensed platform service)

How this product reaches into your cloud, repos, or other SaaS.

Secrets Hub syncs PAM secrets into AWS Secrets Manager by assuming an IAM role you create that trusts a Secrets Hub role with an External ID, into Azure Key Vault through a federated credential on your Entra app (issuer is your Identity tenant), into GCP Secret Manager through Workload Identity Federation from its AWS role, and into HashiCorp Vault through Vault's JWT auth method trusting the same issuer.

Checked every Secrets Hub target store (AWS, Azure, GCP, HashiCorp Vault): all four are keyless. Azure stores created earlier with an app client secret can be migrated, and the script tells you to delete the old secret; HashiCorp setup needs a Vault token once, to configure the JWT role. Not graded as reach-ins: Privilege Cloud's CPM and PSM, which manage target-account passwords and keys as the product's core vaulting job and run through connectors you host, and Connect Cloud Environments onboarding for Secure Cloud Access, which was not inspected.

Hygiene for any static credential the product still issues

✗ Expiry enforceable
A tenant password policy defaults to a 365-day maximum age, but it can be set to 0 and each user can be marked "Password Never Expires", so no policy forces an expiry on a service user (precedent: changeable default is not enforced expiry). Whether an expired password blocks client_credentials was not publicly verifiable.
  • docs.cyberark.com checked 2026-10-22
    “Enter a date when the account expires. If you do not set a date, the account does not expire.”
  • docs.cyberark.com checked 2026-10-22
    “True, t, yes, y — Password never expires”
  • docs.cyberark.com checked 2026-10-22
    “You can use 0 (zero) if you do not want to specify a password expiration period.”
✓ Rotation via API
Service users are created and disabled through the Identity CDirectoryService API, and Privilege Cloud's Identity Service User plugin can verify, change and reconcile their passwords on a schedule.
  • docs.cyberark.com checked 2026-10-22
    “This topic describes how to configure the credential management plugin for managing access credentials to Identity service users from the Privilege Cloud Portal.”
  • docs.cyberark.com checked 2026-10-22
    “/CDirectoryService/SetUserState - Set the state of a user to Locked, Disabled, or Expired.”
✓ Scoped keys
A service user is a purpose-built machine principal that gets only the roles and service permissions you assign it.
  • docs.cyberark.com checked 2026-10-22
    “This user has least privilege access permissions, is not assigned MFA policies, and cannot access Idira IdentityIdentity Administration.”
✗ Last-used visible
No last-used or last-token-issued field for service users is documented on the public Identity or platform pages; not publicly verifiable, so graded as a fail.
✗ Leak revocation
CyberArk does not appear in GitHub's supported secret-scanning patterns table. A service user's credential is an ordinary password, so it has no detectable format anyway.

Notes

Split from `cyberark-conjur-cloud` because machine auth differs materially: Secrets Manager SaaS federates any JWT issuer, while the shared platform APIs take only a service-user password as an OAuth client secret. Docs now carry Palo Alto Networks and "Idira" branding. Hygiene applies to Identity service-user passwords. Self-hosted PAM's PVWA REST API (CyberArk, LDAP, RADIUS logons) is not graded here.

Badge

wif.tax grade C

[![wif.tax grade](https://wif.tax/badge/cyberark-identity-platform.svg)](https://wif.tax/p/cyberark-identity-platform/)