HIPAA Encryption Requirements: At Rest, In Transit and Key Management
HIPAA encryption requirements are addressable, not required, but that technical distinction rarely matters in practice. Under the Breach Notification Rule, ePHI encrypted according to HHS guidance is not considered unsecured, so a lost laptop or stolen database may not trigger breach notification if keys remain protected. That safe harbor makes encryption functionally essential and helps justify budget. This guide covers at-rest and in-transit options, key management, NIST references and a decision guide by data type. Get an encryption review for your systems.
Is Encryption Required by HIPAA?
Is encryption required by HIPAA is one of the most searched compliance questions, and the precise answer matters. Encryption at rest, under 164.312(a)(2)(iv), and encryption in transit, under 164.312(e)(2)(ii), are both addressable specifications. Organizations must assess them, then implement encryption, an equivalent alternative or documented reasoning. Our HIPAA compliance guide explains the wider rule, while this page focuses on practical encryption decisions for software teams. The detailed answer is below.
Addressable, Not Optional
Addressable specifications must be assessed and documented. For almost every modern system handling ePHI, encryption is reasonable and appropriate, so skipping it without strong documented justification is rarely defensible during investigations.
The Breach Notification Safe Harbor
HHS guidance states that ePHI encrypted consistent with NIST standards, with uncompromised keys, is not unsecured PHI. Incidents involving properly encrypted data may therefore avoid breach notification obligations entirely. That protection is valuable.
Why Equivalent Alternatives Are Rare
Few alternatives provide the same protection as encryption for stored or transmitted data. Physical security or access controls alone do not protect data on stolen devices, copied backups or intercepted traffic.
Proposed Rule Changes
HHS proposed Security Rule updates in January 2025 that would make encryption requirements stricter. Check the current rulemaking status before finalizing plans, while treating encryption as expected practice regardless of the outcome.
Documenting Encryption Decisions
Record what is encrypted, which methods and standards are used, how keys are managed and any exceptions. This documentation supports audits, customer security reviews and breach risk assessments after incidents.
Encryption at Rest: Disk, Database and Field-Level
PHI encryption at rest comes in layers, and each layer protects against different threats. Disk encryption protects against stolen hardware, database encryption protects data files and backups, and field-level encryption protects specific sensitive values even from users with database access. Relying only on cloud disk encryption is a weak position, because anyone with application or database access still sees plaintext data. Stronger designs combine layers based on data sensitivity and risk.
Full-Disk and Volume Encryption
Disk encryption protects data if devices, drives or cloud volumes are stolen or improperly disposed of. It is essential for laptops and mobile devices, but provides no protection against users with system access.
Why Cloud Disk Encryption Alone Is Weak
Cloud providers encrypt storage by default, but data is decrypted automatically for anyone with access to running systems. Compromised applications, credentials or database accounts expose plaintext despite disk-level encryption being enabled.
Database Encryption
Transparent database encryption protects data files, logs and backups. It helps when database files or backups are copied, but authorized database users and application accounts still see decrypted data during normal queries.
Field-Level Encryption
Encrypting specific fields, such as Social Security numbers, diagnoses or notes, protects them even from database administrators. It adds development complexity, including search limitations, so apply it to the most sensitive fields.
Backups, Exports and Snapshots
Encrypt every copy of ePHI, including backups, database snapshots, CSV exports and analytics extracts. Copies are frequently less protected than primary systems and are common sources of breaches and exposures.
Key Management and NIST References
Encryption is only as strong as key management. If keys are stored beside encrypted data, shared widely or never rotated, encryption provides limited real protection. HHS guidance on the breach safe harbor refers to NIST publications, including SP 800-111 for storage encryption and SP 800-52 for TLS. Many organizations also use FIPS 140 validated cryptographic modules. Our HIPAA software development checklist includes key management tasks for development teams. The core practices are listed below.
Use Managed Key Services
Store keys in managed services such as AWS KMS, Azure Key Vault or hardware security modules. Managed services provide access control, logging, rotation and protection that application-stored keys cannot match.
Separate Keys From Data
Never store encryption keys in the same database, file system or code repository as encrypted data. Separation ensures attackers who copy data do not automatically obtain the keys needed to decrypt it.
Rotate Keys Regularly
Rotate keys on a defined schedule and immediately after suspected compromise or staff changes. Envelope encryption, using data keys protected by master keys, makes rotation practical without re-encrypting everything constantly.
Restrict and Log Key Access
Grant key access only to services and people that need it, and log every key use. Unusual key access patterns can reveal compromised applications or insider misuse early. Review access logs monthly.
Follow NIST Guidance
Align encryption choices with NIST publications referenced by HHS, including SP 800-111 for data at rest and SP 800-52 for TLS, and document which standards each system follows. Update choices as guidance evolves.
Encryption Decision Guide by Data Type
Different data types need different encryption approaches. A practical decision guide helps teams apply consistent protection without over-engineering low-risk data or under-protecting sensitive records. The guidance below reflects common practice for healthcare software and should be adapted through your risk analysis. Our HIPAA compliant app development guide covers related design choices for mobile and web applications handling ePHI. For the regulatory detail behind each choice, see our HIPAA technical safeguards overview.
Clinical Records and Notes
Use database encryption, encrypted backups and TLS for all access. Consider field-level encryption for highly sensitive notes, such as behavioral health or substance use treatment records requiring extra protection. Limit export rights.
Identifiers and Financial Data
Encrypt Social Security numbers, insurance member IDs and payment details at field level. Tokenize payment card data where possible, and restrict decryption to services that genuinely need plaintext values. Audit every decryption.
Documents and Images
Encrypt stored documents, scanned files and medical images in object storage with managed keys. Use signed, time-limited URLs for access, and never expose storage buckets publicly, even temporarily for testing.
Mobile and Endpoint Data
Encrypt data stored on phones, tablets and laptops using platform encryption, and minimize local storage. Require device passcodes and remote wipe capabilities for devices accessing ePHI in clinical settings. Enforce policies centrally.
Analytics and Research Data
Where possible, de-identify data before analytics use. Our healthcare data anonymization service removes identifiers, reducing risk, while any remaining identifiable datasets stay encrypted with controlled access. Keep keys separate from analytics environments.
Frequently Asked Questions
Is encryption required by HIPAA?
Encryption is addressable under HIPAA, not required. Organizations must assess it and implement encryption, an equivalent alternative, or document why neither applies. In practice, encryption is expected for nearly all systems handling ePHI, because properly encrypted data qualifies for breach notification safe harbor protections.
What encryption standard does HIPAA require?
HIPAA does not name a specific algorithm. HHS breach guidance refers to NIST publications, including SP 800-111 for data at rest and SP 800-52 for TLS in transit. Many organizations use AES-256 for storage, TLS 1.2 or higher for transmission and FIPS 140 validated cryptographic modules.
Does encrypted data count as a HIPAA breach?
If ePHI is encrypted consistent with HHS guidance and the keys were not compromised, it is not considered unsecured PHI. Loss or theft of that data generally does not trigger breach notification. However, organizations should still investigate incidents and document their assessment carefully.
Is cloud disk encryption enough for HIPAA?
Cloud disk encryption helps but is usually not enough alone. Data is decrypted automatically for anyone with access to running systems, so compromised applications or accounts expose plaintext. Combine disk encryption with database encryption, field-level encryption for sensitive fields, strong access controls and managed key services.
How should encryption keys be managed for HIPAA?
Store keys in managed key services or hardware security modules, separate from encrypted data. Restrict access, log every key use, rotate keys regularly and after suspected compromise, and document procedures. Poor key management undermines encryption and may affect whether breach safe harbor protections apply.
Does PHI need to be encrypted in email?
Email containing PHI should be encrypted using secure email services, portals or S/MIME, especially when sent to external parties. Patients may request unencrypted email after being informed of risks. Document those requests, and use encrypted methods for providers, partners and vendors handling PHI.
Want an Encryption Review of Your Systems?
Our integration engineers are ready to help. Free consultation, no obligation.