5 Reasons Email Encryption Should Be Next on Your To-Do List
7 votes, average: 4.00 out of 57 votes, average: 4.00 out of 57 votes, average: 4.00 out of 57 votes, average: 4.00 out of 57 votes, average: 4.00 out of 5 (7 votes, average: 4.00 out of 5, rated)
Loading...

5 Reasons Email Encryption Should Be Next on Your To-Do List

Email encryption helps you fight back against cybercriminals by securing your communications and sensitive email data.

Every day, we read about companies falling prey to phishing attacks that lead to email accounts becoming compromised and attackers gaining access to their employees’ inboxes. A recent example was seen in November 2022 when Work Health Solutions reported an email-related data breach in which names, Social Security numbers, driver’s licenses, and other sensitive protected health and personally identifiable information were compromised.

Now, imagine that this is your company and one of these compromised accounts belongs to one of your employees. If that data was sent unencrypted, it means that the attacker now has access to your secrets. Uh oh. You can kiss that data’s confidentiality goodbye and say hello to a damaged reputation, future lawsuits, noncompliance penalties, and a slew of other concerns.

But what if that the sensitive info was sent in an encrypted message using an email signing certificate? Then you might be able to sigh a (small) sigh of relief because, as long as the attacker doesn’t have access to your impacted employee’s device, it means that email’s data is protected by secure end-to-end protection. (We’ll speak more about what that entails later in the article.) Phew.

This article will explore five reasons why email encryption should be at the top of your security priorities.

Let’s hash it out.

Reason #1: You Have a Responsibility to Secure All Sensitive Data

If you work in specific industries, operate within specific geographic regions, or handle data relating to people located in those specific areas, then email encryption is something that may apply to you. For example, if you work with sensitive healthcare-related information, it’s your duty to protect that information. Under HIPAA’s Security Rule, for example, all protected data must be transmitted securely. So, if you’re sending emails containing sensitive data, you should use encryption to secure the data both in transit and at rest.

For example, consider the following info from the U.S. Department of Health and Human Services:

“The Security Rule does not expressly prohibit the use of email for sending e-PHI. However, the standards for access control (45 CFR § 164.312(a)), integrity (45 CFR § 164.312(c)(1)), and transmission security (45 CFR § 164.312(e)(1)) require covered entities to implement policies and procedures to restrict access to, protect the integrity of, and guard against unauthorized access to e-PHI. The standard for transmission security (§ 164.312(e)) also includes addressable specifications for integrity controls and encryption. This means that the covered entity must assess its use of open networks, identify the available and appropriate means to protect e-PHI as it is transmitted, select a solution, and document the decision. The Security Rule allows for e-PHI to be sent over an electronic open network as long as it is adequately protected.”

As the collector or processor of customer data, you must keep that information secure. (Of course, it’s not just about customer data — the same can be said about your intellectual property and trade secrets.) While it shouldn’t be a surprise that customers should expect you to protect their data, their trust in companies’ abilities to meet that responsibility is waning.

This is especially bad news for you if your company doesn’t take data security seriously enough. Data from Axway’s Global Consumer Survey report shows that 85% of surveyed global users are “somewhat” or “very concerned” that their online data isn’t secure. But what happens if customers determine you aren’t doing enough to make your website or services secure? More than 68% indicate that a lack of security would keep them from making purchases on a company’s website.

By using email encryption to secure messages containing sensitive information, then you’re ensuring that you meet customers’ expectations of keeping their personal or otherwise sensitive data secure. This way, all bad guys see is gibberish (i.e., ciphertext) and no confidential information.

Reason #2: Email Encryption Protects Your Data’s Confidentiality

In a nutshell, encryption is the process of masking or disguising data to make it indecipherable to anyone without a specific key. By encrypting your emails, you’re basically creating a failsafe mechanism to protect the confidentiality of the data. This is because encryption takes your readable information and converts it into unreadable ciphertext:

An illustration that shows the basic concept of how data encryption works
Image caption: A simple illustration that demonstrates how encryption works. The same concept applies to your inbound and outbound emails when using email encryption security measures.

