Use the service desk for request intake and communication, but require the identity system to enforce approval, provisioning, review, and removal. That keeps the operational workflow useful without letting it become the control itself. The goal is a request process that feeds identity governance rather than replacing it.
Why the service desk should stay an intake channel, not the control point
A service desk is useful for capturing demand, collecting business context, and keeping requesters informed. It becomes risky when teams let it approve access, create accounts, or remove access on its own authority. The control must sit in the identity and access process, so the request channel feeds governance rather than substituting for it.
That distinction matters because access requests are really governance events, not just tickets. Once the desk is treated as the decision-maker, approval evidence, entitlement logic, and removal timing become easier to bypass, and exceptions start to accumulate outside the identity record.
Teams should therefore design the service desk as a workflow entry point with clear handoffs to the identity system. The request can trigger the process, but approval, provisioning, access review, and deprovisioning should be enforced by the identity workflow and logged there.
What a sound app access request flow actually looks like
The clean model is request, validate, approve, provision, review, and remove. The service desk can manage the conversation and collect business justification, but the identity system should enforce who may approve, what role or entitlement is granted, how long it lasts, and when it is removed.
That separation keeps the access model consistent across apps and reduces ad hoc handling by individual analysts. It also makes it easier to apply the same entitlement rules to new requests, recurring access, and access changes after role movement.
For application access in particular, the identity system should be the source of record for the entitlement itself. If the desk is used to store approval notes or free-text exceptions, those notes should support the decision, not become the authorization state.
Where access is role-based, teams should map the request to a defined role or policy rather than to an analyst’s interpretation of the ticket. Where access is exception-based, the exception should be time bound, reviewable, and visible in the governance record so it can expire or be recertified.
Where teams usually get this wrong
The common failure is to confuse operational convenience with control. A queue that can route work quickly is not the same thing as an identity control plane, and a ticket comment is not the same thing as an entitlement record. When that line blurs, organizations lose traceability and make later review harder.
Another mistake is to let the service desk become the only place where approval exists. That creates weak evidence quality, especially when approvers are copied into tickets rather than bound to the workflow. It also makes removal brittle, because the request path may not reliably trigger deprovisioning after the original business need ends.
Teams also underestimate how often “temporary” access becomes standing access. If expiry and removal are not enforced by the identity process, temporary app access can remain active long after the ticket is closed.
Risk and Threat Considerations
When the service desk becomes the control, requesters can gain access through process gaps instead of governed entitlement logic. The main exposure is overprovisioning, weak approval evidence, and delayed removal, all of which increase the chance of unauthorized or excessive app access.
Failure mechanism: Analysts approve or provision access from the ticket alone, without a policy-backed entitlement, expiry, or recertification in the identity system, so the request channel quietly replaces the authorization control.
Impact: Excess access can persist after business need changes, reviews become harder to prove, and an attacker or insider who can influence the desk workflow may gain or retain access that should have been denied or removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | App access requests should grant only the entitlement needed for the role. |
| IA-5 — Authenticator Management | The workflow must manage credential issuance and removal, not just ticket notes. | |
| AU-2 — Event Logging | Approval, provisioning, and removal need auditable records beyond the service desk. | |
| Recommendation — Restrict each approved app request to the minimum necessary entitlement. Enforce lifecycle control for credentials tied to app access. Log each access decision and entitlement change in the identity system. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about separating request intake from access enforcement. |
| A.8.2 — Privileged access rights | App access requests often create elevated entitlements that need governance. | |
| A.5.16 — Identity management | Requests, approvals, and removals must be governed through identity records. | |
| Recommendation — Define access approval and enforcement in controlled access policies. Review and time-bound elevated app access through privileged access procedures. Maintain app access decisions in managed identity records and workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Access Management | The subject is about letting IAM govern app access decisions and lifecycle. |
| PR.AA-01 — Identities and Credentials | App access depends on controlled identities and credential lifecycle handling. | |
| Recommendation — Use IAM to enforce approval, provisioning, review, and removal. Ensure each app entitlement is tied to a managed identity and credential. | ||
Practitioner Guidance
What to verify: Confirm that every app access request maps to a governed entitlement, an approver with explicit authority, and a downstream provisioning step that writes to the identity record rather than the ticket. If the ticket can close without the identity state changing, the workflow is incomplete.
What good looks like: The service desk captures context and communicates status, while the identity process enforces approval, provisioning, periodic review, and revocation. A requester should be able to see progress in the desk, but the system of record for access must remain the identity platform.
Common mistake: Do not let analysts “fix” exceptions in the ticket because it is faster. Fast handling is useful only when the entitlement still exists in a controlled model with clear ownership, expiry, and evidence of who approved what.
Practitioner takeaway: Treat the service desk as the front door and the identity system as the lock, because app access is only trustworthy when the decision, the entitlement, and the removal step are all controlled in the same governed flow.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams govern access requests in service desk workflows?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?