Does HIPAA Require Encryption? What Healthcare Teams Need to Know

If you are building a healthcare app or evaluating a software vendor, “does HIPAA require encryption” is one of the most important questions to ask. Indeed, the honest answer is more nuanced than most guides admit. Under the current HIPAA Security Rule, encryption is “addressable,” not “required.” Here is what that distinction means and what hipaa encryption requires.

Key takeaways

• Under the current HIPAA Security Rule, encryption is “addressable,” not explicitly required. Organizations can document an equivalent alternative, but that exception almost never applies in practice.
• In practice, encryption is the expected standard for any system handling ePHI. OCR enforcement consistently treats unencrypted ePHI as a compliance failure.
• The 2026 proposed Security Rule update would make encryption fully mandatory with no alternative path. As of September 2026, that rule is proposed but not yet final.
• HIPAA encryption requirements cover two surfaces: data at rest (stored in databases and backups) and data in transit (moving between systems and users).
• Knack Health provides encryption at rest and in transit on every HIPAA plan, built into platform infrastructure, not a configurable add-on.

What does HIPAA actually say about encryption?

Specifically, the HIPAA Security Rule organizes its technical safeguards into two categories: “required” and “addressable.” Required safeguards must be implemented with no exceptions. Addressable safeguards must be implemented unless the organization documents why the safeguard is not reasonable and implements an equivalent alternative instead.

Specifically, encryption falls into the addressable category. Under this framework, the Security Rule requires covered entities to encrypt and decrypt ePHI when reasonable and appropriate. Consequently, organizations that determine encryption is not reasonable must document that conclusion and implement an equivalent alternative.

However, this is where most guides mislead teams. The “addressable” designation does not mean encryption is optional. Instead, it means encryption is the default expectation, with a narrow documented-exception pathway. In practice, for any organization running software that stores or transmits patient data, encryption is almost always the reasonable and appropriate choice. In fact, OCR enforcement bears this out. OCR has taken significant settlement actions and assessed civil monetary penalties over unencrypted devices and systems, regardless of the addressable classification.

For a full breakdown of all three HIPAA safeguard categories, the HIPAA compliance cornerstone covers the complete picture.

What hipaa encryption requires in practice

In practice, HIPAA encryption requirements cover two distinct data surfaces. Both must be addressed. Here is what each covers.

Encryption at rest

Specifically, encryption at rest protects data stored in a database, server, file system, or backup. When ePHI is at rest, it must be protected against unauthorized access even if the physical storage is compromised. The standard approach uses AES-256 encryption, the same standard used by US government agencies for classified data.

Notably, encryption at rest applies to every location where ePHI lives. That includes the primary database, any replicas or backups, archived records, and exported files. For example, generic cloud storage accounts, shared drives, and standard SaaS platforms without HIPAA plans frequently lack infrastructure-level encryption at rest. Consequently, security reviews frequently surface this as a compliance gap.

Encryption in transit

Similarly, encryption in transit protects data as it moves between systems. Specifically, that includes transmissions from a user’s browser to an application, from an application to a database, or between two integrated systems. The standard is TLS 1.2 or higher, which secures the transmission channel so data cannot be intercepted.

Every transmission involving ePHI must be encrypted in transit. That includes form submissions that collect patient data, API calls that send or retrieve records, and integrations where PHI flows. Consequently, an app that encrypts data at rest but transmits it unencrypted has a gap that OCR treats as a violation.

Why both surfaces must be covered

Both surfaces must be covered simultaneously. Specifically, encryption at rest without encryption in transit leaves PHI exposed during every data transmission. Similarly, encryption in transit without encryption at rest leaves PHI exposed at the storage layer. Consequently, a HIPAA-compliant infrastructure must provide both without requiring the organization to configure them separately at the application level.

For more detail on what makes software HIPAA compliant beyond encryption, that guide covers all four technical safeguards and the organizational responsibilities alongside them. Specifically, it covers the BAA requirement, access controls, and record change logs.

The 2026 proposed Security Rule update: what is changing

