How should security teams share accountability for email-to-identity attacks?

Why email-to-identity attacks need shared ownership

Email-to-identity attacks are not a single-team problem because the attacker’s path crosses controls: mailbox compromise, suspicious message delivery, token replay, password reset abuse, and follow-on account takeover. If email security stops at delivery and IAM stops at authentication, the gap is usually in the handoff, where incident scope, evidence, and response timing get lost.

Joint ownership should be framed around the attack path, not the product boundary. That means defining who confirms initial mailbox abuse, who invalidates sessions or tokens, who resets or rebinds authentication factors, and who verifies that access has actually been restored safely.

Where this is handled well, the response owner is able to move from email compromise to identity containment without waiting for a separate queue or a second triage cycle. A Identity Threat Detection and Response (ITDR) Guide is useful here because it treats identity abuse as an end-to-end detection and response problem rather than a narrow control issue.

What shared accountability should cover across the chain

Shared accountability has to cover prevention, detection, and recovery across the same failure path. Prevention means reducing mailbox takeover and token theft opportunities; detection means correlating email anomalies with identity anomalies; recovery means revoking active sessions, rotating or reissuing affected secrets, and confirming that the attacker no longer has a live path back in.

The practical mistake is assigning each team only the part it directly owns. That leaves phishing recovery, mailbox cleanup, token revocation, and reauthentication checks as disconnected tasks, even though they are operationally one incident. The owner should therefore be defined at the incident-chain level, with clear handoff triggers and no ambiguity about who closes the loop.

This is also where lifecycle discipline matters. A mailbox that was abused, a token that was replayed, or a factor that was reset should all be treated as compromised trust material until proven otherwise. The NHI Lifecycle Management Guide is relevant because it reinforces the need to govern provisioning, rotation, and offboarding as connected lifecycle events rather than isolated admin actions.

For teams trying to formalise ownership, the NHI Ownership and Accountability Guide provides a useful ownership model for ensuring that every identity has a named accountable party and no recovery step falls into a gap.

How teams can make the handoff operationally reliable

The handoff becomes reliable when the operating model is built around shared signals and shared decisions. Security teams should agree on what constitutes mailbox abuse, what evidence proves token compromise, which events trigger forced session invalidation, and which conditions require a coordinated reset rather than a local fix.

That operating model should also include a single place to validate recovery. If email is cleaned up but sessions remain active, or if identity is reset but the mailbox is still exposed, the attack path remains open. One reason to centralise this view is that the same compromise can reappear through another channel unless the full chain is closed. The Identity Security Programme Guide is a good reference point for structuring ownership, RACI, and governance across teams that share the same risk surface.

Teams should also use incident examples to sharpen the boundary between email abuse and identity compromise. The Co-op cyber attack 2025 shows how social engineering and account abuse can move quickly from initial access to broader identity-driven impact when the response is not coordinated.

Risk and Threat Considerations

Email-to-identity attacks are attractive because they exploit trust between systems that are often monitored separately. The main risk is delayed containment: an attacker who gets into a mailbox can reset credentials, intercept recovery messages, or replay tokens before identity controls notice the blast radius.

Failure mechanism: Teams investigate delivery, authentication, and recovery as separate events, so the attacker keeps a valid path through active sessions, reset flows, or trust relationships after the mailbox is “fixed.”

Impact: Account takeover can expand into persistence, lateral movement, and loss of confidence in the affected identity estate, especially when response ownership is split across tools and queues.

Practitioner Guidance

What to prioritise: Define one incident owner for the full email-to-identity path, then assign explicit sub-owners for mailbox containment, token/session invalidation, and identity recovery. The key is not who owns the product, but who owns the outcome that the attacker can no longer use the path.

What to verify: Confirm that the recovery process includes evidence of token revocation, authentication rebind, and mailbox integrity, not just password change completion. If those proofs are missing, treat the incident as only partially remediated.

Practitioner takeaway: Shared accountability works when both teams are measured on closing the same attack chain, because the real control failure is usually the gap between “mailbox cleaned” and “identity actually safe.”

Related resources from NHI Mgmt Group

• How do identity teams and data security teams share accountability for on-prem exposure?
• How should security teams detect identity-based attacks that move through email and login paths?
• How should security teams correlate email, IdP, and SaaS signals to detect identity attacks that look legitimate in each system on its own?
• How do identity and AppSec teams share accountability for spec-driven development security?