ITSM tools are not identity governance tools for access requests

At a glance

What this is: This is a comparison of ITSM tools and access-governance workflows, with the key finding that ticketing systems can process requests but do not govern entitlement quality.

Why it matters: It matters because IAM, NHI, and human access programmes all fail when request handling is mistaken for authorization governance, leaving over-privilege and audit gaps untouched.

By the numbers:

• Zluri says access request tickets can drop by up to 90% when routine approvals are automated instead of routed through ITSM queues.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's full comparison of ITSM tools and access request governance

Context

ITSM tools are designed to record, route, and resolve work. That makes them useful for incidents and change tickets, but weak as access-governance systems because they do not evaluate whether a request is appropriate, least-privileged, or consistent with policy. The primary keyword here is IT service management tools, and the central issue is that service desks are being asked to do identity work they were never built to do.

For IAM teams, the problem is not ticket volume alone. It is the false confidence that a closed request means a governed entitlement, when the real questions are license scope, approval logic, expiry, auditability, and whether the access already exists elsewhere. That distinction matters across human users, service accounts, and AI-adjacent access flows.

Key questions

Q: How should security teams handle access requests without turning ITSM into their authorization system?

A: Security teams should use ITSM to capture and route the request, then apply a separate policy engine to decide what access is appropriate. The decision should consider role, application sensitivity, existing entitlements, and expiry. That keeps workflow efficiency separate from access governance and reduces the chance that ticket closure is mistaken for secure provisioning.

Q: When does faster access approval create more risk than it reduces?

A: Faster approval becomes risky when the request is granted without checking entitlement tier, SoD conflicts, or existing access paths. In those cases, speed can increase over-permissioning and leave orphaned access behind. The right target is bounded, policy-driven access, not approval throughput alone.

Q: What do teams get wrong when they treat self-service request portals as identity governance?

A: They often assume that a clean request experience means the access is properly controlled. In reality, self-service only solves submission and routing. Governance still has to answer who qualifies, what level of access is needed, whether the grant should expire, and whether the user already has equivalent access elsewhere.

Q: Should organisations prioritise access expiry over faster approvals?

A: Yes, when the access is project-based, elevated, or tied to a temporary business need. Expiry makes access bounded from the start and reduces the need for manual cleanup later. Faster approvals help operations, but expiry is what prevents temporary access from becoming permanent risk.

Technical breakdown

Why ITSM ticketing does not equal access governance

ITSM platforms are workflow systems. They route requests, capture approvals, and preserve a record of activity, but they do not make entitlement decisions with enough identity context to govern access. Access governance requires knowledge of role, app sensitivity, existing permissions, policy conflicts, and whether the request should be approved, downgraded, time-limited, or rejected. A ticketing system can carry the request, but it cannot by itself determine whether the resulting access is appropriate. That is why ITSM-only access workflows so often create bloat instead of control.

Practical implication: treat ITSM as a transport layer for requests, not the control point for authorization decisions.

Policy-driven provisioning and time-bound access

Policy-driven provisioning adds decision logic before access is granted. Rather than approving a generic entitlement, the workflow evaluates whether the user qualifies, what permission tier is needed, and whether the grant should expire automatically after a defined project window. Time-bound access matters because most access risk comes from access that outlives the task it was created for. When the approval logic, entitlement scope, and expiry are all explicit, the system can reduce unnecessary standing access and make revocation part of the original grant rather than a later cleanup task.

Practical implication: define expiry and permission scope at request time instead of relying on manual revocation later.

Why audit trails must include entitlement-level detail

A usable audit trail is more than a ticket history. It should show who requested access, what policy evaluated it, who approved it, what was provisioned, and when the access expires or is revoked. That level of detail is what lets security, compliance, and IAM teams reconstruct the decision path and prove that the grant matched policy. Without it, an organization may have records of activity but not records of governance. For identity programmes, that gap is especially risky when access requests are tied to sensitive SaaS tools or overlapping entitlements.

Practical implication: require entitlement-level logging so audits can verify the decision, not just the ticket closure.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

ITSM workflows are a routing layer, not an access control model. The vendor’s comparison makes a larger governance point: request intake can be operationally clean while entitlement quality remains unmanaged. That is why ticketing systems often produce visible process order and invisible privilege creep. IAM teams should not confuse service management efficiency with access governance maturity.

Standalone access requests are the wrong unit of control for modern entitlement management. Access decisions need context about role fit, application sensitivity, current access, and duration. When those variables are not evaluated together, the result is usually over-permissioning disguised as efficiency. Practitioners should see this as a governance gap, not a workflow optimisation problem.

