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 for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights as specified in 45 CFR 164.308(a)(4).

Read that cross-reference carefully, because it is the whole shape of the thing. This standard does not decide who should have access to what. That decision happens elsewhere, in the administrative safeguards, under information access management. What 164.312(a)(1) requires is that your systems actually enforce the decision you already made.

Which means a clinic can do the thinking and still fail the standard. A beautiful role matrix in a Word document, and one shared login for the whole front desk, is a failure of 164.312(a)(1). The decision existed. The system did not know about it.

Unique user identification (Required, 164.312(a)(2)(i))

Assign a unique name and/or number for identifying and tracking user identity.

Required. No assessment, no alternative, no judgment call. Every person gets their own credential.

The shared front desk login, the clinic@ email that four people use, the supervisor password on a sticky note inside the drawer: these are not risk decisions you are entitled to make. They are the one thing in the technical safeguards with no flexibility at all.

And notice the second half of the sentence: identifying and tracking. Unique identities exist so that activity can be attributed to a human being. An audit log that says the front desk account opened forty records tells you nothing at all, which is why this specification and the next standard are really one idea.

Emergency access procedure (Required, 164.312(a)(2)(ii))

Establish, and implement as needed, procedures for obtaining necessary ePHI during an emergency.

This is the forgotten one, and it is required.

Your practice management system is down. Or the one person with administrator rights is on a plane. A clinician needs the treatment plan for a child in crisis. What happens?

There is an answer, and the rule says it must be written down and workable. This is sometimes called a break-glass procedure. It costs an afternoon to write. It is required, it is almost never done, and it is the cheapest gap on this page to close.

Automatic logoff (Addressable, 164.312(a)(2)(iii))

Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.

Addressable, so you assess it. Then look at where your sessions actually happen: a family’s living room, a school hallway, a clinic room with siblings in it. An unattended unlocked tablet in any of those places is a disclosure waiting to be made by a four year old with fast hands.

This one nearly always ends in yes.

Encryption and decryption (Addressable, 164.312(a)(2)(iv))

Implement a mechanism to encrypt and decrypt ePHI.

Addressable, and the most consequential addressable specification in the entire rule. It gets its own section below, because the reason to do it is not the one most people have been given.

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.

No implementation specifications. That does not make this standard soft. It makes it a standard you must meet with no menu to choose from.

Note the two verbs. Record and examine. A system that writes logs nobody ever reads has done half of what the sentence says. The examining half also lives next door as a required administrative specification: information system activity review, at 45 CFR 164.308(a)(1)(ii)(D), which requires you to regularly review records of information system activity such as audit logs, access reports, and security incident tracking reports.

What the rule does not say is just as important. It does not tell you what to log, how much detail to capture, or how long to keep it. That silence is 164.306(b) flexibility, and it means the answer is yours to choose and yours to defend.

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 the rule requires you to maintain, which includes the record of the activity reviews you performed. Your log retention comes from your own policy. Which means OCR will hold you to the policy you wrote, so write one you actually follow.

In an ABA clinic the question audit controls exist to answer is simple: who opened this child’s record, and when? With BCBAs supervising across cases and RBTs rotating between clients, unexplained access is the exact thing you are looking for. If you cannot answer that question, you do not have audit controls. You have storage.

Integrity

45 CFR 164.312(c)(1). Implement policies and procedures to protect ePHI from improper alteration or destruction.

Mechanism to authenticate ePHI (Addressable, 164.312(c)(2)). Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.

This is the quiet standard, and almost everyone skips it, because privacy talk is all about keeping data secret and this one is about keeping data right.

A session note edited after the fact with no trace. A data collection app whose sync silently drops trials. A backup that restores last month’s version over this month’s. Those are integrity failures, and in ABA they are not only compliance failures. The child’s programming is driven by that data. A number that quietly changed is a clinical problem and a billing problem before it is ever a HIPAA problem.

In practice: version history, an edit trail that records who changed what and what it was before, integrity checks on backups, and a restore you have actually performed rather than assumed.

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. Another standard with no menu.

Access control governs what an identity is permitted to do. Authentication asks whether the identity is real in the first place.

Here is the honest answer to the question everyone asks. The current Security Rule does not require multi factor authentication. The words do not appear. It requires you to verify that a person is who they claim to be, and it leaves the method to you under the flexibility of 164.306(b).

But that sentence does not end where people want it to end. Read it alongside risk analysis and risk management, both required, at 45 CFR 164.308(a)(1)(ii)(A) and (B). If your risk analysis identifies stolen credentials as a likely threat, and it will, because phishing is how a large share of healthcare intrusions begin, then risk management obligates you to reduce that risk to a reasonable and appropriate level.

So: 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. Those are different statements, and we are not going to blur them for you.

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.

“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.”

Integrity controls (Addressable, 164.312(e)(2)(i)). Ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of.

Encryption (Addressable, 164.312(e)(2)(ii)). Implement a mechanism to encrypt ePHI whenever deemed appropriate.

“Whenever deemed appropriate” is the softest phrase in the Security Rule, and it has probably caused more unencrypted email than any other five words in American health law, because it reads like permission.

It is not permission. It is still an addressable specification, and addressable still routes through 164.306(d)(3): assess it, then either implement it or document why it is not reasonable and appropriate and implement an equivalent alternative. “We deemed it not appropriate” is a sentence that requires a document behind it.

What counts as transmission in an ABA clinic is broader than people assume. Emailing a progress note to a parent. Moving a session video off a phone into cloud storage. A data collection app syncing over a family’s home wifi, or over the open wifi at the coffee shop between sessions. Texting a colleague about a client. All of that is ePHI travelling over an electronic communications network, whether or not it felt like it at the time.

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.

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.