Is Email Encryption via Just TLS Good Enough for Compliance with Government Regulations?

Published: August 24th, 2015

There are many ways to encrypt email, TLS being the simplest and most seamless.  With SMTP TLS (the use of TLS encryption to secure the “SMTP Protocol” used for the transmission of email between computers), messages are transported between the sender, recipient, and all servers securely.  TLS is a layer that fits seamlessly over “regular email” to ensure transport email encryption when supported by both the message sender and the recipient.  With SMTP TLS, sending a secure message works and feels the same as sending any other email message.

“It just works.” That is the ideal combination of security and usability.

SMTP TLS for Email Encryption

However, SMTP TLS only solves the problem of email encryption during transmission from sender to recipient.  It does not in any way secure an email message while it is at rest, whether while in the sender’s “sent email” folder, queued or backed up on the email servers of the sender or recipient, or saved and stored in the email recipient’s folders.  While SMTP TLS is really easy to use, it is important to consider if use of SMTP TLS alone is “good enough” for companies to comply with the many U.S. government laws which apply to email.

When it  is “good enough,” organizations may opt for the seamless simplicity of TLS over the added complexity of other modes of secure email communication.

In this article, we shall examine the security afforded by SMTP TLS and compare that to other modes of email encryption such as PGP, S/MIME, and Escrow (i.e. picking up your message from a secure web portal).  We shall then look at many of the most important laws (HIPAA, GLBA, Sarbanes-Oxley, SB1386, NASD 3010, FRCP, SEX 17a-4, FINRA, and PCI DSS)  to see what is said or implied about using “Just TLS” vs. other, stronger forms of encryption.  We won’t spend a lot of time explaining each law; if you are interested there are innumerable articles on the web for that.  We  focus only on what they say or imply about encryption for email transmission and storage.

The short answer is that many of these laws outline various requirements for email storage, archival, and retrieval for legal proceedings without specifically delineating requirements for the encryption of those messages.  So, use of TLS is just fine with respect to those.

For PCI compliance, avoid email if at all possible; however, if you must use email for sending credit card data, “Just TLS” is not sufficient.

For the rest, the burden ends up being on each individual organization to decide for itself the level of encryption appropriate to protect sensitive data.  Use of encryption methods that provide protection for data at rest can mitigate liability in the case of a breach, but they are not mandated.  There are also ways of protecting data at rest that do not involve more onerous methods of email encryption.

Indeed, your internal risk analysis may find that “Just TLS” is best in some cases and methods that provide explicit data-at-rest email encryption are warranted in others.

What Are Your Email Encryption Choices?

Before we go into the nuances of various laws, let’s compare some of the common options for email encryption to see how they stack up to each other.

SMTP TLS (Transport Layer Security)

As discussed above, TLS encrypts messages during transmission between servers and between end-user email programs and servers.  As long as all of the programs and servers along the way support TLS, the message can be transparently secured along the whole transmission pathway.

I like to think of TLS as a “secure pipe.”  The unencrypted message goes in on one side, travels to its destination securely inside of this “pipe,” and emerges on the other side once more unencrypted.  Each “hop” from computer-to-server or server-to-server involves a new secure pipe.

SMTP TLS does not protect messages at rest (in backups, in archives, in sent email folders, etc.).  However, it does protect the entire message during transmission, including the recipient addresses, the subject, all other “metadata,” and the complete message body.  No other commonly used encryption system by itself protects everything during transmission.

While SMTP TLS does not secure message data at rest, that message data can be protected at rest in other ways:

  1. It can be saved on the well-secured cloud servers (as opposed to machines in your office) of your email provider where the chance of a breach may be relatively small
  2. It can be saved on encrypted hard drives or disk partitions, so email data is encrypted at rest due to disk encryption, if not due to encryption within the messages themselves.

The biggest risk associated with messages delivered over “Just TLS” involves email messages downloaded and saved to user’s devices, computers, and to servers in the corporate office.  These are the devices and machines that are most likely to be compromised or stolen. For this reason, encryption of those devices is practically required when sensitive data is stored on them.

