June 2nd, 2018

What Level of SSL or TLS is Required for HIPAA Compliance?

SSL and TLS are not actually monolithic encryption entities that you either use or do not use to connect securely to email servers, web sites, and other systems.  SSL and TLS are evolving protocols which have many nuances to how they may be configured.  The “version” of the protocol you are using and the ciphers used directly impact the level of security achievable through your connections.

Some people use the terms SSL and TLS interchangeably, but TLS (version 1.0 and beyond) is actually the successor of SSL (version 3.0). … see SSL versus TLS – what is the difference?  In 2014 we saw that SSL v3 was very weak and should not be used going forward by anyone (see the POODLE attacks, for example); TLS v1.0 or higher must be used.

Among the many configuration nuances of TLS, protocol versions supported (e.g., 1.0, 1.1, or 1.2) anf which “ciphers” are permitted have the greatest impact on security.  A “cipher” specifies encryption algorithm to be used,  the secure hashing (message fingerprinting / authentication) algorithm to be used, and other related things such as how encryption keys are negotiated.   Some ciphers that have long been used, such as RC4, have become weak over time and should never be used in secure environments.  Other ciphers provide protection against people who record a secure conversation from being able to decrypt it in the future if somehow the server’s private keys are compromised (perfect forward secrecy).

What level of TLS is required by HIPAA?

Given the many choices of ciphers and TLS protocol versions, people are often at a loss as to what is specifically needed for HIPAA compliance for an appropriate and compliant level TLS security.  Simply “turning on TLS” without also configuring it appropriately is likely to leave your transmission encryption non-complaint.  

What HIPAA Says about TLS and SSL

Health and Human Services has published guidance for the use of TLS for securing health information in transit.  In particular, they say:

Electronic PHI has been 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, SSL and TLS usage must comply with the details set out in NIST 800-52. This implies that other encryption processes, especially those weaker than recommended by this publication, are not valid and are thus non-compliant.

If you are using a level of encryption weaker than recommended, it is not valid, and thus for all intents and purposes your transmitted ePHI is unsecured and in violation (breach) of HIPAA.

So, What does NIST 800-52 Say?

NIST 800-52 (revision 1 from April, 2014) is a long and detailed document that covers what is needed for strong TLS for government use.  In addition to many small nuances, the biggest things to get out of this document are:

  1. SSL v2 and v3 must never be used,
  2. TLS v1.0+ is OK to be used when interoperability with non-government systems is required, and
  3. Only ciphers in a specific, recommended list are OK to use

The list of technically allowed ciphers (converted into a colon-delimited list of cipher names used by openssl, apache, and many other programs) is:

Full NIST 800-52r1 Cipher List:


However, in 2017, NIST has released an advisory that everyone should move away from 3DES ciphers towards AES due to security issues.   So, everyone should remove the DES ciphers from the above list:

NIST 800-52r1 Cipher List without DES Ciphers:


This move away from DES has no real compatibility issues, except for the native Windows XP encryption stack which, of the list of NIST-recommended ciphers, only supported DES-CBC3-SHA. That said, Windows XP is long deprecated).

Draft: NIST 800-52 r2

NIST has been working away at the next version of its TLS recommendations.  You can access the draft 800-52 revision 2 recommendations here.  These may change somewhat before they are finalized; however, they provide strong additional guidance over revision 1.  These recommendations state:

  1. SSL v2 and v3 must never be used,
  2. TLS v1.0+ is OK to be used when interoperability with non-government systems is required, and
  3. Only ciphers in a [revised] specific, recommended list are OK to use
  4. TLS 1.3 should be supported by your services by 2020.

So, the general tone is the same.  TLS v1.0 is still Ok; however there is general consensus that everyone should move to TLS v1.2 as soon as possible.  However, the list of ciphers recommended has shrunk.  The new recommended list of ciphers is just:

NIST 800-52r2 Cipher List (RSA and ECDHE only):




What Should I Use for Compliance?

