Who is accountable when a phishing attack drains a treasury through a signer?

Why This Matters for Security Teams

A phishing-driven treasury drain is rarely a single-user mistake. It usually exposes a weak approval design, overbroad signer authority, and missing separation between transaction initiation, review, and final authorization. When a signer can move funds after a convincing lure or session hijack, the issue is not only social engineering, but also control design, custody governance, and operational accountability. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because it frames the need for access control, auditability, and defined responsibility around high-impact actions.

The practical question is who owned the signer’s lifecycle, who approved its privileges, and who was responsible for monitoring abnormal approvals. That accountability should not stop at the person who clicked approve if the organisation allowed a single compromised approval path to control treasury movement. Security teams often assume the incident is contained to endpoint hygiene, but treasury signers are governance assets as much as technical ones. In practice, many security teams encounter the accountability gap only after funds have already been routed out through a trusted signer.

How It Works in Practice

In a sound operating model, the signer is treated as a high-risk control point with explicit ownership, documented use cases, and compensating controls. The workflow should define who can propose a transaction, who can validate it, who can sign, and what conditions require step-up review or a second signer. Strong practice also includes device assurance, phishing-resistant authentication, transaction limits, and out-of-band verification for unusual transfers. Where the signer is a human with privileged wallet or payment authority, the organisation should treat that role much like privileged access management, with scheduled review and revocation procedures.

Operationally, accountability is usually distributed across several roles:

• Security owns the control requirements, monitoring, and alerting thresholds.
• Operations or treasury owns the business need, signer assignment, and exception handling.
• Engineering or platform teams own the technical enforcement of approval logic and access restrictions.
• Leadership owns the risk acceptance when a single signer is allowed to move material value.

Incident analysis should map the event to attacker behaviour patterns. The MITRE ATT&CK Enterprise Matrix is useful for understanding initial access, credential theft, and abuse of valid accounts, while CISA cyber threat advisories help teams compare the incident to known phishing and account-takeover patterns. If AI-generated lures or automated targeting were involved, the threat model should also consider agentic abuse paths and adversarial content generation. These controls tend to break down in lean treasury environments where one person can both receive, approve, and release payments because no second control ever interrupts the fraud path.

Common Variations and Edge Cases

Tighter approval controls often increase payment latency and operational overhead, requiring organisations to balance speed against loss prevention. That tradeoff becomes sharper for cross-border treasury, time-sensitive payroll, and market-moving settlement workflows, where a second approval may be operationally painful but still necessary for material transfers.

There is no universal standard for this yet, but best practice is evolving toward risk-based signing rather than blanket trust in a named approver. For low-value or routine payments, organisations may accept a streamlined path with strong logging and anomaly detection. For high-value or exceptional transfers, they should require a separate approver, stronger identity proofing, or hardware-backed signing. Where AI is being used to draft payment instructions, summarise requests, or route approvals, the organisation should also consider prompt injection, workflow manipulation, and impersonation risk. The MITRE ATLAS adversarial AI threat matrix is relevant if automated assistants influence signer decisions, and the Anthropic report on first AI-orchestrated cyber espionage campaign report illustrates how persuasive automation can scale attack preparation. Where treasury controls rely on one human signer plus weak message verification, the model becomes fragile because phishing, urgency pressure, and social engineering can bypass every downstream safeguard.

Related resources from NHI Mgmt Group

• What is the difference between attack surface management and NHI governance?
• Who is accountable when a man-in-the-middle attack succeeds through weak authentication?
• Who is accountable when phishing-resistant MFA is bypassed through fallback methods?
• Who is accountable when sensitive chats are exposed through user error or device phishing?