Cross-stack identity risk under control
CyberArk PAM lifecycle, governed
Discover our mission and values
Our social and environmental impact
Join us
Our strategic alliances
All our news
Our next meetings
Discover our success stories
Most organizations running CyberArk Idira already have some form of automation in place: in-house scripts, scheduled tasks, integrations built up over time as needs arose. These scripts work, but they age poorly. Fragile, poorly documented, and often understood by only one or two people, they make onboarding and off-boarding privileged accounts difficult to audit and to evolve.
Yet as the CyberArk perimeter grows, these very account entry and exit flows are what determine the quality of governance over time. A poorly controlled onboarding means mismanaged accounts, safes created outside naming conventions, or leftover access after an incomplete off-boarding.
The business logic behind an onboarding, which safe to create, which AD groups to associate, which permissions to grant, is often buried in hundreds of lines of code, with no documentation and no simple way to review it. Every change (a new naming convention, a new account type, a new compliance rule) requires technical intervention, with the regression risk that comes with it.
This handcrafted approach becomes a bottleneck as soon as account volumes or request frequency increase, and complicates any audit or regulatory compliance effort on the PAM perimeter.
Ignimission Protec replaces these scripts with no-code, configurable workflows called boarding orders. The same mechanism covers onboarding, off-boarding, and remediation: only the workflow logic changes, the structure stays identical.
A request can come in several ways, a self-service form, an Excel import, or an API call, for example from a ServiceNow RITM or a Terraform or Ansible instruction. Each line of a request triggers a workflow: to onboard 100 Windows accounts, you simply submit 100 lines tied to the corresponding onboarding workflow.
The person submitting the request doesn’t need to know safe names or CyberArk platform IDs: they fill in a handful of business attributes, environment, application, region, technology, and Protec translates that information into technical actions compliant with the organization’s naming convention. On a role-based access control onboarding case, four attributes are enough to automatically trigger around fifteen actions: safe creation following the naming convention, AD group creation for each role, access configuration as safe member.
Each workflow is configured in Protec’s workflow builder, a drag-and-drop system for chaining actions: integrations, API calls, logical conditions. Attributes requested from the user can be static lists, dynamic lists fed by an external source (a CMDB to pull a list of applications, for example), or simple text fields.
A workflow breaks down into scenarios: each step maps to one or more actions, such as creating a safe, an account, an AD group, or removing them. Conditions can also be added, for example, retrieving users through an LDAP query, then branching the workflow based on the result: notifying an administrator in case of an anomaly, or directly onboarding the user into CyberArk and notifying them once their account is created in the vault.
For connectors not natively covered, Protec offers an Integration Builder, a tool similar to an API client (Postman-like) for building requests to any API-accessible endpoint, SailPoint, Ansible, ServiceNow, Jira, or any other source in the IT ecosystem, as well as Active Directory (LDAP) queries. Once built, these integrations are used directly inside the workflow builder, alongside the standard actions.
Boarding orders are themselves accessible via API, which lets Protec plug into existing ITSM or IGA processes rather than adding yet another standalone tool. A workflow can be triggered directly on the target (status “ready for boarding”), or go through an approval step (status “waiting for approval”) so a manager validates the request before execution, useful for onboardings or off-boardings subject to prior review.
Protec also monitors the account lifecycle automatically: once an asset is detected, the platform checks whether it’s missing from the vault or, conversely, still present in the vault but no longer in the source system, and triggers the matching onboarding or off-boarding scenario accordingly, with no manual intervention.
Reliable, traceable onboarding and off-boarding aligned with a shared naming convention determine the quality of the data discovery will later see, and the ability to respond to an audit without manual reconstruction.
But the real value lies elsewhere: every automated onboarding is less time spent on a repetitive task, and more time for security teams to focus on issues that genuinely require their expertise.
That’s the role of the On/Off-boarding module in Ignimission Protec: no-code, auditable workflows connected to your IT ecosystem, running continuously without depending on a script or a single key person.
Request a demo of Ignimission Protec to see an onboarding workflow run live on your own perimeter.