How should security teams govern access requests in service desk workflows?

Why This Matters for Security Teams

Service desk workflows often look administrative, but they are really access-control decision points. If a request can change privileges, create a new service account, or approve a secret without policy, the workflow becomes a bypass around governance rather than a control. That is especially risky for NHIs, where access is often long-lived, shared across systems, and poorly observed.

NHI exposure is already common: in NHI Management Group’s Ultimate Guide to NHIs, only 5.7% of organisations report full visibility into their service accounts. This is why ticket-based approvals need the same discipline as IAM policy. The question is not whether a ticket exists, but whether the approval path maps to a real entitlement, a real owner, and a real revocation process. The NIST Cybersecurity Framework 2.0 reinforces that access governance belongs in repeatable, auditable control processes, not informal exception handling.

In practice, many security teams only discover weak approval paths after a service account has already been over-granted and used outside the original request.

How It Works in Practice

Governance starts by treating the service desk as an enforcement layer, not a forwarding queue. Every access request should be checked against a pre-approved entitlement catalogue that matches live systems, data classifications, and ownership. If the catalogue does not exist, the approval is inherently subjective. For NHIs, that subjectivity is dangerous because requests often involve API keys, service accounts, OAuth grants, certificates, or automation credentials that do not behave like human logins.

A workable process usually includes:

• Request templates that force the requester to name the workload, system, business purpose, and time limit.
• Policy-based approval rules that distinguish standard access from elevated, break-glass, or exception paths.
• An accountable approver tied to the application or data owner, not just a queue manager.
• Just-in-time issuance where possible, with expiry aligned to the task instead of indefinite access.
• Automatic revocation and evidence capture when the ticket closes, the task ends, or the approval window expires.

The OWASP Non-Human Identity Top 10 is useful here because it frames NHI risk as a lifecycle problem, not just a credential problem. NHI Management Group’s Lifecycle Processes for Managing NHIs also emphasises that access should be created, validated, rotated, and removed as part of one control chain. Current guidance suggests service desk approvals should be backed by policy-as-code where possible, so the request engine evaluates context at runtime instead of relying on static rubber-stamp rules. These controls tend to break down in legacy environments where the desk can approve access but cannot enforce downstream revocation in the target system.

Common Variations and Edge Cases

Tighter approval controls often increase ticket latency and operational overhead, so organisations have to balance speed against assurance. That tradeoff is real, especially for incident response, platform engineering, and automation-heavy environments where every extra approval can slow restoration or deployment.

There is no universal standard for every service desk pattern yet, but the safe default is to separate routine access from exceptional access. Routine NHI requests should be mapped to pre-approved roles or short-lived entitlements. Exception requests need stronger scrutiny, explicit expiry, and post-approval review. This is especially important when the request touches third-party integrations, shared credentials, or tools that can chain access across systems. NHI Management Group’s Regulatory and Audit Perspectives highlights why evidence quality matters: if an auditor cannot trace who approved what, when, and under which policy basis, the workflow will not stand up to scrutiny.

For organisations maturing their program, the practical goal is not to eliminate the service desk. It is to make sure the desk can only approve what policy already permits, and that every approval has a clear offboarding path. When those links are missing, the workflow becomes a permanent exception factory rather than a control.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern Active Directory service accounts?
• How should security teams govern access requests for both users and service accounts?