Top Encryption Standards for Healthcare Data Transfers

If healthcare data moves between systems, it should be encrypted at more than one layer. In 2024, HHS OCR logged 725 large breaches and about 276.8 million exposed records, and the average U.S. healthcare breach cost hit $7.42 million in 2025.

Here’s the short answer: TLS 1.3, AES-GCM, ECC or RSA, IPsec, and S/MIME each cover a different part of data transfer security. If I were setting a healthcare transfer stack in 2026, I’d use:

• TLS 1.3 for websites, portals, APIs, and app traffic
• AES-GCM for files, payloads, and stored transfer data
• ECC first, RSA where older systems need it for certificates, signatures, and key exchange
• IPsec for VPNs, site-to-site links, and device-heavy networks
• S/MIME for email that must stay encrypted end to end

A few points matter most:

• Encryption in transit is now required under the January 2025 HIPAA Security Rule update
• TLS 1.2 can still work, but only with strong cipher settings and old versions turned off
• AES-256-GCM is the safer default for high-sensitivity ePHI and long-term protection
• ECC fits modern systems better, while RSA still helps with older partner environments
• IPsec works well below the app layer, especially for legacy medical device security risks
• S/MIME protects the email message itself, not just the mail connection

HIPAA 2026: The Biggest Compliance Shift in Years

sbb-itb-535baee

Quick Comparison

Put simply: use TLS for the session, AES for the data, ECC or RSA for trust, IPsec for network tunnels, and S/MIME for email. The main issue is usually not the cipher. It’s the setup, key storage, rotation, and old systems left in place.

1. TLS 1.2/1.3

TLS protects most healthcare data while it moves from one system to another. That includes third-party APIs, patient portals, telehealth sessions, and third-party risk links. In healthcare, the debate isn't whether to use TLS. It's which version and settings line up with current HIPAA expectations.

HIPAA/NIST Alignment

The January 2025 HIPAA Security Rule update made in-transit encryption for PHI mandatory^[2]. NIST SP 800-52 Rev. 2 sets TLS 1.2 as the minimum and requires federal systems to support TLS 1.3 by January 2024^[2][5]. For 2026, TLS 1.3 is the preferred baseline.

TLS 1.2 is still acceptable for legacy compatibility, but only if it's locked down with strong AEAD ciphers and forward secrecy turned on. SSL v2/v3, TLS 1.0, and TLS 1.1 should be turned off on purpose, not left hanging around by accident.

NIST-aligned encryption can also support HIPAA safe harbor when stolen data remains unreadable^[2].

Security Strength

The difference between TLS 1.2 and TLS 1.3 is bigger than it looks at first glance.

TLS 1.3 strips out old algorithms entirely. There's no static RSA key exchange and no static Diffie-Hellman. It requires ephemeral key exchange, usually ECDHE, which means Perfect Forward Secrecy (PFS) is built in by default. If a private key is later exposed, past sessions still can't be decrypted.

TLS 1.2 can support PFS too, but only when it's set up the right way. That's where teams get into trouble. The risk isn't just weak crypto. It's weak configuration.

TLS 1.3 also limits cipher suites to AEAD-only options like AES-GCM and ChaCha20-Poly1305. These handle encryption and authentication together. TLS 1.2, by contrast, can still permit older ciphers such as 3DES, RC4, and SHA-1 unless someone removes them by hand.

One more detail matters in healthcare: disable TLS 1.3 0-RTT for state-changing actions like updating patient records or submitting prescriptions. It can introduce replay attack risk, which is a bad trade for actions that change data.

That gap matters most when you're weighing legacy support against a secure-by-default setup.

Integration Fit

For service-to-service traffic, EHR links, and partner API connections, Mutual TLS (mTLS) adds another check by requiring both sides to present certificates, not just the server. That ties system identity to the encrypted channel and helps enforce least-privilege access between systems.

Some connected medical devices still can't support TLS 1.3 on their own. In those cases, put a compliant TLS gateway in front of the device. The device talks to the gateway, and the gateway handles modern encryption for it. That's in line with NIST SP 800-213 guidance for IoT and medical device deployments.

Key Management

TLS falls apart when certificate and cipher management fall apart.

Use tools like testssl.sh or Qualys SSL Labs to audit your TLS setup. The goal is simple: confirm that TLS 1.2 fallback paths aren't quietly allowing weak ciphers like 3DES, RC4, or SHA-1.

