Encryption and the proposed Security Rule update

A recurring surprise for engineers reading the HIPAA Security Rule for the first time: encryption is not required.

Section 164.312(a)(2)(iv) makes encryption and decryption an Addressable implementation specification under access control, and 164.312(e)(2)(ii) makes encryption Addressable under transmission security, with the phrasing "whenever deemed appropriate" [1]. Neither is Required in the technical sense the rule uses.

This does not mean encryption is optional in any practical sense, and the reason is worth understanding rather than memorising.

What Addressable means in this specific case

As covered on Required vs Addressable safeguards, an Addressable specification obliges you to assess it and either implement it or document why it is not reasonable and implement an equivalent alternative.

For encryption, in the current environment, there are few defensible alternatives. Encryption at rest on managed cloud infrastructure is close to free and requires no engineering effort. Transport encryption is the default for anything using HTTPS. It is genuinely difficult to construct an argument that implementing either would not be reasonable and appropriate for an organisation holding clinical data, which means the honest reading is that Addressable here creates a documented-decision obligation rather than a real choice.

Where it does create a real choice is in the harder cases: encrypting individual fields within a database, encrypting data in a legacy system that cannot support it, or encrypting a medical device's local storage where the device predates the capability. Those are places where a documented alternative may well be the right answer, and they are exactly the places where teams tend not to write the decision down.

The proposed change

The Notice of Proposed Rulemaking published in the Federal Register in January 2025 would remove the Required and Addressable distinction for most specifications, making encryption of PHI at rest and in transit mandatory, requiring multi-factor authentication for system access rather than only remote access, and requiring a technology asset inventory and a network map showing how PHI moves through the organisation's systems, reviewed at least every twelve months [2].

Three notes on how to treat this.

It is proposed. As of writing, the regulatory agenda targets 2027 for final action, and the comment period drew several thousand responses. A proposed rule can be substantially changed or never finalised, so describing any of this as a current requirement would be wrong.

The direction is nonetheless clear, and it is the direction the rest of the regulatory world is already moving. Building now in a way that would satisfy the proposal costs little more than building to today's minimum.

And the asset inventory and network map requirement, if it is kept in the final rule, is the one most teams would struggle with. Not because it is technically hard, but because almost nobody currently has an accurate list of where PHI is actually stored. That list is worth building regardless, and it is the first step in the audit process described on where PHI leaks in a working application.

Where encryption actually fails

In practice, the encryption gap in healthcare applications is almost never the primary database. It is encrypted, because the cloud provider encrypts it by default and the console shows a green tick.

The gap is in the copies. Backup snapshots, particularly older ones taken before a policy changed or held in a different account. Read replicas and analytics warehouses, which are frequently outside the main infrastructure. Exports to object storage, where the bucket policy was set once by whoever built the export and never revisited. Search indexes, which often hold denormalised copies of record content. Caches, if records are cached. Message queues holding payloads in transit. And logs, if PHI has ever reached a log line.

That last one is the most common and the least noticed. Error handlers routinely capture full request bodies. When an error occurs on a request containing patient data, the body goes into the error report, and if the error reporting service is third-party, PHI has left your infrastructure entirely, to a vendor who may not have a business associate agreement in place. This is covered further on business associates and third-party services.

Internal transmission counts

Transmission security applies to PHI transmitted over an electronic communications network [1], and teams verify the browser connection and stop.

The transmissions that get missed are internal: service to service inside a cluster, application to database, application to a message broker, batch jobs moving files, and replication between regions. Whether unencrypted traffic on a private network is acceptable is a risk-assessment question with a legitimate answer either way, and it is another decision that needs writing down rather than assuming.

Build so the change is cheap

The practical advice, given a proposed rule that may or may not finalise, is to build so that tightening is a configuration change rather than a project.

Centralise PHI access through a data layer, so field-level encryption can be introduced without touching four hundred call sites. Keep the encryption decision for each store in a decision record next to the code, with an assertion that fails when a store's encryption setting is turned off. Maintain the inventory of where PHI is stored as an artefact kept up to date rather than a document produced for an audit, since that is both the hardest part of the proposal and the thing that makes every other control assessable. And treat MFA on internal tooling as a current expectation rather than a future one, because the argument for leaving it off an admin console that reaches clinical data is weak today regardless of what the rule says.

Doing those four things means that if the proposal finalises broadly as written, your response is a short piece of work rather than a rebuild. If it does not finalise, you have a better-documented, better-instrumented system and have lost nothing.

If you want help building the inventory or the checks, get in touch.