Forum Discussion
How do you work around the client restrictions for opening encrypted documents?
We are wanting to roll out Purview sensitivity labels. Specifically, encrypted labels so we can implement controls such as preventing printing, copy/paste, etc. The issue we have ran into is that once an Office doc is encrypted, there appears to only be two ways to open the document:
- In a licensed Office desktop client
- Sharing a link to the document in SharePoint so it can be opened in a web browser.
We share documents with a large variety of 3rd parties that do not use Office. Many are small businesses who seem to prefer Google Workspace, so no Office clients. The SharePoint web browser option also does not work for us as we require users to have an Entra ID account to access our SharePoint, and it would not be feasible to onboard the number of external users we share documents with (nor to purchase O365 licenses for all of them). We considered using both encrypted and non-encrypted labels and using encrypted only when the recipient uses office. However there is no way for our internal users to know if the person they are sending a document to is using Office. So now we are left not really knowing what to do. I would love to hear some suggestions for how other organizations handled this.
3 Replies
Hi, the reply of Ajeeth_Muthu give you an overview of feasable clients. Purview Custom Encrypted documents represent the highest wall to prevent access to content. In most cases the number of custom enrcypted documents, in organisations i was in contact with, represent a low one-digit percentage over all.
We solve this isue with following cornerstones:- custom protection only really highly confidential documents
- external consumers without MSFT ID use Guest Accounts in our tenant
- Guest account governance management and MS Teams Lifecycle Management using EasyLife365
- Guest Accounts do not have a mailbox and do not require a Office License to use the webclient
- Access to documents from unmanaged devices, mean all devices not managed by your tenant, are restricted to webb-only access, no download.
- Collaboration possible for this highly protected content.
There are restrictions, yes - and with such rigid restrictions there are always exceptions. Exception handling in our case underlies a strict governace and audit trail. To keep labeling on documents active you could introduce a dedicated label for sensitive content without encryption and only allow specific users to use this label or a technical user alone to force all decryption through downlabeling with justification in an application logic (eg. Powerautomate) to manage your auditing. This way documents remain labeled and tracable though metadata.
Kind regards
That statement is essentially correct. Here’s the unavoidable reality:
Client/Tool Can open RMS encrypted docs? Office Desktop (modern) Yes Office for web (SharePoint/OneDrive) Yes Outlook desktop / web (via OME) Yes Google Workspace apps No Third-party PDF viewers No Most browsers without native support No Sensitivity label encryption is based on Microsoft Information Protection / IRM, which requires the application opening the file to be MIP-aware (“enlightened”). Only apps that understand IRM can decrypt the content and enforce restrictions like no print or no copy. Today, that realistically means Office desktop apps and Office on the web.
If the recipient uses non-Office tools (for example Google Workspace), they will not be able to open encrypted documents. There isn’t a workaround for this — it’s a fundamental design constraint of IRM-based encryption.
Because of that, most organizations end up at the same trade-off:
- Use encrypted labels for internal users or known partners with Office
- Use non-encrypted labels (with visual markings, DLP, and auditing) for broad external sharing
Trying to apply encryption universally for all external recipients usually isn’t practical unless you control the client environment.
You need an "enlightened" app to work with IRM-protected documents, there is no other way around it. So you're at the classical crossroad - decide between usability and security.
