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

Why Accountability Fails When a Trusted Cloud Identity Is Misused

business email compromise becomes an identity governance problem when the attacker does not need to break the mailbox directly. Instead, they abuse a trusted cloud identity, service principal, API key, or delegated token to send mail, alter routing, or harvest messages. That shifts accountability from a single user mistake to the teams that owned the credential lifecycle, access boundaries, and monitoring model. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities, and its Ultimate Guide to NHIs shows why reusable secrets and excessive privilege remain common failure points.

For security teams, the hard question is not only who clicked or who approved access, but who allowed a machine identity to stay valid, broad, and reusable long enough to be abused. Email compromise through cloud identity often reflects gaps in least privilege, secret rotation, and ownership boundaries rather than a single control failure. The same pattern appears across cloud and SaaS ecosystems where service accounts outlive their business purpose and remain trusted by default. In practice, many security teams encounter the compromise only after mailbox rules, forwarding, or OAuth consent abuse has already expanded the blast radius.

How Accountability Is Assigned in Practice

Accountability is usually shared across the workload owner, the platform or identity team, and the business function that approved the integration. The workload owner should know why the identity exists, what it may access, and when it must be revoked. The platform team should enforce control baselines such as rotation, conditional access, and monitoring. The business owner should validate that the identity still serves a legitimate process. That allocation reflects the governance model used in most NHI programs, not a one-time IT task.

Practitioners should map the identity to a lifecycle that includes creation, review, rotation, and offboarding. If the identity is used for email sending, mailbox access, or delegated automation, then its permissions should be scoped to the minimum necessary and tied to a named service owner. The best available guidance continues to emphasize runtime access control, short-lived credentials, and continuous verification, as described in standards such as OWASP, NIST SP 800-207, and identity lifecycle discipline in the Ultimate Guide to NHIs.

• Assign one accountable owner per cloud identity, even if several teams use it operationally.
• Require justification for every mailbox or messaging permission granted to a non-human identity.
• Rotate secrets and revoke tokens on a fixed schedule, not only during incident response.
• Log changes to forwarding rules, consent grants, and mail access scopes as security events.
• Review dormant identities, especially where service accounts persist after the workflow changes.

Where possible, replace long-lived secrets with workload identity, federated tokens, or just-in-time access so accountability includes both the human approver and the control plane enforcing expiry. These controls tend to break down when legacy integrations require static credentials and no one can prove which team still depends on them.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, requiring organisations to balance auditability against application stability. That tradeoff is especially sharp in email systems, because service accounts, SMTP connectors, and delegated OAuth apps can support critical business processes while also creating attractive compromise paths. Current guidance suggests that accountability should follow the entity best positioned to prevent reuse, but there is no universal standard for this yet.

Edge cases usually involve shared credentials, inherited admin rights, or third-party automation. In those environments, blame is often misassigned to the last person who touched the mailbox, even though the real control failure was a missing owner, an overbroad app consent, or an expired review that never happened. The Anthropic report is a useful reminder that autonomous or semi-autonomous misuse can scale quickly once a trusted identity is available. When organisations cannot attribute an identity to a business process, they usually cannot assign meaningful accountability either. In practice, the real failure is discovered only after a trusted account has already been used to send fraudulent email, not when the access was originally granted.

Related resources from NHI Mgmt Group

• Who is accountable when a secure email gateway misses an identity-led attack?
• Who is accountable when a supplier identity is used in a breach?
• Who is accountable when a stolen credential is used to deploy workloads in cloud environments?
• Who should own identity governance when it spans cloud and enterprise systems?