Private keys should live in a Hardware Security Module (HSM) or a managed Key Management Service (KMS)**, never in environment variables or source code. Rotate high-sensitivity keys on a 90-day cycle, assign at least two named key custodians, and automate certificate renewal so you don't end up with preventable outages.

Expired certificates can break vendor risk management connections overnight. Weak fallback settings can do the same thing while also opening the door to risk. And when TLS terminates, make sure logs don't collect PHI in URLs or headers.

TLS protects the transport channel. The next step is picking the right cipher for the data payload itself.

2. AES-128/192/256

TLS protects the channel. AES protects the payload. You need both, and the AES version and mode you pick can change your risk more than many teams expect.

HIPAA/NIST Alignment

For healthcare data transfers, use AES-GCM with FIPS-validated modules. Keep AES-256 for highly sensitive data or payloads that need to stay protected for a long time. AES-256 meets FIPS 140-2 validation requirements, which is the benchmark HHS uses to decide whether encrypted data counts as "secured."

That matters for HIPAA. Properly encrypted ePHI can fall under HIPAA's breach-notification safe harbor: if data is lost or stolen and the keys are not compromised, the incident may not need to be reported ^[4]. On the flip side, loss or theft of unencrypted PHI can trigger OCR penalties and breach notification ^[4].

Security Strength

For sensitive PHI, AES-256 is the safest default. AES-128 is enough for most transfer channels. AES-192 is not used much in practice, so it's left out here.

Use AES-GCM only. Disable AES-CBC and other legacy modes ^[1][2].

Integration Fit

AES is the payload standard, not a standalone protocol. Use AES-GCM anywhere your transfer protocol supports it, and turn off CBC fallbacks.

That also means looking past the storage layer. In APIs and file transfers, encrypt high-sensitivity payload fields themselves, not just the database or disk sitting behind them.

Key Management

Encrypting data without strong key management is theater. Master keys should never sit in environment variables, config files, or source control. They belong in a managed KMS or a hardware-backed HSM that uses FIPS 140-2 or 140-3 validated modules ^[1][2].

Use envelope encryption:

• Encrypt PHI with a Data Encryption Key (DEK)
• Then wrap that DEK with a Key Encryption Key (KEK) stored in your KMS

This setup lets you rotate keys without re-encrypting petabytes of underlying data. Rotate KEKs at least once a year. For high-sensitivity healthcare workloads, 90 days is the modern best practice. Log all key use and keep those logs for six years ^[4].

If you're working with large health systems, it also makes sense to offer BYOK support. BYOK lets the partner revoke access by revoking the key.

AES protects the data itself, while RSA and ECC still handle identity, signatures, and key exchange.

3. RSA and ECC

AES protects the data itself. RSA and ECC handle trust: they help verify endpoints, sign certificates, and set up trusted third-party transfers.

HIPAA/NIST Alignment

NIST SP 800-52 Rev. 2 sets RSA-2048 as the legacy minimum and points to RSA-3072 for higher-security transfers. For modern integrations, use ECDSA P-256 or P-384 ^[1][2].

Anything below 2,048-bit RSA is obsolete for healthcare transfers. In current NIST-aligned healthcare setups, it isn't acceptable ^[1][2].

Security Strength

RSA leans on compatibility. ECC leans on speed and smaller key sizes. There's also a key difference that often drives the decision: ECC supports Perfect Forward Secrecy (PFS) through ECDHE, while RSA does not provide that on its own.

Integration Fit

For third-party healthcare connections, the choice usually comes down to compatibility vs. speed.

RSA still fits legacy EHR connections, SFTP, and older partner systems where broad support matters most. ECC is the baseline for modern APIs, mTLS, mobile apps, and service-to-service links ^[1].

For EHR-to-vendor APIs and mTLS, ECC should be the default. Keep RSA for older partner systems that still depend on it. When you use mTLS with ECDSA certificates, identity is tied to the communication channel itself, so both sides verify each other, not just the server ^[1].

Key Management

Private keys should live in a FIPS 140-2 or 140-3 validated HSM ^[1][4]. That's the safest place for them when you're dealing with healthcare transfers.

A few habits matter here:

• Automate certificate renewals so expired certs don't knock systems offline.
• Enable OCSP stapling to speed up certificate checks and make revocation checks more reliable ^[1].
• If a staff member with key access leaves the organization, add revocation to the offboarding checklist right away instead of treating it like cleanup work later ^[1][4].

