Sentinel SIEM

Multi-tenancy in Microsoft Sentinel is achieved by using multiple workspaces, typically one per customer tenant, and then managing them centrally. Reusing a single connector and workspace for multiple customers is not supported when data must stay in each customer’s tenant and be logically isolated.

1. Multi-tenancy without customers having Sentinel already

To monitor multiple customers (or multiple Entra tenants) centrally:

• Create at least one Log Analytics workspace enabled for Microsoft Sentinel in each customer’s Microsoft Entra tenant when you need tenant-level or diagnostic-based data connectors (for example, Microsoft Entra ID, Office 365, Azure Activity, Azure Firewall). These connectors only work within their own tenant.
• Use Azure Lighthouse to centrally manage all those Sentinel workspaces from the managing/MSSP tenant. After onboarding with Azure Lighthouse, use the Directory + subscription selector to see and operate on all customer workspaces from a single pane of glass.
• This model keeps ownership and storage of data in each customer tenant, supports data residency and compliance, and allows flexible role assignment between local and central SOCs.

This is the recommended multi-tenant architecture for MSSPs and for organizations with multiple tenants; there is no alternative “single-tenant” Sentinel setup that still provides proper isolation and compliance for multiple customers.

2. Reusing a third‑party EDR connector vs. separate workspace

If a client wants monitoring only for a third‑party EDR:

• The recommended pattern is still a separate Sentinel workspace per customer tenant. Each customer’s EDR data should be ingested into that customer’s own workspace, then managed centrally via Azure Lighthouse.
• Partner/third‑party data connectors are often API/agent based and not tied to a specific tenant in the same way as service‑to‑service connectors, but for MSSP and multi‑tenant scenarios the guidance is to avoid mixing multiple customers’ data in a single workspace.
• Centralizing multiple customers’ EDR logs into one MSSP workspace would:
  • Break data ownership and isolation (all customers’ data in one workspace).
  • Complicate compliance and data residency.
  • Make per‑customer billing and cost attribution harder.

Cost considerations:

• With one workspace per customer, each customer pays for its own ingestion and retention in its own subscription/tenant. This aligns with the documented advantages: data ownership, isolation, compliance, and per‑tenant billing.
• A single shared workspace might look cheaper to operate, but it is not the recommended architecture for MSSPs and is explicitly called out as an alternate model with important limitations (for example, some data sources like Microsoft Defender XDR cannot be connected across tenants).

Therefore:

• Multi‑tenancy is achieved by multiple Sentinel workspaces (one per tenant/customer) plus Azure Lighthouse for central management.
• The third‑party EDR connector should be configured per customer workspace; do not reuse a single connector/workspace to host multiple customers’ data if proper multi‑tenant isolation and compliance are required.

References:

• Prepare for multiple workspaces and tenants in Microsoft Sentinel
• Manage Microsoft Sentinel workspaces at scale
• Extend Microsoft Sentinel across workspaces and tenants
• Manage multiple tenants in Microsoft Sentinel as an MSSP
• Sample Log Analytics workspace designs for Microsoft Sentinel