How should teams automate access provisioning when target systems are not directly integrated with their identity platform?

How automation should bridge approval to execution

When the target system is not directly integrated, the right pattern is to separate decision from delivery. Approval should produce a machine-readable event that another step can consume, whether that step is a ticket, a workflow engine, a webhook, or an application API. That keeps the access request auditable even when the last mile still depends on a legacy console, a private network, or a team that has not yet exposed provisioning APIs.

This matters because manual handoff is where access control often degrades. If approvals end in email, chat, or ad hoc tickets, teams lose the link between who approved, what was granted, when it happened, and whether the access still matches the original request. A workflow that emits structured data can preserve those fields even when provisioning itself is deferred. For legacy estates, that usually means using the identity platform for governance and the downstream system for execution, not pretending both layers are equally integrated. NHI Management Group’s Ultimate Guide to NHIs is useful here because the same separation applies to machine identities, service accounts, and other access paths that are often managed outside a modern identity stack.

In practice, many teams discover the weakest point in access automation only after a request has already been approved and someone still has to finish the grant by hand.

How the workflow works in practice

A workable design usually has four stages: request, approval, handoff, and verification. The identity platform handles the first two, then emits an event that carries the minimum data needed for the next system to act safely. That event can create a service desk ticket, call an orchestration layer, or invoke an application API. The important part is that the downstream action remains tied to the original approval record, so the resulting access can still be traced back to a requester, approver, scope, and time window.

• The workflow should carry a unique request ID so the downstream action can be reconciled later.
• The handoff should include only the fields needed to grant access, such as target, role, expiry, and approver.
• The downstream system should confirm success or failure back into the same audit trail.
• If the system cannot provision automatically, the workflow should still mark the item as pending rather than silently complete it.

For many organisations, a webhook is the cleanest bridge because it lets the identity platform trigger an external process without exposing the full access logic inside the platform itself. Where an API exists, the API should be the primary path because it gives better structure and lower operational drift than free-form ticket handling. Where no API exists, a ticket can still be acceptable if the process defines who fulfils it, how completion is validated, and how exceptions are escalated. The NHI lifecycle perspective in the NHI Lifecycle Management Guide is relevant because the same lifecycle discipline is what prevents temporary access from becoming permanent sprawl.

Controls tend to break down when the handoff is treated as a one-way notification, because then the identity platform knows a request was approved but cannot prove that access was actually provisioned, revoked, or time-bounded.

Where automation gets messy in legacy and siloed systems

Automating access provisioning this way always introduces a tradeoff: the more the target system resists integration, the more the organisation must rely on orchestration, reconciliation, and exception handling. That is not a failure of the pattern, but it does mean the process has to be explicit about what is automated, what remains human, and which systems are allowed to drift.

Legacy targets often have brittle role models, coarse administrative permissions, or inconsistent naming conventions, so the “same” access request may not map cleanly across environments. Current guidance suggests treating those mismatches as governance issues, not just engineering inconveniences. If the downstream grant cannot be expressed consistently, teams should narrow the allowed request options rather than broaden the provisioning logic indefinitely. That is especially important for shared systems, private applications, and third-party platforms where the identity platform can only observe the request, not enforce the final state directly. The OWASP Non-Human Identity Top 10 is a good companion reference when those downstream grants create service accounts, tokens, or other machine access that must still be governed after approval.

Teams should also be careful not to confuse automation with trust. A successful webhook does not prove the right entitlement was granted, only that some action occurred. That is why reconciliation matters: the downstream state should be compared against the approved request, and any mismatch should generate an exception for review. The need for that reconciliation becomes more pronounced when access is provisioned across multiple silos with different ownership, because the most common failure is not a technical crash but a quiet mismatch between the approved scope and the actual grant.

Risk and Threat Considerations

The main risk is control loss at the boundary between approval and execution. Once provisioning moves outside the identity platform, the organisation can lose assurance over whether access was granted correctly, whether it was time-limited, and whether it was later revoked on schedule. That creates governance exposure, but it also creates security exposure if the downstream system grants broader access than intended or leaves residual access behind.

Failure mechanism: The weakness usually appears when the handoff is not structured, not reconciled, or not tied to a unique request record. In that case, tickets can be completed inconsistently, webhooks can trigger partial actions, and legacy systems can retain standing access because nobody owns the final state. For machine access, that same pattern can leave service accounts, keys, or tokens active after the business need has ended.

Impact: The result is unauthorised persistence, audit gaps, and higher blast radius when access is abused or simply forgotten. The organisation may believe approval created a bounded entitlement when the real system state is broader, older, or harder to revoke than expected.

Practitioner Guidance

What to prioritise: Make the handoff deterministic before you automate scale. If a target system cannot accept direct provisioning, define the exact payload, success condition, and rollback path for the webhook or ticket flow so the identity platform remains the source of truth for intent.

What to verify: Verify that every approved request can be reconciled to a downstream outcome. Teams should be able to prove who approved, what was requested, what was granted, and whether the grant expired or was revoked, especially where the final step still depends on a human or a separate tool.

Common mistake: Do not treat “ticket created” as equivalent to “access granted.” That shortcut hides fulfillment failures, encourages silent exceptions, and makes it easy for legacy systems to accumulate access that nobody can confidently account for later.

Practitioner takeaway: The goal is not to automate every target system in the same way; it is to ensure that every approval still ends in a traceable, verified, and reversible access state.

Related resources from NHI Mgmt Group

• How should security teams automate identity provisioning without creating new over-access risk?
• What happens when identity teams rely on tool coverage instead of understanding how access really happens?
• How should IT teams automate access reviews when users do not respond in time?
• How should security teams govern employee use of GenAI tools when most access is happening outside SSO and corporate identity controls?