Azure Lighthouse pattern: why org ≠ tenant for MSPs

MS Learn: managing vs customer tenants. Org≠tenant for MSP ops. Soft Auris tenant-per-customer analogy — industry pattern, not a cert.

Azure Lighthouse documents a clear split: a managing tenant (often the MSP) receives delegated access to subscriptions or resource groups in a customer tenant, without collapsing both into one Microsoft Entra directory. Microsoft Learn describes registration definitions and assignments that project roles from the managing tenant onto customer scopes.

Why org ≠ tenant for MSPs: a commercial “organization” (legal entity, brand, holding) can span many Entra tenants — one per customer, per environment, or per acquisition. Mixing them breaks least privilege, audit trails, and offboarding. Lighthouse is the Microsoft-documented pattern for cross-tenant operations while keeping customer boundaries intact.

Industry analogy (not a certification): multi-tenant SaaS control planes that isolate customer tenants under one operator org follow the same mental model — one brand, many hard isolation boundaries. Map that analogy carefully; it is pattern language, not an ACN/C5/SecNumCloud claim.

FAQ

Does Lighthouse merge customer directories?

No. It delegates scoped access from the managing tenant into customer subscriptions/RGs while tenants remain separate Entra instances.

How does this map to SaaS tenant-per-customer designs?

As an industry pattern analogy: one operator org, hard isolation per customer tenant (e.g. Auris-style tenant boundaries). Not a compliance seal.

Soft FAQ: treat tenant≠org as operational hygiene for EU multi-customer MSP stacks — never as a certification claim.

Sources

Draft only — do not publish without editorial review.