Azure Lighthouse (2025): What It Is, How to Use It, and Why It Accelerates Multi-Customer, Multitenant Management

What Azure Lighthouse is and key benefits

Azure Lighthouse enables cross-tenant management with scalability, automation, and governance. The customer (the tenant that owns the subscriptions) decides what to delegate (one or several subscriptions, or specific resource groups), to whom to delegate it (users, groups, or service principals that live in the provider’s tenant), and with which permissions (RBAC roles). All of this is stored as an Azure resource, visible and revocable at any time.

The main advantage is that the provider team or platform team can work “as if” the remote resources were their own: they see subscriptions in the portal under “My customers”, can deploy Azure Policy, configure Azure Monitor, or review Defender for Cloud; but the customer still retains control and auditing in their own tenant. There is no need to create guest accounts for every engineer, which greatly reduces external identity management.

• Management at scale: a single view for many subscriptions/customers, ideal for SOCs, NOCs, platform teams, and MSPs.
• No guest accounts: no need to populate the customer’s Azure AD/Entra ID with B2B users; delegation is done per resource.
• Native integration: works with most of Azure’s management plane: Policy, Monitor, Defender, Sentinel, Resource Graph, Arc.
• Transparency: the customer can always see which provider has access and which roles it has, and can remove it without depending on that provider.

Architecture and concepts: delegation, roles, and scopes

Internally, Azure Lighthouse is built on the Azure Delegated Resource Management model. Delegation is represented as a resource of type Microsoft.ManagedServices/registrationDefinitions that the customer deploys into their subscription. That resource effectively says: “this tenant (managedByTenantId) can manage this scope (subscription or RG) with these identities and these roles.”

This enables two main strategies:

• Broad delegation (entire subscription): simpler and recommended when you are going to manage posture (Defender, Policy, Monitor) or when the provider offers 24×7 services. You see everything and can manage alerts more effectively.
• Granular delegation (resource group): useful when the customer only wants a specific workload to be managed (for example, a SAP system on IaaS, an IoT environment, or an RG with a critical app).

The identities that receive permissions can be:

• Users in the provider’s tenant.
• Groups in the provider’s tenant (the preferred option, because you can add/remove engineers without touching delegation in every customer).
• Service principals for automations, IaC pipelines, or ITSM integrations.

Onboarding via ARM template (step-by-step)

Onboarding via ARM template is the fastest way to get started. It does not require publishing anything to Marketplace and is perfect for pilots or for customers that already have a relationship with the provider and just need to authorize access.

Detailed steps:

1. Define the model: the provider tells the customer which tenant should appear as managedByTenantId (the provider’s tenant) and which identities (users, groups, apps) will be used. The provider also specifies the appropriate RBAC role: Reader, Contributor, Security Admin, etc.
2. Generate the template from the portal: in the provider’s Azure portal there is an Azure Lighthouse section (“My customers”). From there you can create a delegation definition and the portal automatically generates the ARM JSON with all fields. That JSON is then downloaded.
3. Deliver the template to the customer: the customer deploys the ARM template in their subscription. They can do this from the portal (Import template → Review + create) or via CLI/PowerShell. It is important that the resource provider Microsoft.ManagedServices is registered in the subscription.
4. Validate on both sides: in the provider’s tenant the new customer should appear under “My customers”; in the customer’s tenant the provider should appear under “Service providers”. If this does not show up, something was deployed incorrectly.
5. Document the delegation: it is a good practice to store the exact JSON used so that, if you ever need to add another role or a new group, you build on the same base and do not end up creating a different model.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-08-01/managedservicesDefinition.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "mspOfferName": {
      "type": "string"
    },
    "mspOfferDescription": {
      "type": "string"
    },
    "managedByTenantId": {
      "type": "string"
    },
    "authorizations": {
      "type": "array"
    }
  },
  "resources": [
    {
      "type": "Microsoft.ManagedServices/registrationDefinitions",
      "apiVersion": "2020-02-01",
      "name": "[guid(parameters('mspOfferName'))]",
      "properties": {
        "registrationDefinitionName": "[parameters('mspOfferName')]",
        "description": "[parameters('mspOfferDescription')]",
        "managedByTenantId": "[parameters('managedByTenantId')]",
        "authorizations": "[parameters('authorizations')]"
      }
    }
  ]
}

If later you need to add another group or a new application, you redeploy the same (updated) template or create a new delegation. The key point is not to lose the relationship between “customer” and “which permissions we granted”.

Onboarding via Managed Service in Azure Marketplace

When you want customer onboarding to be self-service or when you are selling managed services packages, the cleanest route is to create a Managed Service offer in Azure Marketplace. This makes your service offer visible to the customer so they can purchase it, and during that same process the Lighthouse delegation is created.

This approach has commercial benefits (visibility, self-provisioning, plan control) and governance benefits (you can have a “basic” plan for everyone and an “extended” plan only for customers with a specific contract).

High-level steps:

