ITSM access requests expose the identity gaps behind service delivery

At a glance

What this is: This article frames ITSM as an access-request and service-delivery layer, but shows that faster ticket handling does not by itself solve identity governance problems around entitlement sprawl and lifecycle drift.

Why it matters: It matters because IAM teams often inherit ITSM workflows as the control surface for access approvals, yet the real risk sits in whether those workflows enforce role change, revocation, and review discipline.

Context

IT service management is a workflow layer for service requests, incidents, change management, and operational support. In identity terms, it often becomes the place where employees ask for application access, but the workflow itself does not prove whether the access is justified, current, or removed when the role changes.

That gap matters because speed and structure can hide weak governance. An access request can be approved quickly through ITSM while entitlement sprawl, stale permissions, and inconsistent revocation continue underneath the process.

For IAM, IGA, PAM, and NHI programmes, the question is not whether ITSM can route tickets efficiently. The question is whether those tickets are tied to lifecycle controls that actually govern who or what should keep access after the request is closed.

Key questions

Q: What breaks when ITSM approvals are used as a substitute for identity governance?

A: Approvals become a routing exercise rather than an entitlement decision. Access may be granted quickly, but the process still fails to verify whether the request matches role need, least privilege, or the user’s current lifecycle state. That is how entitlement sprawl survives inside a well-run service desk.

Q: Why do access request workflows often fail to improve governance?

A: They fail when organisations treat approval speed as the objective. Requests can move quickly while access remains too broad, role design drifts, or certification does not remove stale entitlements. Governance improves only when request workflows are tied to segregation of duties, risk checks, and a separate review process that verifies continued need.

Q: What are the signs that ITSM access governance is failing?

A: Look for missing approval histories, inconsistent changelogs, weak searchability, manual reconstruction of request decisions, and reporting that cannot tie requests to actual provisioning outcomes. Those are signs that the workflow exists operationally but not as defensible governance evidence.

Q: What should IAM teams do with ITSM after adding access governance?

A: Keep ITSM for service requests, incidents, and change workflows, but stop using it as the system that decides entitlement scope. IAM teams should route access through a policy engine, preserve the audit trail, and reserve manual review for high-risk or exception cases.

Technical breakdown

How ITSM request routing works for access approvals

ITSM platforms turn access demand into tickets, queue them, route them, and track closure. That makes them useful for scale, but the workflow is procedural rather than authoritative. A ticket can capture request context, approver identity, and completion status, yet none of that proves the entitlement matched job need, least privilege, or the current lifecycle state of the user. In practice, ITSM is often the front door to access governance, not the governance system itself. The architecture is strongest when it is integrated with authoritative identity data, role logic, and revocation signals rather than treated as a standalone approval engine.

Practical implication: Treat ITSM as the request intake layer and bind it to authoritative identity and entitlement controls before relying on approvals.

Why change management is the real identity control point

The article’s most important identity signal is change management. Role changes create a boundary condition where new access is needed and old access should disappear, but many organisations handle the first half faster than the second. If a workflow approves new access without revoking prior entitlements, the process preserves unnecessary privilege and increases misuse risk. This is an identity lifecycle problem, not just a service desk problem. The control value comes from linking changes in job function to removal as well as provisioning, so the access state reflects the current role rather than the historic one.

Practical implication: Make entitlement removal a required part of role-change workflows, not a separate cleanup activity.

What ITSM metrics do and do not tell you about governance

Metrics such as resolution time, first-call resolution, agent productivity, SLA breach rate, and user satisfaction measure operational throughput. They do not, by themselves, show whether access was appropriate, whether a privilege should have existed, or whether a revocation happened on time. That distinction matters because a fast approval process can still be a weak governance process. For identity teams, the better question is whether service metrics are paired with entitlement quality measures, such as how often approvals are later challenged, how many requests map to approved roles, and how quickly obsolete access is removed.

Practical implication: Pair service-desk metrics with entitlement and revocation metrics so speed does not masquerade as control effectiveness.

NHI Mgmt Group analysis

