They can separate the request, approval, and actual access change across different systems. That separation makes it easy for standing access, delayed revocation, or untracked delegated administration to persist after the business need ends. The risk is highest when human approvals mask machine-executed privilege changes.
Why This Matters for Security Teams
Service management workflows are often treated as administrative plumbing, but they frequently become the control plane for identity change. When a ticket, approval, assignment, and execution step each live in different systems, the organisation can lose a single source of truth for who granted access, when it was changed, and whether revocation actually happened. That creates a governance gap even when the workflow looks compliant on paper. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which helps explain why workflow fragmentation so often becomes an audit issue later. NIST’s NIST Cybersecurity Framework 2.0 also reinforces that identity governance depends on traceable, timely control execution, not just documented intent. In practice, many security teams encounter standing access and delegated administration only after a review finds that the approval record and the real privilege state never matched.
How It Works in Practice
A service management workflow creates risk when it separates the request from the actual identity action. For example, a manager may approve a change in ITSM, but the access update is carried out later by an operator, a connector, or an automation account with broader privileges than the requester intended. If that execution step is delayed, bypassed, or done outside the ticketing system, governance evidence becomes incomplete.
The practical control goal is to bind the request, approval, and implementation to the same identity event. That usually means:
- capturing the business justification and approver in the ticket,
- executing the access change through an approved workflow or automation path,
- recording the resulting entitlement change in the identity system, and
- revoking access automatically when the service need ends.
This is where lifecycle discipline matters. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs frames onboarding, rotation, and offboarding as continuous controls, not one-time events. NIST CSF 2.0 emphasises the same operational expectation through access management and auditability. Where service workflows are used to approve machine identities, the evidence must show not just that someone said yes, but that the platform enforced the change and removed stale privilege afterward. The 52 NHI Breaches Analysis is useful here because it shows how frequently identity failures are tied to weak lifecycle control rather than a single technical exploit. These controls tend to break down when approvals are handled in one platform but entitlement changes are executed manually in another because the audit trail fragments across systems.
Common Variations and Edge Cases
Tighter workflow control often increases operational overhead, so organisations have to balance governance precision against speed of service delivery. That tradeoff is most visible in delegated administration, emergency access, and cross-functional approvals, where strict process can slow response if the workflow is not designed well.
Best practice is evolving, but current guidance suggests that the highest-risk edge cases are the ones that look “approved” while still leaving hidden privilege behind. Examples include:
- temporary access that is never retracted because the ticket closed before the actual change was verified,
- admin accounts created for a service desk team that outlive the change request,
- approvals for a human operator that implicitly authorize a machine to make broader changes, and
- shared automation credentials that are reused across multiple workflow steps.
This is why the operational question is not just “was it approved?” but “did the approval constrain the final identity state?” The 2024 ESG Report: Managing Non-Human Identities is relevant because compromised NHIs are already a common breach path, which makes delayed revocation and untracked delegation especially dangerous. Where service management is tightly integrated with IAM, the safer pattern is to treat the workflow as evidence and the identity platform as the system of enforcement. There is no universal standard for this yet, but teams should assume that any gap between approval and enforcement will become a governance exception eventually.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Service workflows often obscure standing access and delegated admin risk. |
| NIST CSF 2.0 | PR.AC-4 | Identity governance depends on timely access enforcement and revocation. |
| NIST AI RMF | Workflow-driven identity change needs accountable, traceable governance decisions. |
Assign ownership for identity approvals, execution, and audit evidence across the full workflow.
