The enterprise identity stack has two mature layers and one missing one. Identity governance decides who should have access. Privileged access management vaults and rotates the credentials that access requires. But between the decision and the changed state of a real system — the account actually created, the group actually modified, the mailbox actually delegated — sits work that neither layer performs. That work is done by scripts, tickets, and people. It is the least examined layer of the stack, and it is where identity programs actually fail.
The stack everyone bought
Two decades of investment produced a clear division of labor. IGA platforms own the decision layer: joiner-mover-leaver policy, access requests, approval chains, certification campaigns, segregation-of-duties rules. PAM platforms own the custody layer: privileged credentials vaulted, sessions brokered and recorded, passwords rotated. ITSM platforms own the coordination layer: the ticket that carries the approved decision to whoever will act on it. Each layer is genuinely mature. None of them touches the target systems in the way the work requires.
Watch what happens after an IGA platform approves a request to grant an engineer elevated access in Active Directory. The decision is impeccable — policy-checked, approved, logged. Then it becomes a ticket. The ticket enters a queue. An operator picks it up, checks out a privileged credential from the vault, opens a console or runs a PowerShell script written years ago by someone who has since left, makes the change by hand across AD, Entra ID, and Exchange, and closes the ticket with a comment. The most sensitive operations in the enterprise — the ones that create and destroy power — are executed with the least engineering rigor of anything in IT.
The gap between decision and done
This is the identity execution gap: the space between an authorized decision and a verified change of state in a target system. Connectors and provisioning modules narrow it for simple, high-volume cases — birthright access, standard app entitlements — but the operations that matter most fall through: cross-system sequences spanning AD, Entra ID, Exchange, and PAM; privileged changes; anything with an exception, a dependency, or an ordering constraint. Those route to the queue and the operator, every time.
The gap imposes four costs, and every identity leader can find each of them in their own environment:
- Latency. Decisions complete in minutes; execution completes in days. Onboarding waits, offboarding lags, and emergency access — the case where latency is risk — waits with everything else in the queue.
- Error. Manual execution of multi-system sequences drifts: the group membership set in AD but not Entra, the mailbox permission granted to the wrong delegate, the script that half-completed and was never re-run. The approved state and the actual state quietly diverge, and certification campaigns exist largely to find the divergence after the fact.
- Audit reconstruction. When an auditor asks "who made this change, under what authority, and what exactly was done," the answer is assembled by hand from a ticket, a vault log, a session recording, and an operator's memory. The evidence of execution was never captured as a first-class artifact — it must be reconstructed, expensively, per question.
- Standing access. Because execution requires humans with broad rights, the organization maintains a permanent population of powerful operator accounts — precisely the access its zero-trust program is trying to eliminate. The execution model works against the security model.
Governance produces decisions. Vaults produce custody. Nothing in the stack produces verified execution — so people do, one ticket at a time.
Why the gap persisted
Partly because it is invisible in the org chart: the decision layer belongs to the identity team, the custody layer to security, and execution to "operations" — a residual category with no product budget. Partly because the industry's answer has been scripting, and scripts are where rigor goes to decay: unversioned, unreviewed, running under service accounts with standing privilege, encoding one author's understanding of a protocol at one point in time. And partly because the category had no name. What is not named is not measured, and what is not measured is not fixed.
Naming the category: identity execution
Identity execution is the discipline of carrying authorized identity decisions into target systems in a way that is bound, verified, and evidenced. Its unit of work is not a ticket or a script run but an execution contract: a machine-readable specification of an operation that binds, before anything runs, what will be done, to which objects, in which systems, under whose authorization, within what time window, and with what expected end state. Execution then has three properties the manual model cannot offer:
- Protocol-bound. The contract executes through the target systems' native protocols and APIs — LDAP, Graph, Exchange, PAM APIs — under scoped, just-in-time credentials rather than a standing operator account. The operation cannot exceed its contract, because the contract is the permission.
- Verified. Completion is not an operator's ticket comment; it is a post-execution read of the target systems confirming the end state matches the contract. Partial completion is detected at execution time, not at the next certification campaign.
- Evidence-backed. The contract, the authorization, every protocol call, and the verification result are captured as a single sealed record as the work happens. Audit stops being reconstruction and becomes retrieval.
The four costs invert. Latency falls from queue-time to run-time. Error becomes a detected, contract-level event with a defined remediation path. Audit becomes a query. And standing operator access can be retired, because execution no longer depends on humans holding permanent power — the argument carried further in Zero Standing Privilege.
Adjacent, not instead
Identity execution does not compete with the layers above it — it completes them. The IGA platform remains the system of record for policy and approval; its decisions become the authorizations that contracts bind to. The PAM platform remains the system of custody; its vault issues the just-in-time credentials that contracts execute under. The ITSM platform remains the system of coordination; its tickets trigger contracts instead of queues. An execution layer that asks you to replace any of these has misunderstood the problem: the decisions were never the weakness. This is where CAELION positions Cube23 — an identity operations control plane that sits beside the systems of record you already run, and turns their decisions into protocol-bound, zero-trust, evidence-backed execution across AD, Entra ID, Exchange, and PAM.
Nowhere is the gap more visible than in the workflow every enterprise believes it has automated: joiner-mover-leaver, taken apart in Joiner-Mover-Leaver at Enterprise Scale. The decisions there were automated years ago. The execution was not — and the difference is the gap this article names.
If your identity program is strong on decisions and slow on doneness, the gap is where your risk and your latency live. CAELION's Cube23 closes it as an execution layer adjacent to your existing IGA, PAM, and ITSM investments — request a briefing to see an execution contract run against a live directory.