Information Rights Management (IRM) is one of those lovely buzz words we hear at conferences. The idea is simple: “encrypt and apply permissions to a file and follow that file no matter where it goes.” The idea is great especially with Office 365 where most of your content lives. We are going to talk about what IRM is in Office 365, the features, potential workarounds, and the bad stuff that comes with it.

Without question, IRM epitomizes the phrase buyer beware. Most engineers and architects in Office 365 have learned by now that we have a few major issues in O365: (1) replication takes forever and (2) it is remarkably hard to unring the bell.

O365 Information Rights Management Features

Let’s start with the nice stuff that IRM offers. We’ll slice this up into two areas: Outlook (Exchange Online) and SharePoint. Both offer interesting features/options.

IRM Features in Outlook

Outlook supports IRM in a few different ways:

• Creating Mail Flow rules that will automatically encrypt/protect emails sent to specific people, groups, and various criteria like below:

• IRM support for ActiveSync clients (keep in mind that only certain email clients e.g. Boxer and Outlook can support IRM)
• Sensitivity labels and policies that let you block forwarding, printing, or copying messages.
• DLP policies that can display tool tips when you are sending information in email that you shouldn’t be:

• Office Message Encryption (OME) lets you share encrypted email with anyone on any device. With their advances, you can even make it much more user friendly:

We won’t focus on how you configure these items, but moreso about the nice features they have available. Setting them up are not for the feint of heart as it can be problematic when you try to turn it off. Let’s talk about the SharePoint features.

IRM Features in SharePoint Online

SharePoint also supports IRM in some interesting ways. It can do the following:

• Block uploading files that do not support IRM
• Prevent opening docs in the browser
• Restrict printing
• Block scripts or screen readers
• Restrict writing on downloaded files e.g. markup
• Expire access rights after X days on downloaded files
• Restrict sharing to specific groups
• Enforce how often users must re-authenticate with downloaded documents

IRM Gaps with SharePoint Online

When it comes to lessons learned, most of them are in SharePoint, which is where I focus. Let’s cover some of the gaps and any potential workarounds.

Opening PDFs in IRM-enabled SharePoint Online Sites

When you try to open these PDFs in the browser, this is what happens:

Yeah, I know it sucks. You will find the “supported pdf readers” here. Primarily the best thing to do is using Microsoft Edge to open these documents by clicking “Open in browser” if you are using Edge. Additionally, you can use the MIP plug-in for Adobe, which adds Azure IRM support to Adobe.

I tend to stay away from the Azure Information Protection viewer since its basically “foreign” to your users. You will find a number of products support it nicely though.

Uploading Digitally-Signed PDFs to IRM-Protected Sites

A big issue that you will run into if you work in Life Sciences or are securing an AP site is around digitally-signed documents. Many people are unaware that when you digitally-sign a PDF e.g. someone sends you something to sign via Adobe Sign that it encrypts the PDF. You can do some light reading on that here.

Basically, Adobe or whoever locks and certifies the final signed PDF and its assets using AES-256 bit encryption. Adobe’s encryption secures the identity of each digital signature as part of their design. This works similarly with most products.

This becomes an issue with IRM-protected sites as you cannot double-encrypt files. When you try to upload one of these signed PDFs, it bombs out showing you that it cannot be uploaded:

The only real workaround you have in these scenarios is keeping these files in separate sites or other applications e.g. your CRM. I’ve built out some custom Salesforce objects to account for this personally.

Using Office Web Apps with IRM-Protected Sites

Yes, it gets no better when we want to edit files. After clicking on a file to use in the web, you will get these lovely banners.

Your workaround there is using the local desktop application. So you ask does that fix things now? Nope it doesn’t really…

Using the Office 365 desktop client with IRM-protected documents

The first thing that you will notice off the bat is you can no longer use autosave.

Now here’s the REALLY big problem. As you will see below, when using IRM you lose all ability to co-author. Basically, once someone opens that document in the Office client it becomes locked.

There is no real workaround for this. The reality is that you need to be mindful when and where to use IRM. I will discuss that more toward the end, but this is a major problem period.

IRM concerns in Outlook around the user experience

IRM with Outlook is not as troublesome as SharePoint Online. When used elegantly, it can be very useful. The goal is to create mindful sensitivity labels and rules that make sense. Let’s discuss a few lessons learned that will help it be successful.

Testing IRM with Outlook

The top area where people make mistakes is properly testing IRM. A good rule of thumb is:

• Test encryption labels by assigning them only to yourself until you are 200% sure they’re good.

• If you’re going to mark content, make sure you scope it carefully. Only watermark stuff that is actually sensitive.
• Be careful of “buzz words” that set people off like private, top secret, etc. as it can be a poor user experience.
• Label Policies are remarkably hard to pull back. Make sure you limit their scope as much as possible.

Encrypting Content with Outlook

As we discussed earlier, you want to 100% make sure you go through the process of enabling the new Office Message Encryption. A really solid article on it can be found here. It’s a great way of encrypting external email and providing a gorgeous overlay for users to easily access your content.

Encryption overall is about finesse. I suggest taking the time to carefully craft rules and enable the “Protect” feature in OWA/Outlook as mentioned in the above article by enabling Simplified Client Access.

Other Tips around Outlook and IRM

A few other things that I wanted to mention before wrapping up. Do NOT auto-tag everything as it will wreck havoc on your environment. You can easily do this by accident when creating your sensitivity label policies. IRM is an art form. We must be careful and mindful throughout enabling IRM or you will be screwed before you get started.

The last thing that I love to mention are tool tips. I mentioned it earlier, but honestly you cannot have enough tool tips “within reason.” You should use them where they fit. They’re a nice way to remind your users about the right things to do.

We must as technologists enable people as best we can without being invasive. Providing these simple reminders and auditing vs. blocking will make a major difference and accomplish the same thing for the most part.

Closing the Loop on Microsoft’s Information Rights Management Solution

To a degree, this might seem like I am critical of Microsoft IRM. I am to a degree, but I think their product is about nuance. You can be extremely productive with IRM if done carefully. People who rush haphazardly through configuring products will inevitably be overwhelmed and destroyed by IRM.

In my experience with IRM, I learned that you need to evaluate everything and implement it where it can help. Once you annihilate productivity in the fact of making things “safe” you have destroyed your credibility and achieved the exact opposite of what you set out to do. I hope that eventually we will have co-authoring within IRM, but otherwise it makes sense when placed strategically throughout your environment. When you couple it with Defender, which I wrote about recently you deliver a strong defensive against the attack surface. Oh and one last reminder: “Don’t implement IRM like this:”