Top 8 HIPAA Encryption Standards Independent Practices Should Implement

The first SOC 2 Type II report I pulled for a healthcare SaaS audit last cycle contained the sentence "data is encrypted at rest using industry-standard algorithms" as the entire substantive content on encryption — 47 pages of report, one line on the control that determines whether §164.402 safe harbor applies when this vendor's database eventually gets pulled. Let me explain why that sentence is meaningless to anyone actually looking at the box. AES is a family of modes specified in FIPS 197 and operationalized by NIST SP 800-38 series — six commonly deployed modes, four of which I would not let near healthcare data in 2026. ECB encrypts blocks without chaining, so identical plaintext blocks produce identical ciphertext blocks; you can literally see the outline of an encrypted bitmap inside the ciphertext, which Wikipedia famously demonstrates with the Tux penguin. CBC chains but doesn't authenticate, so an attacker who controls the ciphertext can flip bits and the receiving system has no way to know, which is the entire premise of the padding-oracle attacks that ate the early 2010s. GCM and XTS both encrypt and authenticate, the former for streams and the latter for full-disk; one of those two is what you actually want at rest, and the policy ought to say so. The vendor's policy didn't name the mode, the auditor didn't push, the customer renewed regardless, and the eight standards below are the controls I look for when I audit a practice's stack in the order I find the gaps.

HIPAA's Security Rule lists encryption as an "addressable" technical safeguard, which is regulator vocabulary that has confused practices since the rule was finalized in 2003 — the term means the practice must either implement the safeguard or document a reasoned alternative supported by a risk analysis, and in modern healthcare no defensible alternative to encryption exists for PHI at rest or in motion. The reason this single control sits above the others is the Breach Notification Rule safe harbor codified at §164.402, which exempts properly encrypted PHI from the definition of "unsecured PHI" that triggers mandatory notification, and the HHS guidance defining "properly encrypted" points back to NIST SP 800-111 for data at rest and NIST SP 800-52 Rev. 2 for data in transit. The eight standards below are the controls I look for when I audit a practice's stack, ranked by where the protection matters most.

1. AES-256 encryption at rest for all PHI

The baseline. AES-256 (Advanced Encryption Standard, 256-bit keys) is NIST-approved under FIPS 197 and is the minimum acceptable encryption for data at rest under HHS guidance. Apply to every PHI storage system: EHR database, backup volumes, file shares, archive storage.

Configuration trap: The mode matters more than the key length, and the policy needs to name it. Confirm the implementation runs GCM (authenticated encryption, the modern default for streams) or XTS (for full-disk), with keys derived from a vetted KDF and rotated on the schedule documented in NIST SP 800-57 Part 1 Rev. 5 — the reason this matters is that an "AES-256" sticker on a vendor's marketing page tells you nothing about whether the mode underneath is ECB, which leaks structure, or GCM, which doesn't.

2. TLS 1.3 for data in transit

All network transmission of PHI should use TLS 1.3 (or 1.2 with strong cipher suites where 1.3 is unavailable). The 2024 NIST SP 800-52 Rev. 2 update further restricts acceptable configurations.

Configuration trap: TLS 1.0 and 1.1 are no longer acceptable. Confirm every endpoint — including printer servers, fax bridges, and legacy lab integrations — has been upgraded.

3. Full-disk encryption on every endpoint

Laptops, desktops, tablets, mobile devices accessing PHI. BitLocker (Windows), FileVault (macOS), or equivalent for Linux endpoints. Multiple million-dollar OCR settlements have traced back to unencrypted devices — and the safe harbor is the single strongest argument for universal endpoint encryption.

Configuration trap: The setting being available in the OS does not mean the setting is being enforced by the practice's MDM, and the audit will go after the gap between the two. Confirm that BitLocker is enforced via Group Policy or Intune with TPM+PIN protectors and a recovery key escrow process you can actually demonstrate, that FileVault is enabled with the recovery key stored in Jamf or your MDM of choice rather than printed on a sticky note, and that lock-screen timeouts, remote-wipe capability, and the device-and-media policies required under 45 CFR §164.310(d) are written down, signed, and traceable to specific enrolled devices.