This prevents anyone who receives the data from decrypting it because they don’t have the requisite private key. It’s like handing someone a top-of-the-line safe full of unknown valuables when they don’t have the key or lock combination to access them. It’s good for you but sucks for them.

According to the United Kingdom’s Central Digital & Data Office, all modern email service providers use TLS encryption to protect email data while it’s in transit. Moreover, most use TLS version 1.2. Here’s a quick example of an email that was received via a secure, encrypted connection using TLS 1.2:

A screenshot example of email header data, which shows the type of cryptographic algorithms involved in securing an email
Image caption: A screenshot of email header data that shows TLS 1.2 encryption was used with the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher suite.

But what if someone gets access to your email account — can’t they read your encrypted emails then? Nope, so long as you haven’t uploaded the certificate and key to your webmail account (e.g., Outlook on the web). Why? Because the certificate and key wouldn’t be available through that web tool.

If you only have your certificate installed locally on your email client, they’d also have to have access to a physical device that has the certificate and private key installed on it to decrypt the messages. Simply having access to the email account on any other device wouldn’t be enough to access the encrypted data because the attacker still wouldn’t have access to the locally stored cryptographic secret.

When done right, email encryption provides end-to-end security, protecting your email both while it’s in transit and at rest. We’ll speak more about both of these methods of email encryption (which can be used together) in the next two sections.

Reason #3: Email Encryption Protects In-Transit Data Against Man-in-the-Middle Attacks

To quickly recap, email encryption is typically achieved in two ways: 1) encrypting the communication channel that emails transmit through, or 2) encrypting the email data itself that’s being transmitted. The first (in-transit encryption) describes transport layer security, or what’s known as TLS encryption, and the second refers to S/MIME email encryption. But TLS for email encryption is what we’ll focus on here for a moment.

TLS encryption protects your data against interception attacks known as man-in-the-middle attacks. Imagine that someone comes across your data transmission and they want to steal or modify the data in transit. But if they don’t have the key to let them into the secure channel, they can’t do anything because the entire transmission will be indecipherable. This is an example of how TLS email encryption protects your data against man-in-the-middle (MitM) interception attacks.

Implementing TLS involves installing an SSL/TLS certificate on your email server. What this does is encrypt the communication channel. It’s kind of like those old spy movies in which two spies talk over an encrypted phone line. This prevents anyone outside that connection from being able to listen in on the conversation. It’s also what makes the security padlock appear in your inbound emails (depending on which email client you use.)

Installing an SSL/TLS certificate is an email server security best practice. Check out our related blog post to learn more about other email server security best practices.

What Does TLS Email Encryption Look Like?

For example, here’s what TLS mail security looks like for an inbound email in Gmail:

An email security screenshot that shows the email encryption that's provided via TLS
Image caption: A screenshot of an email that uses TLS encryption to secure data in transit.

See the security padlock? This icon indicates that the email has been sent via a secure connection. This means that the email’s data is secure while in transit. However, that data may or may not be secure once it reaches its destination and sits on the recipient’s email server. This is because unencrypted emails are vulnerable to compromise if someone gets access to the server, such as through an exploit). This is why you also need to secure your data at rest. More on that in just a moment.

To learn more about the relationship between SSL/TLS encryption and email servers, be sure to check out our other article on the topic.

Reason #4: S/MIME Email Encryption Secures the At-Rest Data on Your Server

S/MIME encryption, also known as secure/multipurpose internet mail extension encryption, encodes the contents (text, attachments, photos, etc.) of an email. This is why it’s also known as at-rest email encryption. This differs from the TLS encryption we spoke about a few moments ago, which encrypts the communication channel itself (rather than the message) to keep unintended busybodies from messing with your data mid-transmission.

Using the spy analogy from earlier, at-rest encryption is the equivalent of two agents speaking on the phone in a secret coded language. This way, even if someone intercepts the phone call, they can’t understand what’s being said.

At-rest email encryption involves using an S/MIME certificate, or what’s otherwise known as an email signing certificate, to encode the contents of the message itself. When you receive an encrypted message, you’ll see a padlock icon in your email:

