ITIL service request management is becoming an identity control

At a glance

What this is: This is a guide to ITIL service request management, with an emphasis on how access requests are logged, assessed, fulfilled, and closed.

Why it matters: It matters because service request handling is often where access governance is either enforced or quietly weakened across human, workload, and non-human identity programmes.

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.

👉 Read Zluri's guide to ITIL service request management and access control

Context

ITIL service request management is the controlled process for handling routine requests for access, standard changes, and service fulfilment. In identity terms, it is the layer where approvals, entitlement assignment, and closure records either reinforce least privilege or create standing access that no one revisits.

That matters because request workflows often become the practical control point for human access, service accounts, and downstream system permissions. When the workflow is vague, manual, or poorly verified, the organisation is not just slowing down IT. It is weakening the governance model that decides who or what gets access in the first place.

Key questions

Q: How should security teams govern access requests in ITIL workflows?

A: Treat access requests as identity governance events, not just service desk tasks. Every request should have a defined approver, a narrow scope, a time limit where possible, and a closure check that confirms the entitlement was actually needed and remains justified. Without those controls, request fulfilment becomes a bypass for least privilege.

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. The workflow records closure, but the entitlement remains active. Over time, that creates permanent access from temporary requests, especially in organisations that do not review grants after fulfilment.

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. The result is access that is technically authorised but broader than necessary. That weakens least privilege and makes later recertification harder because the original justification was never specific enough.

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.

Technical breakdown

How service request management turns into access governance

Service request management is not just a ticketing discipline. In identity operations, it becomes an access decision chain: capture the request, validate the requester, check entitlement rules, approve or deny, provision access, then close with evidence. The control value comes from consistency. If any one step is informal, the request process can bypass segregation of duties, approve excessive access, or leave no audit trail for later review. For IAM teams, the key distinction is between a request that changes service availability and a request that changes identity state. That second category is where governance risk lives.

Practical implication: map every request type that changes identity state to explicit approval, logging, and review requirements.

Why least privilege depends on the assessment step

Least privilege only works when the assessment step is specific enough to test business need, role, duration, and scope. In practice, many organisations approve by title or by broad function, which is too coarse for modern application access. The result is access that is technically approved but operationally broader than the request required. Automated fulfilment does not fix a weak decision model. It simply makes bad access faster to grant. For service accounts, app roles, and human users, the assessment step is the governance filter that prevents routine requests from becoming permanent privilege creep.

Practical implication: define approval criteria that include scope and duration, not just requester identity.

Why follow-up matters after access is granted

Follow-up is often treated as an administrative courtesy, but it is actually a control test. It checks whether the granted access still matches the original business need and whether the entitlement is still active, useful, and justified. Without this step, access requests become one-time events with no lifecycle discipline. That creates hidden accumulation, especially in organisations that provision quickly but rarely revoke. Follow-up also exposes whether the request process is acting as a lifecycle mechanism or only as a delivery mechanism. Identity governance fails when closure means the ticket is closed, but the access remains open.

Practical implication: require post-fulfilment verification for access that is time-bound, sensitive, or privilege-bearing.

NHI Mgmt Group analysis

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.

Least privilege breaks when request assessment is too coarse. The article describes evaluating requests against role and policy, but role-based approval alone is often too blunt for modern access environments. Many organisations still approve access by job title or broad team membership, which misses task scope and duration. That is how routine requests become standing privilege. The implication is that access request design must be granular enough to express real need, or it will keep manufacturing excess entitlement under the appearance of control.

Follow-up is the governance step that reveals whether access was temporary or permanent. The guide presents follow-up as a service quality measure, but from an identity perspective it is the only practical check on whether fulfilment created durable access. Without post-grant validation, organisations cannot distinguish successful service delivery from privilege accumulation. That failure mode is especially dangerous in environments where access requests are frequent and entitlement review is slow. Practitioners should interpret follow-up as evidence of lifecycle control, not customer satisfaction alone.

Service request workflows expose the boundary between human IAM and machine identity governance. The same request pattern often governs users, service accounts, and automated integrations, yet the approval logic is rarely adjusted for each actor type. Human requests may need manager validation, while non-human access often needs workload ownership, rotation, and revocation logic. When organisations use one generic workflow for all three, they blur governance boundaries and miss actor-specific risk. The practical conclusion is that request management should branch by identity type, not just by service catalog item.

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.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• NHI Lifecycle Management Guide shows why request fulfilment must connect to offboarding, not just provisioning.

What this signals

Request governance is becoming an identity boundary, not a service desk function. Organisations that keep access requests inside ITSM while separating them from IAM will continue to miss the lifecycle consequences of each approval. The stronger model is to make access fulfilment auditable, time-bound, and actor-specific, then tie it to entitlement review and revocation workflows.

The next maturity jump is not faster ticket closure. It is the ability to prove that every access grant had a specific owner, a specific reason, and a specific end state. That is the difference between operational efficiency and defensible identity governance.

Teams that already struggle with lifecycle discipline should start with the high-risk request classes first, especially privileged access and non-human entitlements. The control gap is usually not request volume. It is the absence of a repeatable way to end access cleanly after fulfilment.

For practitioners

• Define identity-changing requests separately Split service requests that change access, credentials, or entitlements from requests that only restore service or answer questions. Route identity-changing items through stronger approval, evidence capture, and closure checks.
• 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. Do not approve based only on job title or team membership.
• 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. Treat the verification record as part of the control evidence.
• Branch workflows by identity type Use different request paths for human accounts, service accounts, and automated integrations. Each should have distinct approval ownership, entitlement logic, and offboarding triggers.

Key takeaways

• ITIL service request management becomes an identity control when requests change access, not just service state.
• Broad approvals and weak follow-up are the main reasons routine fulfilment turns into privilege creep.
• Identity teams should separate human, service account, and automation requests so governance matches the actor type.

Key terms

• Service Request Fulfilment: The process of handling routine requests for access, information, or standard changes through a defined workflow. In identity programmes, fulfilment is also a governance event because it changes entitlements, credentials, or approvals that affect who or what can access systems and data.
• Least Privilege: An access principle that grants only the permissions required to complete a specific task. In practice, it depends on the quality of the request assessment step, the precision of the approved scope, and the ability to remove access once the need ends.
• Access Lifecycle: The full span of an entitlement from request and approval through provisioning, review, and revocation. Identity teams use lifecycle control to prevent temporary access from becoming permanent privilege and to ensure access is tied to a current business need.
• Identity-changing Request: A service request that alters an account, entitlement, credential, or permission set rather than simply restoring or reporting service. These requests need stronger governance because they directly affect access state and can create audit, compliance, and security risk.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Access Management ITIL Service Request Management: A 101 Guide. Read the original.