How should security teams handle access requests when ITSM tools are already in place?

Use ITSM as the intake and routing layer, but move entitlement decisions into a policy-controlled access governance process. The approval should determine the correct role, permission level, and expiry condition before access is provisioned. Otherwise, the organisation measures workflow completion, not access correctness.

Why This Matters for Security Teams

ITSM is useful for intake, evidence collection, and routing, but it does not decide whether access is actually safe. When requests stay inside ticket workflows, teams often confuse process completion with entitlement correctness. That gap is especially risky for NHIs, where access is frequently machine-to-machine, long-lived, and reused across systems. NHI Management Group’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which is a strong signal that approval workflows alone are not enough.

The practical issue is that a ticket can confirm someone asked for access, but it cannot prove the requested role matches the workload, the duration, or the real business need. That is why current guidance increasingly separates request handling from policy decisioning. Security teams should treat ITSM as the front door and access governance as the control point, with entitlement decisions checked against least privilege, expiry, and operational context. In practice, many security teams encounter privilege creep only after an audit finding or incident review, rather than through intentional access design.

How It Works in Practice

The cleanest pattern is to keep ITSM as the intake and orchestration layer, then connect it to a policy-controlled access governance engine that makes the actual entitlement decision. The ticket should capture who is requesting access, for which system, for what purpose, and for how long. The governance layer then evaluates that request against approved roles, approved permission sets, and expiry rules before any provisioning occurs.

This matters because access correctness is more than approval. A manager or approver may validate the business need, but the system still needs to translate that need into the right account, scope, and time limit. For human users, that may mean a standard role with OWASP Non-Human Identity Top 10 style controls around secret handling, rotation, and over-privilege. For NHIs, the same logic should be tighter: request approval should drive just-in-time provisioning, short-lived credentials, and explicit revocation when the task ends.

• Use ITSM to collect request context and approvals.
• Map the request to a policy, not to a free-form entitlement.
• Issue only the minimum role or permission set needed.
• Attach an expiry condition at provisioning time.
• Revoke or rotate access automatically when the approved window closes.

That operational split aligns with the principle behind The State of Non-Human Identity Security, where only 1.5 out of 10 organisations report high confidence in securing NHIs. The confidence gap is a sign that workflow automation is still being mistaken for access governance. These controls tend to break down in environments where ITSM approvals are highly customised but entitlement catalogues, role definitions, and revocation automation are missing or stale.

Common Variations and Edge Cases

Tighter approval control often increases operational overhead, requiring organisations to balance speed against decision quality. That tradeoff is manageable, but only if the access model is designed around standard request types rather than one-off exceptions. For routine access, pre-approved roles and policy templates work well. For higher-risk systems, current guidance suggests adding a second policy check for sensitivity, data class, or blast radius before provisioning.

There is no universal standard for this yet, especially when ITSM, IAM, PAM, and secrets platforms are loosely integrated. Some teams use ITSM only for humans and separate automation for NHIs; others route both through the same intake but enforce different decision rules. The key is not the ticketing tool itself, but whether the entitlement decision is deterministic, reviewable, and revocable. The 52 NHI Breaches Analysis is useful here because it reinforces a recurring pattern: access problems usually emerge when ownership, rotation, and expiry are treated as downstream tasks instead of part of the approval decision.

Edge cases include emergency access, third-party support accounts, and service identities tied to CI/CD or production automation. Those cases often need separate policy paths, because a human approver may not understand the real dependency chain. Best practice is evolving toward request intake in ITSM, policy decisioning in governance, and provisioning through controlled automation rather than manual fulfillment.

Related resources from NHI Mgmt Group

• How should security teams prepare data access governance before enabling GenAI tools?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams handle risks from AI browser extensions?