Notifications
Clear all
Topic starter
12/06/2026 1:07 am
TL;DR: ITIL service request management standardizes access and routine change handling through logged, approved, and fulfilled workflows, reducing delays and operational friction according to Zluri. For IAM teams, the key issue is that request fulfilment is also an access governance control, so approval design, verification, and follow-up determine whether least privilege is actually enforced.
NHIMG editorial — based on content published by Zluri: Access Management ITIL Service Request Management: A 101 Guide
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern access requests in ITIL workflows?
A: Treat access requests as identity governance events, not just service desk tasks.
Q: Why do service request workflows create privilege creep?
A: Privilege creep appears when approvals are broad, fulfilment is automated, and nobody checks whether the granted access is still needed.
Q: What breaks when access requests are approved only by role?
A: Role-only approval is too coarse for modern identity environments because it ignores task scope, data sensitivity, and duration.
Practitioner guidance
- Define identity-changing requests separately Split service requests that change access, credentials, or entitlements from requests that only restore service or answer questions.
- Tighten approval criteria around scope and duration Require approvers to validate what access is needed, for how long, and whether the entitlement should expire automatically.
- Add post-fulfilment verification to every sensitive request Confirm that granted access works as intended, remains limited to the approved scope, and is removed when the task or need ends.
What's in the full article
Zluri's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step service request handling flow from initiation through closure
- Example access-request fulfilment steps for standard software and permission changes
- Automation-oriented workflow guidance for teams reducing manual ticket handling
- Platform-specific context on Zluri's access request capabilities
👉 Read Zluri's guide to ITIL service request management and access control →
Access requests and least privilege: what IAM teams are missing?
Explore further
12/06/2026 10:49 am
Request fulfilment is an identity control, not an administrative afterthought. The article treats service requests as an operations problem, but the deeper issue is entitlement governance. Every approval, fulfilment, and follow-up step changes the identity surface by granting or extending access. If that workflow is weak, the organisation is not merely inefficient. It is creating access decisions that outlive the business need that justified them. Practitioners should treat request management as part of the identity control plane, not just service desk workflow.
A few things that frame the scale:
- 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.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who should own access request governance across human and non-human identities?
A: Ownership should sit with the team accountable for the identity type being granted. Human access usually needs business and IT approval, while service accounts and automation should be owned by the application or platform team with clear offboarding responsibility. One generic workflow for all identities usually hides accountability gaps.
👉 Read our full editorial: ITIL service request management is becoming an identity control
