How should security teams assess acquired email tenants before integration?

Security teams should baseline acquired tenants in read-only mode before close, inventorying users, privileged accounts, OAuth apps, and legacy authentication paths. The goal is to identify inherited exposure before integration work hides it. A pre-close view is the safest point to find weak controls because it reveals what the target already contains, not what post-merger cleanup assumes it contains.

Why This Matters for Security Teams

Acquired email tenants are often treated like a migration project, but the real risk is inherited control debt. A tenant can contain dormant admin roles, abandoned OAuth grants, legacy authentication paths, and mailbox rules that silently preserve attacker access long after the acquisition closes. That is why baseline assessment should happen in read-only mode before integration, when the target still reflects its true exposure. Guidance in the NIST Cybersecurity Framework 2.0 supports this kind of identify-protect-detect sequencing, and NHIMG research on the State of Non-Human Identity Security shows how often organisations miss the permissions and third-party connections already present. In practice, many security teams encounter mailbox compromise or OAuth abuse only after the tenant has been merged and the original evidence has already been normalised away.

Security teams should assume the acquired tenant is a live exposure surface, not a clean asset inventory. The first pass should answer four questions: who can administer the tenant, which identities are privileged, what legacy protocols remain enabled, and which external applications can still act on behalf of users. That includes service accounts, delegated permissions, forwarding rules, transport rules, and any authentication method that bypasses modern conditional access.

Read-only access is important because integration work can mask pre-existing risk by changing policies, consolidating directories, or deleting evidence before the posture is understood. A pre-close view also helps separate inherited risk from cleanup debt. The DeepSeek breach is a reminder that exposed secrets and hidden access paths can persist for long periods when systems are assumed to be benign. Teams should map what exists before deciding what should be trusted.

How It Works in Practice

Start with an isolated assessment account that has read-only visibility into the acquired tenant’s identity, mail, and audit layers. Then inventory the control surfaces that matter most in an email environment: global administrators, helpdesk roles, delegated mailbox access, dormant accounts, OAuth consents, legacy IMAP/POP/SMTP AUTH usage, forwarding configurations, and application-specific credentials. Where available, compare directory data with sign-in and message trace logs so you can see not only who exists, but what they can still do.

Use a structured sequence rather than a broad manual review:

• Identify all privileged users and role assignments, including shadow admins and break-glass accounts.
• Review third-party apps and OAuth grants for excessive scopes and vendor sprawl.
• Check for legacy authentication and protocol exceptions that bypass modern policy.
• Inspect mailbox rules, forwarding, and transport rules for persistence mechanisms.
• Validate whether MFA, conditional access, and device compliance are enforced consistently.

Current guidance suggests this assessment should be evidence-led and reversible, meaning no changes should be made until the baseline is agreed and retained. The NIST Cybersecurity Framework 2.0 helps frame the work as asset, identity, and access governance, while NHIMG’s NHI research reinforces the importance of finding over-privileged access and poor visibility before remediation begins. Teams should also document any inherited exceptions so they can be explicitly approved or removed during integration planning. These controls tend to break down when the acquired tenant uses hybrid identity, because directory trust, mail flow, and legacy authentication settings are often split across multiple administrative planes.

Common Variations and Edge Cases

Tighter pre-close inspection often increases transaction friction, requiring organisations to balance speed against certainty. That tradeoff is real, especially when the seller limits access or the deal timeline is compressed. In those cases, current guidance suggests prioritising the highest-risk checks first: privileged roles, OAuth apps, legacy auth, and mailbox forwarding. If full tenant visibility is unavailable, teams should treat that gap as a risk item, not as a reason to assume the environment is safe.

Edge cases often appear in tenants with federated identity, multiple subsidiaries, or long-lived guest access. Some environments also have service mailboxes or automation accounts that look inactive but still process sensitive workflows. There is no universal standard for this yet, but best practice is to preserve evidence, record every exception, and avoid merging identity stores until the risk picture is stable. The issue is not just whether the tenant is compromised today, but whether hidden access survives the first integration wave and becomes harder to detect afterward.

Related resources from NHI Mgmt Group

• How should security teams think about a compromised integration like Drift?
• How should security teams evaluate identity governance platforms that rely on integration libraries?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?