Azure Lighthouse lets a managing organisation administer customer tenants from its own environment through delegated access. It does not copy data into one tenant, but it does centralise operational control. Security teams should review which roles are delegated, limit blast radius, and monitor cross-tenant administrative actions and approvals carefully.
How Azure Lighthouse operational control is delegated
azure lighthouse is built for cross-tenant administration without requiring the managing organisation to sign into each customer tenant separately. The customer grants delegated access to specific Azure roles and scopes, and the managing team operates through its own tenant, tools, and identity stack. That separation is the main security property: centralised operations, not centralised ownership.
Because access is delegated rather than copied, the important question is not whether a team can reach a tenant, but exactly what it can do once there. This is why role scope, subscription boundaries, management group structure, and approval workflow all matter more than the marketing description of “managed service.”
Azure Lighthouse also fits the broader pattern of delegated cloud administration, where operational convenience has to be balanced against privilege concentration. For a wider Azure security baseline, the Microsoft Azure Security Guide is the best place to anchor Lighthouse in the surrounding control model.
What actually happens when a managing tenant acts in a customer tenant
The managing organisation uses its own identities to access customer resources through Azure’s cross-tenant delegation model. In practice, that means an operator can administer multiple customer environments from one control plane while each customer still retains authority over what has been delegated, what has been approved, and what can be revoked.
Operationally, this is useful for managed service providers, central platform teams, and security operations groups that need repeatable access across many tenants. The model reduces duplication of accounts and manual tenant switching, but it also makes delegated role design the critical design decision. If the delegated role is too broad, the convenience benefit quickly turns into unnecessary blast radius.
When you want to understand the identity and delegation side of that trade-off, the Active Directory and Entra ID Hardening Guide helps place cross-tenant access in the wider governance context, while the Cloud Workload Identity Guide is useful for understanding how modern cloud access differs from static, long-lived credentials.
Why the security model depends on delegated roles, monitoring, and revocation
Azure Lighthouse changes the control problem from “who has local access?” to “who has delegated authority, for which scope, and under what review process?” That means security teams should treat delegated access as a governed control surface, not just an operational shortcut. Scope creep, stale authorisations, and overbroad operator roles are the failure modes that matter most.
Cross-tenant administration also makes activity review more important than usual because the same operator may legitimately touch many environments in a short period of time. If your logging, approvals, and role review process are weak, it becomes harder to distinguish normal managed-service activity from misuse or compromise. The relevant question is not only whether access exists, but whether you can prove it was expected.
That is why practitioners often pair Lighthouse with stronger identity hardening and tenant visibility controls. The Microsoft Storm-0558 key breach 2023 is a reminder that token or signing trust failures can have broad cross-tenant consequences, while the Entra ID actor token flaw (CVE-2025-55241) shows how cross-tenant trust boundaries can become very high impact when identity validation is weak.
Risk and Threat Considerations
Azure Lighthouse reduces administrative friction, but it also concentrates operational power into delegated roles that can span multiple customer tenants. If those roles are overprivileged or poorly monitored, one compromise can create broad downstream exposure across many environments instead of just one.
Failure mechanism: An attacker who gains access to the managing organisation’s delegated admin path can abuse legitimate cross-tenant authority, hide inside normal operator activity, and move laterally across customer scopes that were intended to be separately governed.
Impact: The result can be data exposure, configuration tampering, privilege abuse, or service disruption across multiple tenants, especially when approvals, logging, and revocation are not tightly enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Azure Lighthouse depends on tightly scoped delegated access. |
| AU-2 — Event Logging | Cross-tenant admin actions need traceable logs for review. | |
| IA-2 — Identification and Authentication (Organizational Users) | Managing-tenant operators still need strong authenticated admin access. | |
| Recommendation — Restrict delegated roles and scopes to the minimum needed for each tenant relationship. Log delegated administrative actions across tenant boundaries for review and investigation. Require strong authentication for operators performing delegated cross-tenant administration. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Lighthouse is fundamentally a delegated cloud access and governance pattern. |
| Recommendation — Govern delegated access paths, role assignment, and revocation for each customer tenant. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Delegated cloud administration can become overprivileged if roles are too broad. |
| Recommendation — Limit delegated cloud roles to reduce blast radius across tenants. | ||
Practitioner Guidance
What to verify: Confirm the exact delegated roles, scopes, and approval path for every Lighthouse relationship, and test whether each one can be revoked quickly without breaking unrelated operations.
What to measure: Track how many tenants each operator can reach, how many privileged actions are delegated, and how quickly cross-tenant access can be removed when a contract ends or an account is suspected compromised.
Common mistake: Treating Lighthouse as a pure convenience feature and forgetting that delegated administration is still privileged access, just delivered through a different control plane.
Practitioner takeaway: Azure Lighthouse is safest when it is managed like tightly scoped delegated privilege, with explicit boundaries, strong auditability, and a routine for rapid revocation when trust changes.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org