AegisAI Perspectives · 029
Email encryption is addressable under the HIPAA Security Rule today, so each regulated entity must assess it, then encrypt it or document why it does not.
Not as a flat mandate. The HIPAA Security Rule makes encryption of ePHI in transmission, email included, addressable under 164.312(e)(2)(ii): assess it, then encrypt, or document why not and adopt an equivalent if reasonable28. AegisAI reads each email for what it is trying to do, which is a separate check from encrypting the connection it travels on. Encryption is one item in what email security for healthcare needs to cover.
HHS proposed in January 2025 to require encryption of all ePHI at rest and in transit, with limited exceptions10. That proposal is not final: the OMB website shows final action due in July 202715. This article reads the rule text and is not legal advice.
You run the addressable test in 164.306(d)(3) against email, and you write the result down. The transmission security standard at 164.312(e)(1) requires technical measures that guard against unauthorized access to ePHI sent over an electronic communications network1. Encryption is one specification under it.
List every email path that carries ePHI. Name the outside domains that receive it: referral practices and labs, billing services and payers, and patients. The transmission security standard covers each of these paths.
Read the encryption specification as written. 164.312(e)(2)(ii) says: implement a mechanism to encrypt ePHI whenever deemed appropriate.
Assess it in your environment. For every addressable specification, the covered entity or business associate must assess whether it is a reasonable and appropriate safeguard6.
Implement it if it is reasonable and appropriate. 164.306(d)(3)(ii)(A) leaves no choice once the assessment says yes7.
Document the exception if it is not. Record why encryption is not reasonable and appropriate, and implement an equivalent alternative measure if one is reasonable and appropriate.
Check integrity on the same paths. The integrity controls specification under transmission security is also addressable and asks that transmitted ePHI is not improperly modified without detection4.
Cover the mailbox at rest. Encryption and decryption under access control is a separate addressable specification at 164.312(a)(2)(iv), so assess stored mail as well3.
The table lists one standard and four specifications from 164.312, and only unique user identification is labelled Required. Automatic logoff and encryption and decryption are labelled Addressable5.
| Specification | Section | Label today | What the text asks |
|---|---|---|---|
| Transmission security (standard) | 164.312(e)(1) | Standard | Guard against unauthorized access to ePHI sent over a network |
| Encryption in transmission | 164.312(e)(2)(ii) | Addressable | Encrypt ePHI whenever deemed appropriate |
| Integrity controls | 164.312(e)(2)(i) | Addressable | Detect improper changes to transmitted ePHI |
| Encryption and decryption | 164.312(a)(2)(iv) | Addressable | A mechanism to encrypt and decrypt ePHI |
| Unique user identification | 164.312(a)(2)(i) | Required | One identity per user |
| Proposed encryption rule | Proposed 164.312(b)(2) | Proposed, not in force | Encrypt all ePHI at rest and in transit, limited exceptions |
It names the path and the assessment first, then the decision with its measure. The record answers the two branches of 164.306(d)(3): implement it, or explain why not and substitute.
Illustrative example, figures are fictional. A clinic with 45 staff sends referral letters with ePHI to 14 specialist practices and lab results to about 300 patients a month. Its assessment finds that 12 of the 14 practices accept encrypted connections and that a patient portal can deliver results. The clinic decides encryption is reasonable and appropriate for the 12 practices that accept it, so it must implement it there. For the 2 that cannot, it documents why and sends a portal link instead, keeping ePHI out of the email body. Lab results move to the portal, so no ePHI travels in the patient email at all.
No, encryption is not mandatory under the current rule text, but the decision about it is. HHS itself wrote that, because encryption is addressable today, a regulated entity may comply without encrypting ePHI if encryption is not reasonable and appropriate and certain conditions are met11.
Those conditions are the 164.306(d)(3) record: an assessment with a written reason, plus an equivalent measure where one is reasonable. An organisation with no assessment on file has skipped the step 164.306(d)(3)(i) requires.
For email, the rule requires a transmission security safeguard on every path that carries ePHI, and a documented decision on encryption for each one. The standard at 164.312(e)(1) sets the goal: guard ePHI in transit against unauthorized access. The encryption specification under it is addressable, so the outcome is either encryption or a written reason plus an equivalent.
Stored mail is assessed separately under access control. Integrity of transmitted ePHI is a third addressable item on the same paths. Each one needs its own assessment.
Yes, in practice the distinction matters less than the word suggests, because an addressable label still ends in a duty: implement, or document why not. Unique user identification carries the Required label. An addressable specification must be implemented once your assessment calls it reasonable and appropriate, and otherwise replaced by a documented equivalent.
Encryption in transmission protects ePHI while it travels over a network. A mailbox opened with a phished password reads and sends mail as its owner, over the same encrypted connections. The FBI IC3 received 191,561 phishing and spoofing complaints in 2025, the most of any crime type14.
The account takeover attack chain shows how a stolen login turns into outbound mail. AegisAI reads what each message asks the recipient to do, a check that applies whether or not the connection is encrypted.
No new Security Rule requirements are final in 2026. HHS had planned a May 2026 release of the final rule, but the OMB website now shows final action due in July 2027.
HHS published the proposal in the Federal Register on 6 January 2025 as document 2024-30983, 125 pages, with comments closing on 7 March 20259. Proposed 164.312(b)(2) would require encryption of all ePHI at rest and in transit, with limited exceptions.
OCR received almost 5,000 comments, and the proposal drew criticism from hospitals and health systems as well as industry groups16. HHS put the cost at $9 billion in the first year and $6 billion a year for years two through five17. Until a final rule appears, plan against the addressable text and keep your decision record current.
Track three numbers.
164.312(e)(2)(ii) names no algorithm. It asks for a mechanism to encrypt ePHI whenever deemed appropriate. The algorithm you choose belongs in the documented assessment for each email path.
Neither 164.312(e)(2)(ii) nor 164.306(d)(3) names a product or service. They ask you to assess encryption on each path, implement it where reasonable and appropriate, and document an equivalent where it is not. Choose the method your assessment supports and file that record.
Not as a mandate today. Encryption and decryption under access control is addressable at 164.312(a)(2)(iv). The January 2025 proposal would require encryption of ePHI at rest, with limited exceptions, if it becomes final.
Yes, if your assessment finds it is not reasonable and appropriate. You must then document why and implement an equivalent alternative measure if one is reasonable and appropriate. HHS described this route in its January 2025 proposal.
No. Encryption protects ePHI in transmission. A phished mailbox sends mail as its owner over the same channels. AegisAI reads what each such message asks the recipient to do. Phishing and spoofing led IC3 complaints in 2025, with 191,561 reports, out of 1,008,597 complaints in total.
The OMB website shows final action due in July 2027, a year later than the May 2026 release HHS had planned. Until then, the addressable text in 164.312 applies.