4. Database-level encryption (versus disk-level)

Full-disk encryption protects against the threat model of a laptop being stolen out of a car overnight, which is the threat model OCR settlement narratives have trained practices to fear, but it provides exactly zero protection against the much more common modern scenario in which an attacker reaches the database through the application while the disk is unlocked and the OS is decrypting blocks for whoever asks. Database-level encryption is the layer that closes that gap: Transparent Data Encryption on SQL Server, Always Encrypted for the column-level cases where you want the application to never see plaintext at all, pgcrypto with proper key separation on PostgreSQL, and the equivalent on MySQL via InnoDB tablespace encryption keyed against an external KMS. The reason this layer exists is that NIST SP 800-111 distinguishes between storage-device encryption and database-engine encryption for exactly this reason — they protect against different adversaries and you generally want both.

Configuration trap: This is the most-missed encryption control in independent-practice infrastructure, and the failure pattern is consistent across the engagements I see. The EHR vendor will handle TDE internally on SQL Server 2019 — the customer ticks a checkbox on the order form and the vendor delivers it — while the practice's own reporting warehouse, a PostgreSQL instance one engineer stood up on a Tuesday afternoon to feed a Power BI dashboard the practice manager wanted, holds a denormalized copy of the same PHI tables with pgcrypto disabled, no row-level security, and pg_hba.conf set to trust for local connections, which means any process on that host can connect as any role without a password. The encrypted disk underneath does nothing to stop the session that authenticates through trust, and the OCR investigator looking at the post-incident network capture is going to ask why your shadow warehouse held the same data the EHR vendor was paid to protect.

5. Encrypted backups (and verified recovery)

Backups of PHI are themselves PHI under HIPAA, which means everything the regulation requires of your live data applies equally to the snapshot sitting in cold storage, including encryption on the storage layer, encryption on the wire when the backup is shipped, and documented restore testing on a defined cadence with results captured in writing. The reason the restore testing piece matters more than people expect is that I have walked into ransomware response engagements where the practice's backup script had been running nightly for years, producing encrypted artifacts that looked perfect in the storage console, and not one of them could be restored when the production EHR came back as a wall of .locked files — keys had been rotated without re-keying the archive, the catalog database had been corrupted six months prior, the test restore had never actually been attempted end-to-end on a non-production system the way NIST SP 800-34 Rev. 1 contingency planning guidance recommends.

Configuration trap: Cloud backup services often encrypt by default but use vendor-managed keys. For practices with technical capability, customer-managed keys (CMK) provide stronger separation.

6. Email encryption (S/MIME, portal-based, or TLS-enforced)

Patient email containing PHI requires encryption. Three viable approaches: end-to-end encryption (S/MIME with patient certificates — rare in practice), portal-based delivery (Mimecast, Virtru, ZixMail — most common), or TLS enforcement (works only when both ends support it — most fragile). Full breakdown at our HIPAA-compliant email guide.

Configuration trap: Opportunistic TLS — defined in RFC 3207 as the STARTTLS extension that upgrades an SMTP session to TLS when both ends support it and silently falls back to plaintext when they don't — is what most practice email systems are doing by default, and it is not the HIPAA-defensible standard. The reason this fails is that a downgrade is invisible to the sender, so the practice's MTA happily ships PHI in cleartext over the public internet any time the receiving server is misconfigured or under a downgrade attack. Enforced TLS via MTA-STS (RFC 8461), DANE-TLSA (RFC 7672), or a portal that bypasses SMTP routing entirely is the configuration that actually satisfies the HHS guidance.

7. Encrypted messaging (SMS replacement)

Standard SMS is not encrypted end-to-end and is not HIPAA-compliant. Encrypted messaging through a HIPAA-eligible platform (Spruce Health, Klara, OhMD, others — see our Top 7 Patient Communication Tools) is the required replacement for clinical messaging.

