I had an opportunity to work with my colleague ‘Markus Pitkäranta’ in a very interesting case where we needed to pay extra attention to how highly sensitive material in Sharepoint Online (SPO) is accessed and how activities can be monitored.

Big hand also to ‘Saku‘ whose extensible knowledge of MIP was very helpful in this case.


The following requirements were identified for how these files can be accessed:

  • Access to the dedicated Sharepoint Online site (where sensitive material is located) should be restricted
  • Prevent data exfiltration to another O365 workload or 3rd party service
  • Users should not be able to save content to another SPO site/container

Architecture and Used Solutions

There isn’t one silver bullet to achieve the needed requirements, but rather a set of solutions. We had several sparring sessions with Markus and decided to move forward with the following architecture.

As you can see from the picture below there are multiple solutions included. We also needed to pay extra attention to testing to verify that the planned idea works as expected in the production also. The features you can find from the solutions are:

  • Microsoft Information Protection (MIP)
    • SharePoint site labeled
    • Sensitive content on SharePoint labeled
  • Azure AD – Conditional Access & Authentication context
    • 1 CA policy targeted SPO using authentication context, allowing access with the browser and forwarding requests to MDA session proxy
    • 1 CA policy targeted SPO using authentication context, blocking access when a native client is used
  • Microsoft Defender for Cloud Apps (MDA)
    • A custom policy that blocks download when the sensitive label is detected. The custom policy uses built-in MDA – MIP integration and content inspection
  • Microsoft 365 Defender & Microsoft Sentinel
    • MIP activity events are found in the Defender for Cloud Apps (MDA) activity log. The data is synced from MDA to M365D ‘CloudAppEvents’ table where it can be forwarder to Sentinel with M365 native data connector
  • Data Loss Prevention (DLP) policies
    • A DLP policy to detect sensitivity labels from SPO & ODfB from all other sites than the ones that contain sensitive material. The idea of using the DLP policy is to detect if sensitive material is saved to the another location


Authentication Context

Authentication context can be used with the Conditional Access policy to further secure data and actions in applications. In this scenario, we are using authentication context when a user is accessing to a SharePoint Online (SPO) site that is labeled and contains sensitive material.

Microsoft Information Protection (MIP)

To be able to use sensitivity labels at the container level (in SPO sites) the labels need to be defined in MIP. These labels will be used to classify the sensitive documents and the SharePoint Online (SPO) site where the documents are stored in.

To make sure that SPO demands the authentication context for labeled sites, the sensitivity label must be linked to the authentication context created earlier (picture below). These settings must be set to the “sensitive” label that we are using in this example.

SharePoint Online

On SharePoint Online, we need to label the site that contains sensitive material. Because the label has been associated with an authentication context (previous chapter). SPO will then demand the authentication context be used via the Azure AD Conditional Access policy.

If you haven’t enabled the capability to use labels in Teams, M365 Groups, or SPO you need to configure the feature based on this article. There are pre-requisites that need to be fulfilled that you are able to use labels on the M365 Groups & SPO sites. Besides that, on the label ‘Use Azure AD Conditional Access protect labeled SharePoint sites’ needs to be configured.

When configured properly you should see the configuration on the SPO site settings as below

Side note: It can take 24 hours before the published label is ready to use.

Side note: If you enable co-authoring for files with sensitivity labels, the labels are enabled automatically in Onedrive & SharePoint.

Conditional Access Policies

With the help of Azure AD Conditional policies, we can use authentication context and forward the session to Defender for Cloud Apps session proxy (CASB) for deeper monitoring and session controls.

Policy for Blocking Downloads

CA policy is configured with Azure AD authentication context and to forward session to Defender for Cloud Apps session proxy which uses a custom policy.

Policy for Blocking the Access

CA policy blocks access from native clients. The reason to block native clients is to prevent data exfiltration from the native clients.

Key takeaway: Preventing ‘native clients’ usage we are not able to prevent users from saving the documentation to the alternate location.

