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.
When ITSM approvals are doing IGA’s job, what actually stops working?
An ITSM queue can confirm that someone asked for access and that a manager clicked approve, but it does not prove the access is appropriate. The control breaks when approval is treated as evidence of entitlement rather than just a request checkpoint. That means the process can miss role fit, least privilege, and whether the account should exist at all.
In practice, this shifts the control objective from governing access to expediting work. A service desk workflow is good at routing, timing, and auditability of the request path, but it is weak at deciding whether the entitlement is justified by job role, temporary need, segregation of duties, or current lifecycle state. The result is that the organization can look operationally disciplined while still accumulating standing access.
That is why approval-only patterns often mask privilege creep. Each ticket may appear defensible in isolation, yet the accumulated outcome can still be excessive access, stale access after a role change, or access that was never recertified against business need. IAM and IGA Basics is a useful reference point for separating request handling from entitlement governance, and Access Reviews and Certification Guide shows why access needs periodic validation rather than one-time approval.
Why ITSM approval trails are not a substitute for entitlement decisions
The core failure is conceptual: approval confirms a workflow event, not a security judgment. In a mature access model, the decision should answer whether the requester should receive this specific access, for this duration, under this role or business justification, with this level of privilege. An ITSM approval often captures only a manager’s willingness to unblock work, which is not the same thing as a governed entitlement decision.
This matters because entitlement decisions need context that a generic ticket flow usually does not enforce. The control should consider the user’s current role, whether the request matches a standard role package, whether the access creates SoD conflict, and whether the access should expire automatically. If those checks are absent, the ticket system becomes a paper trail for access growth rather than a control that constrains access.
When organizations confuse approval with authorization, they also lose consistency. Different approvers make different decisions, exceptions become normal, and similar users end up with different access profiles depending on who approved the ticket. Role Mining and Role Design Guide is relevant here because the decision should be anchored in a maintainable role model, not improvised one ticket at a time.
What entitlement sprawl looks like when the service desk is the gatekeeper
Approval-led access often produces slow, visible sprawl rather than an immediate failure. Over time, people accumulate access outside their current need, legacy entitlements survive role changes, and exceptions remain in place because the workflow is optimized to complete requests, not to remove unneeded access. The symptom is that access reviews later find far more privilege than the business can explain.
The practical danger is that a well-run ITSM process can create false confidence. The ticket has an approver, a timestamp, and a closure note, so it looks controlled. But if the workflow does not validate entitlement scope, lifecycle state, and ongoing need, then the organization has simply formalized the wrong decision point. Joiner-Mover-Leaver (JML) Guide is the right complement because lifecycle events should remove or adjust access automatically, rather than waiting for a future approval to notice the problem.
That is also where segregation of duties failures persist. A request can be approved because it seems operationally useful, yet still create a toxic combination or bypass a compensating control. Segregation of Duties (SoD) Guide supports the point that access decisions need conflict analysis, not just managerial consent.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Approval-only access breaks account lifecycle and entitlement governance. |
| AC-6 — Least Privilege | The issue is excessive access surviving approval instead of privilege minimization. | |
| AC-5 — Separation of Duties | Ticket approvals can miss toxic combinations that SoD should prevent. | |
| Recommendation — Use AC-2 to bind access to managed account lifecycle events and recurring review. Apply AC-6 to constrain entitlements to the minimum access needed for the role. Use AC-5 to block conflicting access combinations before fulfillment. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access decisions must be governed by policy, not just service-desk approval. |
| A.5.18 — Access rights | The question concerns how access rights are granted, reviewed, and removed. | |
| Recommendation — Define access policy criteria that determine entitlement eligibility, scope, and review. Require access rights to be approved, provisioned, reviewed, and revoked under one governance model. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is control of access grants, reviews, and removal rather than ticket handling. |
| Recommendation — Centralize access grant and removal decisions under access control management. | ||
Practitioner Guidance
What to prioritize: Treat ITSM as the request intake and routing layer, not the entitlement authority. The control owner should be identity governance, because that layer can verify role fit, entitlement boundaries, expiry, and recertification.
What to verify: Check whether an approval actually triggers a policy decision, or whether it only forwards the request to fulfillment. If the process cannot show role-based rules, lifecycle-aware revocation, and periodic review, it is not governing access.
Common mistake: Using a manager’s approval as a proxy for least privilege. That shortcut is attractive because it is fast, but it usually preserves standing access and makes cleanup harder later.
Practitioner takeaway: The right question is not “who approved it?” but “what entitlement rule justified it, and how will it be removed when that need ends?”
Related resources from NHI Mgmt Group
- What breaks when data governance is used as a substitute for AI agent identity controls?
- Why is it important to integrate identity and data governance?
- What breaks when AI privacy controls are used as a substitute for access governance?
- What breaks when identity governance relies on spreadsheets and email approvals?