TL;DR: Access requests still dominate IT support because fragmented approval paths, changing role needs, and manual handling create delay and risk across software access, according to Zluri's overview of IT support requests. The real issue is governance: access workflows reveal where identity controls, review processes, and accountability break down.
At a glance
What this is: This article frames access requests as an IAM governance issue, arguing that ticketing systems only record the workflow while the underlying problem is how access is approved, owned, and updated.
Why it matters: For IAM, IGA, and PAM teams, the issue is that access-request volume often signals broken entitlement design and fragmented accountability, not just an overloaded help desk.
Context
Access requests are a governance signal, not just a service desk queue. When employees need access for a new role or project, the real question is whether the organisation can decide, approve, and record that access consistently across applications, departments, and ownership boundaries.
In this topic, ticketing is only the transport layer for the request. The IAM problem is whether access reviews, role changes, and permission assignments are controlled well enough to avoid delays, overprovisioning, and fragmented accountability across the identity lifecycle.
Key questions
A: Manual handling usually slows approvals, creates inconsistent decision-making, and makes it easy for temporary access to linger long after the original need has passed. It also reduces visibility for security and IT teams, which makes auditability weaker. A ticketed workflow gives teams a repeatable process for granting, tracking, and revoking exceptions.
Q: Why do access requests become a governance risk as organisations scale?
A: Access requests become risky when approval paths multiply faster than policy control. If different teams approve access in different ways, entitlement decisions drift, records fragment, and offboarding becomes harder to prove. Scale exposes inconsistency, which is why the control problem is governance, not just response time.
Q: How should teams combine automation and human approval in access governance?
A: Use automation for bounded, repeatable decisions such as pausing obvious drift, triggering cleanup or routing low-risk changes. Keep human approval for exceptions, high-impact access and ambiguous context. The goal is to move routine governance earlier without removing accountability from material decisions.
Q: How do IAM teams know whether access governance is working?
A: IAM teams should look for fast revocation after role change or departure, accurate entitlement data, and low numbers of orphaned or over-provisioned accounts. If access creation is easy but removal is slow, governance is incomplete. The strongest signal is whether access still matches business need after the identity changes.
Technical breakdown
Why access requests expose entitlement design flaws
An access request becomes necessary when a user needs a permission that existing role design does not already provide. That makes the request a symptom of entitlement structure, not merely a workflow event. If roles are poorly aligned to job functions, every change in project, department, or responsibility turns into manual approval work. In practice, the volume and shape of requests reveal whether IAM governance is designing access around stable business roles or around ad hoc exceptions that ticketing then has to absorb.
Practical implication: Treat repeated request patterns as evidence that role design and entitlement modelling need review.
Why ticketing systems do not resolve access governance
A ticket can record who asked, who approved, and when access was granted, but it does not decide whether the access should exist in the first place. That governance decision depends on policy, ownership, and review criteria outside the ticketing tool. When approval paths are fragmented across teams or managers, the system becomes a routing layer for inconsistent decisions. The result is slower fulfilment, weak accountability, and permissions that remain in place longer than intended.
Practical implication: Separate request tracking from entitlement authority so approval logic is governed, not improvised in the ticket queue.
Why software access support links directly to lifecycle management
Software access support is not isolated from joiner, mover, and leaver processes. When an employee changes role, access should be adjusted as part of lifecycle governance rather than handled as a one-off support case. If the organisation relies on tickets to catch every change, access drift becomes inevitable because the state of the identity can change faster than the request process. This is where access requests reveal whether the IAM programme is maintaining current permissions or merely reacting after a user notices a problem.
Practical implication: Use lifecycle events as the trigger for access updates, and use requests only for exceptions.
Threat narrative
Attacker objective: The practical objective is not a classic intrusion but the accumulation of unmanaged access that weakens governance and increases the chance of inappropriate or excessive permissions.
- Entry occurs when a user changes role, joins a new project, or needs a new application and the existing entitlement model no longer matches the business need.
- Credential or permission access is then granted through manual approval paths, often across fragmented owners who apply inconsistent standards.
- The escalation point is overprovisioned or stale access, where permissions remain active beyond the user’s current job need because revocation and review are not tightly governed.
- The impact is operational delay, weak accountability, and greater exposure if access is granted too broadly or left unchanged after the role has moved on.
Breaches seen in the wild
- Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Access requests are the visible symptom of poor entitlement governance: When employees repeatedly need approvals for routine software access, the underlying problem is usually role design and ownership, not the ticketing workflow itself. Ticketing can move requests around, but it cannot fix misaligned access models or inconsistent decision rights. The governance question is whether access is being granted from policy and lifecycle logic, not from whatever queue receives the request. Practitioners should read request volume as a control signal, not an operational nuisance.
Centralising request intake does not centralise authority: A shared queue can reduce chaos, but it does not create a common access standard. If approvers, managers, and application owners are making different decisions for the same request type, the organisation has a governance consistency problem. This is where IAM and IGA need to define who can approve, under what criteria, and with what review evidence. The practitioner implication is simple: centralise the policy, not just the form.
Access requests reveal whether lifecycle management is real or decorative: Joiner, mover, and leaver controls are supposed to change access as roles change. When access requests become the main way people get the permissions they need, lifecycle management is not keeping pace with the organisation. That creates entitlement drift, longer fulfilment times, and weaker traceability. The practitioner conclusion is that access requests should be exception handling, while lifecycle automation remains the primary control plane.
Ticketing is a service management mechanism, not an identity governance mechanism: The article's core confusion is common in enterprises: treating request intake as if it were equivalent to access governance. It is not. A ticket can document the decision, but only IAM and IGA processes can define entitlement boundaries, approval policy, and recertification expectations. Teams should stop measuring governance health by queue efficiency alone and start measuring whether access decisions are consistent, reviewable, and tied to identity lifecycle state.
Named concept: request volume as governance telemetry: Persistent access-request demand is not just workload, it is telemetry about misaligned roles, unclear ownership, or fragmented approval chains. In mature programmes, recurring requests trigger entitlement redesign, not simply faster routing. The practitioner takeaway is to treat request patterns as evidence of where governance and actual operating roles have drifted apart.
What this signals
Request volume is governance telemetry: When the same access requests keep appearing, the organisation is seeing evidence of role mismatch, unclear ownership, or entitlement sprawl. That signal should drive access model redesign, not simply faster help desk handling.
Access requests should be the exception path in an IAM programme, not the primary mechanism for keeping permissions current. If mover and leaver changes depend on users noticing problems, the lifecycle process is already lagging the business.
Identity governance and service management solve different problems: Service management records and routes work, while IAM defines who should have what access and when. Conflating the two creates a queue that looks efficient while the underlying permission model remains weak.
For practitioners
- Map recurring access requests to role design gaps Review repeated requests by application, department, and job function to identify entitlements that should be role-based rather than manually approved.
- Separate approval authority from ticket routing Define who can approve access, which entitlement classes they own, and what evidence is required before the ticket can move to fulfilment.
- Trigger access changes from lifecycle events Tie mover and leaver events to access adjustment workflows so permissions are updated when job scope changes, not after users raise a support case.
- Use access requests as governance telemetry Trend request volume, repeat approvals, and exception frequency to identify where access policy, ownership, or role engineering needs redesign.
Key takeaways
- Access requests are often the most visible sign that entitlement design and ownership are not keeping pace with the business.
- Ticketing can manage intake, but it does not replace policy, approval criteria, or lifecycle-driven access adjustment.
- Teams should use request patterns to redesign roles and governance, then reserve manual handling for true exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing access approvals and entitlements across support workflows. |
| Recommendation — Define and review access entitlements centrally so ticketing does not become the source of authorisation. | ||
| CIS Controls v8 | CIS-5 — Account Management | Recurring requests and manual approvals point to account and access management gaps. |
| Recommendation — Standardise account and access management processes to reduce ad hoc approval handling. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article's governance problem is excess or misaligned access relative to role need. |
| Recommendation — Apply least privilege so access requests only fill true exceptions, not systemic entitlement drift. | ||
| NIST Zero Trust (SP 800-207) | 3.4 — Policy Decision Point | Access decisions need a governed decision point rather than fragmented ticket approvals. |
| Recommendation — Centralise access decisions in a policy engine instead of leaving approval logic in ticket queues. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Mover and leaver handling is part of the same lifecycle problem when access changes lag role changes. |
| Recommendation — Revoke or adjust non-human access when lifecycle state changes instead of waiting for support tickets. | ||
Key terms
- Access Request Management: The process of evaluating, approving, provisioning, and revoking access to applications or data through a governed workflow. In practice it sits between identity governance and operational IT, turning access decisions into auditable changes across directories, SaaS tools, and third-party services.
- 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.
- Lifecycle-Driven Access Management: Lifecycle-driven access management ties access changes to authoritative business events such as hire, transfer, promotion, or termination. It reduces reliance on manual ticketing and makes access changes more consistent with real employment status, which improves both operational efficiency and security control.
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.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org