If you have been using Office 365 for encrypting emails, you are likely using the previous version of Office Message Encryption (OME). It has been working perfectly for me for the last year or so. However, the new version of OME is built on the Azure Information Protection and Rights Management platform. This means you are able to get a much better encryption experience and have more control of the content as it leaves your organization. The biggest concern I’ve heard about encrypting emails is that once the recipient has the message and associated attachment, it’s out of your control. And it’s probably not encrypted once they place the file on their corporate file server. The new version of OME changes that to some extent, but presents some challenges as well.
As before, encrypted emails allow for One-Time Passcodes so the recipient doesn’t have to set up a Microsoft Account in order to view the email. This is great for recipients that may receive an email occasionally; however, there is a provision to set up a Microsoft account to streamline the process.
A nice feature of the new encryption methodology is that if the recipient opens the message using OWA or the mobile Outlook app, it auto-authenticates and the message is automatically opened. However, if the recipient opens the email within Outlook, it will open a browser and they will be asked to authenticate or use the One-Time Passcode. It would be expected that if the recipient receives the email inside of an Office 365 mailbox (O365 to O365), it would be seamless, but this is not the case – the recipient will be asked to log in (if they aren’t already logged in) and no One-Time-Passcode is allowed. Microsoft has this on their roadmap to fix.
My favorite addition to OME is the handling of attachments. However as you will see, it would be beneficial for the recipient to understand some of the nuances of encrypted attachments. When an attachment is included in the message, the attachment will be encrypted with a special tag called Encrypt. The cool thing about this is that the encryption will remain with the attachment unless the organization changes this behavior in one of two ways.
First, they can use a PowerShell command. The PowerShell command to decrypt the attachment and remove information protection is as follows:
Set-IRMConfiguration -DecryptAttachmentFromPortal $true.
Second, the recipient could go directly into the properties of the document and remove the encryption, which the recipient is allowed to do with this document tag. The challenge on the recipient’s side is twofold. They will need to know how to remove the encryption if they want do to that and they can also only open the attachment if they are logged into Word or Excel with Microsoft credentials that identify with the same email address where the message was received. If they aren’t logged in or don’t have a Microsoft account, it will ask them to create a Microsoft account in order to proceed.
As mentioned earlier, the system utilizes Azure Information Protection (AIP) for encryption and if your organization is using AIP, you are likely already familiar with some of these features and challenges. Microsoft continues to mature the AIP product and is working to integrate these features throughout Office 365. Additional features and capabilities have been added over the last couple of months, such as the Encrypt tagging, so stay tuned as things continue to develop and we will continue to share updates through our blogs.