Certificate discipline matters most when RSA or ECC is protecting vendor links, APIs, and partner-facing services. If the transfer path is a network tunnel instead of an application session, the next step is IPsec.

4. IPsec

IPsec works at the network level. It secures IP traffic no matter which app created it. In plain English, it protects the path underneath app-layer encryption. That makes it a good fit when an app can't support TLS on its own, especially with legacy devices and closed clinical networks.

HIPAA/NIST Alignment

IPsec setups should follow NIST SP 800-77 and SP 800-113 ^[3].

Security Strength

IPsec has two operating modes. Tunnel mode wraps the entire IP packet, headers included. It's the standard choice for site-to-site VPNs and remote access. Transport mode encrypts only the payload, which makes it a fit for direct host-to-host communication.

For payload protection, use ESP, not AH. ESP provides confidentiality, integrity, and authentication. AH does not, and it also tends to struggle with NAT. For ESP payloads, use AES-256-GCM ^[1].

Integration Fit

A practical setup is "TLS inside, IPsec outside". Use TLS or mTLS for app-layer traffic, then use IPsec tunnels to protect the network paths underneath for site-to-site links and device networks ^[6]. It's a clean split: TLS handles the app session, while IPsec protects the route the traffic takes.

IPsec fits best in places where TLS can't reach. Think legacy medical devices, imaging modalities, and proprietary clinical protocols with no native TLS support.

IPsec adds per-packet overhead. Because of that, tune MSS and enable IKEv2 NAT traversal to reduce fragmentation ^[6].

Key Management

IPsec uses IKEv2 to negotiate Security Associations (SAs). It also supports perfect forward secrecy and automated rekeying ^[6]. Treat IKEv2 credentials like protected assets. Use IKEv2 rekeying, and keep credentials in a managed KMS or HSM, not in config files or environment variables ^[3].

5. S/MIME

S/MIME encrypts the email message itself, not just the mail connection. That matters because PHI stays protected even if an in-between mail server gets compromised. If email is the delivery path, transport security by itself doesn’t do the whole job. This comes up all the time when hospitals send PHI to billing partners, labs, or consultants by email.

HIPAA/NIST Alignment

Under the January 2025 Security Rule update, encryption is, in practice, required for ePHI in transit. Use FIPS 140-2 or 140-3 validated modules for encryption and signatures. S/MIME is a HIPAA-aligned control for email-based PHI transfers ^[1]. NIST-aligned encryption can also support HIPAA breach-notification safe harbor if ciphertext is exposed ^[4][2].

Security Strength

S/MIME uses X.509 certificates to provide message confidentiality and sender authenticity, which helps meet HIPAA integrity requirements ^[1][2]. It may also encrypt email subject lines, but that depends on the vendor. Because support varies, keep PHI out of subject lines unless you’ve confirmed that subject-line encryption works in that setup ^[4].

Integration Fit

Use S/MIME on top of mandatory TLS 1.2+. If the recipient can’t support S/MIME, send the message through a secure portal ^[1]. In other words, S/MIME fits as a backup layer for partner email workflows, not as a substitute for transport encryption. And if an email or security gateway provider handles ePHI, a Business Associate Agreement (BAA) must be in place ^[1].

There’s a clear trade-off here: tighter privacy, but more certificate management.

Key Management

S/MIME adds certificate overhead, and that part can’t be brushed aside. You need to preserve decrypt capability for retained messages. If keys are rotated without escrow, archived PHI can become unreadable. When that happens, the organization may miss its Designated Record Set retention obligations under HIPAA ^[2].

This affects more than secure transfer. It also affects whether clinical records can still be retrieved later when someone needs them.

These controls create the main trade-offs in email-based third-party transfers, which can impact enterprise risk across the organization.

Security, Compliance, and Trade-Offs: A Side-by-Side Analysis

No single standard fits every healthcare transfer. The earlier sections covered each control on its own. This table shows how they compare when you put them side by side in day-to-day use. Since in-transit encryption is now required, the matrix below looks at the five standards through the lens of compliance, strength, fit, and key management.

In practice, TLS 1.3 is the baseline for web-facing healthcare traffic. It fits APIs, portals, and cloud apps without much friction. AES-256-GCM is a strong pick for bulk files, database columns, and batch transfers because it adds authenticated encryption, not just secrecy.

