Top 8 HIPAA Encryption Standards Independent Practices Should Implement

HIPAA's Security Rule lists encryption as an "addressable" technical safeguard — language that has confused practices for decades. Addressable does not mean optional. It means the practice must either implement encryption or document a reasoned alternative; in modern healthcare, no defensible alternative exists.

The reason encryption matters more than any other single control: the Breach Notification Rule safe harbor under §164.402. PHI that is encrypted according to HHS-recognized standards is not considered "unsecured" — and a breach of unsecured PHI is what triggers mandatory notification. Encrypted breaches typically don't.

Below are the eight encryption standards independent practices should implement, 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: AES-256 in some configurations is weaker than others. Confirm the implementation uses GCM or CBC mode with proper key management — not ECB.

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: Encryption enabled is not the same as encryption enforced. Confirm enrollment policies, lock screen requirements, and remote-wipe capability are configured per device. 45 CFR §164.310(d) requires device-and-media policies covering the full lifecycle.

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

Full-disk encryption protects against physical device theft. It does not protect against application-layer breaches where the attacker accesses the database while the disk is unlocked. Database-level encryption (Transparent Data Encryption on SQL Server, Always Encrypted, equivalent on PostgreSQL/MySQL) adds the column-level protection that disk encryption alone misses.

Configuration trap: This is the most-missed encryption control in independent-practice infrastructure. Most EHRs handle it internally, but custom databases or data warehouses often skip it.

5. Encrypted backups (and verified recovery)

Backups of PHI are themselves PHI. Encrypted backup storage, encrypted backup transmission, and — critically — documented restore testing. An encrypted backup that can't be successfully restored isn't a backup.

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 — where the server attempts encryption but falls back to unencrypted — does not satisfy HIPAA. Enforced TLS or portal-based delivery is the defensible standard.

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: Encryption at the platform doesn't excuse content discipline. Staff still type clinical detail into messages; that's where most communication breaches originate.

8. Key management — KMS or HSM

Encryption is only as strong as the key management. AWS KMS, Azure Key Vault, Google Cloud KMS, or hardware security modules (HSMs) provide the rotation, access logging, and separation of duties that meet NIST SP 800-57 recommendations.

Configuration trap: Keys stored in application config files or environment variables fail this standard. Centralized key management with audit logging is the defensible baseline.

How to use this list

Map every PHI flow in the practice to which of these eight controls protects it. The flows that have no encryption control are the breach risk. The flows with encryption controls but no documentation of configuration are the audit risk.

The work is two-fold:

• Technical: Verify each encryption control is actually configured (not just available).
• Documentary: Capture the standard, the configuration, and the verification — because OCR asks for documentation, not for live demonstrations.

Where Patient Protect fits

Patient Protect monitors encryption continuously — endpoint enrollment, configuration drift, expired certificates, key rotation. Documentation-focused compliance platforms generate the policy library covering encryption requirements. Patient Protect adds the active layer — verification that the policy is actually implemented across the device fleet and integrations. The two complement each other. Most practices need both.

---

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.