What should teams do when a trusted account or executive identity is abused through email?

When a trusted account is abused, what is the real incident?

The key question is whether the email compromise has turned a trusted identity into an execution path. If the account can request approvals, trigger work, or influence downstream action, the problem is not just message abuse. It is an identity and authority problem, which means response has to focus on containment, authority revocation, and traceable follow-up.

That distinction matters because business teams often see a familiar sender and assume the request is safe. Once trust has been exploited, the attacker is not relying on the mailbox alone, they are relying on the organisation’s willingness to honour the identity behind it.

Why the compromise must be treated as authority abuse

A trusted executive, shared inbox, or delegated account can function as a shortcut around normal verification. That makes the identity itself the asset under attack. If the account can approve invoices, authorise changes, request resets, or pressure staff into acting, the compromise extends beyond confidentiality into unauthorised business action.

Containment should therefore include the account, any active sessions, and any standing delegation or broad authority that the identity can still exercise. If you only reset a password but leave delegated approvals, mailbox rules, or workflow privileges in place, the adversary may continue to act through the same trust relationship.

A governance-oriented NHI guide is useful here because the same lifecycle discipline applies to any identity that can authorise work, whether human or non-human. The response objective is to remove the identity’s ability to exercise trust until the organisation has re-established control.

What teams should check after containment

Start with the recent actions taken from that identity. Review emails, approvals, delegated tasks, password resets, payment requests, vendor changes, access grants, and any workflow steps that were accepted because the sender was trusted. Then inspect downstream systems for actions that were initiated on the basis of that trust, not just for messages that were delivered.

That review should also include the boundaries around the identity: shared access, delegation settings, forwarding rules, API or workflow permissions, and any other standing authority that could survive the compromise. If the account participates in business processes, those processes may need to be paused until the approval path is revalidated.

The practical question is whether the identity was merely used to send mail or was used to authorise something material. The second case usually requires broader response, because the compromise may have created a chain of valid-looking business decisions rather than a single suspicious email.

Risk and Threat Considerations

Trusted identities are attractive because they can bypass scrutiny and create urgency, especially when the attacker can imitate routine executive or business communication. The main risk is that staff or automated workflows continue to accept requests that would normally be challenged, which lets the attacker convert trust into action.

Failure mechanism: The adversary abuses a legitimate identity, then uses existing delegation, standing privilege, or process trust to push approvals, resets, or payments that look authorised.

Impact: Organisations can suffer fraudulent transfers, unauthorised access changes, business process manipulation, and wider compromise if the same trust path is reused for additional actions.

Practitioner Guidance

What to prioritise: Contain the identity first, then trace what that identity could still authorise. If approvals or transactions are pending, suspend or independently re-verify them before assuming they are legitimate.

What to verify: Check for delegated inbox access, mailbox rules, OAuth grants, workflow permissions, and any standing approvals that survived the compromise. Those are the controls most likely to preserve attacker reach after the password is changed.

Decision rule: If the identity can still cause a business action to execute, treat it as an active authority issue, not a closed email event. If the identity cannot authorise anything and no downstream requests were accepted, the response can stay narrower.

Practitioner takeaway: The measure of success is not whether the inbox is cleaned up, it is whether the compromised identity can no longer cause other teams or systems to trust it.

Related resources from NHI Mgmt Group

• How should security teams handle OAuth account merging when the identity provider email claim cannot be trusted?
• What should teams do in the first 24 to 72 hours after a trusted identity is abused?
• How should security teams handle email account takeover as an identity incident?
• How should security teams detect identity-based attacks that move through email and login paths?