A poisoned tenant is an attacker-created SaaS organisation or workspace that looks legitimate enough to lure a target into joining. The security risk comes from trust in the platform itself, because joining the tenant can open a path to data exposure, follow-on social engineering, or integration abuse.
Expanded Definition
A poisoned tenant is not just a fake workspace. It is a trust trap built inside a SaaS control plane, designed to look like an ordinary organisation, team, or tenant so a target will accept an invite, join a shared channel, or connect an integration. In NHI and IAM terms, the danger is that the platform boundary itself becomes the lure.
Definitions vary across vendors, but the core pattern is consistent: the attacker abuses onboarding, federation, collaboration, or app-consent workflows rather than breaking the tenant directly. That makes poisoned tenants different from simple phishing domains because the victim is operating inside a seemingly legitimate SaaS context. This overlaps with identity trust and access governance guidance in the NIST Cybersecurity Framework 2.0, especially where third-party access and platform trust need validation before connection.
The most common misapplication is treating a poisoned tenant like a generic phishing campaign, which occurs when defenders ignore the workflow step where a user, bot, or service account is persuaded to join a malicious workspace.
Examples and Use Cases
Implementing controls for poisoned tenants rigorously often introduces friction in collaboration and partner onboarding, requiring organisations to weigh faster sharing against tighter trust validation.
- A threat actor creates a SaaS tenant with a believable company name, then invites a target employee into a shared project space to harvest messages, files, or metadata.
- An attacker uses a poisoned tenant to request app consent or OAuth access, then abuses the granted integration to reach mail, chat, or storage data.
- A fake partner workspace is used to imitate procurement or incident-response coordination, pushing a victim to upload sensitive documents or approve a connection.
- A service account is added to a malicious tenant that mirrors a trusted vendor environment, letting the attacker observe automation flows and abuse secrets exposure paths.
These patterns are especially dangerous when organisations already struggle with NHI governance. NHIMG notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which means poisoned tenant access can blend into broader identity blind spots. For identity-proofing and onboarding logic, the NIST Cybersecurity Framework 2.0 remains a useful reference point for governing trust decisions.
Why It Matters in NHI Security
Poisoned tenants matter because they turn legitimate SaaS trust into an attack surface. Once a user, bot, or API integration joins the tenant, the adversary may gain access to messages, files, token grants, activity logs, or downstream workflows that were never intended for external exposure. The risk is not only initial compromise, but also follow-on abuse through shared secrets, weak approval chains, and unreviewed integrations.
In NHI programs, this is where tenant-level trust intersects with secret handling and service identity governance. NHIMG reports that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, a reminder that one malicious workspace can become a delivery point for credentials and automation abuse. The same Ultimate Guide to NHIs also shows how broad the exposure problem is, which makes tenant trust validation a practical control rather than a theoretical one.
Organisations typically encounter the consequences only after a malicious invite is accepted or an integration token is abused, at which point poisoned tenant response becomes operationally unavoidable to address.
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 Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Poisoned tenants exploit trust and secret handling in SaaS onboarding flows. |
| NIST CSF 2.0 | PR.AC-4 | Access and trust decisions for external tenants map to least-privilege and approval controls. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust demands continuous verification of platform and tenant relationships. |
Validate tenant joins, review integrations, and restrict secret exposure to trusted workspaces.
Related resources from NHI Mgmt Group
- Why does tenant ownership matter for NHI governance?
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
- What is the difference between tenant ownership and data residency in identity governance?
- What is the difference between user error and tenant misconfiguration in collaboration security?
