ITSM tools do not solve access governance in 2026

At a glance

What this is: This article argues that ITSM platforms are useful for request routing and service workflows, but they do not provide access governance for approvals, scoping, expiry, or segregation logic.

Why it matters: IAM and IGA teams need to separate ticket handling from entitlement decisions, or they will keep approving access without knowing whether it is appropriate, time-bound, or policy-compliant.

Context

IT service management tools are designed to move work through queues, not to decide whether a person should receive a specific entitlement. In access governance terms, the gap is not request intake but control over scope, duration, policy fit, and existing entitlements.

Zluri’s article frames the practical failure clearly: if access requests are treated like ordinary service tickets, organisations can end up provisioning the wrong license tier, ignoring standing access elsewhere, and leaving permissions active after the need has passed. That is an IAM and IGA problem, not an ITSM problem.

Key questions

Q: How should security teams handle access requests when ITSM tools are already in place?

A: Use ITSM as the intake and routing layer, but move entitlement decisions into a policy-controlled access governance process. The approval should determine the correct role, permission level, and expiry condition before access is provisioned. Otherwise, the organisation measures workflow completion, not access correctness.

Q: Why do access requests in ITSM create over-permissioning risk?

A: Because a ticket workflow treats each request as a separate event, while real identity risk accumulates across many requests and systems. Users can gain overlapping permissions, broader license tiers, or persistent access that no single ticket looks dangerous on its own. The risk emerges from cumulative entitlement drift, not from one approval alone.

Q: What breaks when access requests are handled like ordinary support tickets?

A: What breaks is accountability. Access requests often need approvers, documentation, and downstream fulfilment steps, but ordinary support tickets are designed to close quickly. That shortcut creates weak audit evidence, inconsistent ownership, and greater risk that entitlement changes outlive the original business need.

Q: Should organisations use ITSM or IGA for access governance?

A: Use both, but for different jobs. ITSM should route and record the request, while IGA should determine whether the entitlement should exist, what level it should have, and when it should expire or be removed.

Technical breakdown

Why ITSM workflows cannot govern access decisions

ITSM platforms are built around case management: they record a request, route it, track approval, and close it. Access governance requires different logic. The system must understand entitlement scope, license type, policy conflicts, segregation of duties, and expiry. A ticketing workflow can say that someone asked for access and someone approved it. It cannot decide whether that access is proportionate, whether the user already has overlapping permissions, or whether the access should end automatically when the business need ends.

Practical implication: Use ITSM as a routing layer, not as the decision engine for entitlements.

Why license fit and scope are separate controls from approval

Approval does not equal appropriate access. In practice, a request for an application may need a read-only role, a full-user role, or an administrative entitlement, depending on the job function and risk. ITSM systems do not model that nuance. Access governance needs policy-driven mapping between request intent and the exact entitlement issued, because over-provisioning often starts with a vague approval that says yes to the application but not to the correct level of access.

Practical implication: Define role-to-entitlement rules so approval cannot bypass scope validation.

Why time-bound access matters more than ticket closure

A closed ticket does not remove risk if the entitlement remains active. Access governance has to manage the full lifecycle of the permission, including expiry, revocation, and recertification where needed. ITSM can record that a request was handled, but it usually has no built-in mechanism to enforce access end dates or detect orphaned permissions after project completion. That is why ticket completion and access completion are not the same event.

Practical implication: Tie approvals to automatic expiry and revocation, not just to ticket closure.

NHI Mgmt Group analysis

ITSM-based access approval creates a governance illusion: the process looks controlled because every request has a ticket, but the entitlement itself is still being decided without access intelligence. That separation matters because governance is about the quality of the access decision, not the existence of workflow metadata. The practitioner conclusion is simple: ticketing evidence is not entitlement evidence.

Access governance fails when approval is treated as authorisation: a manager or service desk can approve a request without evaluating whether the entitlement matches the role, violates policy, or duplicates existing access. This is why organisations end up with over-permissioned users and licence sprawl. The implication is that approval workflows must be subordinate to entitlement policy, not mistaken for it.

Time-bound access is the missing control in ticket-centric models: ITSM can track request completion, but it cannot reliably enforce permission expiry or lifecycle revocation. That leaves access active beyond the business need and creates avoidable residual risk. Practitioners should treat access duration as part of the decision, not as an operational afterthought.

Identity governance and ITSM solve different problems: ITSM optimises service handling, while identity governance optimises entitlement correctness, separation of duties, and lifecycle control. When those roles blur, teams measure throughput instead of access quality. The right model is to let ITSM carry the service case and let IGA determine whether the access should exist at all.

Policy-driven access decisions are becoming the minimum viable control for enterprise access: the article reflects a broader shift away from manual judgement and toward governed entitlement logic. The named concept here is access decision intelligence, which means using policy, role context, and lifecycle state to decide what access is granted. Practitioners should build their governance around that decision layer, not around the queue.

From our research library:

• Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.

What this signals

Access request governance needs a decision layer, not just a workflow layer: if the platform cannot reason about role fit, policy conflicts, standing access, and expiry, it is not governing access. That means many organisations will need to re-architect their request path so the approval event and the entitlement event are no longer the same thing.

Access decision intelligence is the practical shift this article points to. Teams should think less about speeding up tickets and more about constraining what access can be granted in the first place, especially where licence cost, segregation of duties, and project-based access intersect.

For practitioners

• Separate request handling from entitlement decisioning Keep ITSM responsible for intake, routing, and audit trail, but require a governed access layer to decide what entitlement is issued, at what scope, and for how long.
• Map requests to specific roles and license tiers Replace generic application approvals with policy rules that assign the exact role, license level, and permission scope tied to the requester’s function.
• Add expiry to every non-permanent entitlement Make project, contractor, and exception-based access expire automatically so request closure does not become a substitute for revocation.
• Block approvals that conflict with existing access Check current entitlements before approval so overlapping permissions, SoD conflicts, and unnecessary duplicate access are caught before provisioning.

Key takeaways

• ITSM tools can handle request routing, but they do not decide whether a specific entitlement is appropriate or policy-compliant.
• The control gap is not speed, it is scope, duration, and fit, which is why ticket closure does not equal access governance.
• Enterprises need a separate entitlement decision layer if they want to reduce over-permissioning, licence waste, and residual access risk.

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: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.
• Authorization scope: Authorization scope is the set of actions and data resources a caller is allowed to access after authentication succeeds. In SMART on FHIR environments, scope is a primary security boundary because it determines whether an app can see only the records it needs or far more.
• 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.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.