Configuration trap: The platform encrypts the channel, but the content traveling through the channel is still authored by humans typing under pressure, and that is where most of the communication breaches I see actually originate. A staff member types "Mrs. Chen's biopsy came back positive, schedule the follow-up oncology referral and remind her about her anticoagulation history" into an encrypted message to a colleague at another practice, the colleague replies by forwarding to a personal Gmail because the encrypted platform's mobile app was slow that morning, and the forward is the breach — the encryption did exactly what it was supposed to do and the failure happened a layer above it. Content discipline policies, training, and DLP scanning at the gateway are what close that gap.

8. Key management — KMS or HSM

An encryption implementation is only as strong as the key management underneath it, and the key management is the place I find the largest gap between what a practice's policy claims and what the system actually does. AWS KMS, Azure Key Vault, Google Cloud KMS, or a FIPS 140-2 Level 3 HSM are the four serious options for storing and rotating data encryption keys in a way that produces the access logging, dual-control, and separation-of-duties evidence that NIST SP 800-57 Part 1 Rev. 5 expects. The reason a managed KMS matters more than its marketing suggests is that the audit log of every key use — every Decrypt API call, every GenerateDataKey request, with caller identity and timestamp — is the artifact that lets you reconstruct what an attacker actually accessed during an incident, which is the question OCR will eventually ask.

Configuration trap: Keys stored in appsettings.json, in a .env file checked into the repository, in a Kubernetes secret base64-encoded with no envelope encryption, or in an environment variable visible to every process running on the host are the configurations I find most often when I audit a small-practice stack — and every one of them fails the standard. The defensible baseline is a centralized KMS or HSM with per-call audit logging, IAM-scoped access for the specific service principal that needs decryption, and a documented rotation cadence that runs automatically rather than relying on a calendar reminder nobody opens.

How to use this list

The practical exercise is to draw the PHI flow map for the practice — every system that creates, stores, transmits, or processes PHI, with arrows showing how data moves between them — and then walk each arrow against the eight controls above, noting which arrow is protected by which standard and which arrow has nothing protecting it at all. The flows that come up empty are the ones where a breach becomes a notifiable event because no safe harbor applies, and the flows that have a control in production but no documentation describing the configuration are the ones where OCR will still cite you on documentary grounds even if the actual cryptography is fine.

The work splits into two tracks that need to happen in parallel:

• Technical verification. Confirm each encryption control is configured the way the policy says it is, not just nominally available — run openssl s_client against your TLS endpoints, query the database for IS_ENCRYPTED on the relevant tables, check the KMS audit log for actual key usage, validate backup restores end-to-end on a non-production host.
• Documentary capture. Write down the standard you're meeting, the configuration achieving it, the verification you ran, and the date — because the OCR investigator who shows up after an incident is going to ask for documentation rather than a live demonstration, and the audit-defensible answer is the one that was already written before they arrived.

Where Patient Protect fits

I built Patient Protect's encryption telemetry around the specific configuration questions I have spent 30 years asking when I audit a stack, because those are the questions an OCR investigator will eventually ask the practice and the answers need to be true on a random Tuesday, not just true on the day the consultant ran the assessment. The platform fingerprints every endpoint to confirm BitLocker or FileVault is enforced through MDM rather than merely available in the OS, runs continuous TLS handshake probes against your published mail and API endpoints to catch the day one of them starts negotiating down to TLS 1.0 because somebody re-enabled a legacy cipher suite to support a fax bridge, watches your KMS audit log for keys that have crossed the rotation interval defined in your written policy, and inventories every database in the PHI path to flag the one a contractor stood up last quarter with pg_hba.conf set to trust for local connections. Plans start at $39/month.

---

Patient Protect monitors encryption across every PHI flow in your stack — endpoints, databases, backups, email, messaging — starting at $39/month. Free HIPAA Risk Assessment inventories your encryption footprint, no account required.