Microsoft Lighthouse is a delegated management model that allows a service provider to administer customer environments with controlled access. It is commonly used for managed security operations because it separates operational support from direct ownership of customer data and resources, reducing the need to hand over full administrative control.
How Microsoft Lighthouse Works
Microsoft Lighthouse is a delegated management model, so the provider operates within a customer environment without taking over full ownership. The key design point is controlled delegation: support teams can perform defined tasks, while the customer keeps authority over its own tenants, resources and data boundaries.
That separation matters because it changes how administrative trust is granted. Rather than sharing the same broad credentials or standing privileges used by internal administrators, Lighthouse is intended to constrain what a service provider can see and do. In practice, it sits at the intersection of access delegation, operational support and tenant boundary management.
Why Delegated Administration Matters
Delegated administration is useful whenever an organisation needs external or centralised support but does not want to hand over complete control. It is especially relevant in managed security operations, where the provider needs enough reach to monitor, remediate and coordinate actions across multiple customer environments, but not enough privilege to become a full owner of those environments.
The model also helps make responsibilities clearer. The customer retains governance over the environment, while the provider works inside an agreed access envelope. That reduces ambiguity about who can change what, and it supports a cleaner split between operational assistance and account ownership.
Security Boundaries And Access Control
The security value of Lighthouse comes from its boundary design. A delegated model is only safe when access is narrow, auditable and purpose-built for the support task. If the delegated relationship is too broad, the model can drift into de facto administrative takeover, which weakens segregation of duties and increases blast radius if the provider account is misused.
Well-implemented delegation should preserve tenant separation, limit standing privileges and make access decisions explicit rather than informal. That is why models like this are often discussed alongside least privilege, controlled delegation and strong auditability. They are not just operational conveniences, they are access-governance choices with direct security consequences.
Where Microsoft Lighthouse Fits In Managed Security Operations
Microsoft Lighthouse is most useful when a service provider needs recurring, repeatable access across many customer environments. That makes it a natural fit for managed security operations, help desk escalation, tenant-level monitoring and structured remediation workflows. The model is designed to make multi-customer administration more scalable without collapsing each customer into a shared administrative plane.
Its practical advantage is that it can reduce the need for direct credential handoffs, ad hoc remote access and permanently shared admin roles. Those practices are operationally convenient but create avoidable exposure. A delegated management model gives organisations a way to keep support efficient while still preserving customer control and a clearer trust boundary.
Risk and Threat Considerations
Delegated management concentrates trust in the provider relationship, so the main risk is overreach, abuse or configuration drift that grants more access than intended. If the delegation layer is mis-scoped, compromised, or poorly audited, an attacker who reaches the provider side can inherit broad cross-customer reach.
Failure mechanism: Excessive delegation, weak tenant scoping or poor review of provider permissions can turn a support relationship into a privilege escalation path, especially when the same operational workflow touches many customer environments.
Impact: A compromise can expose customer resources, administrative actions, and sensitive operational data across multiple tenants, while also making incident containment harder because the trusted access path itself becomes part of the attack surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Delegated support access should be limited to the minimum needed for the task. |
| AU-2 — Event Logging | Delegated administration needs auditable records of provider actions across customer tenants. | |
| IA-2 — Identification and Authentication (Organizational Users) | Provider administrators must be strongly authenticated before they can use delegated access. | |
| Recommendation — Restrict provider permissions to the minimum set needed for delegated administration. Log delegated actions so customer and provider activity can be reviewed and investigated. Require strong authentication for provider users who operate under delegated access. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Delegated access aligns with verify-explicitly and least-privilege trust boundaries. |
| Recommendation — Apply zero-trust principles to verify every delegated request and constrain access by context. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Delegated management depends on controlled provisioning, review and revocation of access paths. |
| Recommendation — Manage delegated access centrally and remove it promptly when no longer required. | ||
Practitioner Guidance
Governance implication: Treat Lighthouse-style access as a formal delegated authority relationship, not as a convenience layer. Define who owns the access model, what actions are permitted, and how often the delegation is reviewed.
What to watch for: Pay close attention to standing access, broad support roles and any workflow that allows a provider to cross tenant boundaries without clear justification. The safest deployments are the ones where the support model is narrowly expressed, easy to audit and easy to revoke.
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 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org