For public-key cryptography, ECC is usually the better default today. It gives you strong protection with smaller keys, while RSA still has a place when older systems need it. A simple way to think about it: use TLS for the app traffic and IPsec for the tunnel underneath when you need network-level protection between sites or devices.

S/MIME plays a different role. It protects the email message itself, end to end, which means PHI can stay protected even if a mail server is compromised.

For FIPS validation, use FIPS 140-2 or 140-3 validated HSMs to protect master keys, especially for high-sensitivity fields such as SSNs and MRNs ^[1][2]. These differences drive the most common deployment choices. Organizations should also evaluate these standards during third-party vendor risk management to ensure external partners maintain equivalent security.

Pros and Cons by Deployment Scenario

The table below turns those standards into plain deployment choices for vendor APIs, file exchanges, secure email, and clinical network links. To streamline these choices, teams often use standardized questionnaires to verify vendor security controls. It shows what to use, where it fits, and where things tend to go sideways first.

The biggest differences don't usually come from cipher strength. They show up in day-to-day operations.

For web traffic, TLS 1.3 is the default pick. It fits patient portals, EHR API traffic, and payer connections well. But the catch is certificate handling. If teams leave TLS 1.0 or 1.1 turned on, that old baggage can undercut the setup fast.

S/MIME fits a different job. Use it when message-level protection needs to stay in place even if the mail server gets popped. That matters for PHI sent to outside specialists or in doctor-to-patient messages, where the email may pass through systems you don't fully control.

With AES-256-GCM, the math is rarely the weak spot. The problem is usually key handling. If keys in your KMS or HSM are stored poorly, shared too broadly, or rotated badly, the encryption won't save you. Put simply: strong locks don't help much if the keys are left on the front desk.

IPsec can be a good fit when you need to secure whole network paths, like remote imaging centers connecting back to a central data center or device-heavy medical subnets. Its weak point is operational friction. NAT and MTU mismatches can quietly break connectivity, which is the kind of issue that turns into a long night for the network team.

RSA and ECC are often about fit and compatibility. ECC, especially P-256 and P-384, works well for mobile and IoT use because it does the job with less overhead. RSA still helps in older environments, but RSA 1024 is not safe and shouldn't stay in service.

Conclusion

These standards each handle a different piece of the same issue. There isn't one single option that fits every healthcare transfer. The right fit depends on the data flow, the endpoint, and the third party on the other end, whether that's TLS, AES, public-key cryptography, IPsec, or S/MIME.

In day-to-day use, the best pick comes down to four variables. Start with ePHI sensitivity and the transfer model. Then look at interoperability and vendor controls.

Since the January 2025 Security Rule update, encryption in transit is required for covered entities and business associates ^[2][4].

Censinet RiskOps™ can help healthcare organizations verify vendor encryption controls during third-party risk assessments. That's a big deal when those controls need to be checked across vendors, APIs, and clinical partners.

FAQs

When is TLS 1.2 still acceptable?

TLS 1.2 is still acceptable for protecting ePHI in transit as long as it's set up with strong, authenticated cipher suites. TLS 1.3 is the better option because it brings more modern security, but TLS 1.2 still works as a solid baseline for HIPAA and NIST alignment.

To keep things locked down, turn off old protocols like TLS 1.0, TLS 1.1, and SSL. You should also avoid weak ciphers, since they can make downgrade attacks and man-in-the-middle attacks more likely.

Do healthcare organizations need both TLS and AES?

Yes. They do different jobs, and you need both.

TLS protects data in transit, like information moving between services, web browsers, or third-party APIs. AES protects data at rest, like files stored in databases, laptops, or mobile devices.

How should legacy medical devices be secured?

Secure legacy medical devices with strong transmission security, using modern TLS to protect data in transit. Organizations should put TLS 1.3 first or, at minimum, TLS 1.2, and disable old SSL and early TLS versions.

Older hardware often can’t support modern standards out of the box. That’s why healthcare organizations need to spot security gaps and track encryption compliance. They should also use role-based access controls, multi-factor authentication, and regular audit logging.

Related Blog Posts

• Best Practices for End-to-End Encryption in Healthcare
• Encryption in Transit: Compliance for Healthcare IT
• Top Encryption Standards for PHI: Symmetric vs. Asymmetric
• HIPAA Encryption in Transit: Key Protocols