For HIPAA + PCI Compliance (or just PCI compliance)

For systems through which credit card data passes, PCI compliance rules and PCI is currently more strict that HIPAA guidance.  PCI requires use of TLS 1.1+ (no TLS 1.0 or below) by June 30th, 2018.

As TLS v1.1 provides no compatibility advantages over TLS v1.2 (most everything that supports TLS v1.1 also supports TLS v1.2), those systems needing PCI compliance should use TLS 1.2+ and the NIST 800-52r2 cipher list (or the subset thereof that is specific to TLS 1.2+)

NIST 800-52r2 Cipher List for TLS 1.2+:


Note that, depending on your systems, some may fall under HIPAA, some under PCI, and some under both.  I.e., your email may fall under HIPAA and not PCI (as you should never email credit card data); your web sites may fall under PCI and HIPAA.
Fortunately, requiring TLS 1.2 and these good ciphers will still leave your web site compatible with most modern web browsers made in the last 5 years.  People using Vista or Windows 7 and native Internet Explorer browsers may have issues connecting, however.

For HIPAA Compliance

If you are not a government organization but have HIPAA-compliance requirements and have to interact with people using a wide array of systems and devices, we would recommend the following:
  1. Support TLS 1.0, 1.1, and 1.2+
  2. Use all of the non-DES ciphers from BOTH the NIST 800-52r1 and 800-52r2 lists

As the 800-52r2 list is not yet finalized, but it does contain recommended ciphers that are better than those in the r1 list, using both is a good compromise.  Once 800-52r2 is finalized and becomes “the word from above,” you will want to update your servers to only support those.   We do not recommend it quite yet for general use, as you will experience compatibility issues with some systems.

NIST 800-52 r1+r2 Ciphers (no DES)


One thing that is interesting to note is that there are many ciphers included in this list that are not 256-bit.  E.g. 128bit AES is allowed for HIPAA and for high-security government use.  We often hear people stating that 256-bit encryption is a requirement of HIPAA … it is not (that answer is “too simple” — it comes down to which specific algorithms are used, for example).

If you are not dealing with “a wide variety of users and devices,” then we recommend that you restrict your ciphers and protocols as much as possible.  I.e., using the same ones required for PCI compliance, listed above, would be very good if it works in your environment.  You will eventually move to that in the future anyway.

What Does LuxSci Do?

LuxSci’s services use TLS for secure web site, POP, IMAP, and SMTP connections.

LuxSci currently enables you to use TLS in a HIPAA-compliant way by:

  1. Only allowing TLS v1.0+
  2. Only allowing connections using the above recommended cipher list for HIPAA compliance (800-52 r1+r2 no DES)

For dedicated-server customers, we can upgrade the security of your connections to TLS 1.2+ with NIST 800-52r2 ciphers (i.e., if you need PCI compliance or just want a higher minimum level of security for your users and web site visitors).  Just ask support and we can make that change for you.

LuxSci also enables HIPAA-compliant customers to choose to have secure email messages delivered to recipients using “TLS Only” secured connections to recipient servers that support TLS for SMTP.  For many customers, the ease-of-use of TLS for secure email delivery is a great solution, when available.  LuxSci’s systems dynamically check all of the recipient’s inbound email servers to ensure that all of them support a sufficient level of TLS.  Only then will LuxSci permit TLS-Only email delivery.

We do observe some email servers on the internet do not support TLS at all and some support only SSL v3 or very weak/old ciphers.  We do not allow our HIPAA customers to communicate with them using only TLS (SSL), as that would place them out of compliance.   We recommend that these servers upgrade their software configurations. Until then, LuxSci automatically upgrades secure messages to them to the use of SecureLine Escrow (portal pickup) or PGP or S/MIME to ensure compliant communications.

Use our TLS Checker Tool to see if a domain supports SMTP TLS and if its support is “good enough” for HIPAA-compliant email delivery.

Check a domain’s SMTP TLS capability

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.