From Partners for Partners: Simplifying Customer Onboarding with Microsoft Defender

Overview: Microsoft Defender onboarding for MSSPs (Partners for Partners episode)

The video discusses how Microsoft Defender streamlines managed security services provider (MSSP) onboarding by focusing on:

• Delegation of access to customer environments
• Simplifying onboarding workflows
• Enabling scalable distribution of security content across many tenants

---

Key onboarding challenges for MSSPs (BlueVoyant: Jaime Guimera)

The main goals are:

• Transparency
• Simplicity
• Seamless onboarding

MSSPs often must access multiple customer environment resources using different access mechanisms, which makes onboarding:

• Complex and difficult to follow
• Slow (many steps and involved roles)
• Documentation-heavy (repeated risk/step explanations per customer)

Two major technical phases in onboarding

1. Access Obtain delegation/access to the customer environment (including access to multiple things with different access controls).

2. Configuration/content push After access is established, push rules, workbooks, and threat hunting content into the customer environment.

---

Microsoft enhanced GDAP for non-CSP partners (Defender engineering: Saggie Haim)

The video explains how Microsoft moved beyond older models:

Historically

• B2B access required heavy customer configuration and involvement, making it difficult to manage at scale.
• GDAP was limited to CSPs only.

Enhancement introduced

• Enhanced GDAP is now a native Defender capability that enables all customers and partners, including non-CSPs, to leverage GDAP.
• This removes the dependency on the Microsoft Partner portal for partner-customer access relationship setup.

---

“Three-way handshake” workflow (how the delegation relationship is established)

To validate partner↔customer relationships without the Partner portal, Microsoft introduced a three-way handshake:

1. Customer invites the partner to manage their environment.
2. Partner selects who gets access and what access type (defining an access template).
3. Customer approves/declines the access template via a single-click approval.

Timing improvement example (Jaime)

Previously, GDAP setup could be tedious due to email routing complexities (mailboxes/filters/permissions). Now:

• The partner provides the customer their tenant ID for the managing tenant.
• The customer uses the Defender portal to send an invitation.
• The partner responds with a prebuilt template.
• The customer approves in the portal.

Note: Email notifications still exist, but the critical actions are 100% in the Defender portal.

---

Unifying access for Sentinel + Defender (MSSP benefit)

A core MSSP benefit highlighted by BlueVoyant is one single flow that establishes access for:

• Microsoft Sentinel content and management
• Defender content/configurations

Previously, this required two different portals and more people/roles. The new flow can complete relationship setup in 10 minutes or less.

---

Demo: Microsoft Defender “MTO” delegated access + templates

In the Defender portal (called MTO in the demo), Jaime demonstrates:

• Delegated access relationships across multiple customer tenants
• A governing tenant concept (the partner tenant managing multiple customer tenants)

Templates define

• Roles (using Entra ID roles)
• Groups to assign those roles to
• Access packages per customer type, region, or service

Multiple assignments per template

Templates support multiple assignment patterns (e.g., SOC analyst vs security admin style access).

Role guidance from the discussion

• The portal uses out-of-the-box roles to support least-privilege selection.
• Custom roles are not currently supported in the enhanced GDAP flow.
  • If custom roles are introduced, additional transparency would be needed to understand atomic permissions.

---

Entra roles to avoid high privilege (security workflow permissions)

Saggie explains that older workflows required high privileges (e.g., global admin / security admin).

Microsoft introduced four new Entra roles that allow managing the workflow from both MSSP and customer sides without requiring full global admin or security admin.

---

How Sentinel access is granted using remote tenant groups (Jaime)

Within the unified setup, Sentinel access is granted by:

• Adding role assignments in the Azure Sentinel resource group
• Selecting an appropriate Sentinel role (e.g., Sentinel contributor)
• Assigning access using remote tenant groups
  • Groups live in the partner tenant, bound via the GDAP relationship
• Choosing the relevant group (e.g., a SOC engineering team) to control which partner users can access Sentinel in the managed customer environment

---

Content distribution at scale (policies/rules/workbooks + Defender items)

After onboarding, the MSSP can distribute managed content by organizing customers into tenant groups, such as:

• Region
• Service tier
• Access level (e.g., read-only)
• Types like “threat hunting” vs “MDR”

Content distribution selection

In Content distribution, the partner selects:

• Target tenant groups
• Artifacts to distribute (from a source tenant)
• Push those artifacts into the selected customers

Supported artifact categories called out

Sentinel-related (unified XDR portal)

• Analytic rules
• Automation rules
• Workbooks
• Saved searches

Defender-related

• Alert tuning
• Custom detection rules
• Endpoint security policies

The example also shows that partners can distribute only Sentinel-focused artifacts by excluding Defender/endpoint items.

---

Relationship to Azure Lighthouse (and why it still matters)

• Jaime: Azure Lighthouse was the main distribution mechanism for Sentinel.
• With Microsoft Sentinel moving into Defender:
  • Azure Lighthouse isn’t supporting Defender
  • the industry needs Defender-native mechanisms (MTO + GDAP)

Exceptions where Azure Lighthouse is still required (Saggie)

• Workspace Operator scenarios
• Access to Azure resources outside Sentinel, such as:
  • function apps / connectors
  • DCR/DCE-related resources

Microsoft states parity and removal of Azure Lighthouse needs are in progress, but not complete yet.

---

Tenant scalability / limits clarification

A limit is mentioned related to being able to view or take actions across large numbers of tenants at once.

• MTO can support onboarding “as many tenants as you need” (stated as 500–1,000).
• The limitation is specifically about actions/views across more than 100 tenants at once.

Mitigation

• Use tenant groups to operate within manageable scopes.
• Switch context quickly.

UI demo: switching tenant groups immediately changes incidents/content views based on the selected group context.

---

Main speakers / sources

• Heike Ritter — Host, “The Virtual Ninja Show”
• Jaime Guimera — Security and AI Architect, BlueVoyant (MSSP customer/onboarding + demo)
• Saggie Haim — Product Manager, Defender engineering (MTO/GDAP/partner workflow explanation)