This content is part of the Buyer's Guide: The best email encryption products: A comprehensive buyer's guide

How to procure email encryption software

Expert contributor Karen Scarfone examines the most important criteria for evaluating email encryption software for deployment within the enterprise.

Email encryption software is used to automatically or manually encrypt email messages and attachments so as to protect sensitive information from unauthorized disclosure. It is most commonly used to protect emails sent from one organization to another -- or to individuals, such as customers -- but increasingly it's also being used for internal emails between employees.

There are many email encryption software products available, but their features can differ significantly. Therefore, it's important for organizations to establish criteria for evaluating email encryption software before comparison shopping, so as to get the product that's the best fit in terms of features, performance and cost.

Above all else, email encryption software must be highly usable -- especially if end users are responsible for manually selecting which emails will be encrypted, and/or if recipients of the encrypted emails are outside the organization. An unusable product will likely be ignored or circumvented, thus putting sensitive data at increased risk of compromise.

Below are several important criteria to consider as part of any email encryption software evaluation.

Support for internal and/or external users

As discussed in the second article in this series, the most important decisions to be made when planning an email encryption software product are whether encryption is needed for individual internal senders or not (as opposed to doing all encryption behind the scenes based on policy) and whether encryption is needed for external recipients or not.

Based on which direction the organization decides to go, it's then critically important to ensure the email encryption software evaluated supports those decisions. So, for example, if the organization wants individual senders to be able to encrypt emails, it should only evaluate potential products that provide an encryption interface for end users. Similarly, if the organization wants external recipients to be supported, then only potential products that provide Web-based interfaces for external recipients should be considered.

Usability is also something that can't be overlooked. Many email encryption products in the past have failed, not because they didn't work, but because users found them too challenging or cumbersome. For instance, when earlier generations of email encryption products required users to trade keys before sending encrypted emails, users often sent the wrong keys (private keys instead of public keys), thus compromising their encryption. If email encryption is made optional and it's inconvenient, users won't use it; they'll either send emails without encryption or they'll use alternate email systems, file-sharing websites, or other means to exchange information with each other without using encryption.

Integration with existing email infrastructure

The ease of integration with the existing email infrastructure is an obvious, yet important, factor to consider when purchasing and deploying and email encryption.

On the mail server/gateway side of the equation, some email encryption software products only work with one or more particular email server brands. A similar problem exists on the client side (assuming an organization wants individual clients to be able to encrypt emails). Some email encryption products are only compatible with one or a few client email flavors, such as Microsoft Outlook or Novell GroupWise. In addition, to make encryption available on the client side, users may need to install an add-on for their email client or possibly a separate piece of software.

Consequently, it's important to be aware of which email servers and email clients users run, and to make sure that either all the servers and clients are supported by the encryption product or that the organization can migrate all users from unsupported servers and clients to supported servers and clients, which is not something to be taken lightly in terms of effort and disruption.

Strength of cryptography

The details of cryptography are often hidden under the covers of email encryption products, but it's important to get access to at least the major cryptography attributes: algorithms, key size, and certification statuses. Ideally the product chosen should support the Advanced Encryption Standard (AES) algorithm with minimum 128-bit keys (preferably 256-bit keys) and be FIPS compliant. FIPS compliance is a certification that demonstrates that a cryptographic implementation has passed basic testing (not that the implementation is bug-free).

Another important cryptographic consideration is key management. Many email encryption implementations issue a new key for every email message. Others may issue a key pair per email address. In this case, it is important that the email encryption product provide the full cryptographic key management lifecycle, including regular key rotation.

File security

Email encryption software isn't just about protecting email message bodies, but also email file attachments. By default, attachments are encrypted as part of any email encryption product worth its salt. However, there are two special considerations involving attachments that merit investigation when evaluating products.

The first is the ability to transfer large files via email encryption software. Many email systems limit maximum email or attachment sizes, often at 10 or 20 megabytes. These limits are often inconvenient.

But because the encryption product is actually sending a link to the file, and not the file itself, the file is unaffected by the email system's file attachment size limit. Some email encryption products support file sizes in gigabytes. This may provide a more usable product than other secure file transfer methods.

The second is the ability to have the encryption "stick" with a file even after the attachment has been separated from the email message. This typically involves the installation of an email client add-on or separate software tool that handles the encryption and decryption. Note that if files are leaving an organization's boundaries, some sort of user or client provisioning for the external users will probably be necessary to allow them to decrypt the files.

Mobile workforces

With workforces increasingly going mobile, it's more important than ever for an  email security product to support smartphones and tablets and telecommuters, including all flavors of the bring your own device (BYOD) phenomena. Generally, this is only a necessary consideration if an organization is allowing individual users to encrypt emails. Make sure all email encryption products evaluated provide support for the mobile devices and apps that will need to send and receive encrypted email within the organization.

Policy- and identity- based encryption

Most email encryption products tout that they use policy-based encryption or identity-based encryption.

Policy-based encryption refers to encrypting email messages and attachments based on a set of policies -- for example, automatically encrypting all email messages sent by members of the human resources department, or all email messages that appear to contain credit card numbers. Identity-based encryption (IBE) is when public/private key pairs are created based on a characteristic of a user, such as the user's email address.

IBE allows encrypted messages to be sent to recipients without any previous key exchange. But to decrypt messages, each recipient must contact the sender's infrastructure to get the private key. With email encryption products, this is typically done through a Web interface.

Policy-based encryption and IBE are not mutually exclusive, and it's certainly possible for a product to use both of these forms of encryption, so they should not be thought of as either/or. Most vendors seem to state that they perform one or the other, but in reality, most email encryption vendors perform both types of encryption.

In terms of criteria, it is important to know if policy-based encryption and/or IBE is being used, and if either one is not being used, what architecture is being used instead of them.


Evaluating any security product for enterprise use can be challenging, and this is particularly true with cryptographic products. By relying on some basic criteria, various products can be compared with each other in an objective way. Even though there may be existing third-party comparisons of email encryption software products, such comparisons involve a lot of generalization, and they can't possibly take an individual organization's requirements, needs and culture into account. It is therefore necessary that each organization perform its own evaluation of any email encryption software product it is considering. Note that most vendors make trial versions of their products available for download.

This article presents several criteria that are generally helpful to use when evaluating products. However, these criteria aren't necessarily the only criteria that's needed. Each organization may have additional requirements that merit inclusion in the list of criteria. Think of this article as a starting point for creating a personalized list of criteria evaluation.

Next Steps

Find out if email attachments sent via SSL are encrypted

Read up on the pros and cons of using an email encryption

This was last published in February 2015

Dig Deeper on Disk and file encryption tools