When one identity can both initiate and approve a sensitive workflow, the independent oversight model fails. That creates a direct path for fraud, errors, and concealed manipulation because the same person can create the event and validate it. SoD controls exist to prevent exactly that collapse of accountability.
Why This Matters for Security Teams
When a single identity can both create and approve sensitive transactions, segregation of duties collapses and the control no longer proves independent review. That is not just a process weakness. It removes the friction that exposes fraud, mistakes, and concealed privilege use before damage spreads. Current guidance from the NIST Cybersecurity Framework 2.0 still treats access governance as a core risk-reduction function, but in practice the failure is often operational, not policy-based.
NHI Management Group has documented how frequently identity controls fail in real environments, including the fact that 97% of NHIs carry excessive privileges and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to Non-Human Identities. Those numbers matter here because the same control gap that affects service accounts also affects human workflows when approval rights are over-assigned or not truly independent.
Security teams often assume that a second click or a second credential means a second control, but if both actions are bound to the same trust decision, the oversight is only cosmetic. In practice, many organisations discover this only after a disputed transaction, not through intentional control testing.
How It Works in Practice
The control objective is simple: the party that initiates a sensitive action must not be the same party that approves it. In practice, that means approval authority has to be technically and operationally independent, not merely separated by a checkbox in a ticketing workflow. The strongest implementations combine role separation, policy enforcement, and auditability so that approval cannot be self-issued or routed around.
This becomes especially important where sensitive transactions involve payments, access grants, release approvals, or configuration changes. A well-designed workflow usually includes:
- Distinct initiator and approver identities with no shared fallback path.
- Policy checks that block self-approval and detect delegated approval loops.
- Step-up verification for high-risk actions, especially when the transaction value or blast radius increases.
- Immutable logging so reviewers can reconstruct who initiated, who approved, and under what context.
- Periodic reviews to catch role creep, temporary exceptions, and emergency access that was never removed.
For identity-centric controls, the principles in Schneider Electric credentials breach are a reminder that over-trusted identities can be turned into an execution path when governance is weak. That same lesson maps cleanly to transaction approval: if one identity can both request and confirm, the organisation has no real independent validation. Framework guidance from NIST Cybersecurity Framework 2.0 supports least privilege, segregation of access, and continuous monitoring as operational controls rather than one-time setup tasks.
These controls tend to break down when emergency access, shared admin accounts, or poorly designed approval delegation rules allow the same person to bypass the intended second line of defence.
Common Variations and Edge Cases
Tighter separation of duties often increases workflow friction, so organisations have to balance control strength against operational speed. That tradeoff is real in small teams, on-call operations, and incident response, where the same person may need to initiate and advance a change to keep the business running.
Best practice is evolving, but current guidance suggests handling those cases with time-bound exceptions, explicit compensating controls, and post-event review rather than permanent dual-role assignments. If the environment is highly automated, the approval step should still be independent even if the workflow is machine-assisted. A system can auto-route approvals, but it should not auto-approve them without a separate policy decision.
Another edge case is delegated authority. A manager can delegate approval rights for continuity, but if delegation chains become long or opaque, the original segregation objective disappears. The same risk appears when approval is embedded in email threads or chat tools without strong identity binding. In those cases, the organisation may have process evidence, but not control evidence.
Where sensitivity is low and reversibility is high, some teams accept lighter review. Where funds, production access, or regulated records are involved, the safest posture is to treat self-approval as a control failure, not a convenience feature.
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 |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Addresses least privilege and access governance for sensitive approvals. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Excessive privileges and poor governance often enable self-approval paths. |
| NIST AI RMF | AI RMF governance maps to accountability and oversight for automated approvals. |
Reduce standing privileges and enforce distinct identities for initiating versus approving sensitive actions.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
