One SOC, Many Tenants: Centralizing Microsoft Sentinel with Azure Lighthouse

Most large organizations don’t live in a single Microsoft Entra ID tenant. Acquisitions, regulatory separation, sovereignty mandates, and mission boundaries all multiply tenants over time. For a security operations team, that sprawl creates one hard question: how do you run a single security operations center (SOC) with one pane of glass, without copying every tenant’s logs into a central bucket and inheriting the compliance risk that comes with it?

Azure Lighthouse provides delegated resource management for this scenario. It lets authorized operators in a central hub tenant work with scoped resources in spoke tenants from their own tenant. Paired with Microsoft Sentinel, it supports cross-tenant visibility while source logs remain stored in each spoke workspace. Group-based RBAC and Privileged Identity Management (PIM) can help govern privileged access.

This practical blueprint applies least privilege to that pattern: one Sentinel deployment in the hub, delegated read access to the Log Analytics workspaces in each spoke, and RBAC and PIM controls that support auditability. The delegation is scoped to the workspaces the SOC needs.

Before you begin: prerequisites

Gather the identifiers and identity groups below before you touch any tenant. The consistency you establish here is what makes the per-spoke procedure repeatable across an entire estate.

Collect tenant and workspace identifiers

• Hub CSOC tenant ID and hub Sentinel workspace resource ID.
• For each spoke: tenant ID, subscription ID, workspace resource group, and workspace resource ID.

Create hub security groups in Microsoft Entra ID

• SOC-Readers, the required core query-access group.
• SOC-Responders, an optional group for response-specific actions.
• SOC-Admins, an optional and tightly controlled group.

Define the minimum RBAC baseline

• Assign Log Analytics Reader to SOC-Readers at the spoke workspace or resource-group scope.
• Add elevated roles only when a documented use case requires them.

Register the required resource providers

Lighthouse and Sentinel both depend on resource providers being registered before delegation will work. In every spoke subscription, register Microsoft.ManagedServices so the delegation can be created. And because Sentinel lives only in the hub, register Microsoft.SecurityInsights and Microsoft.OperationalInsights on at least one subscription in the hub tenant. That last step is easy to overlook, and skipping it quietly blocks cross-tenant operations.

What you’ll find here

• The architecture, and why data residency makes hub-and-spoke the right call.
• Prerequisites, including the resource providers teams most often forget to register.
• A repeatable, per-spoke delegation procedure.
• Validation queries that prove the access path actually works.
• A complete RBAC assignment matrix and PIM activation policy.
• Troubleshooting for the errors you’ll actually hit.

Why hub-and-spoke for a cross-tenant SOC

In this model, Microsoft Sentinel is deployed once, in the hub (CSOC) tenant. Each spoke tenant keeps its own Log Analytics workspace, where its logs are collected and retained. Azure Lighthouse connects the two: the spoke delegates scoped access to the hub, and authorized hub analysts query spoke workspaces from their own tenant. The source logs remain stored in the spoke workspace, while query results are returned across tenant boundaries to authorized users and services.

Figure 1. The hub runs Sentinel and queries each spoke’s Log Analytics workspace through a scoped Azure Lighthouse delegation; logs never leave the spoke tenant.

That separation is the entire point, and it lines up with the advantages Microsoft calls out for centralized cross-tenant management:

• Workspace ownership and source-log storage remain with each spoke tenant.
• Source telemetry remains stored in the configured spoke workspace and region, subject to the service configuration and authorized query access.
• Separate workspaces help maintain tenant isolation between spokes.
• Cross-tenant detection and hunting can query spoke workspaces without centralizing the underlying source logs; authorized query results are returned across tenant boundaries.
• Ingestion and retention costs are billed to the tenant that generates the data, not to the hub.

What this runbook delivers

The objective is a centralized CSOC with scoped, governed access across spoke tenants from a single Sentinel instance. Hub SOC teams query spoke Log Analytics workspaces through delegation, run cross-tenant analytics, and create and manage incidents centrally, while spoke logs stay in spoke workspaces and tenant isolation is preserved.

Just as important is how that access is granted. The target state is least-privilege by construction: RBAC assignments carry only the permissions the SOC needs, privileged roles are PIM-governed rather than standing, and every delegation is scoped to the specific resources in play. When the build is complete, the operating model is both active and auditable.

 

Configuring the delegation (per spoke tenant)

Repeat the three steps below for each spoke. For fleets larger than a handful of tenants, capture the same authorization in an Azure Lighthouse ARM template and deploy it per spoke, so the scope and role assignments stay identical across the estate.

Step 1: Register the provider in the spoke subscription

