Who is accountable when a control failure lets one identity approve and execute the same transaction?

Accountability usually sits with the organisation that defined the workflow, the access owners who approved the entitlement, and the control owners who failed to enforce SoD. Governance frameworks expect traceable decisions, so unclear ownership is itself part of the control failure.

Why This Matters for Security Teams

When one identity can both approve and execute the same transaction, the issue is not just a missing policy check. It is a separation of duties failure that erodes non-repudiation, weakens auditability, and makes incident response slower because the control path no longer proves who decided what. That risk shows up in privilege design, workflow design, and control ownership at the same time. NIST Cybersecurity Framework 2.0 frames this as an accountability problem, not a purely technical one.

For NHI-heavy environments, the same pattern appears when service accounts, agents, or automation tokens are allowed to request, approve, and complete work without a second control boundary. NHIMG coverage of real-world compromise patterns in the 52 NHI Breaches Analysis shows how quickly weak identity boundaries turn into operational failure, especially where access is broad and workflow ownership is vague. The practical lesson is that accountability begins before the transaction is executed, when roles and controls are still being defined.

In practice, many security teams discover the missing separation only after a transaction has already been both approved and executed by the same identity.

How It Works in Practice

Effective separation of duties is enforced by designing the workflow so no single identity can complete every sensitive step. That usually means splitting request, approval, execution, and reconciliation across distinct identities, distinct control owners, or distinct runtime states. For human users, this is commonly handled through PAM and workflow approvals. For service accounts and agents, the design must go further: the identity that initiates the action should not also carry the authority to bless it.

Current guidance suggests using policy-as-code and runtime authorization rather than relying only on static role definitions. NIST CSF 2.0 and zero trust guidance both support this direction, because access should be evaluated in context at the moment of use. In non-human identity programs, the Ultimate Guide to NHIs emphasises that identity, ownership, and credential lifecycle must be explicit enough to support traceable decisions. That is especially important when secrets, tokens, or API keys are used to trigger downstream systems.

• Separate the approving identity from the executing identity wherever the transaction creates material risk.
• Assign a control owner who can prove the SoD rule is enforced in the workflow engine, not only in policy documents.
• Use short-lived credentials and constrained entitlements so delegated execution cannot be reused as approval authority.
• Log both the decision and the execution path so audits can reconstruct who authorised what, and when.

For transaction-heavy environments, the most reliable pattern is to make approval a different trust event from execution, even if the same team operates both controls. These controls tend to break down when orchestration platforms cache long-lived privileges and bypass human approval layers because the workflow engine itself becomes the de facto approving authority.

Common Variations and Edge Cases

Tighter separation of duties often increases operational friction, so organisations have to balance resilience against workflow speed. That tradeoff is real, especially in incident response, emergency maintenance, and low-latency automation where a second approver can delay containment or execution.

There is no universal standard for this yet in agentic or automated environments, but best practice is evolving toward compensating controls when hard separation is not feasible. Those compensating controls include temporary elevation with expiry, independent post-execution review, and rule-based exception handling that is tightly scoped and logged. Where one identity must request and act, the control should require an additional trust signal, such as a separate signing key, a second operator, or an external policy decision point. The Top 10 NHI Issues highlights how entitlement sprawl and unclear ownership often undermine these compensating layers before the organisation notices.

In environments that rely on automation, the hardest edge case is not a single bad approval. It is a workflow platform, bot, or agent that inherits both permission and authority from the same poorly governed identity boundary. The issue becomes acute when identity ownership is fragmented across application, infrastructure, and security teams because no one can prove where the SoD control actually failed.

Related resources from NHI Mgmt Group

• What breaks when one role can approve and execute the same transaction?
• Who is accountable when a cloud identity can both approve and execute changes?
• What breaks when one person can create and approve the same financial transaction?
• How should IAM teams reduce identity sprawl without losing control depth?