Summary
CyberArk is moving EPM API authentication onto its Identity Security Platform Shared Services (ISPSS), using an OAuth2 service user instead of the native username/password logon our integration relies on today. This epic adds Identity-based authentication as a supported option so customers on ISPSS-connected EPM tenants can onboard, while existing customers continue working unchanged.
Background / why now
Our cyberark_epm integration authenticates via EPM's legacy native logon (Auth/EPM/Logon). CyberArk now documents an Identity/ISPSS OAuth2 flow as the path for API and automation access (CyberArk: Set up API authentication for EPM REST APIs using Identity).
There is no published deprecation date for the legacy API authentication method itself. However, CyberArk's broader platform migration carries a real end-of-2026 horizon: reporting indicates customers can run standalone EPM alongside EPM-on-ISPSS only until December 31, 2026, with related migration milestones (e.g. endpoint group activation) cited as October 31, 2026. Since the legacy native logon is tied to the standalone EPM console while ISPSS tenants authenticate via CyberArk Identity, the practical runway for the legacy method is bounded by this console migration deadline even absent an explicit API sunset notice.
We should support Identity authentication now to avoid onboarding friction for customers already on ISPSS, and to be ahead of this migration window rather than reacting to it.
Goal
Let a user choose their authentication method when configuring the integration, with both the legacy logon and CyberArk Identity fully supported.
Scope
- Add an authentication-method selector to the integration configuration.
- Support the CyberArk Identity OAuth2 service-user flow end to end across all EPM data streams.
- Keep the existing logon method as the default so current deployments are unaffected.
- Document the Identity setup (service user, API web app, server URL) for customers.
Out of scope
- Removing or deprecating the legacy logon method.
- Any new event types, fields, or dashboards — this is an authentication change only.
- Changes to other CyberArk integrations (PAS, PTA).
Acceptance criteria
- A user can select either authentication method and successfully collect logs from all EPM data streams.
- Existing configurations continue to work with no changes required.
- Setup documentation covers the CyberArk-side prerequisites for the Identity method.
- Package validation and tests pass; the change ships as a minor version release.
Risks & dependencies
- Customer-side setup: the Identity method requires configuration in the customer's CyberArk Identity tenant (a service user and an EPM API web app) before onboarding — documentation must make this clear.
- Test coverage: validating the Identity path in CI requires additional test fixtures beyond the default flow.
- Migration timeline: no forced API cutoff is confirmed yet, but the ISPSS migration deadline (reported as end of 2026) means this should not be deprioritized — revisit priority if CyberArk publishes a firm sunset date for the legacy auth method.
References
Summary
CyberArk is moving EPM API authentication onto its Identity Security Platform Shared Services (ISPSS), using an OAuth2 service user instead of the native username/password logon our integration relies on today. This epic adds Identity-based authentication as a supported option so customers on ISPSS-connected EPM tenants can onboard, while existing customers continue working unchanged.
Background / why now
Our
cyberark_epmintegration authenticates via EPM's legacy native logon (Auth/EPM/Logon). CyberArk now documents an Identity/ISPSS OAuth2 flow as the path for API and automation access (CyberArk: Set up API authentication for EPM REST APIs using Identity).There is no published deprecation date for the legacy API authentication method itself. However, CyberArk's broader platform migration carries a real end-of-2026 horizon: reporting indicates customers can run standalone EPM alongside EPM-on-ISPSS only until December 31, 2026, with related migration milestones (e.g. endpoint group activation) cited as October 31, 2026. Since the legacy native logon is tied to the standalone EPM console while ISPSS tenants authenticate via CyberArk Identity, the practical runway for the legacy method is bounded by this console migration deadline even absent an explicit API sunset notice.
We should support Identity authentication now to avoid onboarding friction for customers already on ISPSS, and to be ahead of this migration window rather than reacting to it.
Goal
Let a user choose their authentication method when configuring the integration, with both the legacy logon and CyberArk Identity fully supported.
Scope
Out of scope
Acceptance criteria
Risks & dependencies
References