ITSM is often mistaken for identity governance because it operationalises approvals, not because it proves entitlement. Ticket routing, prioritisation, and workflow automation reduce friction, but they do not determine whether access is justified, current, or properly removed. The governance risk is that organisations confuse process efficiency with access correctness, which leaves the identity model untouched. Practitioners should treat ITSM as an orchestration surface and nothing more.

Change management is the control point where identity lifecycle failures become visible. The article correctly notes that role changes should trigger both new access and revocation of old access, but many organisations stop at provisioning. That creates privilege residue, where yesterday’s access remains active after the job changes. In lifecycle terms, the failure is not the absence of a ticket. It is the absence of a complete mover process.

Service-desk metrics can hide governance debt when they are not paired with entitlement outcomes. Fast resolution time and strong first-call resolution may look healthy even while inappropriate access persists. That means the programme is measuring ticket velocity rather than identity correctness. The practical consequence is that IAM, IGA, and service management teams need shared definitions of success that include revocation timeliness and role-to-access alignment.

ITSM exposes the identity governance gap because it sits between request intent and access state. That gap is where many programmes discover that approvals are easy to automate, but ownership, lifecycle, and entitlement validity are harder to enforce. The result is a control model that moves faster without necessarily governing better. Teams should design around that gap instead of assuming workflow automation closes it.

Entitlement drift is the hidden failure mode behind accelerated service delivery. When requests are approved at scale without strong lifecycle linkage, access accumulates faster than it is removed. That changes the security problem from ticket handling to governance of persistent privilege. The implications are clearest for IAM and IGA teams: service delivery improvement is real only when access state follows role state.

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

ITSM request speed is not the same as identity control. Many programmes modernise the service desk first and only later discover that faster approvals do not reduce privilege drift. The real test is whether the workflow is anchored to role state, entitlement state, and revocation state.

Identity lifecycle discipline is what separates process automation from governance. When a move event triggers both new access and removal of obsolete access, ITSM becomes part of control enforcement rather than just ticket movement. Without that linkage, the service layer can scale the wrong access state faster.

Service-delivery teams should watch for a familiar pattern: improving SLA performance while access reviews still uncover stale permissions. That is the sign that operational efficiency has advanced more quickly than the identity model behind it.

For practitioners

• Tie access requests to authoritative role data Require request workflows to validate the employee’s current role, department, or designation before approval. Use that role data to determine whether the request is legitimate and to prevent ad hoc access grants that bypass governance.
• Make revocation part of every move process When a user changes role, trigger a paired review that removes no-longer-needed application access at the same time new access is granted. Do not leave revocation as a separate cleanup queue.
• Measure entitlement quality, not only ticket speed Add governance metrics for approval validity, revocation timeliness, and access-to-role alignment alongside resolution time and SLA measures. That prevents service metrics from masking stale permissions.
• Use workflow automation to standardise approvals Automate routing, assignment, and notifications only after the approval policy is explicit. Standardisation should reduce manual handling, but it should not replace identity decision logic.
• Review access after lifecycle changes Run access checks whenever an employee changes job function, manager, or team. The review should confirm both what access must be added and what inherited access should be removed.

Key takeaways

• ITSM can speed up access handling, but ticket workflow alone does not prove that access is appropriate or current.
• The strongest governance gap appears at role change, where new access is granted faster than old access is removed.
• Identity teams should judge ITSM by entitlement correctness and revocation discipline, not by resolution speed alone.

Key terms

• It Service Management: IT service management is the set of processes used to request, approve, deliver, and support internal technology services. In identity programmes, it often becomes the operational layer where access requests, approvals, and exception handling are recorded and enforced.
• Service Request Management: Service request management is the ITSM process for receiving, triaging, approving, and fulfilling routine requests. In identity programmes, it becomes the mechanism that decides who gets access to what, for how long, and under whose approval. Poor design turns it into a fast path to overprovisioning.
• Change Management: Change management is the controlled process used to manage role shifts, service changes, and operational updates. In identity governance, it is the trigger point where access should be added, reduced, or removed based on a new business need. If change handling is weak, privilege creep becomes normal.
• Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.

Deepen your knowledge

NHI governance, identity lifecycle management, and workload identity security 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.