MS Purview Encrypted emails will not open in outlook with OWA login disabled

Hello Brad Benaway,

Hello Brad Benaway,

Good day!  

After thorough research and consulting, it’s been concluded that If OWA is disabled, the only way to open MS Purview encrypted emails is by using a supported email client that has the necessary encryption capabilities.

Microsoft Outlook is one such client that supports MS Purview encryption. However, if the email is encrypted with MS Purview, it can only be decrypted using the same technology. Therefore, if the recipient does not have access to MS Purview, they will not be able to open the encrypted email.

Reference: Send, view, and reply to encrypted messages in Outlook for PC - Microsoft Support

We apologize if we are not able to meet your requirements; however, thank you for bringing this to our attention, we will surely raise you concerns to our Product Team and hopefully this can be included in the future updates.

In the meantime, the issue with the 400 bad request error, sounds like your Admin turned off the owa web email app. in 365 EAC under active users, click the user and under the mail tab click "email apps."

that error sounds too familiar and i think that may it. see if "outlook on the web" is unchecked.

If it is not the case, you can try clearing the browser cache and cookies or try accessing OWA from a different browser or device and check.

Please feel free to let us know if there are any questions or if we got you wrong. We will continue to assist you based on the information you provide. We sincerely appreciate your patience and cooperation. 

Hi Eben-Ezer,

Thanks for all the information on this. This particular client does have OWA disabled as a security precaution. The client has a mix of Outlook 2016 through Outlook 2021.

When we try to open this in Outlook the link always prompts for the OWA login. With OWA disabled they are unable to open the link.

When you state this "Microsoft Outlook is one such client that supports MS Purview encryption. However, if the email is encrypted with MS Purview, it can only be decrypted using the same technology. Therefore, if the recipient does not have access to MS Purview, they will not be able to open the encrypted email." Does this mean I need to set a up Purview for this client? I am not sure what you meant about the client having access to MS Purview.

I looked at the link referenced here and I am going to send the one-time passcode as an option. Looks like this is something the sender has to allow on in their EAC setup from my research.

Thanks for all your help on this

I can confirm that Purview Encryption requires OWA in order to process the Encryption/Decryption process within the Old Outlook client, and the New Outlook client.

Meaning - Purview Encryption requires OWA to be enabled, regardless of the client having a Purview license or not.

This is not how its supposed to work. According to all documentation, the full Outlook Client (both old and new) "natively" performs these encryption/decryption operations in-line with the standard Email experience. But they do not. If OWA is disabled, the client receives a email, redirecting them to OWA, yet OWA is inactive. There is no way for the user to decrypt these messages.

Certainly this is an issue that requires a solution. Otherwise, Purview Encryption is useless since we cannot determine if a customer or vendor has OWA enabled or not.

Adding to this.

Is there a fix in the works from Microsoft on this?

We would rather not have encryption require OWA and we prefer to keep OWA disabled for our organization but have to enable it just to receive encrypted emails from clients that use MS encryption.

No - the New Outlook will require OWA anyway (they will be the same). So, I imagine the "Enable Outlook" and "Enable OWA" options per user actually merge within the next year.

What is it you are attempting to mitigate by turning off OWA? There is no logical attack vector or data-risk that eliminating OWA will someone blanket-protect you from something. Unclear why so many clients turn it off in the first place.

To restrict access to outlook outside of the terminal server.

But the Terminal Server is centralized. That means all users access the Internet (and in this case, OWA) via a single IP (or group of IPs).

As such, Azure AD P2 readily mitigates your scenario by locking down Auth access to all O365/Azure assets via geo-location/IP.

Thus my point - locking down OWA is no longer needed, nor the best process for "locking down" access. Data should be locked down with Purview, and Access should be locked down with Azure AD P2. Everything else is immaterial.

I'm not sure why you are pretending that OWA is safe. EVERY. SINGLE. TIME. we find a compromised account, it is because the malicious actor has taken control of OWA.

Browsers don't even always sign out of it. You can close one account, sign in with a second account, and still end up inside the inbox of the first account.

Users often do not concern themselves with security. If the organization is concerned enough to turn OWA off, why force them to undermine that?

It would be laughable that security has to be lowered to read "safe" encrypted emails... if this wasn't the easily the hundredth time in the last 8 years or so I opened a search engine hoping that this was finally over... and there was FINALLY a setting that would allow the mail client to decrypt the message. But no, once again, I'll go tell the user that they have to sign in.... So they can pull that post-it note (or whatever other trash method they have of "remembering" their password), off the bottom of their keyboard. Then clean the redirects to the RSS feed out of their compromised OWA account later. Rinse/Repeat.

Employees come and go but the org remains... and STILL doesn't want to use OWA.

My point is that it has nothing to do with OWA. You neglect that and still focus on it.

Email can be compromised and credentials exposed - either via OWA, a standard Web Page, or even the Outlook thick-client. You make it seem as if the only vector is OWA. It is far from the truth.

So, do explain or cite articles whereby AD P2 plus Purview Encryption has been "compromised". I love to learn. Don't just sensationalize the past - because I am specifically talking about "now".