1. Create the offer in Partner Center, of type Managed Service.
2. Define the plans (public and/or private) and, in each plan, specify which provider identities will get which roles.
3. Publish and test with a test tenant to confirm that, when the offer is purchased, the delegation appears under “Service providers”.
4. Explain to the customer how to acquire that offer and which permissions they will be granting.

Day-to-day operations: portal, CLI/API, Policy, Monitor, Defender, and Sentinel

Once delegation is in place, day-to-day work looks very similar to managing your own subscriptions, but with a customer filter. From “My customers” in the portal you can select a customer; when you do, the portal switches context and everything you do from that point onward (create alerts, view machines, assign a Policy) is performed against the delegated subscription.

This is especially powerful for tasks such as:

• Azure Policy: assign an initiative (e.g., ISO 27001 or Azure Security Benchmark) from the provider’s tenant to the customer tenant and see compliance for several customers in a single pane of glass.
• Azure Monitor and diagnostics: send Activity logs, PaaS resource logs, and infrastructure logs to a Log Analytics workspace in the provider’s environment. Then build dashboards grouped by customer.
• Defender for Cloud: review recommendations and secure score without logging into the customer’s tenant. If the customer has delegated the entire subscription, visibility is almost complete.
• Microsoft Sentinel: collect telemetry from multiple customers into one or several workspaces and apply common rules and playbooks.

You can also work via CLI or PowerShell: simply run az account get-access-token --tenant <provider-tenant> (or your standard login) and then select the delegated subscription. ARM operations will run against that subscription as if it were your own.

Security and governance: MFA, least privilege, “eligible” permissions, and auditing

One key point that is sometimes overlooked: the customer’s conditional access policies do not always protect the provider’s identities, because those identities live in another tenant. That is why security must be reinforced in the provider’s tenant:

• Mandatory MFA for all engineers and apps operating via Lighthouse.
• Conditional access (location, device, risk) in the provider’s tenant.
• Group-based assignments and regular access reviews.
• Just-in-time elevation (“eligible” permissions) for high-risk operations.
• Auditing and log export on the customer side to verify who did what.

This strikes the right balance: the customer feels safe because they can revoke and audit access; the provider works efficiently because they no longer need to juggle 15 different guest accounts.

Costs and availability

Azure Lighthouse has no additional cost. You pay the same as if the customer were not using it. The real cost comes from what you do on top (logs, Sentinel, Defender, monitoring, automations). For that reason, it is also a good idea to enable budgets and cost alerts per delegated subscription, even if the invoice is paid directly by the customer: this allows the provider to warn them in time.

It is available in public Azure. For sovereign clouds (government, China, etc.), you must verify compatibility, as cross-cloud delegation is not always supported.

Limitations and technical considerations

Although very flexible, there are some limitations you need to keep in mind to avoid designing processes that cannot be executed later:

• Management plane only: if your scenario requires reading storage contents or a Key Vault secret, you will need to grant data-plane permissions or deploy a function/Logic App in the customer’s tenant.
• Built-in roles over custom roles: built-in roles are fully supported and tested; custom roles sometimes do not behave as expected in delegated scenarios.
• Delegate at the right level: if you want to measure complete security posture, delegate the entire subscription; if you only delegate a single RG, some security views will be incomplete.
• No cross-cloud mix: do not design assuming that a public Azure tenant can control a sovereign cloud tenant via Lighthouse.

Use cases: MSP/CSP and multitenant enterprises

MSP/CSP

The typical pattern is: the MSP has its own operations tenant, onboards each customer via ARM or Marketplace, and then applies the same Policy templates, diagnostic settings, and Sentinel rules to all of them. Incidents land in a central NOC/SOC, and you can see the customer’s context with a single click.

Multitenant enterprise

Many organizations have a corporate tenant plus “satellite” tenants for subsidiaries, projects, acquisitions, or geographical regions. With Lighthouse they can manage all of them from the corporate tenant without forcing subsidiaries to invite users or give up full control.

Frequently asked questions about Azure Lighthouse

Clear answers to the questions that usually appear when Lighthouse is proposed in managed operations, MSP, or multitenant projects.

Official links

• Azure Lighthouse — overview
• Onboard customers using ARM templates
• Publish Managed Service offers in Marketplace
• Recommended security practices
• Azure Lighthouse architecture
• View and manage customers
• Samples and templates
• Requirements for Managed Service offers (Partner Center)

Conclusion and next steps

Azure Lighthouse is the missing piece that lets Azure operations become truly multi-customer without the usual headaches: the customer keeps control and can revoke access, the provider works from its own tenant with its own security policies, and the platform team can standardize tools, dashboards, and runbooks.

The practical path usually looks like this: 1) define roles and scopes, 2) test an ARM-based delegation with a pilot customer, 3) standardize the templates, and 4) if you have a broader commercial offer, publish it to Marketplace. From there, adding Policy, Monitor, Defender, and Sentinel is mostly a matter of operational maturity.