Office Apps to Get Native Support for Office 365 Sensitivity Labels

Office 365 Hero

Removing the Need for the Azure Information Protection Client

Microsoft released sensitivity labels for Office 365 in November 2018. Sensitivity labels allow users to apply “stickers” to documents and messages to mark the relative importance of their content. For the most sensitive content, the application of a sensitivity label can invoke encryption through an Azure rights management template. At present, you must deploy the preview version of the Azure Information Protection (AIP) client to expose the ability to apply sensitivity labels to Office documents. In addition, the AIP client takes care of fetching the label and policy information from the Security and Compliance Center and applying rights management templates to files if necessary.

Microsoft is working to remove the need to install the AIP client by incorporating native support for sensitivity labels in the Office desktop, mobile, and online apps. When this happens, the apps will include the necessary code to download the sensitivity labels and policies and process the templates. It’s also expected that other Office 365 user interfaces, such as SharePoint’s browser interface to document libraries, will allow users to assign sensitivity labels.

Office ProPlus Support in 2H 2019

According to a post shared with customers in a group (open to all) in Microsoft’s Yammer network, the Azure Information Protection team expect the Office ProPlus (click to run) Windows applications to offer native support for sensitivity labels in the second half of 2019. The exact time when a tenant will see this functionality depends on what Office update channel they use. Only the Office ProPlus applications support sensitivity labels – you won’t see this in the MSI release.

Removing the need to deploy, support, and manage the AIP client means that native-based labeling is the easiest way to introduce labeling inside an Office 365 tenant. When the need for the AIP client is removed, users with Office 365 E3 and E5 licenses won’t need AIP licenses because their use of sensitivity labels is covered by their Office 365 licenses.

AIP Client is More Functional

However, because the AIP client exposes extra functionality that won’t be included in the Office apps, customers might want to continue using the AIP client. These features include the ability to apply labels to content stored outside Office 365, user-defined permissions, track and revoke protected documents, and support for encryption using HYOK (Have Your Own Key) instead of a Microsoft managed key.

To keep using the functionality available in the AIP client, users must set the DWORD UseOfficeForLabelling value set to 0 in their system registry at the key HKEY_CURRENTUSER\Software\Microsoft\Office\16.0\Common\Security\Labels.

The presence of the key tells the Office applications to use the AIP client instead of their inbuilt support for sensitivity labels. The AIP client sees the same set of labels and can apply them to information stored inside and outside Office 365. Those who choose to use the AIP client continue to need AIP P1 or P2 licenses, even if they only use the client to apply labels to Office 365 content.

Time to Update System Registries

Microsoft suggests that customers who intend using the AIP client should proactively roll out the registry change using GPOs or another mechanism. This will make sure that users don’t see a change in behavior following the update to the version of Office ProPlus that includes native labeling.

Office 365 Tenants Need to Prepare for Encryption

The news that native support for sensitivity labels is coming in the Office apps is good, albeit a tad delayed compared to the expectations set by Microsoft at Ignite 2018. But having sensitivity labels available in apps is only one part of the journey to deploy encrypted content within Office 365. If you want to take advantage of this technology, then you need to make sure that all parts of the ecosystem are prepared – apps, users, and third-party software (see my piece on how encryption affects ISVs who produce email autosignature products for Exchange Online). Encrypting content is no good if it makes it impossible for people to work with that content afterwards – unless that’s what you intend.