SMTP TLS is good, but it also needs to be implemented properly.  For compliance with government regulations the servers participating in SMTP TLS need to be properly configured to exclude old and deprecated encryption methods (e.g. such as SSL v3 and RC4) that could put the transported data at risk.  See: What Level of SSL or TLS is Required by HIPAA?

PGP and S/MIME

When comparing to TLS and Escrow, PGP and S/MIME are two 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. So, this data is protected while being transmitted over the Internet and while being stored at rest on disk.

Unlike TLS, however, PGP and S/MIME do not encrypt or protect the message subject, recipient list, sender address or other metadata.  So — sensitive information located in these places is not secured.  For this reason, most secure email companies recommend or require not including sensitive information in message subjects.

Messages sent using PGP or S/MIME can also be delivered using TLS so one has “double encryption.”  This double encryption protects all of the message during transport; however, subjects and metadata are still not protected at rest.

The difficulty with using PGP or S/MIME is the requirement that the chosen technology must be supported by both the sender and the recipient and that somehow the sender and recipient must be able to communicate their “keys” to each other in order to initiate secure communications.  This is not problematic if everyone involved uses the same secure email provider or the community of correspondents is small and pretty tech-savvy.  PGP and S/MIME are impractical if you need to communicate securely with “anyone” or with people that are not tech-savvy.

“Escrow” or “Secure Message Pickup”

If you need to communicate securely with anyone and also want the message to be (a) encrypted at rest, and (b) delivered securely to the recipient, then a technology (which LuxSci calls “Escrow”) has been developed where:

  1. The sender sends the message and attachments.
  2. These are encrypted and stored in a secure database “in the cloud.”
  3. The recipient(s) are sent a notice by email with a link to come and “pick up” their message.  This notice does not include any of the sensitive information from the original message (except perhaps the sender, recipient, and subject).
  4. The recipient connects to a secure web site, verifies his/her identity somehow, and then opens and views the message over a secure connection.
  5. The recipient can optionally reply securely back to the sender.

This provides transport and storage security that works for any recipient.  It also allows senders to retract sent messages and to get reports that show who has viewed a message when. Additionally, it allows for secure reply.

Escrow is an ultimate solution … but it is obviously more work for recipients, and for this reason, many senders would prefer something more seamless (like using just TLS) if possible.  For many, it is a function of business revenue — the easier it is for the recipients, the more money they ultimately make.  Like many things, it is risk vs revenue.

For more background on email security in general, and these encryption methods in particular, see: The Case For Email Security.

HIPAA: Health Insurance Portability and Accountability Act

HIPAA strictly requires that all sensitive data (Electronic Protected Health Information – ePHI) must be encrypted during transport (i.e., data in motion) and it in fact indicates that TLS is a sufficient means of doing that.  In particular, HIPAA says:

“ePHI can be encrypted as specified in the HIPAA Security Rule 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” (45 CFR 164.304 — definition of encryption) 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.  The encryption processes identified below have been tested by the National Institute of Standards and Technology (NIST) and judged to meet this standard.”

They go on to specifically 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, use of TLS is OK as long as it complies with the details set out in NIST 800-52.  So — you can go ahead and use SMTP TLS to secure email transport, as long as your email provider ensures that TLS is configured in a strong enough manner (see What Level of SSL or TLS is Required by HIPAA? for more details).  Check with your email security provider to be sure that they support this level of secure TLS and do not support anything disallowed.

What about email encryption at rest and HIPAA?

HIPAA does not explicitly require that sensitive information (ePHI) be encrypted at rest.  However, it does say in the Breach Notification Rule Guidance that:

“The HIPAA Breach Notification Rule, 45 CFR §§ 164.400-414, requires HIPAA covered entities and their business associates to provide notification following a breach of unsecured protected health information.

Covered entities and business associates must only provide the required notifications if the breach involved unsecured protected health information. Unsecured protected health information is protected health information that has not been rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary in guidance.

