Who is accountable when a compromised signing workflow causes exchange losses?

Accountability should sit with the team that owns transaction governance, signing approvals, and incident containment, not only with infrastructure or application security. Custody risk spans operations, treasury, security, and platform engineering. Frameworks such as NIST Cybersecurity Framework 2.0 help assign responsibility across detect, respond, and recover functions.

Why This Matters for Security Teams

When a signing workflow is compromised, the loss is rarely caused by a single bad control. The real issue is that transaction authority was distributed across people, systems, and secrets without clear ownership of who approves, who can sign, and who can stop the blast radius. NHI Management Group’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows why this matters: 80% of identity breaches involve compromised non-human identities such as service accounts and API keys.

That pattern maps directly to exchange loss scenarios because signing credentials, approval bots, release pipelines, and treasury automation often act as a single control plane. If that control plane is weak, the compromise is not just technical. It becomes a governance failure spanning operations, treasury, security, and platform engineering. Current guidance suggests that accountability must follow decision authority, not just asset ownership. In practice, teams often discover that after funds move, nobody owned the full signing chain end to end.

How It Works in Practice

Accountability should be assigned to the team that owns transaction governance, signing approvals, and incident containment, with named backup owners for platform and security support. The practical test is simple: identify who defines policy, who approves exceptions, who holds signing authority, and who can revoke access during an incident. That is the accountable function, even if the tooling is operated elsewhere.

For signing workflows, strong governance means separating initiation, approval, execution, and recovery. A request should not be able to self-approve through the same identity path that created it. Where automation is used, the workflow should rely on workload identity, short-lived secrets, and explicit policy gates rather than long-lived static credentials. NIST’s SP 800-53 Rev 5 Security and Privacy Controls supports this model through access control, auditability, and incident response requirements.

NHI Management Group’s 52 NHI Breaches Analysis and the GitHub Action tj-actions Supply Chain Attack both illustrate the same operational truth: once secrets or signing paths are exposed, compromise can spread through trusted automation faster than human responders can react.

• Define one accountable owner for transaction governance, not a committee with shared ambiguity.
• Separate approval logic from signing execution and from key custody.
• Use short-lived credentials and revocation hooks for every automated signer.
• Log approvals, policy decisions, and key-use events in tamper-evident form.
• Pre-assign incident containment authority so revocation does not wait on escalation.

These controls tend to break down in highly automated exchange environments where signing is embedded in CI/CD, treasury ops, and market-making pipelines because the same identity often performs both business logic and privileged execution.

Common Variations and Edge Cases

Tighter transaction governance often increases operational overhead, requiring organisations to balance speed against control integrity. That tradeoff is especially visible when exchanges need near-real-time settlement, multiple approvers across time zones, or emergency hotfix signing during volatile market conditions.

There is no universal standard for exactly how much authority should sit with treasury versus security, but current guidance suggests the accountable owner must be the function that can answer four questions without delay: who approved it, who signed it, who can revoke it, and who bears the loss if controls fail. In some firms, that is a treasury risk leader; in others, it is a platform or payments operations owner. Security supports the control framework, but should not be left as the default loss owner unless it also owns the signing decision chain.

Edge cases appear when third-party custodians, multi-sig wallets, or outsourced DevOps teams participate in the workflow. In those cases, contracts and runbooks must still map operational authority back to an internal owner. The key risk is shared access without shared accountability. The lesson from NHI compromise events is consistent with the broader breach record in the The 52 NHI breaches Report: if nobody can stop the signing path quickly, accountability exists only on paper.

Related resources from NHI Mgmt Group

• What actions should I take if my OAuth tokens are compromised?
• Who is accountable when a digital loan signing workflow fails compliance review?
• Who is accountable when a compromised workflow exposes cloud and repository credentials?
• Who is accountable when account takeover fraud causes downstream losses?