Time-bound access is the real control, not faster approvals. If access is granted for a project, it should expire as part of the original decision rather than being cleaned up later. That shifts governance from reactive revocation to bounded entitlement design. The practical conclusion is that access programmes should measure expiry discipline, not just approval speed.

Named concept: access request drift. This is the tendency for request workflows to keep expanding beyond the governance question they were meant to answer, until the process tracks tickets instead of entitlement risk. Over time, the system optimises for closure, not least privilege. Practitioners should reframe the programme around entitlement outcomes, not request throughput.

For NHI and human IAM alike, governance fails when the request channel becomes the control plane. Service accounts, API keys, and employee access all suffer when the platform handling the request is mistaken for the system that should validate it. That assumption creates a blind spot across identity programmes, especially where approvals, expiry, and audit evidence are split across multiple tools. Teams should align request routing with a separate authorization decision layer.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• That is why the NHI Lifecycle Management Guide is the right next resource for teams that need lifecycle controls, not just request handling.

What this signals

Access request drift: once a service desk becomes the de facto authorization layer, organisations start optimising ticket closure instead of entitlement quality. The result is predictable in both human and NHI programmes. Teams that want durable governance should separate submission, approval, and provisioning so each control has a clear owner and evidence trail.

The broader signal is that identity programmes are moving toward policy-first provisioning and away from generic ticket workflows. That shift matters for any environment where standing access accumulates quietly, because the control question is no longer how fast a request moves but whether the resulting entitlement is scoped, time-bound, and reviewable. The Top 10 NHI Issues is a useful companion view on why over-privilege keeps reappearing.

For teams managing service accounts or machine credentials, the same pattern shows up in a different form. If request handling and governance are fused, the organisation loses the ability to prove why access exists and when it should end. That is where lifecycle discipline and NIST Cybersecurity Framework 2.0 alignment start to matter in practice.

For practitioners

• Separate request intake from authorization decisions Keep ITSM for ticket routing and use a dedicated policy layer to decide whether access should be approved, downgraded, auto-rejected, or time-limited. This prevents the service desk from becoming the de facto access control system.
• Define entitlement tiers before provisioning Map each high-value application to specific license or permission tiers so the requester gets the minimum viable access, not a generic app grant. This is especially important when the same application exposes read, write, and admin levels.
• Make expiry part of the grant Attach automatic expiration to project-based access and review whether the access needs to persist after the task window closes. That reduces orphaned permissions and cuts the cleanup burden that manual revocation creates.
• Audit for overlapping access paths Check whether the same person already has standing access through another app, role, or group before approving a new request. Overlap is where least privilege quietly collapses, especially in SaaS-heavy environments.
• Measure governance, not ticket speed Track how many requests were auto-approved, auto-rejected, time-limited, or provisioned at the wrong permission tier. Those metrics tell you whether the access programme is governing entitlements or just closing cases faster.

Key takeaways

• ITSM tools can route access requests, but they do not by themselves determine whether access is least-privileged, policy-aligned, or time-bound.
• The governance risk is not just more tickets. It is the accumulation of over-permissioned and orphaned access when request closure is treated as control.
• Practitioners should separate routing from authorization, define entitlement tiers, and build expiry into the original grant rather than relying on cleanup later.

Key terms

• Access Request Drift: Access request drift is the gradual expansion of a request workflow until it tracks ticket closure more than entitlement risk. The process still looks orderly, but the real control question, whether access is appropriate, bounded, and reviewable, gets pushed out of view.
• Policy-Driven Provisioning: Policy-driven provisioning is the practice of making access decisions with pre-defined rules before access is granted. It uses role, app sensitivity, approval logic, and expiry conditions to determine whether the entitlement should be approved, reduced, rejected, or time-limited.
• Time-Bound Access: Time-bound access is access that expires automatically after the business need ends. It reduces standing privilege by building revocation into the original grant, which is especially useful for project work, elevated permissions, and temporary access to high-value applications.
• Entitlement Tier: An entitlement tier is a specific permission level within an application, such as read-only, standard user, or administrator. Defining tiers allows access governance to grant the minimum viable access instead of issuing a broad application-level permission that is difficult to audit later.

Deepen your knowledge

ITSM access requests and entitlement governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are separating ticket handling from access control in a similar environment, it is worth exploring.

This post draws on content published by Zluri: IT Teams Top 14 IT Service Management Tools (ITSM Tools) in 2026. Read the original.