Daily Defender News
Aboutmerill.net
Microsoft Sentinel
Cloud and workloads

Protect Managed Security Service Provider (MSSPs) Intellectual Property in Microsoft Sentinel

4 September 2026Doc update+16 / −21 lines

In brief

The article title, link wording, image alt text, and phrasing and formatting across its Azure Lighthouse, workspace, alert, and Power BI guidance were updated.

What Defender admins need to know

No administrator action is required; the revised article provides clearer guidance for existing practices.

Summaries are generated from the documentation change itself.

Documentation change

View full page diffView on Microsoft Learn

The comparison below shows only the changed extract. Use the full-page view for complete context.

ProtectingProtect MSSP intellectual property in Microsoft Sentinel

This article describes the methods that managed security service providers (MSSPs) can use to protect intellectual property they've developed in Microsoft Sentinel, such as Microsoft Sentinel analytics rules, hunting queries, playbooks, and workbooks.

If you're reselling Azure as a Cloud Solutions Provider (CSP), you're managing the customer's Azure subscription. Thanks to Admin-On-Behalf-Of (AOBO), which lets partner admin agents manage a customer's subscription, users in the Admin Agents group (the Partner Center role whose members administer customer subscriptions) from your MSSP tenant are granted Owner access to the customer's Azure subscription, and the customer has no access by default.

If other users from the MSSP tenant, outside of the Admin Agents group, need to access the customer environment, we recommend that you use Azure Lighthouse. Azure Lighthouse enablesallows you to grant users or groups with access to a specific scope, such as a resource group or subscription, using one of the built-in roles.

If you need to provide customer users with access to the Azure environment, we recommend that you grant them access at resource group level,level rather than the entire subscription, so that you can show / show/hide parts of the environment as needed.

For example:

Even with granting access at the resource group level, customers have access to log data for the resources they can access, such as logs from a VM, even without access to Microsoft Sentinel. For more information, see Manage access to Microsoft Sentinel data by resource.

Sample Microsoft Sentinel CSP architecture

The following image describes how the CSP permissions described in the Cloud Solutions Providers (CSP) section might work when providing access to CSP customers:

:::image type="content" source="media/mssp-protect-intellectual-property/csp-customers.png" alt-text="ProtectDiagram showing how to protect your Microsoft Sentinel intellectual property with CSP customers.":::

In this image:

When adding a workspace statement to your analytics rules, consider the following:

  • Use the customer's explicit workspace identifier: Use the customer workplace identifier in the cross workspace query for best performance. For more information, see Identifier formats for cross workspace queries.

  • No alerts in the customer workspace.: Rules created in this manner,manner don't create alerts or incidents in the customer workspace. Both alerts and incidents exist in your MSSP workspace only.

  • Create separate alerts for each customer.: When you create cross-workspace analytics rules, we also recommend that you use separate alert rules for each customer and detection, because the workspace statement is different in each case.

    You can add the customer name to the alert rule name to easily identify the customer where the alert is triggered. Separate alerts may result in a large number of rules, which you might want to manage using scripting, or Microsoft Sentinel as Code.

    :::image type="content" source="media/mssp-protect-intellectual-property/mssp-rules-per-customer.png" alt-text="Create separate rules in your MSSP workspace for each customer.":::

  • Create separate MSSP workspaces for each customer.: Creating separate rules for each customer and detection may cause you to reach the maximum number of analytics rules for your workspace (512). If you have many customers and expect to reach this limit, you may want to create a separate MSSP workspace for each customer.

    For example:

The key to using cross-workspace analytics rules successfully is using automation to manage a large set of rules across your workspaces.

For more information, see Cross-workspace analytics rules

Workbooks

Exporting your workbook to Power BI:

  • Makes the workbook visualizations easier to share.: You can send the customer a link to the Power BI dashboard, where they can view the reported data, without requiring Azure access permissions.
  • Enables scheduling.: Configure Power BI to send emails periodically that contain a snapshot of the dashboard for that time.

For more information, see Import Azure Monitor log data into Power BI.

Playbooks

You can protect your playbooks as follows, depending on where the analytic rules that trigger the playbook have been created:

  • Analytics rules created in the MSSP workspace.: Make sure to create your playbooks in the MSSP tenant, and that you get all incident and alert data from the MSSP workspace. You can attach the playbooks whenever you create a new rule in your workspace.

    For example:

    :::image type="content" source="media/mssp-protect-intellectual-property/rules-in-mssp-workspace.png" alt-text="Rules created in the MSSP workspace.":::

  • Analytics rules created in the customer workspace.: Use Azure Lighthouse to attach analytics rules from the customer's workspace to a playbook hosted in your MSSP workspace. In this case, the playbook gets the alert and incident data, and any other customer information, from the customer workspace.

    For example:

Next stepsRelated content

For more information, see: