They fail because they are easy to spoof, hard to bind to the exact request, and often lack proof that the approver was the intended person on the intended device. Separation of duties only works when the approval is cryptographically linked to the action, the identity, and the expiry window.
Why This Matters for Security Teams
Email and chat approvals look convenient, but they are weak evidence for separation of duties because the approval channel is not the same thing as the approving identity, the approving context, or the approved action. For privileged change control, access grants, and financial or production releases, security teams need proof that an approver was authorised for that specific decision at that specific time. That is why current guidance increasingly aligns approval workflows with NIST Cybersecurity Framework 2.0 concepts such as controlled access and auditable oversight, rather than relying on informal messages.
The practical failure is simple: messages can be forwarded, copied, forged, or approved out of context, and those records rarely bind the approver to the exact request payload or expiry window. NHIMG research on The State of Secrets in AppSec shows how confidence often outpaces actual control maturity, which is the same pattern seen in approval sprawl. In practice, many security teams discover weak separation of duties only after an incident review shows that the “approval” was just a message thread, not a verifiable control.
How It Works in Practice
Effective separation of duties requires approvals to be bound to the transaction, not merely to the conversation around it. That means the approval event should reference a unique request ID, the exact change set or access scope, the time window, and the approver’s authenticated session. A message in Slack or email may be useful as a notification, but it should not be the control itself.
Practitioners usually implement this by moving approvals into a workflow system that supports strong authentication, immutable audit trails, and policy checks at the point of action. For higher-risk approvals, best practice is evolving toward cryptographic linkage: the approver signs or confirms the request inside a system that records identity, device context, and expiry, rather than replying “approved” in a thread. In NHI-heavy environments, that same logic applies to service accounts and automation, where approval should gate credential issuance or privilege elevation rather than merely record intent.
- Bind approval records to a specific change ticket, access request, or deployment artifact.
- Require re-authentication or step-up authentication for sensitive approvals.
- Use time-limited approvals so the decision expires if the request is not executed promptly.
- Log who approved, from where, on what device, and for which exact action.
- Prevent the approver from also executing the same control action when duties must remain separated.
For zero trust and workflow governance patterns, the NIST Cybersecurity Framework 2.0 is a useful baseline, while NHIMG’s coverage of secret exposure and operational leakage in DeepSeek breach is a reminder that informal trust channels often fail to scale. These controls tend to break down when approvals are handled across fragmented tools because the request, the approver, and the execution record no longer share a common trust boundary.
Common Variations and Edge Cases
Tighter approval control often increases workflow friction, requiring organisations to balance auditability against operational speed. That tradeoff is real: emergency changes, small teams, and cross-functional operations can make rigid approval chains impractical if they are designed without exception handling.
Current guidance suggests three common edge cases deserve special treatment. First, emergency or break-glass approvals should be pre-authorised, heavily logged, and time-boxed, not improvised in chat. Second, low-risk requests may tolerate lighter controls, but only if the request scope is narrow and the business impact is genuinely limited. Third, distributed teams often rely on asynchronous communication, so approval tooling must preserve evidence even when the approver is offline or in another timezone.
There is no universal standard for this yet, but the direction is clear: the control must prove intent, identity, and scope together. Email and chat can still support the process as notification layers, yet the actual SoD decision should live in a system that can resist spoofing, replay, and ambiguity. That is the dividing line between a procedural checkbox and a defensible control.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Approval workflows must enforce least privilege and verified access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Weak approvals often enable unauthorized use of secrets or privileged NHI actions. |
| CSA MAESTRO | TBD | MAESTRO addresses governance patterns for trusted agent and workflow authorisation. |
Use workflow policy checks and immutable logging to ensure each approval is bound to the exact action.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
