Who is accountable when compromised cloud identity is used for business email compromise?

Why This Matters for Security Teams

business email compromise is rarely just an email problem. When a compromised cloud identity is used to send invoices, reset passwords, or impersonate executives, the failure usually starts with identity scope, token exposure, or overly broad service permissions. That makes accountability shared across IAM, cloud platform, and security operations, not isolated to the team that first notices the fraud. NHI Management Group research on the Ultimate Guide to NHIs shows how often organisations leave secrets exposed and privileges excessive, which creates the conditions for account takeover to become business impact.

For teams trying to assign blame, the useful question is not who clicked the phishing link but who approved the identity, credential, or delegation path that made abuse possible. That includes cloud administrators, identity engineers, application owners, and sometimes third-party operators. Current guidance suggests accountability must follow control ownership, because incident response can contain the damage but cannot retroactively fix poor entitlement design. In practice, many security teams encounter the true ownership gap only after a mailbox has already been used to redirect payment flows or authorise fraudulent changes.

How It Works in Practice

Compromised cloud identities often enable BEC through a chain of small permission decisions. An attacker may steal a session token, abuse a synced account, or obtain access through a service principal with mailbox or directory privileges. Once inside, they use legitimate cloud controls to look normal while changing forwarding rules, creating inbox delegates, or approving vendor payment changes. The abuse path matters because accountability follows the control point that enabled the action, not just the actor who executed it.

Operationally, teams should separate three layers of accountability:

• Identity governance: who approved the account, role, or conditional access policy that created the exposure.

• Credential and secret ownership: who is responsible for rotation, storage, and revocation of tokens, keys, and certificates.

• Service and application permissions: who granted mailbox access, API scope, or delegated admin rights.

This is why cloud identity incidents need join-up between IAM, platform engineering, and SOC. The 52 NHI Breaches Analysis shows how often identity misuse is tied to broad privileges and poor visibility, while industry reporting from the Anthropic report on AI-orchestrated cyber espionage reinforces a wider point: automated abuse scales fast once a trusted identity is captured.

Strong programmes map each cloud identity to an owner, a business purpose, and an expiry or review cycle. They also log who can approve risky actions such as mailbox delegation, OAuth consent, federation changes, or payment-related workflow exceptions. These controls tend to break down when identities are shared across teams, service accounts are inherited without formal ownership, or cloud admin privileges are granted faster than review processes can track them.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance fraud resistance against response speed and administrative friction. That tradeoff becomes especially visible during mergers, outsourced support, and fast-moving cloud migrations, where account ownership is unclear and emergency access is common.

There is no universal standard for this yet, but current guidance suggests accountability shifts depending on how the compromise occurred. If a phishing attack hijacks a human mailbox, HR and security awareness may be part of the root cause, but the accountable control owners are still the teams that allowed excessive access, weak conditional access, or poor monitoring. If a service account is used to send fraudulent mail or alter records, the accountable party is usually the platform or application owner that granted and maintained that entitlement.

Cloud environments also create edge cases where one team controls identity provisioning while another controls the application that actually sends or receives the email. In those cases, incident review should document:

• who owned the identity at the time of compromise;

• who approved the permissions in scope;

• who was responsible for detecting and revoking abuse;

• which business process the identity was supporting.

That ownership model should be explicit before an incident, not reconstructed during one. Otherwise, organisations end up debating responsibility while attackers continue using trusted cloud access to move money and manipulate communications.

Related resources from NHI Mgmt Group

• Who is accountable when a trusted cloud identity is used for business email compromise?
• Who is accountable when a secure email gateway misses an identity-led attack?
• Who is accountable when a compromised non-human identity causes major outage or data loss?
• Who is accountable when a supplier identity is used in a breach?