Access decisions should remain with the control owner, not with whichever team happens to receive the ticket. The service desk can collect and route requests, but IAM, PAM, or application owners should approve entitlements according to documented policy and risk.
Why This Matters for Security Teams
When service desk tools are placed in the middle of access workflows, the risk is not the ticket system itself. The risk is authority drift: requests get routed to whichever team is convenient, while approval responsibility becomes unclear. That is how excessive access, stalled revocation, and policy exceptions accumulate. NHI Management Group’s Ultimate Guide to NHIs shows how often organisations struggle with visibility and control over non-human access, which is exactly where service desk handling can become a governance gap rather than a process aid. OWASP’s OWASP Non-Human Identity Top 10 also highlights that approval and lifecycle failures are common attack paths for credentials and service accounts.
The key point is simple: the service desk can intake, enrich, and route, but it should not become the decision-maker for entitlements it does not own. Access authority belongs with the control owner because that team understands the application context, the risk of the entitlement, and the compensating controls already in place. In practice, many security teams encounter over-provisioning only after a ticket trail has already been treated as an approval trail.
How It Works in Practice
In a sound operating model, the service desk acts as a workflow layer, not an authorisation authority. It collects the request, validates minimum required data, confirms identity of the requester where needed, and routes the request to the correct approver. The approver should be the control owner, usually IAM for identity lifecycle decisions, PAM for elevated access, or the application owner for business entitlement approvals. This separation is consistent with the governance direction in the 52 NHI Breaches Analysis, where weak ownership and poor lifecycle discipline repeatedly show up in compromise paths.
Operationally, the workflow should answer four questions before approval:
- Who owns the resource or entitlement being requested?
- What policy or risk rule justifies approval or denial?
- Is the access time-bound, reviewed, and revocable?
- Does the request require PAM, JIT provisioning, or a secondary review?
This model works best when ticket categories map to named owners, approval rules are documented in policy-as-code or service catalog logic, and revocation is tied to the same system of record. NIST’s Cybersecurity Framework 2.0 reinforces the need for clear governance and accountable access management, while the OWASP Non-Human Identity Top 10 underscores that credential misuse often starts with weak process ownership. These controls tend to break down in large shared-service environments where a central desk is measured on ticket closure speed rather than entitlement risk.
Common Variations and Edge Cases
Tighter approval routing often increases friction, requiring organisations to balance speed against decision quality. That tradeoff becomes visible when teams want the service desk to “just approve” low-risk requests, especially after hours or during incidents. Current guidance suggests that delegating the decision is acceptable only when a documented policy explicitly defines the entitlement, risk threshold, and delegation scope. Even then, the service desk is still a process executor, not the policy owner.
There are a few common edge cases. For break-glass access, the service desk may trigger the workflow, but PAM or the incident commander should own the decision and post-event review. For repetitive low-risk requests, pre-approved catalog items can reduce manual work, but the approver should still be the accountable control owner for that entitlement class. For NHI-related requests, the service desk should never independently approve long-lived secrets, API keys, or service account privileges without IAM or application-owner sign-off. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is explicit that ownership gaps and poor visibility are recurring risk multipliers.
Where this guidance breaks down is in outsourced service desks with no direct line to the control owner, because ticket queues then become the de facto approval authority even when policy says otherwise.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Ownership and approval gaps often drive excessive NHI access. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed by accountable owners, not ticket handlers. |
| CSA MAESTRO | Agentic workflows need clear human and system accountability for access decisions. |
Tie each entitlement to a named owner and require policy-based approval before granting access.
Related resources from NHI Mgmt Group
- Who should own access decisions when service management and IAM are connected?
- Who should own database access accountability when contractors or service teams are involved?
- Why do SSO tools often fail to solve access governance on their own?
- What breaks when service desks handle both support tickets and access decisions?
