They work because authentication proves the email came from the platform, not that the tenant behind it is legitimate. The attacker uses trusted delivery infrastructure to carry a malicious invitation, so the weak point is governance over tenant creation and member onboarding rather than message spoofing.
Why This Matters for Security Teams
Poisoned tenant attacks succeed because delivery trust and tenant trust are not the same control. Email authentication can confirm that a message was sent through a legitimate platform, yet it says nothing about whether the tenant issuing the invitation, link, or payload is authorised to exist in your trust boundary. That gap matters because onboarding flows often inherit trust from the transport layer while ignoring governance over tenant creation, namespace abuse, and member admission.
This is not a spoofing problem in the classic sense. It is a trust-propagation problem that crosses identity, messaging, and administrative controls. NHI Management Group’s 52 NHI Breaches Analysis and Top 10 NHI Issues both reflect the same operational pattern: attackers exploit whatever is trusted by default, then move through onboarding paths that were never designed to validate provenance at depth. Industry guidance from CISA cyber threat advisories reinforces that trusted channels remain attractive precisely because defenders often monitor content more closely than identity context. In practice, many security teams encounter tenant poisoning only after a user has already accepted the invitation and granted the attacker a foothold.
How It Works in Practice
A poisoned tenant attack usually starts with an attacker creating or compromising a tenant on a SaaS or collaboration platform, then using that tenant to send invitations, shared documents, or messages that appear routine to the recipient. Email authentication passes because the platform is genuinely sending the message. The abuse lives one layer deeper: the tenant itself, the onboarding path, or the shared-resource workflow is the malicious object.
The defensive model has to shift from message validation to tenant and identity governance. Security teams should treat onboarding as a high-risk trust decision and evaluate:
- Whether new tenants, partner workspaces, or external domains are approved through policy rather than manual convenience.
- Whether invitations are scoped to pre-approved collaborators and bounded by domain reputation or federation rules.
- Whether SaaS admin actions, token grants, and external sharing events are logged and correlated with tenant lifecycle events.
- Whether the organisation can revoke trust in a tenant, not just block a sender.
That posture is consistent with broader threat research. The Anthropic AI-orchestrated cyber espionage report and MITRE ATLAS adversarial AI threat matrix show how attackers chain trusted automation, delegation, and context abuse rather than relying on obvious spoofing. For NHI-oriented control mapping, NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is useful because tenant credentials, API tokens, and service identities often become the bridge from a benign-looking invitation into persistent access. These controls tend to break down when external collaboration is wide open, tenant approvals are informal, and admins cannot quickly distinguish legitimate business onboarding from tenant-level impersonation.
Common Variations and Edge Cases
Tighter tenant approval and invitation controls often increase operational friction, requiring organisations to balance user convenience against the need to stop attacker-controlled onboarding paths. That tradeoff is especially visible in environments where external collaboration is routine, such as M&A activity, managed services, or multi-tenant B2B integrations.
Best practice is evolving, but current guidance suggests treating tenant trust as a separate decision from email trust. In some platforms, conditional access, sender authentication, and phishing filters will all pass while the recipient still lands in a poisoned workspace. In others, the attack arrives through shared documents, calendar invites, or app-consent prompts instead of email alone. The core edge case is federation: when a trusted partner’s tenant is compromised, your controls may see a legitimate identity source while the attacker controls the workflow.
That is why response playbooks should include tenant quarantine, external sharing review, and app-consent rollback, not just mailbox protection. It also explains why NHI governance is relevant here: a malicious tenant often succeeds by abusing service principals, API keys, or delegated access once the victim trusts the environment. If the organisation lacks a process to validate tenant provenance and revoke downstream tokens, email authentication becomes a false reassurance rather than a security boundary.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses trust and lifecycle weaknesses in non-human identities and tenant access paths. |
| NIST CSF 2.0 | PR.AC-1 | Covers identity proofing and access enforcement where tenant trust is abused. |
| NIST AI RMF | Useful for managing trust, governance, and misuse risk in automated onboarding workflows. |
Validate tenant provenance, restrict external onboarding, and review NHI trust relationships before granting access.
