Who is accountable when stolen credentials from a phishing email are used for fraud?

Why This Matters for Security Teams

When stolen credentials from a phishing email are used for fraud, the failure is rarely just “someone clicked a bad link.” The real issue is that authentication succeeded, the identity was trusted, and downstream controls did not stop the abusive transaction. That makes accountability shared across the identity owner, the approving function, and the business process that allowed the payment, transfer, or access request to complete. Guidance from the NIST SP 800-63 Digital Identity Guidelines treats identity proofing and authentication as only part of the trust chain.

This is why NHIMG research on 52 NHI Breaches Analysis is relevant even in a human-phishing scenario: once an identity is compromised, the attacker uses whatever permissions, approval paths, and secrets are already in place. Fraud becomes an identity, governance, and workflow problem at the same time. In practice, many security teams encounter the loss only after a valid login is used to approve the fraudulent action, rather than through intentional detection of the phishing event.

How It Works in Practice

Accountability usually breaks into three layers. First is identity governance: who controls the account, reset path, MFA enrollment, and privileged entitlements. Second is operational approval: which team signed off on the transfer, vendor payment, password reset, or workflow exception. Third is financial or business ownership: which process executed the transaction and who is responsible for loss prevention.

That is why frameworks such as OWASP Non-Human Identity Top 10 matter even when the stolen credential belongs to a person. The same control gaps appear when a trusted identity is reused after compromise: excessive standing privilege, weak session controls, and poor secret handling. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets highlights the operational advantage of short-lived credentials; the same principle applies to human sessions that should be narrowed by risk, time, and transaction value.

• Use step-up verification for high-risk actions, not just for login.
• Separate account ownership from payment approval and from fraud review.
• Bind approvals to context such as amount, destination, device, and time.
• Revoke sessions quickly after suspicious email access or mailbox rule changes.

Practitioners should also treat mailbox compromise, identity compromise, and business fraud as one incident with multiple control owners. NIST identity guidance and the Anthropic report on AI-orchestrated cyber espionage both reinforce a simple point: once an attacker has a valid identity, they often move through legitimate workflows instead of breaking them. These controls tend to break down when finance approvals are handled outside the identity system because the approval trail and the authentication trail no longer line up.

Common Variations and Edge Cases

Tighter approval controls often increase friction for legitimate payments and urgent business actions, so organisations must balance fraud reduction against operational speed. There is no universal standard for this yet, especially where fraud spans email, shared service desks, and treasury systems.

One common edge case is delegated access: if an assistant, temporary worker, or service account was allowed to act on behalf of the victim, accountability shifts toward the organisation’s access governance and approval design, not just the end user. Another is conditional access failure: if phishing-resistant MFA was available but not enforced for the risky transaction, the gap sits with policy implementation. NHIMG’s Guide to the Secret Sprawl Challenge is useful here because fraud often accelerates when credentials, tokens, and approvals are scattered across too many systems.

Where organisations have outsourced payment execution or customer support, accountability may be contractually shared, but control ownership still remains internal for identity assurance and transaction approval. Best practice is evolving toward explicit control mapping: who authenticates, who approves, who executes, and who monitors. That clarity matters most when the phishing email is only the entry point and the actual loss occurs in a separate business system.

Related resources from NHI Mgmt Group

• Who is accountable when a hijacked subdomain is used for phishing or malware?
• Who is accountable when a mobility platform is used for fraud or laundering?
• Who is accountable when stolen tokens are used after a device code phishing incident?
• Who is accountable when repository credentials expose downstream systems?