Microsoft Defender Portal Multitenant Management for MSSPs
Reviewed by ContraForce Security Operations Team ยท Updated 2026-08-12
Microsoft Defender multitenant management gives authorized security teams a unified view across managed tenants for Microsoft Defender XDR and Microsoft Sentinel. MSSPs should prepare delegated access, workspace onboarding, incident procedures, and automation for the Defender portal rather than treating the portal transition as a visual redesign.
Microsoft states that Sentinel will no longer be supported in the Azure portal after March 31, 2027 and will be available in the Defender portal. See Automation in Microsoft Sentinel.
What changes for an MSSP
The Defender portal brings XDR and SIEM operations into a unified experience, but the operational model still depends on permissions and tenant relationships. Microsoft notes that multitenant interactions respect the permissions granted by the managed tenant. See multitenant management requirements and governance relationships.
For an MSSP, preparation should cover four layers:
| Layer | Decision |
|---|---|
| Delegated access | Which roles can view incidents, hunt, change configuration, or execute response in each customer tenant? |
| Workspace topology | Which Sentinel workspace is primary, and where do automation rules run? |
| Operating procedure | Which incident classes can close automatically, require approval, or always escalate? |
| Customer evidence | Where are investigation notes, approvals, response actions, and service records retained? |
Migration checklist
1. Inventory every managed tenant
Record the customer's licensing, Defender products, Sentinel workspace, delegated relationship, operator roles, automation rules, Logic Apps, and ticketing route.
2. Validate delegated access
Test the lowest practical role set for viewing incidents, querying evidence, and executing each approved response action. Avoid using a broad global role as the operating default.
3. Review Sentinel workspace behavior
Microsoft documents that XDR data integrated with multiple Sentinel workspaces in one tenant is ingested into the primary workspace in the Defender portal. Confirm the primary workspace and move relevant automation rules where necessary.
4. Test automation differences
Microsoft identifies portal-specific limitations and timing behavior for automation rules and manually run playbooks. Re-run existing playbook tests from the Defender portal instead of assuming identical behavior.
5. Rehearse customer workflows
Use a benign test incident to validate triage, investigation, approval, response, ticketing, and closure. Record both the technical event and the customer-facing service evidence.
Where ContraForce fits
Microsoft provides the detection controls, unified portal, multitenant views, and native automation primitives. ContraForce provides a governed delivery layer that applies provider procedures across customer environments, executes supported investigation and response work, and synchronizes evidence into the service workflow.
ContraForce does not replace Defender XDR, Sentinel, governance relationships, or Microsoft licensing. It operates across those controls.
Questions for each customer tenant
- Which data and actions has the customer delegated?
- Which incidents can be handled without approval?
- Which response actions require customer consent?
- Which ticket board, priority, and SLA apply?
- Which Sentinel workspace owns automation?
- How is the investigation record retained for audit?
- Who reviews access when the customer relationship changes?
Primary Microsoft references
- Set up Microsoft Defender multitenant management
- Configure governance relationships
- Automation in Microsoft Sentinel
- Create and manage Microsoft Sentinel playbooks
Sources and review method
Product capabilities were reviewed against primary sources on 2026-08-12. ContraForce performance figures are product telemetry, not independent industry benchmarks.