Who is accountable for email security during an acquisition?

Why This Matters for Security Teams

Email security during an acquisition is not just a messaging problem. It is an identity transition problem, a routing problem, and a trust problem that crosses legal close, IAM cutover, and post-merger operations. Attackers look for the gap between “the deal is signed” and “the controls are fully integrated,” especially where legacy mailboxes, forwarding rules, shared inboxes, and vendor-managed domains still exist. Guidance in the NIST Cybersecurity Framework 2.0 places clear emphasis on governance and access control, but acquisition work often moves faster than policy can be enforced.

That is why accountability has to be explicit across deal, security, and IAM leads. If no one owns inbox assurance, mailbox discovery, and decommission timing, attackers can abuse stale authentication paths or compromised accounts before controls are normalized. NHIMG research on the State of Non-Human Identity Security shows how often organisations lack confidence in identity control, which is exactly the kind of weakness acquisition teams inherit. In practice, many security teams encounter mailbox abuse only after forwarding rules, inherited access, or token exposure have already been used to move laterally.

How It Works in Practice

The right operating model is joint accountability with clear handoffs. Deal teams typically control acquisition timing and scope, IAM teams validate identities, and security teams validate risk and exception handling. That division only works if it is turned into an acquisition runbook with named owners for each mailbox domain, tenant, and exception path. Current best practice is to treat email security as part of the identity merger, not as a late-stage hygiene task.

• Inventory every mail system, gateway, forwarding rule, alias, and delegated mailbox before integration begins.
• Disable or tightly constrain legacy access paths until assurance checks are complete.
• Review admin roles, shared mailboxes, and external collaboration links for over-privilege.
• Rotate secrets and revoke stale tokens tied to acquired systems once ownership transfers.
• Monitor for suspicious inbox rules, unusual sign-ins, and mail flow changes during the transition window.

Where possible, acquisition teams should use central identity signals and policy enforcement rather than relying on manual checklists. The DeepSeek breach illustrates how exposed credentials and poorly governed access can create fast-moving compromise paths, which is relevant when inherited email systems still trust old identities. For broader acquisition governance, security teams should align control mapping to NIST Cybersecurity Framework 2.0 so detection, protection, and recovery are all tracked through the transition.

These controls tend to break down when the acquired organisation uses multiple tenants, outsourced mail administration, or undocumented federation because ownership of mail flow and admin rights becomes fragmented.

Common Variations and Edge Cases

Tighter acquisition control often increases integration overhead, requiring organisations to balance rapid business continuity against the risk of hidden inbox exposure. That tradeoff is especially visible when the acquired company keeps its own email stack for a period of time, or when legal and regulatory requirements prevent immediate account consolidation. In those cases, guidance suggests treating the legacy environment as high-risk until it is fully verified.

There is no universal standard for this yet, but current practice increasingly favours phased cutover with temporary restrictions on external forwarding, privileged mailbox access, and dormant accounts. The same applies to carve-outs, divestitures, and joint ventures, where email accountability may shift more than once. NHIMG’s State of Non-Human Identity Security highlights how weak visibility and over-privilege are common failure points, which matters whenever inherited mail systems contain service accounts or automated notifications tied to business-critical workflows.

In regulated environments, the practical answer is often a dual-control model: one team owns operational continuity, another owns security approval for exceptions. That structure reduces ambiguity, but it only works if exception expiry dates, review cadence, and offboarding criteria are documented before integration starts.

Related resources from NHI Mgmt Group

• Who is accountable when risk remains open after security flags it?
• What should security leaders do when executives keep complaining about email clutter?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?