Blog Post

Security, Compliance, and Identity Blog
6 MIN READ

The benefits of deploying built-in labeling within Microsoft 365 apps

Nir Hendler's avatar
Nir Hendler
Icon for Microsoft rankMicrosoft
May 11, 2021

During 2016, Microsoft introduced a new product that allowed organizations to implement a sensitivity label taxonomy and empower information workers to leverage these and apply them to documents or emails as part of daily work. This product is known as “Azure Information Protection (AIP)” and uses a client application for the Windows platform which deployed an add-in within Office apps including introducing a new “Sensitivity” button that can be used by information workers to flag documents and emails according to their sensitivity.

Since then, Microsoft’s information protection platform has evolved, implemented across all common platforms (MacOS, iOS, Android, Web) and the Azure Information Protection Client with rich capabilities across Microsoft 365 and is now under the wide umbrella of Microsoft Information Protection offering.

The main change as part of the transition to Microsoft Information Protection is that sensitivity labels are available across all common platforms and do not require an add-in or additional implementation, they are just part of the service offering. If you are using Microsoft 365 apps for Enterprise (formerly known as Office 365 Professional Plus) and you deployed sensitivity labels within your organization, no additional deployment stage is required. The same “Sensitivity” button is now exposed within the application ribbon. This integration is applicable consistently to all supported platforms. Moving forward, this integrated capability is to be known as “Built-in sensitivity labeling.”

 
 
 
 
 

Fig. 1: Built-in labeling within Microsoft 365 apps for Enterprise

 

Benefits to moving from client-based labeling to built-in labeling.

Using built-in labeling is seamless and does not require any management overhead in addition to cloud-based policy configuration. As part of your existing Microsoft 365 apps deployment, the bits are already available for every information worker without the need for installing additional components. The important aspects to consider are:

  1. No need to test, deploy and update another application or add-in within your endpoints. You leverage the deployment stage as part of ongoing or existing Microsoft 365 app project.
  2. Microsoft 365 apps will work with improved performance since no add-in needs to be loaded and all labeling functionality runs inside the application itself.
  3. Updates are being pushed as part of Microsoft 365 apps releases.
  4. Seamless experience across all Microsoft 365 platforms.

This is in line with other initiatives at Microsoft to provide built-in functionality that reduces or eliminates the need to deploy and maintain add-ins and plugins for other security and compliance-related functionality, which can potentially reduce an IT department’s challenges while providing a better user experience with more performance and stability to end users across workloads.

So, what is the Azure Information Protection Client, and should I continue to use it (or consider deploying it)?

Azure Information Protection Client (or Unified Labeling Client) is an application package for the Windows platform that include 4 components:

  1. Azure Information Protection add-in for Microsoft 365 apps
  2. Classify and protect (Ability to apply and consume labels outside Microsoft 365 apps) via a File Explorer extension
  3. Azure Information Protection viewer (to consume Non-Microsoft protected documents)
  4. Azure Information Protection PowerShell cmdlets to apply and consume labels.

Using built-in labeling replaces the first item in the list which is the Azure Information Protection add-in. Other components (described in number two, three, and four) can still be deployed without any dependency on the add-in portion of Azure Information Protection.

If you are using the Azure Information Protection add-in today and wish to use built-in sensitivity labeling instead to gain the benefits described above, then you can disable the add-in, uninstall the complete client, or control the behavior with a group policy. You have the choice to select the best approach which fits your business use cases and needs.

If you are NOT using the Azure Information Protection add-in today and looking to implement sensitivity labels across your organization, we recommend starting directly with built-in sensitivity labeling and deploy Azure Information Protection Client components (items described in number two, three, and four) if desired, but without enabling the AIP plugin for Office apps.

 

Fig. 2: Built-in labeling within Microsoft 365 apps highlight the sensitive information identifies within a Word document.

 

Where is built-in labeling available today?

Built-in labeling is already available and in use as part of your deployment of sensitivity labels in MacOS, iOS, Android, and web apps. If you deployed your sensitivity labels policies then these are already enabled and deployed (Web apps integration need to be enabled separately as documented). The main requirement here is to ensure that you are using the right Microsoft 365 apps for Windows that support this capability.

