ITSM tools are not identity governance tools for access requests

At a glance

What this is: This is an analysis of why ITSM workflows handle request routing well but fail as access governance, because they cannot evaluate scope, fit, policy conflict, or expiry.

Why it matters: IAM, IGA, and PAM teams need to separate service-desk intake from access decisioning so that provisioning is policy-driven, time-bound, and auditable instead of merely ticketed.

Context

ITSM tools are built to move work, not to govern access. In identity terms, that means they can capture a request and route it for approval, but they do not determine whether the requested entitlement is appropriate, licensed correctly, or consistent with policy.

That distinction matters because access requests create governance decisions, not just operational tasks. When a service desk is asked to approve access, the organization still needs entitlement scope, separation-of-duties checks, role fit, and expiry logic somewhere in the process.

Zluri uses the contrast to argue that request handling and access governance are different control problems. The article is about that boundary, and the practical failure that appears when teams treat ticket closure as evidence of controlled access.

Key questions

Q: What breaks when ITSM tools are used as the only access request control?

A: The workflow still records requests, but it cannot judge entitlement scope, license fit, time limits, or SoD conflicts. That means access can be approved quickly while still being wrong, which leads to over-permissioning, orphaned access, and weak audit evidence. Service desks can move the ticket, but they cannot prove the access was appropriate.

Q: Why do inherited access approvals create governance risk?

A: Because copied access often carries hidden excess privilege into the new account. If approvers do not inspect the source entitlement set, they can reproduce over-privilege at scale and normalise access that was never justified for the new role.

Q: How can security teams tell whether provisioning governance is working?

A: Look for evidence that access changes are being removed as reliably as they are granted. If leaver accounts, role changes, and application group updates routinely require manual cleanup, then the provisioning model is not governing the full lifecycle and audit reports are masking drift.

Q: Should organisations keep ITSM in the access request process?

A: Yes, but only as the intake and traceability layer. ITSM is useful for routing, status visibility, and audit history, but it should not be the system that decides entitlement scope, license fit, or time-bound revocation. Those decisions belong in the access governance layer, where policy can be enforced consistently.

Technical breakdown

Why ITSM workflows stop at request routing

ITSM systems are optimized for intake, assignment, and closure. They create a record, move it through an approval path, and preserve a support trail, but that workflow does not include entitlement evaluation. Access governance requires more than a logged request because the control must know what application, permission level, license type, and business justification are acceptable before access is granted. A ticket can prove that someone asked and someone approved. It cannot prove that the access was the right one, that it remained valid, or that the request avoided policy conflicts.

Practical implication: Separate ticket handling from access decisioning so the approval step is policy-aware, not just process-complete.

How policy-driven provisioning changes the access decision

Policy-driven access provisioning evaluates a request against predefined rules before a human approves or rejects it. Those rules can encode role, department, risk level, approval depth, and duration so that the system knows when a request is routine, when it is risky, and when it should be denied outright. This is materially different from manual provisioning because the decision is made against a control model, not a queue. When time-bound access is included, the governance control also extends beyond issuance into expiry, which reduces the chance that access lingers after the business need ends.

Practical implication: Use policy logic to determine both initial approval and automatic expiry, rather than relying on post-hoc cleanup.

Why license fit and SoD checks belong in the access layer

License fit and segregation-of-duties checks are governance controls, not service-desk features. A request for an application is not the same as a request for the correct license tier, the right permission scope, or a combination that avoids conflicting access. If the workflow only knows that access was requested, it can still over-provision users, create unused entitlements, or approve combinations that violate policy. The access layer has to understand the difference between availability of service and appropriateness of privilege. Without that layer, the ITSM system becomes a fast pathway to bad access rather than a control point.

Practical implication: Route access decisions through governance checks that evaluate privilege scope, conflicts, and license appropriateness before provisioning.

NHI Mgmt Group analysis

