Both. ITSM defines the workflow, but IAM defines who or what may act inside it, on which identities, and under what conditions. When an agent can reset passwords, grant access, or support onboarding and offboarding, the control boundary sits at the intersection of service governance and identity authorisation.
When self-resolution belongs to service workflow design
Self-resolution is not just a help desk feature. It is a service journey that defines what requests can be completed without a human approver, how exceptions are handled, and which events must be logged for audit and recovery. That makes ITSM responsible for the workflow design, queueing, approvals, service ownership, and measurable service outcomes.
The practical question is whether the flow is framed as a ticketing convenience or a governed service path. If the goal is to reduce resolution time, standardise handling, and keep a consistent customer experience, ITSM is the right control plane for the process itself. The identity decision still sits underneath that process, because the workflow must know who is asking and what entitlement change is being requested.
When teams treat self-resolution as “just automation,” they usually miss the operating model requirements around ownership, exception handling, and auditability. A well-run ITSM process gives you a clear path for service catalog design, approval routing, and evidence that the request was completed under policy rather than by ad hoc manual action.
Where IAM becomes the controlling boundary
IAM defines the authority behind the workflow: who may reset a password, who may approve access, whether an agent can act on behalf of a user, and whether the action is valid for that identity, application, or role. A self-resolution journey becomes an IAM control problem the moment it changes authentication state, grants or revokes access, or touches privileged lifecycle events such as onboarding and offboarding. For a broader identity-control view, see NHIMG’s Ultimate Guide to NHIs section on non-human identity types and Lifecycle Processes for Managing NHIs for lifecycle governance patterns.
This is where control boundaries matter most. If the self-resolution flow can act on identities, secrets, tokens, or entitlements, then the control is no longer only about case handling. It becomes a question of least privilege, delegated authority, step-up conditions, and whether the requestor is allowed to trigger the change without weakening the assurance of the underlying identity state.
That is why identity and service management should be designed together, not handed off in sequence. ITSM can own the ticket, but IAM must own the conditions under which the ticket may change authentication or authorization state. In practice, that means explicit policy on which request types are self-service, which require additional verification, and which are blocked from automated completion entirely.
How to split the control model without creating gaps
The cleanest model is to assign ITSM responsibility for the workflow and service evidence, while IAM owns the enforcement points and authoritative identity decisions. For example, a password reset request may be initiated through the service desk, but the reset policy, identity verification, session invalidation, and recovery rules should be enforced by IAM. The same logic applies to joiner, mover, and leaver events, where the workflow may orchestrate the steps but IAM determines the entitlement changes.
This separation also helps when self-resolution is delivered by an agent or automated assistant. The workflow can collect the request, but the agent should only be able to perform actions that IAM explicitly permits. NHIMG’s Identity Security Programme Guide and IAM and Identity Provider Buyer’s Guide are useful references when you need to separate operating-model ownership from control enforcement and identity-platform capabilities.
The best pattern is to make the workflow visible and auditable, but make the identity decision authoritative and narrowly scoped. That means a self-resolution action should succeed only when the relevant identity policy, assurance level, and entitlement boundary are satisfied. If those conditions are not explicit, the organisation has created a process shortcut that can quietly become a privilege path.
Risk and Threat Considerations
Self-resolution increases exposure when service convenience is allowed to outrun identity assurance. If a workflow can reset credentials, approve access, or move users between access states without strong verification and approval boundaries, the likely failure mode is privilege abuse, account takeover, or inappropriate entitlement change.
Failure mechanism: The request path becomes an alternate control plane, so an attacker, insider, or overly broad automation can use the self-service process to bypass stronger IAM checks and complete a sensitive change with insufficient assurance.
Impact: The organisation can end up with unauthorized access, weakened audit evidence, and faster blast radius when a workflow is misused at scale.
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, CSA Cloud Controls Matrix 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 | IA-5 — Authenticator Management | Self-resolution may reset or issue credentials, so authenticator lifecycle controls apply. |
| AC-6 — Least Privilege | Workflow actors and automation should only hold the minimum authority needed to self-resolve. | |
| IA-2 — Identification and Authentication (Organizational Users) | Self-resolution often depends on verifying the requesting user before a sensitive change. | |
| Recommendation — Control reset and issuance paths under IA-5 so identity changes remain governed. Limit workflow and agent permissions to the smallest allowed access scope. Require robust user authentication before permitting identity-affecting self-service. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Self-resolution changes access paths, so access control policy must define allowed actions. |
| A.5.16 — Identity management | The question hinges on who may act within the workflow and under what identity conditions. | |
| Recommendation — Define and enforce access-control rules for self-service identity changes. Govern identity assignments and authority boundaries across the workflow. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Self-resolution combines service workflow with identity and access governance. |
| Recommendation — Use IAM controls to constrain self-service actions that affect access or privilege. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions Management | Self-resolution affects who can do what, so permission governance is central. |
| Recommendation — Review and enforce permission changes through controlled approval and policy. | ||
Practitioner Guidance
What to verify: Confirm that every self-resolution action is mapped to a named owner, a specific identity decision, and an explicit policy condition. If the workflow can alter authentication, access, or privilege state, it should have a stronger control test than a simple ticket closure check.
Decision rule: If the action changes who can act, what they can access, or how long they retain access, treat IAM as the control authority and ITSM as the orchestration layer. If it only manages routing, status, or communications, ITSM can own it without expanding identity control scope.
Practitioner takeaway: The right boundary is not “ITSM versus IAM,” but “workflow orchestration versus identity authority.” The safer design keeps service convenience inside a process that IAM can still constrain, verify, and revoke.