Is TLS Email Encryption Suitable for Compliance?

This article discusses what types of email encryption are sufficient to comply with government regulations. TLS email encryption is a good option for many organizations that manage sensitive data. However, it does not protect data at rest. Each organization must perform a risk assessment to determine which encryption methods suit their legal requirements.

Email Encryption Options

Before we review the requirements for each law, let’s compare some of the most common email encryption technologies to determine their suitability for compliance requirements.

SMTP TLS Email Encryption

There are many ways to encrypt email, but TLS is the easiest to use. With SMTP TLS, messages are transported between the sender and recipient securely. Over 90% of email providers support TLS, meaning most users can receive emails encrypted with TLS. No passwords are required to read the message- it looks like a regular email in the recipient’s inbox.

The downside of TLS email encryption is that it can only encrypt emails as they are transmitted from sender to recipient. It does not protect email messages at rest. Emails located in the sender’s sent email folder, in the queue, messages backed up on email servers, or saved and stored in the email recipient’s folders are not encrypted. Anyone who can access the recipient’s email inbox can read the secure message, making it less secure than other forms of message encryption.

Secure Portal Pickup

Secure Portal Pickup encrypts messages both in transit and at rest. It works like this:

1. The sender sends the message and attachments.
2. The message is encrypted and stored in a secure database.
3. The recipient is notified via email with a link to retrieve their message. This notice does not include any sensitive information from the original message.
4. The recipient connects to a secure website, verifies their identity, and reads the message over a secure connection.
5. The recipient can reply securely back to the sender.

Secure Portal Pickup allows users to send secure messages to any recipient. It is very secure but requires users to log in to another website to read their messages. Adding an extra step for security does sacrifice some usability. By requiring a login to read the message, important messages may go missed or unread by users who do not have the time or desire to log in to the portal.

PGP and S/MIME

PGP and S/MIME are encryption technologies that perform the same kind of encryption but through slightly different methods. In both cases, the message body and attachments are encrypted inside of the message itself. The data is protected in transmission and at rest.

The downside of PGP and S/MIME technology is that they are challenging to use. The sender and recipient must communicate their keys to each other before sending secure emails. Like Secure Portal Pick Up, adding an extra step slows down secure email communication. It is not too tricky if everyone involved uses the same secure email provider and understands email technology. However, this barrier makes PGP and S/MIME impractical for communicating with external recipients who are not tech-savvy. Exchanging encryption keys is not easy at scale, meaning these methods are better utilized for secure internal communications or with people you frequently correspond with.

Does TLS Email Encryption Meet Compliance Requirements?

Since TLS is widely supported and easy to use, many organizations want to encrypt emails this way. However, since TLS emails are visible as plaintext at rest, TLS email encryption may not be sufficient to meet compliance requirements. Organizations should review their legal obligations to determine if they need to encrypt messages at rest. If so, Secure Portal Pickup or another form of encryption can be used to ensure sensitive data is secured.

Now, we dive into some of the most common US government regulations and discuss the suitability of TLS for each. Note that this is not legal advice, and organizations should conduct their own risk analysis to determine what course to take.

HIPAA: Health Insurance Portability and Accountability Act

HIPAA requires that all electronic protected health information (ePHI) be encrypted during transport. The law says that ePHI can be encrypted by:

“The use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or key and such confidential process or key that might enable decryption has not been breached. To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data they are used to encrypt or decrypt.”

They go on to state what valid encryption processes for HIPAA compliance are:

“Valid encryption processes for data in motion are those which comply, as appropriate, with NIST Special Publications 800-52, Guidelines for the Selection and Use of Transport Layer Security (TLS) Implementations; 800-77, Guide to IPsec VPNs; or 800-113, Guide to SSL VPNs, or others which are Federal Information Processing Standards (FIPS) 140-2 validated.”

