Should You Use the New Microsoft Entra Tenant Governance or Azure Lighthouse? (part 3 of 3)

I really appreciate the thoughtful comment, and the underlying concern is real. A provider identity authorized across many customers does create correlated exposure. What I'd add is that the model is designed to bound that exposure tightly, and to hand most of the mitigating controls to the customer. Any breach is effectively blunted by each individual customer control.

One boundary I emphasized in the article is worth highlighting again which is that neither Lighthouse nor Tenant Governance delegates the resource data plane. The proxy can't obtain a data‑plane token for blob contents, database data, or Key Vault secret values. Those still require an identity native to the customer tenant. So with the recommended read‑only baseline (Global Reader in the directory), what a compromise could reach is primarily configuration and directory metadata, which still includes sensitive PII and useful reconnaissance, so it isn't nothing but not the resource data itself. And of course, if the provider has elevated privileges, a breached account has the potential to wreak havoc (even without data plane access) - though as I'll explain, there are significant hurdles an attacker must overcome to cause widespread chaos. 

The point I'd push hardest on is Conditional Access, because it speaks directly to the "one breach reaches everyone" concern. With Tenant Governance the technician actually signs in to each customer's tenant, so it's that customer's Conditional Access that evaluates the login separately, in every single tenant. There is no shared, provider‑side policy an attacker could flip to unlock the whole book of business. A stolen provider credential would have to satisfy each customer's controls independently. An MFA challenge at minimum, plus whatever else that customer's Conditional Access requires, one tenant at a time, each policy owned and enforced by a different organization the attacker doesn't control. So a compromise doesn't fan out into "all customers at once", it runs into N separate front doors, and any customer enforcing MFA/Conditional Access (as they all should) is independently gating that access on its own terms. Authentication still happens in the provider tenant, but the policy governing the inbound session is the customer's.

None of this makes the provider tenant a place to be casual about, standing delegation remains unless JIT is configured, permitted control‑plane changes are still possible, and the provider's own identities deserve strong protection and least privilege. But between the data‑plane boundary and each customer's independently‑enforced Conditional Access, the highest‑severity outcomes are meaningfully constrained. The blast radius isn't a single policy failure, it's gated separately by every customer. Appreciate you digging into this, these are important things to think about and I'm glad you brought it up.