Tenant abuse occurs when an attacker uses a legitimate organisation’s collaboration tenant or external account to send malicious content. The message may pass normal policy checks because the sender looks authorised, even though the tenant has been compromised or the access path has been intentionally weaponised.
Expanded Definition
Tenant abuse refers to malicious use of a legitimate collaboration tenant, mailbox, workspace, or externally trusted account to deliver harmful content while appearing to come from an approved source. In NHI and IAM operations, the key risk is not only account compromise but also the exploitation of normal trust pathways, shared domains, and policy exceptions that let messages clear controls. This is adjacent to phishing, business email compromise, and account takeover, but tenant abuse is broader because the attacker may operate from infrastructure that is itself authentic, merely misused.
Definitions vary across vendors, especially when a campaign blends compromised SaaS identity, delegated access, and abuse of allowed outbound channels. The operational question is whether the sender was technically authorised at send time, whether the tenant was trusted by the recipient ecosystem, and whether abuse detection looked at behaviour rather than only reputation. For control mapping, this aligns closely with identity assurance and continuous monitoring concepts in the NIST Cybersecurity Framework 2.0. It is also consistent with NHI governance concerns documented in Ultimate Guide to NHIs because compromised service paths and overtrusted credentials often become the delivery mechanism.
The most common misapplication is treating tenant abuse as a pure email filtering problem, which occurs when defenders ignore identity provenance, tenant trust relationships, and authenticated sending paths.
Examples and Use Cases
Implementing tenant-abuse detection rigorously often introduces friction in collaboration workflows, requiring organisations to weigh user convenience against tighter trust controls and more frequent verification of sender context.
- A compromised Microsoft 365 or Google Workspace tenant sends internal-looking messages to partners, using legitimate domain reputation to bypass basic spam checks.
- An attacker abuses an externally shared guest account to post malicious links into a project channel, leveraging the recipient’s trust in the workspace.
- A stolen API key or service account sends notifications from a sanctioned SaaS tenant, making malicious content appear operationally routine.
- A vendor-managed tenant is weaponised to distribute attachment-based malware to customers who allow-list the sender domain.
- A compromised collaboration workspace is used to stage follow-on phishing, where replies from victims are collected inside the same trusted tenant.
These scenarios are often analysed alongside email and cloud identity abuse patterns described in Ultimate Guide to NHIs and the threat modelling emphasis in NIST Cybersecurity Framework 2.0. The practical test is whether the tenant itself, not just the message content, has become part of the attack surface.
Why It Matters in NHI Security
Tenant abuse matters because it turns legitimate identity infrastructure into a delivery channel for malware, fraud, and data theft. Once a tenant is trusted by recipients, conventional reputation checks become less effective, and defenders must rely on stronger signals such as anomalous authentication, unusual message volume, impossible travel, delegated access misuse, and secret exposure. In NHI programs, the same weaknesses that create service account sprawl and weak secret hygiene can also enable tenant abuse through compromised automation, poorly governed integrations, and externally shared credentials.
This is where the NHI control problem becomes visible at scale. NHI Mgmt Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, as documented in Ultimate Guide to NHIs. Those conditions make tenant compromise and malicious tenant use far more likely, especially when teams lack continuous inventory and revocation discipline. For governance, the issue also maps to monitoring and response expectations in NIST Cybersecurity Framework 2.0.
Organisations typically encounter tenant abuse only after a trusted workspace has already sent malicious content to customers or employees, at which point identity containment and tenant recovery become 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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Tenant abuse often begins with secret exposure or compromised non-human access. |
| NIST CSF 2.0 | DE.CM-1 | Tenant abuse is detected through continuous monitoring of identity and outbound activity. |
| NIST CSF 2.0 | PR.AA-1 | Trusted tenant use depends on strong identity assurance and access governance. |
Verify sender identity, constrain delegated access, and require stronger assurance for tenant operations.
