ITSM-native approval means the authorisation for a change lives inside the service-management workflow rather than in an external review trail. For identity systems, this binds the business decision, the configuration event, and the audit evidence into one chain of custody.
Expanded Definition
ITSM-native approval places the approval decision inside the same service management system that records the change, assigns the work, and preserves the audit trail. In NHI operations, that means a service account update, API key rotation, or privilege change is not merely documented after the fact; it is authorised through the workflow that executes it.
This distinction matters because the approval is part of the control, not a detached email, chat thread, or spreadsheet. For identity governance, ITSM-native approval creates a single chain of custody that can be reviewed against policy and change history. That aligns closely with the governance emphasis in the NIST Cybersecurity Framework 2.0, where traceability and accountability support resilient change handling. In practice, definitions vary across vendors on whether embedded sign-off, delegated CAB review, or automated policy gates count as “native,” so organisations should verify that the approval is actually enforced within the system of record.
The most common misapplication is treating a ticket comment or a linked approval email as sufficient authorisation when the configuration change can still be executed outside the ITSM workflow.
Examples and Use Cases
Implementing ITSM-native approval rigorously often introduces workflow latency, requiring organisations to weigh faster remediation against stronger evidence of authorisation.
- A platform team requests rotation of a production API key, and the ITSM record requires approver sign-off before the secrets manager updates the credential.
- A service account is granted temporary elevated access through a change ticket, with the approval, implementation, and rollback steps captured in one record.
- An SRE opens a standard change for certificate renewal, and the ITSM system enforces policy checks before the automation job runs.
- A security team reviews the Ultimate Guide to NHIs to compare approval handling with lifecycle controls such as rotation, revocation, and offboarding.
- Change managers use the workflow to prove who authorised a service-account privilege increase, rather than reconstructing decisions from chat logs after the event.
In mature environments, the approval step is also used to trigger downstream evidence collection, so the record itself shows who approved, what changed, when it changed, and which control validated it. That pattern is especially useful when integrating with zero-trust programs and service-account governance models described in the NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
ITSM-native approval reduces ambiguity in environments where NHIs can outnumber human identities by 25x to 50x, and where 97% of NHIs carry excessive privileges according to the Ultimate Guide to NHIs. When approvals live outside the operational system, audit evidence fragments across email, chat, and manual notes, making it harder to prove that privileged access was intentionally granted and later revoked.
This matters most when service accounts, API keys, and automation agents are allowed to change production state. If approval and execution are separated, teams can lose the ability to show whether a risky change was sanctioned, emergency-only, or simply bypassed. That weakens incident response, complicates compliance, and makes privilege review less reliable. The control also supports broader governance expectations in the NIST Cybersecurity Framework 2.0, where accountable change management reinforces secure operations.
Organisations typically encounter the consequences only after a privileged change is disputed, a service account is abused, or a post-incident review cannot reconstruct who approved the action, at which point ITSM-native approval becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Approval workflow integrity affects how NHI changes are authorised and evidenced. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access changes need auditable approval and traceable assignment. |
| NIST Zero Trust (SP 800-207) | DP-3 | Zero Trust depends on controlled, reviewable authorization paths for privileged actions. |
| NIST SP 800-63 | Identity proofing and authentication assurance inform who can approve sensitive changes. | |
| OWASP Agentic AI Top 10 | A2 | Agentic systems need governed action approval before tool use or state change. |
Keep NHI changes inside the system of record and require approver evidence before execution.
Related resources from NHI Mgmt Group
- When should organisations require human approval for an AI agent action?
- What is the difference between identity governance and ITSM for access control?
- When does human approval become ineffective for AI agent security?
- How should security teams prioritize vulnerabilities in cloud-native applications?