In other words, it can be used if TLS is configured to meet NIST standards with up-to-date ciphers. Emails do not need to be encrypted at rest. If they are, it can protect from liability if a breach occurs. TLS-only email encryption is good enough for email security under HIPAA; however, each organization must perform its own risk analysis and determine what level of encryption is appropriate to minimize risk.

Is TLS Email Encryption Okay for Compliance? YES, but consider your internal risk analysis.

GLBA: Gramm-Leach-Bliley Act

GLBA has a Safeguards Rule that discusses the requirements for email encryption. This rule does not reference any particular technology or encryption mechanism. Instead, it focuses on ensuring that each organization:

“…sets forth standards for developing, implementing, and maintaining reasonable administrative, technical, and physical safeguards to protect the security, confidentiality, and integrity of customer information.”

In GLBA, businesses must:

1. Ensure the security and confidentiality of customer information;
2. Protect against any anticipated threats or hazards to the security or integrity of such information, and
3. Protect against unauthorized access to or use of such information that could result in substantial harm or inconvenience to any customer.

There is no specific mandate for how organizations must protect their email. Unencrypted email transmission is a risk that can be mitigated by using TLS email encryption (or one of the other methods). Similarly, your security team could decide that based on the email contents and storage, explicit email encryption at rest is not needed to mitigate the risk.

Is TLS Okay? YES, but consider your internal risk analysis.

SOX: Sarbanes-Oxley Act

All publicly traded companies must abide by the Sarbanes-Oxley Act (SOX). Sarbanes-Oxley is like GLBA in that it does not address email encryption in particular but instead seeks to ensure that organizations analyze their risk and establish internal controls to protect sensitive information. Furthermore, SOX requires that organizations provide evidence of the effectiveness of these internal controls in their annual reports.

While SOX does not discuss email encryption, it is consensus-established that the COBIT and COSO frameworks are good guidelines for SOX compliance. COBIT says:

DSS5.11: Exchange of sensitive data: “Exchange sensitive transaction data only over a trusted path or medium with controls to provide authenticity of content, proof of submission, proof of receipt and non-repudiation of origin.”

TLS email encryption meets most of these criteria (though the other encryption methods provide more). Adding other technologies like DKIM to email workflows will protect against forgery and non-repudiation of origin without using PGP, S/MIME, or Secure Portal Pickup.

DS11.6: Security Requirements for Data Management: “Define and implement policies and procedures to identify and apply security requirements applicable to the receipt, processing, storage, and output of data to meet business objectives, organizational security policy, and regulatory requirements.”

DS11.6 can apply to “encrypted email at rest.” There is no mandate to encrypt individual messages. Organizations must only review their risk and implement policies and procedures to protect that data appropriately.

When considering SOX compliance, as with GLBA and HIPAA, it comes back to the organization’s processes and risk analysis to determine what level of encryption is appropriate for compliance needs.

Is TLS Okay? YES, but consider your internal risk analysis.

SB 1386: California Senate Bill 1386

California Senate Bill No. 1386 (“SB 1386”) requires any company that stores customer data electronically to notify California customers of a security breach to the company’s computer system if the company knows or reasonably believes that unencrypted information about the customer has been stolen.

This is an example of a breach notification law that exists in most states. It does not say anything explicit about email, but it does imply a lot. Customer data is often contained in emails. If emails containing unencrypted customer data are breached, SB 1386 would require companies to notify their customers.

TLS encrypts email during transport. Using it prevents the capture of customer data in transmission from the sender to the recipient.

If stored email is breached and not encrypted at rest, it triggers the breach notification requirement. Companies need to consider where and how email under their control is stored. If there is a significant risk of stored email being breached, companies may encrypt emails or the disks/drives where they are stored.

This would start with encrypting end-user devices (phones, laptops, exchange servers, etc.), as these are the most frequent breach targets. Organizations should also consider the likelihood of the breach of email stored with SaaS (Software-as-a-Service) cloud email providers.

Is TLS Okay? YES, but consider your internal risk analysis.