This guidance was first issued in April 2009 with a request for public comment. The guidance was reissued after consideration of public comment received and specifies encryption and destruction as the technologies and methodologies for rendering protected health information unusable, unreadable, or indecipherable to unauthorized individuals.”

This is backed up by the Health and Human Services FAQ on “Is encryption required by HIPAA?

“No. The final Security Rule made the use of encryption an addressable implementation specification. See 45 CFR § 164.312(a)(2)(iv) and (e)(2)(ii). The encryption implementation specification is addressable, and must therefore be implemented if, after a risk assessment, the entity has determined that the specification is a reasonable and appropriate safeguard in its risk management of the confidentiality, integrity and availability of e-PHI. If the entity decides that the addressable implementation specification is not reasonable and appropriate, it must document that determination and implement an equivalent alternative measure, presuming that the alternative is reasonable and appropriate. If the standard can otherwise be met, the covered entity may choose to not implement the implementation specification or any equivalent alternative measure and document the rationale for this decision.”

So — what does this all mean for HIPAA?

This means that you must encrypt email during transport, but a sufficiently-secure version of TLS is good enough for that purpose.  You do not have to encrypt email at rest, but if you do, that provides protection against breach liability.

Additionally, HIPAA requires auditing and that users be authenticated when they access ePHI.  E.g. a unique username and password for each person is required for access to ePHI and records of these “logins” must saved. There is some significant gray area with regards to communication with people and entities outside of your own organization – are you responsible for providing the authentication to access the data? Do you need to record when they see the ePHI after you have “handed it off to them,” e.g. by sending them an email that now resides under their control? Are you responsible if a breach of their systems that reveals the contents of emails that you have sent them (securely), which are now under their control, but which you have not taken steps to the ensure encryption of and access control to – forever going forward?

Certainly the more steps that you take, the less potential liability there is for anyone as the ePHI involved is better and better protected. Many would argue that once a secure email is delivered to a party outside of your organization, it may the responsibility of that party to care for that email going forward. This could of course depend on the context and to whom you have handed off the ePHI. Such a perspective makes “Just TLS” a reasonable choice for email delivery. Others would argue on the side of caution and require something like Escrow: the sender ensures access, auditing, and encryption going forward … unless the recipient manually makes their own copies of the data.

Note that even the use of S/MIME and PGP do not necessarily provide any kind of audit trial and may not even provide any more authentication than mere access to the recipient’s email program (recipients often save their passwords in their programs or use the same password for convenience) – in such cases these strong encryption technologies are very similar to TLS in their effective value for auditing and the protection of data. Even systems like “Escrow” may allow “password resets” to anyone who has control over the recipient’s email.

So, 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 actually appropriate for them, based on their business practices, to minimize their risk.

You should ask yourself questions such as: if your recipients will be replying to your messages and their replies might come back insecurely … is that OK for you based on who they are and what they are sending? Do you have a means for them to send you secure messages to you and do you encourage that? Does your email system meet your internal access and auditing requirements?  The answers of these questions and nuanced and vary from business to business; however, in many cases, when you organize yourself properly, using just TLS is fine.

Just TLS could be OK? YESbut consider your internal Risk Analysis.

GLBA: Gramm-Leach-Bliley Act

GLBA addresses many aspects of email from encryption, to data loss prevention, to archival, to anti-virus and anti-spam filtering with the goal of protecting private financial information.  With respect to email encryption, GBLA has a Safeguards Rule.  This rule does not reference any particular technology or encryption mechanism, instead (like HIPAA) it is focused 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.”

Digging a little deeper into the act, we see that this means that businesses are tasked with: (1) insuring the security and confidentiality of customer information; (2) protecting against any anticipated threats or hazards to the security or integrity of such information, and (3) protecting against unauthorized access to or use of such information that could result in substantial harm or inconvenience to any customer.  How?  By identifying risks, choosing methods to control the risks, and by selecting vendors that help you with that.

