Yes, if they want clean accountability. Request orchestration can live in ITSM, but identity enforcement should be clearly defined in the downstream system that changes entitlements. Without that separation, teams often struggle to prove when access was actually granted, revoked or denied.
Why separation improves accountability
Separating request orchestration from identity enforcement creates a cleaner control boundary. Orchestration can collect the request, route approvals, and coordinate work, while the downstream system that changes entitlements remains the system of record for access decisions. That split makes it easier to answer the basic audit question: who approved the request, what actually changed, and when did the access state change?
It also reduces confusion when multiple tools participate in the same workflow. If the ticketing layer, IAM platform, and target application all claim to have “handled” the request, organisations can lose a reliable timeline. A downstream enforcement point gives you one place to verify whether access was granted, denied, or revoked, and whether the final state matches the request.
When access governance and entitlement changes are explicit, teams can apply clearer lifecycle management and review the identity security programme around ownership, approval, and revocation rather than treating the ticket itself as proof of control.
Where the boundary should sit in practice
The practical rule is simple: orchestration should decide how a request moves, not whether a privilege exists. Identity enforcement should live where entitlements are actually created, updated, or removed, because that system can validate policy, apply least privilege, and record the authoritative outcome.
This matters most when requests span more than one system or when approvals are asynchronous. A workflow tool can start the process, but the access control decision belongs with the system that owns the account, role, group, token, or entitlement being changed. That keeps the enforcement logic close to the asset and reduces the chance that a downstream application silently diverges from the original request.
For organisations dealing with service accounts, workload credentials, or other machine-facing access, this boundary is especially important. NHIMG’s Ultimate Guide to NHIs is useful here because it frames the lifecycle of non-human access material, while identity data and fabric concepts help explain why authoritative sources and clean handoffs matter for enforcement.
What breaks when orchestration and enforcement are blended
When the request layer also decides access, organisations often end up with weak evidence and inconsistent state. A request can be “approved” in one tool, partially executed in another, and later corrected by a manual fix. At that point, no one can easily prove which system changed the entitlement, whether the change was complete, or whether a denial was overridden.
Blending the layers also makes revocation harder. If the workflow engine is treated as the source of truth for access, then rollback, expiry, and exception handling may be scattered across teams. That increases the chance of orphaned access, stale permissions, and delayed offboarding, especially where multiple systems integrate through different APIs or manual steps.
Those failure modes are why request orchestration and downstream enforcement should be designed as separate responsibilities rather than separate teams merely “sharing” a process. The operating model works best when the orchestration layer is traceable, but the enforcement layer is authoritative. In practice, the difference between a clean control and a weak one is often whether the final entitlement change can be independently verified.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Access changes must be attributable to the system that manages accounts and entitlements. |
| AC-6 — Least Privilege | Separation supports limiting who can approve versus who can enforce access changes. | |
| Recommendation — Centralise account change authority and log the resulting entitlement state in AC-2 records. Restrict enforcement privileges so orchestration cannot directly grant broader access than approved. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about defining and enforcing access responsibilities across systems. |
| Recommendation — Define access control ownership so the downstream system enforces entitlement changes consistently. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Clear enforcement boundaries reduce missed revocation and stale access. |
| NHI-05 — Overprivileged NHI | Separated enforcement helps prevent requests from turning into excess access. | |
| NHI-07 — Long-Lived Secrets | Authoritative enforcement is needed when requests change credential lifecycle. | |
| Recommendation — Use the enforcement system to revoke access at offboarding, not the request workflow alone. Approve only the minimum entitlement and enforce it where privileges are actually assigned. Tie secret rotation and expiry to the system that owns credential enforcement. | ||
Practitioner Guidance
What to verify: Confirm that every access request has one authoritative enforcement point that writes the entitlement change, and that the workflow tool only records orchestration steps. If both systems can modify access, treat that as a control design flaw until the ownership boundary is explicit.
Decision rule: If a system can change permissions, group membership, roles, or tokens, then it should also produce the evidence of that change. If it cannot, it should not be called the enforcement system, even if it approves the request or triggers the action.
Practitioner takeaway: Clean accountability comes from separating request handling from the authoritative access change, then proving that the recorded decision and the actual entitlement state are always the same.