What Is Multiworkspace for Microsoft Sentinel and Defender XDR? Complete Guide
The Multiworkspace for Microsoft Sentinel and Defender XDR model lets security teams monitor, hunt, and respond across many workspaces without juggling tabs or losing context. It centralizes the single pane of glass while preserving strict data boundaries, so each workspace remains its own “island.” This approach gives global SOC teams a full tenant view—yet still respects permissions and separation for subsidiaries, business units, or regions.
Where it lives: You’ll work primarily in the Defender portal (unified SecOps platform) and, when needed, the Azure portal for Microsoft Sentinel. Changes you make to incidents in either place reflect bi-directionally when those items are in scope to sync.
Core Building Blocks & Terminology
Workspaces, Tenants, and the Unified SecOps Platform
- Workspace: A Sentinel data boundary (often per subsidiary, BU, or geography)
- Tenant: An Azure AD/Microsoft Entra boundary that can contain many workspaces
- Unified SecOps platform: The Defender portal experience that brings XDR and Sentinel together
Incidents, Alerts, and the XDR Correlation Engine
- Alerts are raised by detections
- Incidents group related alerts into an attack story
- The XDR correlation engine stitches signals from Defender products and, in the right conditions, Sentinel alerts into rich multi-stage incidents
Primary vs. Secondary Workspaces (Deep Dive)
What “Primary” Means: The XDR Connector and Tenant-Level Correlation
A primary workspace acts like your “global” workspace. It’s where the XDR connector is connected. In the primary, Defender (XDR) data can correlate with Sentinel alerts to produce full attack stories (e.g., Defender + Sentinel in one incident). This is typically the view your global SOC uses for cross-tenant-level signals.
What “Secondary” Means: Autonomous Correlation with Local Data
A secondary workspace correlates only its own Sentinel data. It does not ingest or correlate other workspaces’ data. This is ideal for subsidiaries or teams that need autonomy and privacy but still want modern correlation and SOC workflows within their own boundary.
Data Boundaries: Why Each Workspace Is an Island
- No data blending between workspaces
- Users only see the workspaces they are permitted to access
- Cross-workspace hunting is possible via queries, but incidents/alerts remain scoped to their workspace
Custom Detections: Current Scope and Considerations
- Custom detections currently apply to the primary workspace
- Secondary workspaces still enjoy XDR-style correlation—just against their own data
Single-Tenant Multiworkspace: Operating Model
Workspace Selector Across Sentinel Experiences
Switch context quickly inside the Defender portal: analytics, content hub, incidents, hunting—use the workspace selector to pivot without leaving the page.
Incident & Alert Queues with Workspace Filtering
View everything in a unified queue, then filter by workspace to drill down. This helps global SOCs triage by severity across all workspaces and hand off local cases to subsidiary teams.
Unified Entity Page and Investigation Workflow
Search any entity (user, device, IP) from the global search. The entity page aggregates relevant alerts, incidents, and timelines from the workspaces you can access—giving a fuller picture, faster.
Advanced Hunting Across Multiple Workspaces
Choosing a Single Workspace vs. Cross-Workspace Queries
- For deep local investigations: Run hunting in the specific workspace
- For global sweeps (e.g., “what else talked to this IOC?”): Use cross-workspace queries
Using the Workspace Operator Safely and Clearly
- The workspace operator lets you query multiple workspaces in one statement
- For clarity in results, include workspace name/ID as a column in your query output so analysts know the source of each row
- Remember: queries don’t merge incidents; they only read data. Boundaries remain intact
Bi-Directional Sync: Defender Portal ↔ Azure Portal
Owner, Status, Closing Reason, and Consistency Guarantees
When you change owner, status, or closing reason on an incident in one portal, those fields sync to the other portal for the same workspace (and when that item is in scope to sync). This keeps analysts in different portals aligned.
What Syncs, What Doesn’t, and Why
- Syncs: Standard incident fields (owner, status, closing reason) and other supported updates
- Doesn’t sync across workspaces: Data never jumps the boundary. A change to Workspace A doesn’t modify Workspace B. That’s by design
Content Management & Distribution
Analytics Rules and Exporting/Importing Across Workspaces
- Build or tune an analytics rule where it belongs, then export/import to other workspaces to replicate coverage
- For primary vs. secondary, remember custom detections are primary-scoped today; use analytics rules for broad repeatability
Repositories (GitHub/Azure DevOps) and CI/CD Pipelines
- Use Repositories (in the Defender single-tenant experience under Sentinel Content Management) to connect GitHub and keep rules versioned
- Pair with Azure DevOps or GitHub Actions for CI/CD to test and roll out changes per environment (dev → test → prod)
Versioning, Testing, and Staged Rollouts
- Maintain JSON templates for rules
- Use pull requests for peer review
- Stage deployments to reduce risk and make rollbacks easy
Multi-Tenant Operations: The MTO Portal
One Interface to Manage Them All (Incidents, Alerts, Hunting)
The Multi-Tenant Organization (MTO) portal provides centralized visibility across customers/tenants—incidents, alerts, and Sentinel data from multiple tenants and workspaces in a single view, with data boundaries still intact.
Delegated Access: B2B for Defender, Azure Lighthouse for Sentinel
- Use B2B (cross-tenant guest access) to see Defender data
- Use Azure Lighthouse to administer and query Sentinel across tenants (e.g., cross-workspace hunting, content deployment)
- Respect boundaries: the portal is a UI lens, not a data blender
Scale, APIs, and Automation
Incident Sync with ITSM, Enrichment, and Data Collection APIs
- Sync incidents with ServiceNow or your MSSP platform
- Enrich incidents automatically (owner, priority, contextual tags)
- Data collection APIs give you flexible ingestion and transformation options
Template-Driven Content Rollout at Scale
- Distribute analytics rules and content programmatically to tenant groups
- Keep consistent detection coverage across all customers with minimal manual effort
Security Boundaries & Zero-Overexposure Principles
Tenants and Workspaces Kept Separate by Design
- No lateral movement via the UI
- You only see what your permissions allow
- Incidents/alerts never cross from one workspace to another
Why Defender Data Correlates with Primary (and Not Secondary)
- The primary is intended for global SOC views and tenant-level Defender signals
- Secondary workspaces stay clean and local to protect privacy, sovereignty, and operational autonomy
SOC Use Cases & Best Practices
Global SOC Triage Flow (Severity-First, Entity-First)
- Open the unified incident queue
- Sort by severity to hit the riskiest items first
- Use workspace filters to assign to local teams
- On an incident, inspect related alerts, graph, and entities
- Pivot to the entity page for user/device/IP history and blast radius
From Hunting to Detections: Turning IOCs into Rules
- Spot a suspicious IP in one workspace?
- Run a cross-workspace hunt to see where else it appears
- If it’s real, create an analytics rule and export/import (or CI/CD) to other workspaces or tenants
Sharing Learnings Between Subsidiaries Without Mixing Data
- Share rules and playbooks, not raw event streams
- Keep permissions tight, give least privilege, and document ownership per workspace
Limits & Considerations
At-a-Glance Limits
- Up to 100 workspaces per tenant in the Defender portal (1 primary + 99 secondary)
- Up to 100 tenants in the MTO portal
- Up to 20 cross-workspace references in a single query
Performance, Naming, and Permission Hygiene
- Use clear naming for workspaces (e.g., Contoso-EMEA-Prod)
- Maintain RBAC baselines; audit regularly
- Favor rule exports/CI-CD over ad-hoc portal tweaks for consistency
Troubleshooting & Common Pitfalls
“Why Can’t I See X?”—Permissions, Scope, and Filters
- Check workspace permissions and role assignments
- Verify workspace selector and filters in the grid
- Confirm the incident lives in the workspace you’re viewing
Sync Surprises and How to Validate Updates
- Remember: changes sync only within the same workspace across portals
- To validate, open the corresponding incident in the other portal and confirm owner/status/closing reason
FAQs (Single-Tenant & Multi-Tenant)
1) Do secondary workspaces get XDR capabilities?
Yes. They correlate their own Sentinel data with the XDR correlation engine. They don’t mix with Defender data from the tenant—by design.
2) Is there anything primary can do that secondary cannot?
The main difference today is custom detections are primary-scoped. Otherwise, operational features are largely consistent.
3) Will data from one workspace sync to another?
No. Each workspace is an island. No cross-workspace data sync.
4) Why does Defender data correlate only with primary?
To maintain strict data boundaries and because the primary is typically the global SOC view with tenant-level visibility.
5) Can we split Defender data between workspaces with Data Collection Rules (DCRs)?
You can’t connect the XDR connector to secondary workspaces. However, you can still store Defender raw tables (extended retention) in other workspaces as needed for retention/search use cases.
6) How do I manage at scale across many customers?
Use the MTO portal, Azure Lighthouse (Sentinel), B2B (Defender), and CI/CD + APIs to automate content distribution and incident workflows.
7) What about Security Copilot with secondary workspaces?
Security Copilot aims to work across multiple workspaces with feature parity. For the latest specifics, coordinate with your Microsoft contacts or community channels.
8) Does the MTO portal merge tenant data?
No. It’s a centralized view that respects tenant and workspace boundaries. No data blending or lateral exposure.
Optimizing Multiworkspace Operations for Enterprise Security
The Multiworkspace for Microsoft Sentinel and Defender XDR approach gives you a clear, scalable way to operate a global SOC while honoring data boundaries and local autonomy. Use the primary workspace for tenant-level correlation with Defender data, keep secondary workspaces focused and private, leverage the workspace selector and entity page for speed, and bring it all together at scale with MTO, Lighthouse, B2B, APIs, and CI/CD.
This unified approach transforms how enterprises manage security operations across complex organizational structures while maintaining the strict data isolation required for compliance and governance.
Recommended external resource: Microsoft Sentinel documentation
For more insights on Microsoft security architecture, check out our guide on Microsoft Defender Threat Intelligence convergence for enhanced SOC operations.