So, there is no specific mandate for how you must handle your email.  You are required to identify your risks and take appropriate steps so that in the case of a breach, your liability is minimized.   Clearly, unencrypted email transmission is an obvious, large risk that is easily mitigated these days — so use of SMTP TLS (or one of the other methods) could be your organization’s means of risk mitigation.  Similarly, it could be decided that, based on where the messages are going, what is being communicated, and where/how the information is being stored, that explicit email encryption at rest is not needed to mitigate the risk in some or all cases.

While not specifically mandated, database, folder, full-disk and transport VPN/transport encryption all apply in your GLBA risk analysis.  Obviously a requirement for at-rest data encryption is strongly implied, especially for your own organization’s work stations, internal servers, and devices.  Encryption at rest is always better, even in cloud-hosted solutions, but may or may not be required by your organization based on the particulars of your risk assessment and risk vs cost analysis.

Just TLS could be OK? YES… but consider your internal Risk Analysis.

SOX: Sarbanes-Oxley Act

All U.S. Publicly Traded Companies must abide by SOX.  Sarbanes-Oxley is strongly reminiscent of 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.  Digging into COBIT and trying to figure out what it says about email encryption, we find requirements:

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 can provide most of these criteria (though the other encryption methods provide more).  Adding other technologies such as DKIM to your email flow will add protection against forgery and non-repudiation of origin without having to go to PGP, S/MIME, or Escrow.

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 clearly no mandate that individual messages be encrypted — only that organizations review their risk and implement policies and procedures to protect that data in an appropriate way.   Depending on your data flow, this could once more involve encrypted devices, workstations, and servers in your office.  It could involve  PGP, S/MIME, or Escrow.  It could involve encryption in the cloud, or it could involve TLS with non-encrypted-at-rest storage on highly secured cloud servers.  It could also mean a hybrid approach for an organization — stronger encryption mechanisms where the data is being transported outside of the company’s control, and weaker when it is within a well defined and secured perimeter.

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

Just TLS could be OK? 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 its 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 many different “breach notification laws” that exist in most states.  It does not say anything explicit about email, but it does imply a lot.

  • Customer data can be in email.
  • If that email is breached AND if it was unencrypted, then SB 1386 requires breach notification.

TLS encrypts email during transport and thus its use exempts any breach/capture of customer data being delivered over TLS from requiring notification.  Eavesdropping on a TLS-encrypted connection is supposed to be useless.  For most practical purposes (e.g., unless you are trying to hide from governments or unless your TLS implementation is old) that is pretty much true.

However, if your stored email is breached and it is not encrypted at rest, that also triggers this 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, then these companies may choose to ensure that such email, or the media on which it is stored, is encrypted.  This would start with encryption of end user devices (phones, laptops, exchange servers, etc), as these are the most frequent subjects of breach. This should also include consideration of the likelihood of the breach of email stored with SaaS (Software-as-a-Service) email providers in the cloud.

Just TLS could be OK? YES… but consider your internal Risk Analysis.

NASD 3010

NASD 3010 is concerned with written policies and the oversight/supervision of any written and electronic correspondence with the public relating to investment banking or the securities business.  As such, compliance with NASD 3010 has a lot to to with transparency and email archival, but nothing, really, to do with how email messages are actually transmitted or stored with respect to encryption.

Just TLS OK? YES.

FRCP: Federal Rules for Civil Procedure

FRCP is concerned with ensuring that organizations retain copies of all email (and other documents) so that they can be retrieved as evidence in civil law suits.  This imposes a strong requirement for archiving copies of all sent and received email messages.

However, FRCP does not at all delineate when or how the original email messages themselves should be encrypted.  Clearly,  archives need to be secured and tamper resistant.  As long as archival happens in relatively real time with respect to the actual flow of email, the encryption of those messages (e.g. to prevent tampering) is of marginal relevance to this law.

Just TLS OK? YES.

SEC 17a-4: Securities and Exchange Commission

According to the SEC, requirements for the retention and archiving of electronic communications was made effective by Rule 17a-4, enacted on May 12, 2003.  This rule goes into detail on the requirements for the archival of email and other documents and what, technically, needs to be done to archive them properly.

