<img src="https://ad.doubleclick.net/ddm/activity/src=11631230;type=pagevw0;cat=pw_allpg;dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;npa=;gdpr=${GDPR};gdpr_consent=${GDPR_CONSENT_755};ord=1;num=1?" width="1" height="1" alt=""> Protect Confidential Emails with Email Encryption for Microsoft Office 365

Protect Confidential Emails with Email Encryption for Microsoft Office 365

TABLE OF CONTENTS

    See Virtru In Action

    { content.featured_image.alt }}

    Microsoft’s cloud collaboration suite, Microsoft 365 (formerly Office 365), provides excellent default email and file security, but many customers require additional layers of encryption and data protection capabilities to meet regulatory, compliance, or privacy needs.

    Email remains the most common method of business communication: It’s where companies create, house, and share their most valuable information. So when unauthorized third parties go searching for corporate data, they know exactly where to look. 

    Regardless of your industry or the nature of your work, you may want to consider additional layers of security for Microsoft Office 365, especially for sensitive information in motion and at rest. 

    The Challenges of Email Encryption

    Few would argue that having an email encryption solution is a good idea. But choosing the right encryption solution can be challenging: Technology leaders using Office 365 have several options for encryption, and depending on their compliance needs, the best solution may look different. 

    Organizations also face several challenges when it comes to email encryption: 

    • Historically, there hasn't been a single, standardized tool for end-to-end email encryption solution across all email clients and use cases.
    • Traditional email encryption can be difficult: It works relatively well in a business-to-business communications scenario, but it fails to evolve to meet more dynamic collaboration patterns, where sensitive data needs to move into and out of an organization easily.
    • Business managers may not understand the need for email encryption, or they may assume that it will be too cumbersome for their teams and clients to navigate.
    • IT organizations may end up adopting a patchwork of solutions that don't work well together and are expensive to replace.

    As such, Gartner suggests that successful email encryption solutions should adhere to the following principles:

    1. Enterprise users prefer to receive and manage their email from multiple senders via one email client, and have a strong dislike for web-based portals to access secure content.
    2. Consumers typically leverage multiple web mail clients to receive their personal email and typically [recipients] will not welcome the installation of third-party software on their systems to access secured content, especially when dealing with multiple secure senders.
    3. Secure email solutions must seamlessly support mobile devices such as tablets and smartphones’ “anytime, anywhere” access paradigm.

    With these privacy and security concerns in mind, it’s essential that Microsoft organizations understand the encryption options available to them, how these solutions work, and when it makes sense to deploy them.

    What Makes a Successful Email Encryption Solution? 

    When you're evaluating your encryption options for Office 365, it's helpful to have some key capabilities in mind.

    • Ease of use: A security solution is only effective if people will actually use it. You'll want to select an encryption solution that's likely to be adopted and used — and that means it needs to be as frictionless as possible, both for the user and the recipient of shared information. 
    • Support for multiple email clients: The nature of modern collaboration assumes that users will inevitably be using different devices, apps, and platforms to get their jobs done. Microsoft users will need to collaborate with Google users, and a good email encryption solution should support seamless interoperability between multiple platforms. 
    • No software installs required: If you're sharing encrypted data externally, you want to make sure that the recipient can easily access the information they need. A strong encryption solution will have a seamless user experience with encryption and will not require the recipient to jump through hoops (like installing software or creating new accounts) to access information. 
    • Support for mobile devices: Our phones and tablets have become our de facto work devices, but using encryption on smartphones and tablets has historically been difficult. It's important that an encryption solution can support mobile collaboration and secure data sharing. 

    Understanding Microsoft 365 Encryption Options 

    To meet advanced data protection and encryption requirements, most Office 365 customers rely on one of the following:

    1. Microsoft’s native email security features
    2. Portal-based email encryption from legacy vendors
    3. Object-level protection and access control from Virtru

    We'll break down some of the highlights of what to consider with each of these options. 

    Native Microsoft 365 Encrypted Email

    Default Outlook desktop and Outlook Web App (OWA) encryption has native support for email protection, but it has its limits. These Office 365 email clients encrypt messages both when they’re stored (data at rest) and when they’re being sent (data in motion). Like most cloud email providers, Microsoft uses Transport Layer Security (TLS) to encrypt emails in transit. But TLS depends on both the sender’s and recipient’s email provider, so depending on who you're sharing information with, it may not work in some situations.

    TLS is a type of point-to-point encryption; when you send an email from Outlook or OWA, your mail client contacts Microsoft’s server and creates a secure connection. The message is encrypted, sent to the server, and decrypted. The server repeats the process with the next server, until it reaches your recipient’s server.

    Transport Layer Security Diagram

    If both parties use Microsoft 365 Outlook's default encryption, the risk of your message being compromised is very low. However, if your recipient’s email service doesn’t use TLS, messages won’t be encrypted upon arrival. Even if both parties use TLS, the message could potentially pass through a hacked or improperly configured server outside of the Office 365 network, allowing a third party to decipher and read it.

    In addition to these default options, Microsoft offers its own email security add-on, Azure Rights Management (RMS), which can be purchased for an additional fee on top of a customer’s Office 365 subscription. Azure RMS encompasses two product offerings:

    • Office 365 Message Encryption (OME) – OME allows customers to send emails with encryption that exceeds the basic TLS built into Outlook desktop and OWA by default. OME also includes data loss prevention (DLP) capabilities that can automatically take actions on emails according to policies preconfigured by an administrator.
    • Azure Information Protection (AIP) – AIP – and its on-premise counterpart, Information Rights Management (IRM) – enables customers to apply usage restrictions to email messages shared with other Microsoft recipients.

    Azure RMS processes email security policies at the network level, after messages have left the sender’s Outlook or OWA inbox and are received by Microsoft’s Office 365 mail servers. Messages are encrypted in transit via TLS until they reach Microsoft’s servers, at which point

    Microsoft stores the customer’s unencrypted content on a hosted portal to ensure that email will be protected for all recipients – even those whose email servers do not have TLS configured.

    As with Outlook and OWA’s native TLS, Microsoft can access the unencrypted content shared by Azure RMS customers, which makes it more difficult to meet certain data residency, privacy, and compliance (CJIS, EAR, etc.) requirements in Office 365.

    Sending with Microsoft Azure RMS relies on customers to build policies that match a particular text string, such as “encrypt,” in the subject line or message body in order to activate encryption. If users forget to utilize keyword triggers, their emails may be sent without encryption.

    Recipients who have already configured Azure RMS onto their email servers can read Azure RMS messages transparently. If recipients do not have Azure RMS configured, they will receive an email containing an HTML attachment and instructions on how to download it.

    If their organization security policies permit them to download the attachment, recipients will then have the option of creating a new Microsoft account, signing in with their existing Microsoft account, or accessing a one-time email code. After authenticating, recipients can view and reply to the decrypted message in a web reader that is hosted on Microsoft’s servers.

    Via AIP, Azure RMS customers can add some control permissions to individual emails – such as message expirations and forwarding control – but only recipients at other Microsoft organizations can read messages sent with them, which poses a risk when sharing externally. As a result, most Azure RMS customers can only use control capabilities after confirming that each of their recipients has the technical requirements needed to view AIP-protected messages.

    Azure RMS can be difficult for administrators to deploy, but it provides a seamless experience when sharing with recipients whose organizations also use Office 365 Message Encryption. It meets some Microsoft security use cases, but does not offer client-side encryption or control, and as a result, many privacy and regulatory requirements may not be covered.

    Since certain protected-messages can only be read by other Microsoft customers, Azure RMS does not satisfy many organizations’ ease of use and cross-platform accessibility expectations for enterprise-grade encryption. As a result, most Office 365 customers rely on third party security vendors to fill in the gaps that Microsoft’s native tools have been unable to fill.

    Portal-Based Encryption: The Legacy Email Security Approach

    Has your bank or doctor every sent you an email that required you to create a new account and leave your inbox to view? If so, you likely have experience with portal-based email encryption – a legacy approach offered by most third party Office 365 security vendors in the market.

    With portal-based encryption, an administrator identifies certain keywords or other message criteria that trigger encryption when detected. Recipients are notified by email, and can then establish a user ID and password to access their content separately from their Outlook or OWA inboxes via web portals.

    Like Azure RMS, portal-based encryption takes place exclusively at the server level, after emails have already left the sender’s device and made it to the cloud. This architecture adds additional security by requiring new usernames and passwords to access sensitive content, but – as with Azure RMS – unencrypted plaintext is sent via TLS connection, giving intermediate providers access to this unprotected content.

    Portal Based Security

    This distinction means that portal providers manage the encryption keys protecting customer content and could have access to unencrypted versions of emails and attachments sent through their systems. This architecture introduces additional security risks and does meet the requirements of certain regulations like ITAR and CJIS, which mandate that no intermediate party can ever have access to unencrypted content.

    What’s more, most portal-based encryption providers do not offer any email access control features, so senders and administrators have no way to audit and manage where their emails travel after leaving the organization.

    The only way to restrict third party access to your Office 365 data, while also maintaining the ability to control this data wherever it travels, is via object-level email encryption technology that incorporates client-side encryption and customer-managed keys.

    Virtru Data Protection for Microsoft Office 365

    Virtru protects emails and attachments using object-level, or data-centric, encryption. This means that data is encrypted the moment it is created, and it remains encrypted no matter where it travels.

    Like regular Outlook and OWA messages, content is transmitted and stored on Microsoft’s (or any recipient’s mail provider’s) servers, but in encrypted form. The encryption keys that protect these emails are stored on Virtru’s servers, and access to them is always managed by the customer.

    Since protected content and encryption keys are stored separately, neither Microsoft nor Virtru – nor any other cloud provider – can access unencrypted customer content.

    In addition to its Network Data Protection option, which encrypts data at the server-side no matter from where it’s shared, Virtru provides client-side encryption – a powerful form of encryption that Azure RMS and portal-based vendors do not offer. This means that, unlike Azure RMS and portal-based vendors, Virtru can encrypt your Outlook and OWA messages on your computer before they ever reach the cloud. Until Virtru-protected emails and files reach their destination, they remain encrypted, meaning that Microsoft and other intermediary third-party providers can never access unencrypted messages.

    Virtru integrates encryption directly into the sender experience in major browsers, email clients, and devices with minimal disruption or change to the way users work. With a simple toggle in Microsoft Outlook or OWA, senders can decide on-demand which messages and files to encrypt, and they can indicate which messages were sent out with encryption.

    For recipients, Virtru uses existing platform credentials to enable recipients to decrypt and consume messages and content, so there’s no need to create new passwords like there is when using portals. This decryption can occur using either federated identity authentication (OAuth, OpenID, SAML) or using an email confirmation loop. In all instances, Virtru provides recipients with two authentication options:

    • Users can activate a browser extension or desktop plugin that enables them to read their messages, as well as send their own encrypted messages, directly from OWA, Windows Outlook, or mobile.

    • Users can read via a secure web reader that opens in the browser.

    Just like sending and reading, Virtru configuration is also straightforward. Individuals can download the client-side plugins directly from Virtru’s website, or administrators can push them out directly to their end-users.

    Once configured, Virtru offers a centralized dashboard from which administrators can view active Virtru users, track where end-user emails travel and control access, and configure data loss prevention (DLP) rules to detect and automatically encrypt sensitive information.

    Since Virtru offers client-side DLP in addition to network level scanning, customers can enable DLP policies that do not require Virtru to access customer plaintext, which is sometimes necessary for regulatory and business privacy requirements.  Azure RMS and most portal providers also offer DLP functionality, but these vendors can only scan end-user content at the network level, which means that customers must give these third parties the ability to scan their unencrypted content to identify policy indicators.

    Virtru also offers the Virtru Private Keystore that enables organizations to maintain complete and exclusive access to the encryption keys that protect their data. The Virtru Private Keystore adds public key encryption to Virtru’s standard SaaS product, so that the encryption keys hosted on Virtru’s servers are encrypted by additional keys that only the customer can access.

    As a result, Virtru customers can choose where their encryption keys are stored, either in the cloud or on a physical device.

    Since Virtru offers a more modern, object-level architecture than Azure RMS and the portal providers’ legacy network-centric approaches, it allows users and administrators to exercise granular, persistent control of emails and files across different platforms.

    While Azure RMS does not offer the ability to add information protection capabilities to emails

    that leave Microsoft’s systems, Virtru allows both senders and administrators to manage access to encryption keys. As a result, customers can apply the following control capabilities for their messages even after they’ve been read:

    • Revoke message access
    • Expire message access
    • Disable message forwarding
    • Track where messages have been forwarded
    • See when messages have been read
    • Watermark PDF attachments with recipient email addresses

    Virtru’s integration directly into existing email platforms provides a user experience that mirrors Outlook and OWA. The combination of client-side encryption with customer-managed keys provides enhanced levels of privacy and control that enables organizations to protect data even when it leaves the Microsoft ecosystem.

    In particular, the following capabilities allow Virtru to meet most privacy and regulatory requirements for Office 365 organizations:

    1. Message control capabilities allow customers to manage and control access to emails and files shared with non-Microsoft recipients.
    2. On-demand Outlook and OWA encryption, combined with cross-platform authentication options and lack of recipient download requirements, provide excellent ease of use.
    3. Client-side encryption prevents third parties from viewing customer content – a security requirement for many organizations with regulatory or privacy requirements.

    Looking to add an extra layer of protection to your Office 365 encrypted email? Let’s chat.

    Editorial Team

    Editorial Team

    The editorial team consists of Virtru brand experts, content editors, and vetted field authorities. We ensure quality, accuracy, and integrity through robust editorial oversight, review, and optimization of content from trusted sources, including use of generative AI tools.

    View more posts by Editorial Team

    See Virtru In Action