The current addressable designation for encryption may not remain in place much longer. In January 2025, HHS published a Notice of Proposed Rulemaking that would significantly overhaul the Security Rule. Among the most consequential proposed changes is the reclassification of encryption from addressable to required.

Under the proposed rule, encryption of ePHI at rest and in transit would become a hard requirement. The flexibility that currently exists (the ability to document why encryption is not reasonable) would be eliminated entirely. In other words, there would be no alternative implementation path.

As of September 2026, however, the proposed rule is not yet final. HHS received approximately 4,700 public comments and is still reviewing them. Meanwhile, OCR continues to enforce the current Security Rule. The finalization timeline targets 2027. Once a final rule publishes, covered entities and business associates would have 240 days to comply.

The practical implication for organizations evaluating their hipaa encryption posture now is straightforward. Organizations already running on infrastructure with encryption built in face no additional burden when the rule finalizes. However, organizations storing patient data in unencrypted systems face a significant gap to close within a fixed compliance window. For a full breakdown of each proposed change, the HIPAA Security Rule update guide covers the complete proposal in detail.

Where hipaa encryption requirements apply across your app

Understanding where encryption is required means mapping every place ePHI touches your system. Most gaps occur not at the primary database but at the edges.

Forms and intake

Specifically, every form that collects patient data (intake forms, consent forms, authorization forms) creates a transmission of ePHI. That transmission must be encrypted in transit. Additionally, the data submitted must land in a system that encrypts it at rest. A form that routes submissions to an unencrypted email inbox or a standard spreadsheet fails on both counts.

API integrations

When your app integrates with other systems and ePHI flows through that integration, each API call must be encrypted in transit. Furthermore, any system that stores the data on either side must encrypt it at rest. Each vendor in that chain also needs a signed business associate agreement with your organization.

Backups and exports

Encryption requirements do not stop when data is backed up or exported. Backups containing ePHI must be encrypted. Additionally, exported files containing patient records must also be encrypted or handled through a controlled, access-managed process. This is a common gap. Organizations with compliant primary databases often create unencrypted backup files or export patient lists to standard spreadsheets.

Devices and endpoints

If your team accesses patient records from laptops, tablets, or mobile devices, those devices must encrypt locally stored data. Devices that contain ePHI without device-level encryption create a compliance exposure even when the primary system is fully compliant. This is why OCR has consistently taken enforcement action following lost or stolen devices that contained unencrypted patient data.

For items OCR examines when reviewing a healthcare app, the HIPAA compliance checklist for no-code apps covers each requirement at the implementation level.

What Knack Health provides for hipaa encryption

For healthcare teams building on Knack Health, the encryption layer is part of the platform infrastructure on every HIPAA plan. Teams do not configure it separately.

Encryption at rest

Specifically, Knack Health encrypts all patient data at rest using AES-256. This applies to the primary database, all records, and all backups. Knack builds this into the platform architecture rather than leaving it as a customer-configured option.

Encryption in transit

Knack encrypts all data in transit using TLS, covering every transmission between the user’s browser, the application layer, and Knack’s backend. Every form submission, every API call, and every record read or write goes through an encrypted channel.

No configuration required

For teams building on Knack Health, encryption at rest and in transit is not a setting to enable or a tier to upgrade. Instead, Knack builds it into the infrastructure on every HIPAA plan. Consequently, a clinic administrator building a patient intake system does not need to manage encryption configuration. The platform handles it.

Signed BAA included

Encryption alone does not satisfy HIPAA’s requirements. A signed BAA from the infrastructure vendor is also required. Specifically, Knack Health includes a signed BAA on every HIPAA plan, covering all PHI stored in Knack’s infrastructure. Teams do not need to negotiate it separately. For detail on what a BAA covers and why it is required alongside encryption, the BAA explainer covers the specifics.

Additionally, Knack Health includes role-based access controls at the field level. Knack also logs every PHI access and change automatically. Furthermore, encryption is one of four technical safeguards HIPAA requires. The HIPAA compliance guide for healthcare apps covers how all four work together.