ITSM is a request system, not an access-governance system. That distinction is not semantic, it is structural. Ticketing platforms are designed to move work through queues, while access governance is designed to decide whether entitlement should exist at all, at what scope, and for how long. When organisations collapse those two jobs into one workflow, they end up measuring service efficiency while losing control precision.

The real control gap is not approval speed, it is entitlement judgment. The article correctly exposes that a closed ticket says nothing about whether the user needed the right role, the right license tier, or a time-bound grant. That gap matters because access risk is usually created by over-provisioning, not by request latency. Practitioners should treat request routing as a service function and entitlement judgment as an identity control function.

Time-bound access turns access requests into lifecycle events. Once access can expire automatically, the governance model shifts from one-time approval to governed issuance and revocation. This is where NHI-style lifecycle thinking matters even in human access flows: the control has to manage the whole privilege window, not just the point of entry. Teams should stop asking whether the ticket was approved quickly and start asking whether the access ever should have persisted.

Access governance needs policy semantics that ITSM was never built to carry. Separation of duties, license fit, role alignment, and permission scope are not incidental metadata. They are the actual decision variables that determine whether a request is safe to grant. The governance programme is weak when the service desk becomes the de facto policy engine, because ticket completion is not the same as access assurance.

Structured access intelligence is now a governance requirement, not an optimisation. The market signal here is that access requests have outgrown generic workflow tooling. As organisations mature, they need systems that can evaluate who should get what, under which policy, and for how long, then keep that decision auditable. Practitioners should reframe access requests as a governed entitlement lifecycle rather than a support queue.

From our research library:

• Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
• Read next: NHI Lifecycle Management Guide

What this signals

Access requests should now be treated as governed entitlement events, not routine support tickets. When the access decision is separated from the ticketing workflow, teams can enforce policy, scope, and expiry without depending on manual cleanup.

Request routing is not the control: the service desk can record who asked and who approved, but it cannot decide whether the entitlement was appropriate. That boundary matters for IAM and IGA programmes because the control objective is not speed, it is correct access.

For practitioners, the next step is to define where approval ends and privilege issuance begins. If the platform cannot evaluate role fit, license tier, and revocation timing, it is only documenting access risk.

For practitioners

• Separate access approvals from service-desk routing Define which requests belong in ITSM and which require policy-driven entitlement decisions. Keep the service desk as the intake and audit trail, but move privilege scope, approval logic, and expiry into the access control layer.
• Encode license and role rules before provisioning Build request policies that distinguish between an application request and the correct license tier, permission set, and business role. Reject or route for review when the requested access does not match the user’s job function or entitlement policy.
• Automate expiry for time-bound access Treat project-based or temporary access as a lifecycle event with a built-in end date. Use automatic revocation so access does not remain active after the business need has ended.
• Add SoD checks to the approval workflow Evaluate requests against separation-of-duties rules before approval reaches the service desk queue. Flag conflicting access combinations so the system can route them for higher scrutiny instead of silently provisioning them.

Key takeaways

• ITSM platforms are useful for logging and routing, but they do not replace access governance because they cannot evaluate whether a request is justified, scoped correctly, or time-limited.
• The evidence problem is structural: a ticket can show that an access request was approved, but it cannot prove that the right entitlement, license, or segregation-of-duties decision was applied.
• Teams should keep the service desk in the workflow but move policy decisions, expiry, and privilege checks into the access governance layer.

Key terms

• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
• Entitlement Scope: Entitlement Scope is the exact set of actions, resources, or permissions attached to an identity during a session. In cloud and NHI governance, scope is as important as duration because broad permissions can turn a short-lived grant into a high-impact access event. Narrow scope is a core control objective.
• Time-Bound Access: Time-bound access is a control pattern that grants permissions for a defined window and removes them automatically when the window ends. It is a practical least-privilege mechanism for cloud operations and NHI governance because it reduces how long elevated access can be abused.
• Service Desk Workflow: A service desk workflow is the structured path a request follows from submission to resolution or approval. In identity programmes, it often becomes the mechanism that routes access decisions, so its design affects governance, auditability, and who can grant entitlement.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.