Notifications
Clear all
Topic starter
08/07/2026 6:58 pm
TL;DR: Tenant-local deployment through Azure Lighthouse shifts security tooling for MSPs, MSSPs, and enterprises away from shared vendor clouds and toward customer-controlled environments, according to Senserva. The governance lesson is that control, visibility, and delegated access now matter more than deployment convenience when identity and security state must stay inside the tenant.
NHIMG editorial — based on content published by Senserva: Why Senserva’s Azure Lighthouse Approach Is a Security Game-Changer
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
A: The decision should start with custody of identity state.
Q: Why does delegated Azure access create governance risk in MSP and MSSP models?
A: Delegated access is powerful because it scales administration across tenants, but it can also behave like standing privilege if scopes are broad or never reviewed.
Q: What do security teams get wrong about agentless identity scanning?
A: Teams often assume that because a tool installs nothing on the workload, it is automatically low risk.
Practitioner guidance
- Map your trust boundary to the tenant first Document which identity and security objects must remain inside the Azure tenant, including configuration state, audit logs, and policy records.
- Review delegated access as a lifecycle control Treat Azure Lighthouse permissions as time-bound governance objects.
- Audit API permissions and telemetry paths Confirm that Microsoft Graph and related API access is limited to the minimum needed for scanning, reporting, and drift detection.
What's in the full article
Senserva's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step deployment flow for Azure Lighthouse onboarding across customer tenants
- Specific Microsoft Graph, Defender, Sentinel, and Entra ID integration points used by the platform
- Packaging and update mechanics for tenant-local instances, including CI/CD rollout behaviour
- Tenant UI lockdown and access restriction details for operator-only administration
👉 Read Senserva's analysis of tenant-local Azure security management with Azure Lighthouse →
Azure Lighthouse tenant-local security control: what changes for IAM teams?
Explore further
08/07/2026 7:20 pm
Tenant-local security tooling is really a control-boundary decision, not a deployment preference. When security state stays in the customer tenant, the organisation preserves clearer ownership of logs, policies, and configuration history. That matters because identity governance fails quickly when telemetry and control evidence are scattered across external environments. The practitioner takeaway is to judge tools by where they store trust, not by how quickly they install.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which shows how thin identity oversight still is in many environments.
A question worth separating out:
Q: Who is accountable if a tenant-local security tool exposes identity data?
A: Accountability depends on custody and delegation. If the data remains inside the tenant, the customer retains primary governance responsibility, while the operator is accountable for the delegated permissions and the way it handles the environment. If the tool centralises data outside the tenant, the accountability chain becomes broader and harder to prove during audit or incident review.
👉 Read our full editorial: Azure tenant-local security management changes the NHI trust model
