Because the service desk workflow often becomes the place where access is requested, approved and tracked. If the platform cannot preserve accountability across the full lifecycle, access decisions become harder to audit, especially for service accounts, tokens and delegated access that rely on process discipline.
Why ITSM Becomes the Control Plane for NHI and IAM
ITSM platforms matter because they often become the system of record for who asked for access, who approved it, and when it was removed. That makes them part of the identity control plane, not just an operational workflow tool. For NHIs, this is especially important because secrets, service accounts, API keys, certificates, and delegated access can outlive the change ticket unless the process is tied to enforcement.
Current guidance suggests that accountability fails when approval, provisioning, and revocation are split across disconnected tools. NIST’s NIST Cybersecurity Framework 2.0 emphasizes governed, measurable access processes, while NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames lifecycle evidence as a recurring audit requirement. The practical issue is not whether a ticket exists, but whether the ticket can prove the identity state at each step.
NHIMG research shows the scale of the gap: in The 2024 Non-Human Identity Security Report, 88.5% of organisations said their non-human IAM practices lag behind or merely match human IAM. In practice, many security teams discover weak accountability only after a service account or token has already been used beyond its intended scope, rather than through intentional lifecycle design.
How ITSM Supports Access Requests, Approvals, and Revocation
In practice, ITSM matters most when it is integrated with identity, secrets, and provisioning workflows. A strong pattern is to treat the ticket as the approval artifact and the IAM or secrets platform as the enforcement layer. The ticket should not be the place where access merely gets documented; it should trigger a time-bound change in privilege, with the resulting state written back for audit.
For NHIs, that usually means linking service catalog requests to workload identity issuance, secrets rotation, or delegated access grants. The workflow should capture business justification, scope, owner, expiry, and rollback conditions. Where possible, the approval should map to policy-as-code in the target platform so the request is validated at runtime rather than relying on manual interpretation of the ticket.
- Use ITSM to request and approve access, but use IAM, PAM, or secrets management to enforce it.
- Record the workload owner, target system, TTL, and revocation trigger in the ticket.
- Synchronise change records with provisioning logs so the audit trail shows who approved, what changed, and when it expired.
- Tie exceptions to explicit expiry dates, especially for service accounts and API keys.
The operational value is strongest when the workflow supports Lifecycle Processes for Managing NHIs and when approvals can be compared against the risk patterns identified in Top 10 NHI Issues. These controls tend to break down when the ITSM platform is used as a static approval archive while the real access changes happen manually in cloud consoles or scripts, because the ticket no longer reflects the actual identity state.
Where ITSM Helps and Where It Falls Short
Tighter ITSM control often increases workflow overhead, requiring organisations to balance auditability against speed, especially in fast-moving engineering environments. Best practice is evolving, and there is no universal standard for how deeply an ITSM platform must integrate with identity automation before it becomes effective.
ITSM is helpful for traceability, but it does not solve weak identity design by itself. A ticket can approve a bad privilege model, a long-lived secret, or an over-broad role. It also cannot compensate for missing inventory, unclear ownership, or broken offboarding. For that reason, current guidance suggests using ITSM as one control among several: identity governance, secrets management, PAM, and recurring access review.
NHIMG’s Ultimate Guide to NHIs — What are Non-Human Identities is useful when teams need to distinguish the identity object from the workflow around it. The 52 NHI Breaches Analysis also shows why process records alone are insufficient when credentials are reused, over-privileged, or left active after the change window closes. ITSM adds value when it proves control intent and handoff accountability, but it falls short if it is treated as a substitute for actual enforcement.
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 | Covers NHI lifecycle governance, including request, approval, and revocation traceability. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be approved, tracked, and reviewed across the lifecycle. |
| CSA MAESTRO | Agentic and automated workflows need accountable orchestration across request and execution steps. |
Link ITSM approvals to enforceable NHI lifecycle actions and verify the recorded state matches the live one.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
