← All posts

Encryption: Encryption in transit and the safe harbor it buys

March 31, 2026 · Ken Armstrong

45 CFR 164.312(e)(2)(ii) covers encryption. In most assessments the control itself is present and the record proving it is not, which is why this requirement produces findings at organizations that are, in practice, doing the work.

What the rule says

Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.

That is the text of 45 CFR 164.312(e)(2)(ii). Read it closely: it describes an outcome to achieve, not a product to buy, which is why two practices of the same size can satisfy it in different ways and both be right.

This is an addressable implementation specification, and addressable does not mean optional. Under 45 CFR 164.306(d)(3) you assess whether the specification is reasonable and appropriate in your environment, and then either implement it or, if implementing it is not reasonable and appropriate, document why and implement an equivalent alternative measure if that is reasonable and appropriate. The documented reasoning is itself part of the requirement, so an undocumented decision to skip it is the finding.

The safe harbor is in the Breach Notification Rule, not the Security Rule. The notification duties in 45 CFR 164.404 through 164.410 apply to a breach of unsecured protected health information, which 45 CFR 164.402 defines as PHI "that is not rendered unusable, unreadable, or indecipherable to unauthorized persons through the use of a technology or methodology specified by the Secretary in the guidance issued under section 13402(h)(2) of Public Law 111-5." Encryption that meets that HHS guidance is what takes intercepted data outside the notification duties.

What this looks like in practice

In an assessment, 45 CFR 164.312(e)(2)(ii) is not one question. It resolves into several, and each one is really asking for different evidence. These are among the questions asked about it:

Does the organization require strong encryption for all sensitive data transmitted over networks, using current protocols and ciphers while disabling deprecated ones, or, where it has determined that encrypting a transmission path is not reasonable and appropriate, documented that determination and implemented an equivalent alternative measure (45 CFR 164.306(d)(3))?
Does the organization require remote workers who access ePHI to use approved encrypted devices and secure encrypted network connections rather than public or unsecured networks, or, where it has determined that this safeguard is not reasonable and appropriate, documented that determination and implemented an equivalent alternative measure (45 CFR 164.306(d)(3))?
Does the organization manage cryptographic keys across their full life, covering how keys are generated, distributed, stored, rotated, and destroyed, or, where it has determined that this safeguard is not reasonable and appropriate, documented that determination and implemented an equivalent alternative measure (45 CFR 164.306(d)(3))?

Ownership usually sits with the IT or security team, though the evidence is often produced by someone else, which is where the trail breaks. A control that works but has no owner tends to stop working the month the person who quietly maintained it changes roles.

Who this applies to

Every covered entity and every business associate, at any size. 45 CFR 164.306(b) allows flexibility of approach, so a two-provider practice and a hospital system may implement this differently and both comply. What flexibility does not allow is skipping the decision: the smaller the organization, the more the written reasoning carries the weight, because there is no scale of operation to make the control self-evident.

Building it, in order

These steps are one way to meet it, drawn from our question bank. Unless a step names a provision, the Security Rule does not require that particular measure: 45 CFR 164.306(b)(1) lets you use any security measures that allow you to reasonably and appropriately implement the standards and implementation specifications, chosen with the factors in 45 CFR 164.306(b)(2).

The sequence below is the order that produces evidence as a by-product rather than as a separate documentation exercise:

Define a standard for encryption in transit specifying minimum protocol versions (such as TLS 1.2 or higher) and approved ciphers and key strengths.
Identify all channels that carry sensitive data, including web traffic, email, file transfer, and remote access. For any channel the organization decides not to encrypt, record the risk-based determination that encryption is not reasonable and appropriate and the equivalent alternative measure implemented instead (45 CFR 164.306(d)(3)).
Configure each channel to enforce the approved protocols and ciphers and to reject deprecated or weak options.
Periodically scan endpoints and services to confirm only approved protocols are negotiated.
Establish a policy requiring remote access to sensitive data only from organization-approved, encrypted devices. Where the organization determines this safeguard is not reasonable and appropriate, record that determination and the equivalent alternative measure implemented, as 45 CFR 164.306(d)(3) provides.
Require connections through an encrypted tunnel (such as a VPN or equivalent zero-trust access control) and prohibit access over public or unsecured networks unless an equivalent alternative safeguard is documented under 45 CFR 164.306(d)(3).

Where else this maps

The questions behind 45 CFR 164.312(e)(2)(ii) also map to HHS 405(d) HICP (2023 Edition) CSP 4, CSP 6 and NIST SP 800-66 Rev. 2 5.3.1, 5.3.5, which are voluntary guidance rather than law; following them does not by itself establish compliance with any law. That matters for scoping: the same evidence can be written once and referenced from each, rather than rewritten per framework.

Evidence an assessor asks for

For this requirement the evidence types that satisfy it are configuration, policy, and procedure. The distinction matters more than it looks: a policy states what you intend to do, a procedure states how, and a record proves it happened on a date. Auditors ask for all three, and a practice that has written the first two often has nothing for the third.

Date every document and keep the superseded versions. 45 CFR 164.316(b)(2)(i) requires the documentation 164.316(b)(1) calls for (the Security Rule policies and procedures, and the written record of any action, activity or assessment the Security Rule requires to be documented) to be retained for six years from the date of its creation or the date when it last was in effect, whichever is later, so a policy you replaced two years ago is still part of the record.

Where this usually goes wrong

The most common failure here is treating addressable as optional. A practice decides the specification does not fit, implements nothing, and writes nothing down. At assessment the answer to "why not" is a verbal explanation, which is not evidence. The second most common failure is the opposite: implementing an alternative that works, and still not recording the reasoning, so the control looks accidental.

What to do about it

Produce the evidence, not the intention. For 45 CFR 164.312(e)(2)(ii) that means a configuration export or screenshot showing the setting live, dated, a signed, dated policy with a named owner and a review date, and a step-by-step procedure someone unfamiliar with the task could follow. If the only evidence is that someone knows how this works, you have a practice and not a record.
Put a name on it. Whoever administers the systems should be recorded as the owner. Where the work is done by someone else, say so in the document: the split between who owns it and who performs it is where the trail usually breaks. A control with no owner stops working the month the person who quietly maintained it changes roles, and nobody notices.
Review it on a fixed date, not when you remember. In our question bank this is weighted Critical: a gap here is raised as a critical finding (a partial answer as high). Put the review on the calendar with an owner, and keep the dated output of each one.
If you decide not to implement it, write the decision down. Addressable is not optional: under 45 CFR 164.306(d)(3) the documented assessment IS part of the requirement, so an undocumented decision to skip it is the finding, and a working alternative with no recorded reasoning looks accidental.

If 45 CFR 164.312(e)(2)(ii) is new to you, the useful first step is not a policy template. It is writing down what you already do, dating it, and naming an owner. That turns an undocumented practice into evidence, and it usually reveals the real gap.

Related requirements

References

45 CFR 164.312(e)(2)(ii), in 45 CFR 164.312 on eCFR. Quoted text verified against the eCFR text current as of 2026-10-06.
The Required and Addressable designations are defined at 45 CFR 164.306(d).
Crosswalk references in this post are the mappings in our question bank, and are not verified against the published text of those standards.
This post describes what a requirement asks for and what evidence documents it. It is not legal advice, and your counsel owns the conclusion. State law may impose additional obligations; HIPAA preempts a State law only where it is contrary to HIPAA (45 CFR 160.202, 160.203).