Defender for Cloud Apps (MDA)

A custom policy is used in MDA to prevent downloads when the user is accessing labeled sensitive material in SharePoint.

Template used: Block downloads based on content inspection

Session control type: Control file download (with inspection)

Files matching: Sensitivity label used on the content (files)

Inspection methods: None (we are using labels)

Actions: Block

Alerts: Select based on your needs

Data Loss Prevention (DLP) Policy

DLP policy is configured to detect content that is saved or moved outside the labeled SPO site. The idea is to search content from SPO & ODfB and exclude the site that contains sensitivity labels.  

Based on the requirements, a custom DLP policy needs to be created. DLP policies can be managed from Compliance Center ‘compliance.microsoft.com‘.  

End-User Experience

If you are familiar with the MDA session policies the user experience is similar to any session policy. When a user is accessing SPO that contains sensitive material and is labeled:

  • SPO forwards requests to AAD because the site is labeled and linked to Azure AD authentication context
  • Authentication context is part of the Conditional Access policy when is a requirement to use ‘Conditional Access App Control’ which in short means – forward session to MDA session proxy
    • The second CA policy prevents using of native clients when the authentication context is used
  • In MDA we have a custom policy that prevents downloading of the documents if the sensitivity label is detected from the files
  • Lastly, DLP policies detect if files are saved to alternate locations in M365 workloads


From the browser trace or in Fiddler, we can see the id (c4) of the authentication context in claims.

Also, from AAD sign-in events and from the MDA activity log we can trace the activities and verify Conditional Access policies used in the pipeline when needed.

Defender for Cloud Apps

MDA uses the same audit logging pipeline as the O365 Unified Audit log and receives MIP events from the pipeline. For that reason, the events are found from the ‘CloudAppEvents’ table in M365 Defender and also from Sentinel if you are using one and have integrations in place (Sentinel – M365D).

Thijs Lecomte has written a great blog post on how to monitor sensitivity label events in M365, take a look. Our case is a bit different and we would like to have information on how the specific labels are used. Below you can find a sample KQL to get started with the scenario.

| where ActionType contains "Sensitivity" or ActionType == "MipLabel"
| where Application contains "Microsoft SharePoint Online"
| where RawEventData.SensitivityLabelEventData contains "e93fad56-9b6f-43d6-82bb-bea9dda4579f or RawEventData.SensitivityLabelEventData contains "a41ed017-022b-445d-93aa-9718819111c7"
| sort by Timestamp desc

Data Loss Prevention (DLP)

The idea of using DLP policies is to detect a situation where a user saves a labeled document to another location in the M365 ecosystem. This works fine in M365 but if a user tries to save the documentation to 3rd party solution it’s much harder to detect. One alternate solution could be of using MDA-MDE integration and prevent 3rd party cloud storage applications.


During the research, we were struggling with several issues, and here are the most notable ones:

  • I’m nowhere close to a SharePoint expert but was quite surprised how long it takes to take sensitivity labels into use in SPO
    • Creating new label – 1 hour based on the documentation. In my POC environment, it took hours
    • Editing existing label – 24 hours. In the demo environment, it leads to a situation where you would like to throw the current label into the trash and create the new one
  • MDA didn’t detect new labels automatically. It means that there wasn’t a sync in place in the backend between MDA – MIP even though MIP integration was configured
    • The solution was found from MDA documentation (even if this is related to existing files scan operation)
      • Create a new File policy
      • Delete all the preset filters
      • Under the inspection method select built-in DLP.
      • In the Content inspection field, select Include files that match a preset expression and select any predefined value, and save the policy.
    • This enables content inspection, which automatically detects sensitivity labels from Microsoft Purview Information Protection.
    • service-to-service integration should do the trick but in my environment, I didn’t get labels visible until I create a file policy


Manage site access based on sensitivity label

Azure AD Authentication Context

MDA session policies

Manage DLP policies