Encrypted Office 365 Content is a Wake-Up Call for ISVs

New Challenges for ISVs

It’s much easier than ever before for users to encrypt Office 365 content. It is simple to protect email with the Encrypt-Only or Do Not Forward options in OWA and Outlook or by assigning a sensitivity label to SharePoint and OneDrive documents. The net result is that the percentage of encrypted content stored within Office 365 is only going to grow over time. Microsoft’s plan to introduce a transport rule to encrypt outbound email containing sensitive data is another example of where the puck is heading.

Much of the success of on-premises products like Exchange and SharePoint came from the development of a thriving ecosystem of third-party (ISV) products created to enhance and expand product functionality. As anyone who has visited a major Microsoft-centric technology exhibition recently can testify, those ISVs have transferred their attention to Office 365.

The new world of protected content creates new challenges for Office 365 ISVs because encryption has not been much of a factor in the past. I’ve pointed out in a previous article that cloud-based autosignature services can’t process protected email, but the problem is much wider and extends across the entire ISV community.

ISV Products for Email and Documents

Let’s look at three examples of how encrypted content might pose problems for products that interact with Office 365 data.

If you export email from an Exchange Online mailbox to a PST, any protected email copied to the PST is only accessible if the user can authenticate themselves with the rights management service using the account that received the messages. People often use these products to take copies of their mailbox when they move jobs. Of course, they have a new account at the new company, so they won’t be able to open protected email. This is a good thing for their current employers as it reduces the potential for trade secrets to leave along with employees.

On a more serious note, if you move mailboxes or documents from one Office 365 tenant to another, protected email moved from the source domain won’t be accessible in the target. The reason is the same – the user can’t authenticate themselves with an account that has permissions to see the content.

If you archive or backup information from Office 365 to a third-party platform (let’s say an Azure-based archive service), you might not be able to read protected content after it is retrieved for eDiscovery reasons. Office 365 content searches can deal with protected email because the messages are decrypted automatically when search results are exported, but they have the problem with protected documents, which must be decrypted using an account with super-user permission.

Essentially, once you move protected Office 365 content away from its original tenant, it’s likely that you will lose the ability to authenticate your access to that content.

Befuddled ISVs

I asked some ISVs how they deal with protected Office 365 content today. In most cases, the response was a mixture of befuddlement and ignorance because protected content is not on their radar, or encryption is confused with the question of how to protect data as it travels between Office 365 and another storage location (or between Office 365 tenants).

The best suggestion I received was that an Office 365 tenant should decrypt any protected content before it is moved outside Office 365. That’s reasonable and logical, but it’s also impractical because the success of the tactic depends on being able to find all protected content and then decrypt it. There’s no effective way to do this today for either email or documents.

More Protection for Office 365 Workloads in the Future

The challenge of how to handle protected data exists for email and documents today because Exchange Online, SharePoint Online, and OneDrive for Business support rights management. In the future, I would not be surprised if Teams and Planner support sensitivity labels to protect plans and channels.

What can ISVs do?

Microsoft will continue to make encryption easy for Office 365 tenants to use. Protecting sensitive business information is goodness, and it’s even better when the platform makes it easy for companies to create policies to enable users to apply protection naturally when working with email, documents, and other data.

The first thing ISVs must do is to understand the current limitations (if any) of their products when handling protected email and documents. For example, the autosignature ISVs know that they can inject autosignature text using client-side code but not after messages have been sent to Exchange for processing.

With the current limitations documented, the next step is to figure out if any workarounds are available. For instance, as I noted in the article about handling protected documents found by GDPR Data Subject Request searches, an account with super-user privilege for the rights management service can decrypt protected documents. A similar approach might be acceptable if a small percentage of protected documents need to be processed, but this is not a long-term answer if the volume of protected content climbs. It will take too long to decrypt tens of thousands of protected documents.

ISVs also need to engage with Microsoft to understand the long-term strategy for rights management within Office 365 and how this might affect ISV products. If they don’t know what’s coming, an ISV can’t plan how changes will influence their product strategy.

Maybe Not in 2019

It’s valid for ISVs to argue that they have time to figure out how best to deal with protected content. Relatively few Office 365 tenants generate protected content now. However, new technology like sensitivity labels and the Microsoft-Adobe initiative to protect PDF files with Azure Information Protection mean that protected content will become more common over time, especially in large enterprises where protection of intellectual property is usually more of a concern.

ISVs won’t come up with a solution themselves. They need to work with Microsoft to create a secure mechanism to process protected content that ensures the integrity of the content with the consent of the owning tenant. Creating such a mechanism won’t happen overnight, but the sooner this discussion happens, the earlier a solution will appear.

Technology Changes Can Cause Havoc

Office 365 changes all the time and ISVs must keep pace with new developments or get out of the market. Microsoft has done a lot in 2018 to make encryption more accessible than ever before. I’m sure tenants will respond by encrypting more content going forward. The question now is how will ISVs respond?