Built-in labeling in Microsoft 365 apps for Windows is available in all updated releases with versions newer than 1910+. (How to check your version of Microsoft 365 apps). If you are using an up to date version, no matter if you use Current Channel or Semi-Annual Channel, the capability is there and operational.

We do recommend ensuring your organization Microsoft 365 apps update channel is set to Current Channel or Monthly-Enterprise channel. These channels get the latest and greatest features in a shorter time frame. If your organization is using the Semi-Annual channel, then updates are deferred for a later period. Read more about Microsoft 365 Apps update channels here.

 

Deployment method

Once you have ensured you are using a version of Microsoft 365 apps that is released after 1910 in your organization, all you need to do is to implement your labeling taxonomy in the Microsoft 365 Compliance portal and publish your labels. You can use the official documentation to understand more on the backend configurations that need to be done.

If you do want to use Azure Information Protection client capabilities side by side with built-in labeling (referring to PowerShell module, Classify & Protect app and, AIP Viewer), you can download and deploy the Azure Information Protection unified labeling client (available to be downloaded from this link). Then configure a Group Policy to ensure that built-in labeling will always override and disable the Azure Information Protection add-in component. Read more about how to configure the group policy here. With this deployment approach you can enjoy both from the benefits of using built-in labeling and additional components.

 

Feature parity

Azure Information Protection Client and built-in labeling for Microsoft 365 apps do not have feature parity today. As we move forward, built-in labeling will add more capabilities which are currently available in the Azure Information Protection client. It is important to understand that the key features available, which include:

Feature marked as are exclusive to built-in labeling with Microsoft 365 apps.

Read more about the feature comparison between Azure Information Protection Client and built-in labeling for Microsoft 365 apps here.

In addition, see complete roadmap and timelines for additional features within built-in labeling for Microsoft 365 apps here.

Latest update on feature availability within built-in labeling is available at: Manage sensitivity labels in Office apps - Microsoft 365 Compliance | Microsoft Docs

 

Additional considerations

In perpetual versions of Microsoft 365 apps (Office 2013, 2016, 2019) built-in labeling is not included, so if you are using one of these versions you will need to use the Azure Information Protection client and add-in for Office instead.

Do note that using built-in labeling does require sensitivity labels to be configured and published in the M365 Compliance portal (or Office 365 Security and Compliance portal). If your sensitivity labels are deployed as part of the Classic platform in Azure, please ensure you are migrating to unified sensitivity labels as documented here.

 

Additional resources:

 

 

 

Updated Jan 12, 2022
Version 4.0
  • MagicHair's avatar
    MagicHair
    Brass Contributor

    You say this is only available for Microsoft 365 apps for Enterprise however please review the matrix here: https://aka.ms/MIPLicenseXLSX
    Can you please clarify your statement with regards to the Business plans as the info seems contradictory.

  • StephanK's avatar
    StephanK
    Brass Contributor

    Yes good question MagicHair , was wondering the same thing! I have a lot of customers with the M365 Business Premium License.

  • Hey markwarnes. Built in labeling is not designed to replaced features outside Office client. as stated in this article, for these use cases, deploy AIP Client side by side to built-in labeling and just disable the add-in.

    In the future we are working on capabilities to inherit the label from a document to saved/exported PDF.

  • Are there any plans for including the reset settings & export logs option for the built-in client? These 2 features available for the unified labeling are very helpful in the troubleshooting process.

  • markwarnes's avatar
    markwarnes
    Brass Contributor

    One of the biggest obstacles to choosing the built-in functionality over the UL client is applying sensitivity labels to PDF files. At the moment, the UL client can do this in the File Explorer but the built-in functionality cannot do this so for organisations needing to easily label PDF files (created from an Office app such as Word), the UL client is the best option.

     

    This obstacle could be easily overcome if the Office apps could export to PDF and automatically retain the label that has been applied to the original document (e.g. a labelled Word doc exported to a labelled PDF). That would resolve so many challenges and make it far easier to recommend a built-in first approach.