Why does a connected tenant not appear as a target for content distribution?

Reviewed by ContraForce team · Updated 2026-09-04

> Microsoft documents that a cross-cloud tenant removed from cross-cloud visibility becomes unavailable, and describes this as a recognised limitation of cross-cloud tenant management currently under review. Beyond that case, eligibility for content distribution follows the access model: multitenant management requires GDAP or Microsoft Entra B2B for Defender data, and Microsoft Sentinel data is not reachable through GDAP.

What does Microsoft document about tenants going missing?

One cause is stated plainly. A cross-cloud tenant removed from cross-cloud visibility becomes unavailable, and Microsoft describes this as a recognised limitation of cross-cloud tenant management that is currently under review. If an estate spans clouds, this is the first thing to check.

Beyond that, the documentation describes eligibility rather than failure modes. Tenants are added and removed from the settings page, and access to Defender data requires either GDAP or Microsoft Entra B2B. A tenant reachable by neither is not reachable by multitenant management.

There is no published diagnostic for a tenant that is connected but absent from a picker, which is worth saying directly rather than implying a cause the documentation does not give.

What is worth checking, in order?

The checks that follow from what is documented, cheapest first.

• Cloud boundary. Is the tenant in a different cloud from the one you are working in? That is the one case Microsoft names.
• Access model. Does the relationship carry GDAP or Entra B2B for Defender data? A relationship that exists commercially is not necessarily one that carries the access.
• Data type. Is the content Sentinel-related? GDAP does not reach Sentinel data, so a tenant reachable for Defender content may not be reachable for Sentinel content.
• Content type. Automation rules that trigger a playbook cannot be distributed at all, and playbooks are not a distributable type, so an absent target may be an ineligible content type rather than an absent tenant.

Why is this hard to diagnose at scale?

Because the negative case is silent. A tenant that does not appear produces no error explaining why, and the four causes above have no distinguishing signal between them in the console. Verifying coverage means checking each tenant individually, which is the work multitenant management exists to remove.

How do you make coverage verifiable?

The underlying issue is that intended state and actual state live in different places, and only one of them is written down.

ContraForce manages detection content as versioned repositories deployed to the workspaces you choose, with drift detection that scans a workspace and reports the rules that no longer match the baseline. A tenant that did not receive content appears as a difference rather than as an absence somebody has to notice.

Sources

• Microsoft Defender multitenant management requirements
• Manage multitenant content distribution
• Microsoft Defender multitenant management overview