Management and GovernanceDelegated resource managementpremium
Azure Lighthouse
Azure Lighthouse is Azure’s delegated resource management service for securely managing resources across customer or business-unit tenants from one provider tenant. In plain English, it gives teams cross-tenant operations without creating separate local accounts in every customer tenant, while retaining scoped roles and. You usually see it when managed service providers, central IT teams, or enterprise platform groups need auditable access across many Azure tenants. It still needs ownership, monitoring, and change control. The practical question is whether it lets operators deploy, inspect, govern, or troubleshoot the workload clearly.
Lighthouse, delegated resource management, Microsoft Managed Services delegation
Difficulty
advanced
CLI mappings
5
Last verified
2026-05-11
Microsoft Learn
Azure Lighthouse enables secure delegated management of Azure resources across customer tenants, supporting service providers and central teams with scalable cross-tenant governance. Microsoft Learn places it in What is Azure Lighthouse?; operators confirm scope, configuration, dependencies, and production impact. Use the linked source for exact Azure behavior.
Technically, Azure Lighthouse is configured through registration definitions, assignment scopes, managedBy tenant IDs, and principal IDs. Operators verify it with managedservices CLI output, delegated resource views, activity logs, and RBAC assignments. It integrates with Azure Resource Manager, Azure Policy, Microsoft Defender for Cloud, and Azure Monitor. Key settings include delegated scope, provider tenant, principal IDs, and built-in role IDs. Capture desired state, compare it to live Azure state, and keep evidence for releases, incidents, and audits. These details matter because control-plane mistakes can affect many resources quickly.
Why it matters
Azure Lighthouse matters because it turns a broad platform capability into something teams can design, review, and operate. Without a clear understanding of it, teams often make weak assumptions about ownership, limits, dependencies, or failure behavior. Used well, it helps architects choose the right boundary, gives operators observable signals, and gives security and finance teams evidence they can review. The value is not the label alone; the value is the repeatable operating model around it. For secure cross-tenant Azure operations, that operating model reduces surprises during releases, audits, incidents, and scale events. That clarity keeps small design choices from becoming hidden production risks.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
You see Azure Lighthouse in delegated resource views, Managed Services registration assignments, role definitions, customer onboarding artifacts, where engineers confirm the design matches current resource state.
Signal 02
You see Azure Lighthouse in managed service runbooks where operators confirm customer scope, support rights, escalation owners, where operators connect evidence to ownership, recent changes, and incident response.
Signal 03
You see Azure Lighthouse in governance reviews covering cross-tenant permissions, provider identities, customer contracts, offboarding controls, and, where architects, security, operations, and finance teams keep one shared decision record.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Use Azure Lighthouse for secure cross-tenant Azure operations when the workload needs repeatable governance.
Use it during production readiness reviews to confirm configuration, owners, and evidence.
Use it in incident response when operators need a shared technical reference.
Use it in automation when portal-only steps would create drift.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Managed security provider onboarding
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
SentinelPeak Advisory, a managed security services organization, needed to monitor customer subscriptions without creating separate accounts inside every customer tenant.
🎯Business/Technical Objectives
Onboard 18 customer subscriptions.
Delegate only approved built-in roles.
Centralize security alert triage.
Reduce onboarding effort per customer by 60 percent.
✅Solution Using Azure Lighthouse
The provider used Azure Lighthouse registration definitions and assignments to delegate scoped access from customer subscriptions to provider security groups. Roles were limited to approved built-in permissions for monitoring, policy review, and incident response. Microsoft Sentinel and Defender for Cloud views were integrated into the provider operations process. CLI checks listed registration assignments and definitions before each go-live. Customer offboarding steps were documented so delegated access could be removed cleanly at contract end. The team also assigned named owners, saved acceptance evidence, and reviewed rollout notes with support staff responsible for managed security provider onboarding. A final readiness check compared design assumptions, operator permissions, monitoring signals, and rollback steps before the production milestone. After launch, the runbook kept Azure Lighthouse checks tied to the same business objective rather than letting the configuration drift silently.
📈Results & Business Impact
Eighteen subscriptions were onboarded through delegated access.
No standing local customer accounts were created.
Security alert triage ran from the provider tenant.
Average onboarding effort dropped from 12 hours to 4 hours.
💡Key Takeaway for Glossary Readers
Azure Lighthouse enables scalable managed operations when delegation scope and role evidence are tightly controlled.
Case study 02
Enterprise subsidiary governance
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
ArborVale Holdings, a manufacturing conglomerate organization, had subsidiaries using separate Azure tenants, making central policy visibility and cost governance inconsistent.
🎯Business/Technical Objectives
View 22 subsidiary subscriptions centrally.
Apply delegated governance without tenant consolidation.
Standardize policy and cost review access.
Create repeatable offboarding controls.
✅Solution Using Azure Lighthouse
Central cloud governance used Azure Lighthouse to onboard subsidiary subscriptions with delegated registration assignments. Built-in roles allowed policy compliance review, cost analysis, and monitoring but avoided Owner-level access. Management groups remained inside each subsidiary tenant, while the parent team gained cross-tenant visibility for approved operations. CLI commands captured assignment state, registration definitions, and delegated scopes for quarterly governance packets. Offboarding procedures removed assignments when a subsidiary changed support model. The team also assigned named owners, saved acceptance evidence, and reviewed rollout notes with support staff responsible for enterprise subsidiary governance. A final readiness check compared design assumptions, operator permissions, monitoring signals, and rollback steps before the production milestone. After launch, the runbook kept Azure Lighthouse checks tied to the same business objective rather than letting the configuration drift silently.
📈Results & Business Impact
Twenty-two subsidiary subscriptions became visible centrally.
No tenant consolidation project was required.
Policy and cost reviews used consistent delegated access.
Offboarding tests removed access within 30 minutes.
💡Key Takeaway for Glossary Readers
Azure Lighthouse is useful beyond service providers when enterprises need scoped cross-tenant governance without merging tenants.
Case study 03
Municipal cloud support program
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
CivicCloud Partners, a public sector services organization, supported small municipal Azure tenants but struggled with inconsistent emergency access during outages.
🎯Business/Technical Objectives
Create auditable support access for 12 municipalities.
Limit emergency roles to documented scopes.
Improve outage response time.
Give customers clear delegation evidence.
✅Solution Using Azure Lighthouse
The support program created Azure Lighthouse definitions for standard monitoring and emergency response roles. Each municipality approved a registration assignment at subscription scope, with just-in-time procedures for elevated response when available. Activity logs and provider group membership were reviewed monthly. Operators used CLI inventory to prove which customers were delegated and which roles applied. Incident runbooks included customer notification, escalation, and removal steps after emergency work completed. The team also assigned named owners, saved acceptance evidence, and reviewed rollout notes with support staff responsible for municipal cloud support program. A final readiness check compared design assumptions, operator permissions, monitoring signals, and rollback steps before the production milestone. After launch, the runbook kept Azure Lighthouse checks tied to the same business objective rather than letting the configuration drift silently.
📈Results & Business Impact
Twelve municipalities had auditable support delegation.
Emergency access scopes were documented before go-live.
Median outage response time fell from 74 minutes to 29 minutes.
Customers received monthly delegation evidence reports.
💡Key Takeaway for Glossary Readers
Azure Lighthouse makes emergency support safer when delegated roles, customer consent, and review evidence are built into the process.
Why use Azure CLI for this?
Use Azure CLI for Azure Lighthouse when you need repeatable inventory, governed changes, deployment checks, migration evidence, or incident proof. CLI output makes scope, identity, configuration, and timing explicit, which is better than relying on screenshots or memory during reviews.
CLI use cases
Inventory Azure Lighthouse configuration across subscriptions, projects, tenants, or resource groups before a design review.
Capture repeatable evidence for incidents, audits, migrations, and release readiness checks.
Create or update supported settings through reviewed scripts instead of manual portal-only changes.
Compare expected state with actual state after deployment, rollback, migration, or platform upgrade work.
Before you run CLI
Confirm the active tenant, subscription, resource group, workspace, cluster, or project before running any command.
Check whether the command is read-only, mutating, cost-impacting, security-impacting, or destructive.
Use least-privilege identity and store sensitive output in approved locations only.
Have rollback notes and owner contacts ready before changing production configuration.
What output tells you
The output identifies the current Azure Lighthouse resource, setting, relationship, or runtime state being inspected.
IDs, regions, SKUs, tags, endpoints, identities, and scopes show whether deployment matches the design.
Empty or missing fields often reveal an incomplete configuration, wrong scope, unsupported feature, or stale deployment.
Metric and state values help separate Azure configuration issues from application behavior problems.
Mapped Azure CLI commands
Azure Lighthouse operations
direct
az managedservices assignment list
az managedservices assignmentdiscoverManagement and Governance
az managedservices assignment show --assignment <assignment-id>
az managedservices assignmentdiscoverManagement and Governance
az managedservices definition list
az managedservices definitiondiscoverManagement and Governance
az managedservices definition show --definition <definition-id>
az managedservices definitiondiscoverManagement and Governance
az managedservices definitionsecureManagement and Governance
Architecture context
Technically, Azure Lighthouse is configured through registration definitions, assignment scopes, managedBy tenant IDs, and principal IDs. Operators verify it with managedservices CLI output, delegated resource views, activity logs, and RBAC assignments. It integrates with Azure Resource Manager, Azure Policy, Microsoft Defender for Cloud, and Azure Monitor. Key settings include delegated scope, provider tenant, principal IDs, and built-in role IDs. Capture desired state, compare it to live Azure state, and keep evidence for releases, incidents, and audits. These details matter because control-plane mistakes can affect many resources quickly.
Security
Security for Azure Lighthouse starts with knowing who can configure it, who can use it, and what data or access path it can influence. The main risk is granting broad cross-tenant access, using unsupported custom roles, weak approval evidence, stale delegations, or unmanaged provider identities. Review RBAC assignments, managed identities, keys or credentials, network exposure, diagnostic logs, and any linked resources before production use. Prefer least privilege, private connectivity where appropriate, audited changes, and secret storage outside application code. Also confirm that support teams can prove the current configuration during an incident without relying on screenshots or memory. Document the approved evidence before the first high-risk change and review it during access recertification.
Cost
Cost impact for Azure Lighthouse comes from service provider operating model, duplicated tenant administration, marketplace offer management, monitoring scale, support effort, and delayed offboarding of unused delegations. The common waste pattern is enabling the capability for a pilot, then leaving resources, replicas, logs, or supporting infrastructure running after the original need changes. Estimate costs before rollout, tag resources to a clear owner, and compare steady-state usage with the design assumption. During reviews, look for unused resources, overbuilt tiers, avoidable data movement, and duplicated environments. Cost control works best when finance data is tied back to operational intent. Tie each optimization to an owner, forecast, and retirement date.
Reliability
Reliability depends on whether Azure Lighthouse is designed for the workload’s real failure modes. Focus on delegation state, provider identity health, customer scope accuracy, activity log visibility, onboarding rollback, role availability, and management plane access during incidents. A reliable design documents what should happen during scale-out, regional disruption, credential failure, deployment rollback, and operator error. Monitoring should show both the Azure resource state and the application symptoms users actually feel. Test the runbook before an outage, capture evidence from CLI or portal checks, and decide which failures require manual intervention versus automated recovery. Include dependency maps and health signals so responders know whether the platform or application failed during triage.
Performance
Performance depends on how Azure Lighthouse affects latency, throughput, deployment speed, or operator decision time. Focus on operator decision speed, cross-tenant query scale, portal load behavior, automation fan-out, alert triage time, and reduced handoffs between customer tenants. Do not assume the default setting is fast enough for production or that a faster tier fixes design problems. Measure before and after important changes, watch for throttling or slow control-plane calls, and test with realistic scale. Performance evidence should include user-facing symptoms, resource metrics, and configuration details so the team can distinguish service limits from application defects. Include baseline measurements so later tuning work has a defensible comparison point for teams.
Operations
Operationally, Azure Lighthouse should appear in runbooks, dashboards, release gates, and ownership records. Focus on customer onboarding, delegation reviews, role recertification, provider group ownership, incident access checks, marketplace offer updates, and evidence for managed service audits. The team should know which commands are safe for inventory, which changes are mutating, and which outputs prove compliance or readiness. Keep naming, tags, environments, and documentation consistent so support engineers can find the right resource quickly. Review the configuration after major releases, incident retrospectives, platform upgrades, and cost reviews rather than treating it as a one-time setup. Assign a named owner, keep an escalation path, and review stale automation before quarterly platform reviews.
Common mistakes
Running commands against the wrong subscription, tenant, workspace, cluster, or environment because context was not checked.
Treating a successful create command as proof that security, monitoring, and operations are complete.
Copying examples into production without adjusting regions, names, identities, SKUs, and network rules.
Ignoring service-specific limits, preview behavior, retirement status, or required extensions before automation rollout.