Email encryption is no longer a choice — it is a requirement

Every day, healthcare practices send thousands of emails containing patient names, appointment details, clinical notes, insurance information, and billing records. Every one of those messages is a potential HIPAA violation if it is not properly encrypted. And every one is a potential breach vector if it is intercepted.

The threat is not abstract. Email interception attacks targeting healthcare rose significantly in 2024, with business email compromise (BEC) attacks against medical practices increasing across every provider category. Attackers know that healthcare email is often the weakest link — carrying the most valuable data with the least protection.

276 million Americans had their health data exposed in 2024. A meaningful percentage of those exposures originated from email-related incidents: compromised accounts, misdirected messages, phishing attacks that led to credential theft, and unencrypted transmissions intercepted in transit.

What HIPAA requires for email containing ePHI

The HIPAA Security Rule addresses email encryption under two technical safeguard standards:

Transmission security (45 CFR 164.312(e)(1))

Covered entities and business associates must implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network. The encryption implementation specification (45 CFR 164.312(e)(2)(ii)) requires implementing a mechanism to encrypt ePHI whenever deemed appropriate.

As discussed in our guide on why encryption alone is not enough for compliant email, this is an "addressable" specification — meaning you must implement it or document why an equivalent alternative is reasonable. In practice, there is no equivalent alternative for email transmission. Encryption is the standard.

Access controls (45 CFR 164.312(a)(1))

Email systems containing ePHI must implement technical policies and procedures that limit access to authorized persons. This means unique user identification, emergency access procedures, automatic logoff, and encryption of data at rest.

The practical standard

OCR's enforcement actions have made the practical standard clear: if your practice transmits ePHI via email, that email must be encrypted in transit and at rest, with access controls, audit logging, and a BAA with every entity that handles the data. The 2025 HIPAA Security Rule amendments reinforce this expectation by moving several "addressable" specifications toward required status.

Types of email encryption

Not all encryption is created equal. Understanding the differences matters for both compliance and operational planning.

TLS (Transport Layer Security)

What it does: Encrypts the connection between email servers during transmission. If both the sending and receiving mail servers support TLS, the message content is encrypted while in transit between them.

Limitations: TLS protects the pipe, not the message. Once the message reaches the destination server, it is stored in whatever state that server uses (which may or may not be encrypted at rest). TLS also requires both parties to support it — and many email systems silently fall back to unencrypted transmission if the receiving server does not support TLS.

Best for: Baseline encryption for all outbound email. Should be configured as mandatory (no fallback to plaintext) for any message that might contain PHI.

S/MIME (Secure/Multipurpose Internet Mail Extensions)

What it does: Provides end-to-end encryption and digital signing of email messages. The message is encrypted on the sender's device and can only be decrypted by the intended recipient's device using their private key.

Limitations: Requires certificate management — both sender and recipient must have S/MIME certificates installed. This creates significant administrative overhead and is impractical for patient-facing communication where you cannot control the recipient's email configuration.

Best for: Provider-to-provider communication where both parties have managed email systems and can exchange certificates.

Portal-based encryption

What it does: Instead of sending the actual message content via email, the practice sends a notification with a link to a secure web portal. The recipient clicks the link, authenticates, and reads the message in an encrypted environment.

Limitations: Adds friction for the recipient. They must visit a website and log in to read every message. Adoption rates for portal-based email are lower than direct delivery because of this extra step.

Best for: Sending sensitive clinical information to patients or external parties where end-to-end encryption is required and you cannot control the recipient's email system.

Automatic outbound encryption gateways

What it does: An intermediary service (Paubox, Virtru, LuxSci, Zix) sits between your email system and the internet. It automatically encrypts all outbound email without requiring the sender to take any additional action. Messages arrive in the recipient's inbox like normal email — no portal, no extra clicks.

Limitations: Requires a subscription and integration with your email system. The recipient's experience depends on the gateway provider's capabilities.

Best for: Practices that want encryption without workflow disruption. This is the approach that achieves the highest compliance rates because it removes the human decision from the process.

Implementation without workflow disruption

The number one reason practices cite for not implementing email encryption is workflow disruption. Here is how to deploy encryption without breaking your team's productivity:

Step 1: Inventory your email PHI

Before changing anything, understand what you are protecting. Use the ePHI data flow mapper to trace where patient data moves through your email system. Common PHI in email includes:

• Appointment confirmations with patient names and dates
• Clinical notes or summaries sent to referring providers
• Insurance verification details
• Billing statements and collection correspondence
• Patient inquiries containing health information
• Lab results or imaging reports

Step 2: Choose the right encryption for each use case

Different communication types warrant different encryption approaches:

| Communication type | Recommended encryption | Why | |---|---|---| | Internal staff email | TLS (enforced) + at-rest encryption | Controlled environment, both sides managed | | Provider-to-provider referrals | TLS + S/MIME or gateway encryption | High-sensitivity clinical content | | Patient communication | Portal messaging (EHR) or gateway encryption | Uncontrolled recipient environment | | Billing and insurance | Gateway encryption or portal-based | Contains financial and health identifiers |

Step 3: Enforce TLS and eliminate plaintext fallback

Configure your email system to require TLS for all outbound messages. In Google Workspace, this is done through compliance routing rules. In Microsoft 365, it is configured through mail flow rules. Set the system to reject delivery — not fall back to plaintext — when the receiving server does not support TLS.

Step 4: Deploy a gateway (if applicable)

For practices sending PHI-containing email to external recipients regularly, an automatic encryption gateway provides the best combination of security and usability. Setup is typically completed in one to two hours and requires no changes to staff workflow.

Step 5: Train on the process, not the theory

Staff do not need to understand how TLS handshakes work. They need to know: "If you are sending patient information to an external email address, use this process." Keep training practical and scenario-based.

BAA requirements for major email providers

If your email system handles PHI, your email provider is a business associate and needs a BAA:

• Google Workspace (Business, Enterprise, Education) — BAA available, must be accepted by admin before PHI is stored. Free Gmail accounts are not eligible.
• Microsoft 365 (Business, Enterprise) — BAA available through the Microsoft Trust Center. Free Outlook.com accounts are not eligible.
• Apple iCloud Mail — Apple does not offer a BAA for iCloud Mail. It cannot be used for PHI.
• Yahoo Mail, AOL, other free providers — No BAA available. Not HIPAA compliant under any configuration.

Having a BAA with your email provider does not automatically extend to plugins, add-ons, or third-party integrations connected to your email account. Each integration that can access email content containing PHI requires its own BAA.

The cost of inaction vs. the cost of implementation

The math is not close:

• Encryption gateway subscription: $5-$15 per user per month
• Average healthcare breach cost: $9.8 million
• OCR penalty per unencrypted email violation: $141 to $71,162 per violation (2024 inflation-adjusted)

For a 10-person practice, email encryption costs $600-$1,800 per year. A single email-related breach investigation — even without enforcement action — will cost more than a decade of encryption.

The free risk assessment evaluates your email security alongside every other system in your practice. It takes five minutes and identifies exactly where your communication channels are exposed.

Email encryption is not a future consideration. It is a present requirement. The practices that implement it now will be the ones still operating when the next breach cycle hits.