Like with FRCP, SEC 17a-4 does not deliniate when or how the original email messages themselves should be encrypted. That is really the purview of Sarbanes-Oxley.  So, SEC 17a-4 compliance is not relevant to the use of just TLS for email delivery.

Just TLS OK? YES.

FINRA: Financial Industry Regulatory Authority

The key FINRA regulations related to email, in addition to compliance with SEC 17a-4, 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-3.

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, reviewing incoming and outgoing electronic correspondence on a regular basis.

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.

Just TLS OK? 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.  If a company violates these requirements, then it could be fined, or at worst, its ability to process credit card payments could be suspended.  Needless to say, that would be bad.

We see many small organizations wanting to send credit card information over secure email.  PCI says in section 4.2.b:

“4.2.b Verify the existence of a policy stating that unencrypted PANs are not to be sent via end-user messaging technologies.

E-mail, instant messaging, SMS, and chat can be easily intercepted by packet-sniffing during delivery across internal and public networks. Do not utilize these messaging tools to send PAN unless they are configured to provide strong encryption. Additionally, if an entity requests PAN via end-user messaging technologies, the entity should provide a tool or method to protect these PANs using strong cryptography or render PANs unreadable before transmission.”

So — never send the PAN (Primary Account Number — i.e. the credit card number) over regular email.  If one does send it over email, then your need to encrypt the PAN before transmission.  This eliminates “Just TLS” as a viable delivery mechanism, as TLS only deals with transmission.  It does, however, technically allow one to use PGP, S/MIME, or Escrow.

However, if one does decide to send credit card information over encrypted email, one must be very careful where the unencrypted information goes.  E.g., consider the sending computer, the recipient’s computer, other “gateway” machines that are performing automated encryption or decryption.  All of these may now be inside of the PCI compliance “scope” and that may make meeting PCI compliance requirements much more difficult than if the data were never emailed in the first place.  As anyone who has reviewed PCI compliance requirements or participated in an assessment knows, PCI is strict, technically complex, and the smaller your scope is, the better.

Just TLS OK? NO.

Were You Hoping for Definitive Guidance?

It seems that it would be so much simpler if the government’s guidelines and requirements spelled out exactly what you should do, what encryption method you should choose, and what vendor you should sign up with. However, there are good reasons why the laws are written ambiguously  — they provide flexibility for organizations to implement technology in a way consistent with their particular and unique business methods.  They also leave wide berth for the development and adoption of new technologies.  The laws provide a goal and some guidelines and leave execution up to each business.  The “proof is in the pudding” — if you get breached, your policies and implementation will be evaluated and fines and penalties will be assessed based on that.  In some cases, surprise audits may come your way before any actual breach… and you must be ready for those.

Back to the question: “Can we use Just TLS or something more?”

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

For maximal security and least risk, one should choose encryption technologies that provide for encryption of data at rest.  Use of SMTP TLS “on top of” these technologies is a best practice to ensure that all message data, including the metadata, is encrypted during transport.  However, there is a strong burden on usability when using email encryption technologies other than TLS.  In many cases, it may be determined that sensitive information can be sent over “Just TLS” in order to take advantage of usability.  E.g., when the messages are “internal” and you have good confidence in your internal email system, or perhaps when you no longer have responsibility for the security of the emailed data once it has been delivered to your recipients.

Sometimes a strong method of encryption, such as Escrow, PGP, or S/MIME can’t reasonably be used for every sensitive message.  We would recommend picking a email solution where users can use TLS where acceptable and dynamically choose something more powerful, such as Escrow, as needed.

What are your next steps?

  1. Perform your internal risk analysis to understand where sensitive data is stored and goes and what rules govern your organization.
  2. See if your email usage aligns with mitigating your risk.
  3. Find an email security provider, such as LuxSci.com, that enables sufficiently secure SMTP TLS and provides configurable options for more secure email encryption methods, so that you tailor your email usage to your changing security needs.

Leave a Comment


You must be connected or logged in to post a comment. This is to reduce spam comments.

If you have not previously commented, you can connect using existing social media account, or register with a new username and password.