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.
Expanded Definition
Microsoft Lighthouse is a delegated management model for managed service providers and security teams that need to operate across customer tenants without taking full ownership of those environments. Its core value is separation of duties: the provider receives scoped access to perform support tasks while the customer retains control over the tenant, data, and policy boundaries.
In practice, Lighthouse sits between direct tenant administration and shared credentials. That distinction matters because the model is designed around delegated authorization rather than account sharing, which makes access more auditable and easier to revoke. Definitions vary across vendors, but the practical boundary is consistent: Lighthouse is about controlled cross-tenant administration, not universal tenant takeover or broad partner equivalence.
For readers comparing it with ordinary remote administration, the useful test is whether access is explicitly delegated, limited in scope, and tied to the customer relationship. If it is, the model is operating as intended. For a broader NHI context, NHIMG’s guide to Non-Human Identities is a useful reference for how delegated access and machine credentials fit into modern identity governance.
Examples and Use Cases
Microsoft Lighthouse most often appears in managed services where one provider needs repeatable visibility across many customer environments without creating separate administrative chaos for each tenant.
- A managed detection and response team uses delegated access to review alerts, investigate suspicious activity, and apply response actions inside a customer tenant.
- A cloud operations partner checks configuration drift and policy posture across multiple tenants while preserving customer ownership of the environments.
- A security provider performs administrative tasks such as remediation, license changes, or endpoint coordination without reusing shared partner passwords.
- A multi-customer support desk uses Lighthouse-style delegation to reduce the operational friction of tenant-by-tenant login handling.
The main tradeoff is control versus scale. Delegation improves auditability and reduces credential sharing, but it also creates a high-value access path that must be tightly governed because one partner relationship can touch many customer environments.
Security Implications
Microsoft Lighthouse can reduce exposure from shared admin accounts, but it also concentrates trust. If delegated access is over-scoped, poorly reviewed, or not retired when a contract ends, the result is persistent cross-tenant access that is difficult to spot during routine administration.
That failure mode is especially serious in security operations because provider access often includes visibility into alerts, configurations, and remediation workflows. A compromise of the provider side can therefore create downstream access to many customer tenants at once, which turns a single trust relationship into a broad blast-radius problem.
NHIMG research shows that 92% of organisations expose NHIs to third parties, raising supply chain concerns, and only 20% have formal offboarding and revocation processes for API keys. The same governance weakness appears here: if delegated access is not inventoried, reviewed, and withdrawn on time, access outlives the business need.
A common practitioner symptom is that no one can quickly answer who still has delegated access, what they can do, or whether their access matches current contract scope. That is usually the warning sign that the control model has drifted from delegated administration into unmanaged trust.
Domain and Governance Relevance
In NHI governance terms, Microsoft Lighthouse is significant because it operationalizes delegated machine-mediated access across organisational boundaries. The governance question is not just whether access exists, but whether the provider’s identity, permissions, and lifecycle are owned as deliberately as the customer’s internal accounts and service principals.
This matters because the security model depends on clear accountability for onboarding, least privilege, monitoring, and offboarding. When Lighthouse is used well, it supports Zero Trust-style separation of access from ownership. When it is used casually, it becomes another pathway for over-privileged third parties to reach sensitive environments.
For managed security operations, the practical relevance is straightforward: delegated access must be treated as a governed identity relationship, not as a convenience feature. That interpretation aligns with the broader NHI pattern that access paths used by people, tools, and providers need the same discipline around scope, visibility, and revocation.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Delegated access depends on tightly controlled credentials and tokens, not shared admin accounts. |
| NHI-03 — Access Scope and Privilege | Lighthouse is fundamentally about constrained cross-tenant privileges for providers. | |
| NHI-06 — Lifecycle and Offboarding | Provider access must be inventoried, reviewed, and removed when it is no longer needed. | |
| Recommendation — Enforce scoped credential handling and revoke provider access when the business relationship ends. Limit delegated permissions to the smallest set of actions needed for support work. Track delegated relationships and remove stale access during offboarding and renewal reviews. | ||
| CIS Controls v8 | 6 — Access Control Management | Cross-tenant support requires controlled account and privilege administration. |
| Recommendation — Review and remove third-party access paths that exceed current operational need. | ||
| NIST Zero Trust (SP 800-207) | AC-4 — Policy-Based Access Control | Delegated management works best when access is explicitly policy-scoped and continuously checked. |
| Recommendation — Apply policy-scoped access decisions to each provider action and tenant boundary. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Abuse of delegated provider access can create or preserve unauthorized tenant access. |
| Recommendation — Hunt for unauthorized changes to delegated access and partner permissions. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