An example email that shows an email was digitally signed and encrypted
Image caption: A screenshot that shows the security padlock that displays in encrypted emails in Outlook.

If you click on the padlock, here’s the email encryption certificate information you’d be able to review:

A three-part graphic that shows the email signature information relating to the S/MIME email security certificate that was used to sign and encrypt it
Image caption: A series of highlighted screenshots that show details about the email signer’s verified digital identity and the cryptographic details used to secure the message.

Reviewing this information is handy because it shows:

  • Who the verified sender is (in this case, it shows both the sender’s email and their verified organization),
  • What the email address is of the intended recipient, and
  • What security measures were used to secure the message.

To use S/MIME email encryption, the email recipient first must give the sender their public key. This is what they’ll use the encrypt the message prior to sending it. Then the recipient, once they receive the message, can use their corresponding private key to decrypt the message.

If you try to send a message in Outlook but don’t have the recipient’s private key (or they aren’t using an S/MIME certificate), then you can’t send an encrypted message. You’ll receive the following error message:

An example of an email security error message displaying in Outlook that communicates that an email is missing a valid certificate

Reason #5: Email Encryption Is Often an Implicit Requirement

Many industry and regional regulations and laws require you to secure sensitive data, especially personally identifiable information (PII). While they may not all specifically state you have to use encryption, it’s well implied considering that encryption is one of the leading tools and processes for securing data in transit and at rest.

For example, let’s consider the Health Insurance Portability and Accountability Act (HIPAA). In the Security and Privacy section (§ 164.306 Security Standards: General Rules), it specifies the following:

“(1) Ensure the confidentiality, integrity, and availability of all electronic protected health information the covered entity or business associate creates, receives, maintains, or transmits.”

Okay, cool. But how do you do that? Under Technical Safeguards (§ 164.312), it specifically lists data encryption and decryption: “(iv) Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt electronic protected health information.” It also mentions specifically securing data transmissions as well, which would include email communications:

“(2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable). Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.

(d) Standard: Person or entity authentication. Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.

(e)(1) Standard: Transmission security. Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.”

The use of an email signing and encryption certificate would cover both the authentication and security aspect of things because only the authorized party should have the decryption key.

Let’s next look at another well-known regulation: the European Union’s General Data Protection Regulation (GDPR). Article 32 (Security of Processing) specifies that you need strong technical security measures to secure data. One of the examples it provides is “the pseudonymisation and encryption of personal data” and ensuring “the ongoing confidentiality, integrity, availability and resilience of processing systems and services.”

… So, yeah. The big takeaway here is that you must encrypt all sensitive emails, especially those containing health-related information or other sensitive personal data.

Want to Start Using Email Encryption? Here’s How…

Now that you know the reasons why you need to implement email encryption within your organization, let’s quickly look at how you can put email encryption to use within your environment. There are a couple of ways to go about doing it:

  1. Install an SSL/TLS certificate on your email server. Yup, you knew this was coming. SSL/TLS isn’t just for your website; it’s also a great solution for securing your email server connections as well. Just be sure to use the right ports for your inbound and outbound messages:
    1. 465 or 587 for the secure mail transfer protocol (SMTP) for outbound emails,
    1. 993 for the internet messaging access protocol (IMAP) for inbound emails, or
    1. 995 for the post office protocol (POP3) for inbound emails.
  2. Install S/MIME certificates in your employees’ email clients. This is something that’s done on the client level and requires both parties to use email signing certificates. Traditionally, it involves manually installing an email signing certificate on each device, but leading certificate management platforms enable you to do this task remotely from a single dashboard.

It’s always a good idea to secure both your in-transit and at-rest data. So, pairing TLS with an S/MIME certificate is a great way to ensure end-to-end security. You’ll also want to ensure you’re using secure TLS protocols.

For a closer look at how you can implement email encryption within your organization, be sure to check back with Hashed Out. Within the next couple of weeks, we’ll publish another article on email encryption that will look under the hood at what it is and how to implement it.

Author

Casey Crane

Casey Crane is a regular contributor to and managing editor of Hashed Out. She has more than 15 years of experience in journalism and writing, including crime analysis and IT security. Casey also serves as the Content Manager at The SSL Store.