Technical safeguards: what 45 CFR 164.312 actually requires

The technical safeguards are the part of the HIPAA Security Rule that talks about your systems. Not your staff, and not your building. Your software, and the machines it runs on.

There are five standards, and this is the entire list (45 CFR 164.312): access control, audit controls, integrity, person or entity authentication, and transmission security. Underneath them sit seven implementation specifications. Two are required. Five are addressable.

Everything below is read against 45 CFR 164.306, which is what makes any of it legible. If you have not read what addressable actually means, read that first, because five of the seven specifications here are addressable, and addressable does not mean optional.

Access control

45 CFR 164.312(a)(1). Implement technical policies and procedures so that only the persons or software programs granted access rights under information access management (45 CFR 164.308(a)(4)) can reach ePHI. Read that cross-reference carefully: this standard does not decide who should have access, it requires your systems to enforce the decision you already made elsewhere. A beautiful role matrix in a Word document, defeated by one shared login for the whole front desk, is a failure of 164.312(a)(1). Its four implementation specifications, unique user identification and an emergency access procedure (both Required) and automatic logoff and encryption (both Addressable), get their full treatment, and the reason shared logins break every other control, in Access control: enforcing the decision you already made.

Audit controls

45 CFR 164.312(b). Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. Note the two verbs: record and examine. A system that writes logs nobody ever reads has done half of what the sentence says, and the examining half is its own required administrative specification, information system activity review at 45 CFR 164.308(a)(1)(ii)(D). One correction, because you will be told otherwise: the Security Rule does not impose a six year retention period on audit logs. The six year rule at 45 CFR 164.316(b)(2)(i) applies to the documentation you must maintain, not to raw logs, whose retention comes from your own policy. The full treatment, including why this collapses without unique logins and the test of whether you can say who opened a child’s record, is in Audit controls: who opened this child’s record, and when.

Integrity

45 CFR 164.312(c)(1). Implement policies and procedures to protect ePHI from improper alteration or destruction, with one Addressable specification, a mechanism to authenticate ePHI (164.312(c)(2)), to corroborate that ePHI has not been altered or destroyed without authorization. This is the quiet standard almost everyone skips, and in ABA the stakes are not abstract: a session note edited with no trace, or a data collection app whose sync silently drops trials, is a clinical and billing problem before it is ever a HIPAA problem, because the child’s programming is driven by that data. The full treatment, including what version history, edit trails, and a tested restore actually look like, is in Integrity: the standard almost everyone skips.

Person or entity authentication

45 CFR 164.312(d). Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. No implementation specifications: access control governs what an identity is permitted to do, while authentication asks whether the identity is real in the first place. The honest answer to the question everyone asks is that the current Security Rule does not require multi factor authentication, the words do not appear, and the method is left to you under 164.306(b). But read alongside required risk analysis and risk management (164.308(a)(1)(ii)(A) and (B)), it is very difficult in 2026, on an internet facing system holding children’s clinical records, to write the document that explains why you did not do it. The full treatment is in Person or entity authentication: the rule does not name a method.

Transmission security

45 CFR 164.312(e)(1). Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network. Two Addressable implementation specifications sit under it: integrity controls, so transmitted ePHI is not modified without detection (164.312(e)(2)(i)), and encryption, whenever deemed appropriate (164.312(e)(2)(ii)). “Whenever deemed appropriate” is the softest phrase in the Security Rule and reads like permission, but it is not: it is still Addressable, and addressable still routes through 164.306(d)(3), assess it, then implement it or document why not and use an equivalent alternative. Transmission in an ABA clinic is broader than people assume, an emailed progress note, a synced session video, a data app syncing over home wifi, a text about a client, and the full treatment is in Transmission security: PHI in motion is still PHI.

The encryption safe harbor, which nobody told you about

This is the single most useful fact in the technical safeguards, and most clinic owners have never heard it.

The Breach Notification Rule applies only to unsecured PHI. And unsecured has a precise meaning: PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized individuals through a technology or methodology specified by the Secretary in guidance (45 CFR 164.402).

The Secretary specified it. Under the HHS guidance (74 FR 19006, April 27, 2009, and maintained since by the Office for Civil Rights), electronic PHI is rendered secured when it is encrypted consistent with NIST Special Publication 800-111 for data at rest, or with FIPS 140-2 validated processes for data in motion, and the key that would decrypt it has not been breached along with it.

Now follow the consequence.

“MFA is not required by the letter of the rule. In 2026, on an internet facing system holding children's clinical records, it is very difficult to write the document that explains why you did not do it.”

An encrypted clinic tablet is left in a family’s living room and never comes back. You have lost a device. You have not necessarily had a breach of unsecured PHI, and the notification machinery does not fire.

The same tablet, unencrypted, and you are running a four factor risk assessment under 164.402, notifying every affected family within 60 days under 164.404(b), notifying HHS under 164.408, and if it touched more than 500 people in one state, calling the media under 164.406.

Encryption is technically addressable. Given that this is what sits on the other side of the decision, and given that full disk encryption is already built into the tablets and laptops you own and costs nothing to switch on, it is very hard to write an honest document explaining why it was not reasonable and appropriate.

Two caveats, stated plainly, because we are not selling you a false sense of safety:

• The safe harbor protects you from breach notification. It is not a defense to a Security Rule enforcement action. OCR can still conclude your safeguards were inadequate.
• If the key travelled with the device, the passcode was never set, or the password was on a note in the same bag, the data was not secured, and you are back where you started.

What may change

In January 2025, HHS proposed the first substantial rewrite of the Security Rule in over two decades (90 FR 800, published January 6, 2025). For this section, the proposal would make encryption of ePHI at rest and in transit required rather than addressable, would require multi factor authentication, and would eliminate the addressable category across the entire rule.

This is a proposal. It is not law. No final rule has been issued, the comment period closed in March 2025, and the federal regulatory agenda now shows final action pushed to July 2027. It may be finalized, narrowed, delayed again, or withdrawn entirely.

But look at what the proposal is actually made of. It is largely a list of the addressable specifications that an honest risk analysis already concludes are reasonable and appropriate. A clinic doing the addressable work properly today is already most of the way there. A clinic that has been treating addressable as optional is standing at the edge of a cliff and calling it a floor.

Where clinics actually fail

None of it is exotic.

Shared logins. No emergency access procedure written down anywhere. Audit logs that exist and are never read. Encryption available on every single device and switched on for none of them.

And underneath all four, the same root cause: nobody wrote the decision down, so there is no decision. There is just a system that was set up once, by whoever set it up, and a hope that nobody asks.

The rule is more flexible than most people fear, and less forgiving than most people hope. It does not tell you which product to buy. It tells you to look honestly at your clinic, decide, and be able to show the decision.