• • Register Microsoft.ManagedServices in the spoke subscription.
  • Confirm the provider registration state is Registered before continuing.

Step 2: Create the Lighthouse delegation from spoke to hub

• • Open Azure Lighthouse in the spoke tenant.
  • Create a delegation, or offer, and set the managing tenant to the hub CSOC tenant ID.
  • Add an authorization with the principal set to the hub SOC-Readers group and the role set to Log Analytics Reader.
  • Set the scope to the workspace resource group (preferred) or to the individual workspace.
  • Prefer group-based assignments and avoid direct user assignments.

Step 3: Repeat across all spoke tenants

• • Apply the same pattern and naming convention every time.
  • Document any scope or role exceptions for security review.

Validating the delegation

Three checks confirm the delegation is wired correctly: visibility, query access, and incident generation. Run them in order, because each one depends on the check before it. 

Figure 2. The three validation checks run in sequence — visibility, then cross-tenant query, then incident generation — each building on the one before.

Confirm delegated visibility

• From the hub context, verify that each spoke appears under Azure Lighthouse delegated resources.
• Confirm that the expected principals and scopes are listed.

Run a cross-tenant query from hub Sentinel

• Run a simple take query to verify that the access path resolves.
• Run a data query against a known active table to confirm you can see ingestion.

Confirm the access path resolves:

workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>") | take 1

Check that a known table is receiving data:

workspace("/subscriptions/<spoke-sub-id>/resourceGroups/<spoke-rg>/providers/Microsoft.OperationalInsights/workspaces/<spoke-ws>").Heartbeat | where TimeGenerated > ago(24h) | summarize Events = count()

Verify incident generation in hub Sentinel

• Create a temporary scheduled analytics rule that uses cross-tenant query logic.
• Trigger the test condition and confirm that the incident is created in the hub.

Standardizing new-spoke onboarding

Turn the procedure into a checklist so every new spoke is onboarded the same way and nothing slips.

• Resource provider registered.
• Delegation deployed with the hub as managing tenant.
• Roles assigned to hub SOC groups.
• Cross-tenant query test passed.
• Hub incident-generation test passed.
• Access-review owner assigned.

Security and governance

Delegation connects the hub to scoped spoke resources; governance helps control that access. Three controls do most of the work.

Enforce privileged identity controls

• • Make privileged groups PIM-eligible rather than permanently assigned.
  • Require MFA, approval, justification, and time-bound activation.

Maintain separation of duties

• • Keep SOC monitoring, content engineering, and platform administration in separate roles.
  • Review delegated access on a recurring governance cadence.

Manage exceptions with formal controls

• • Document every elevated-access and broad-scope delegation exception.
  • Require security-architecture approval for any non-standard scope.

Role and RBAC assignment matrix

The tables below translate those principles into concrete assignments: first the hub-local roles, then the delegated spoke roles, and finally the PIM activation policy that governs both.

Hub (CSOC) tenant: local assignments

Spoke (service) tenant: delegated via Azure Lighthouse

PIM activation requirements

Key design rules

• Minimum privilege governs spoke delegation. Log Analytics Reader covers every cross-tenant detection and query operation, so Owner and broad Contributor at subscription scope have no place in a SOC delegation.

• Sentinel Responder in a spoke is rarely needed. It matters only when analysts must acknowledge, close, or act on spoke-level resources directly, and in a hub-only Sentinel model spoke incidents don’t exist, so the role usually isn’t required.

• Separation of duties is strict. Content engineers don’t get responder rights, responders don’t get content-deployment rights, and platform admins sit apart from both monitoring and detection engineering.

• Routine privileged roles are eligible and time-bound. SOC responders, hunters, content engineers, and platform admins use PIM rather than permanent assignment. Emergency-access accounts are the exception and should follow Microsoft Entra emergency-access guidance, including monitoring and regular validation.

Troubleshooting common issues

Most problems fall into three buckets, and each has a short diagnostic path.

Design notes and what’s next

By default, Sentinel stays enabled in the hub only, unless a spoke-specific requirement is approved. Spoke tenants remain data-source focused and don’t generate local Sentinel incidents; detection, incident management, and automation all live in hub Sentinel, giving you one place to build content and one place to respond.

A centralized SOC does not require centralizing every source workspace. With scoped Azure Lighthouse delegation and PIM-governed access, a CSOC can query a multitenant estate while source logs remain stored in their spoke workspaces.

Further reading

• Manage Microsoft Sentinel workspaces at scale (Azure Lighthouse)
• Manage multiple tenants in Microsoft Sentinel as an MSSP
• Extend Microsoft Sentinel across workspaces and tenants