NASD 3010

NASD 3010 is concerned with written policies and the oversight of correspondence with the public relating to investment banking or the securities business. As such, compliance with NASD 3010 involves transparency and email archival, but not with how email messages are transmitted or stored concerning encryption.

TLS Okay? YES.

FRCP: Federal Rules for Civil Procedure

FRCP ensures that organizations retain copies of emails to be retrieved as evidence in civil lawsuits. This imposes a strong requirement for archiving copies of all sent and received email messages.

FRCP does not delineate when or how the original email messages should be encrypted. Email archives need to be secured and tamper-resistant. As long as archival happens in real-time with respect to the actual flow of email, the encryption of those messages is of marginal relevance to this law.

TLS Okay? YES.

SEC 17a-4: Securities and Exchange Commission

SEC Rule 17a-4 outlines requirements for the retention and archiving of electronic communications. This rule describes how to archive email communications and other documents properly.

Like with FRCP, SEC 17a-4 does not delineate when or how the original email messages should be encrypted. That is the purview of Sarbanes-Oxley. So, SEC 17a-4 compliance is irrelevant to using TLS for email delivery.

TLS Okay? YES.

FINRA: Financial Industry Regulatory Authority

The key FINRA regulations related to email include:

FINRA 3110: Requires each firm to preserve accounts, records, and correspondence in adherence with applicable laws and FINRA rules, regulations, and policy statements, as well as those prescribed by SEC Rule 17a-4.

FINRA 3010: Requires firms to maintain a system to supervise transactions and correspondence with their users. Companies should establish and maintain a supervisory system with written procedures and regularly review incoming and outgoing electronic correspondence.

FINRA is about archival, data preservation, supervision of compliance with procedure and review of correspondence. Like FRCP and SEC 17a-4, FINRA does not specify when or how the flow of email messages should be secured.

TLS Okay? YES.

PCI DSS: Payment Card Industry Data Security Standard

PCI is not a law but a set of requirements imposed by the credit card industry. Many small organizations want to send credit card information over secure email but must proceed cautiously.

PCI says in section 4.2.b: “Verify the existence of a policy stating that unencrypted PANs (Primary Account Number- i.e., the credit card numbers) are not to be sent via end-user messaging technologies.”

Email, instant messaging, SMS, and online chats can be intercepted across internal and public networks. Only use these messaging tools to send credit card numbers if configured to provide strong encryption.

Never send credit card numbers over regular email. If it is necessary to send credit card numbers over email, they must be encrypted before transmission. TLS should not be used because it cannot secure the PAN at rest. PGP, S/MIME, or Secure Portal Pickup are better options for sending highly sensitive information like credit card numbers.

TLS Okay? NO.

Is TLS Email Encryption Sufficient for Compliance?

It would be simpler if the government’s guidelines and requirements spelled out exactly what types of encryption to use. However, there are good reasons why the laws are written ambiguously- they provide flexibility for organizations to implement technology consistent with their particular and unique business methods.

The regulations described above leave the choice of security implementation up to the security officer, who must make choices based on a detailed risk analysis and evaluation of how using various technologies would impact business processes, profits, and risk profile.

In many cases, TLS email encryption satisfies compliance requirements. However, even if it meets requirements, businesses may opt for a more robust method of encryption to reduce liability. At a minimum, TLS should be used for every email. To reduce risk, organizations should choose flexible encryption technologies that enable users to dial up the level of security for highly sensitive emails (like those that contain medical records or credit card data) and enable the use of TLS for less sensitive communications.

What are the next steps?

1. Perform a risk analysis to understand where sensitive data is stored and sent and what rules govern the organization.
2. See if current email usage aligns with risk mitigation.
3. Find an email security provider, like LuxSci, that enables secure TLS email encryption and provides configurable options for more secure email encryption methods to tailor email usage to changing security needs.
4. Repeat the risk analysis annually to ensure compliance with changing regulations and security threats.