HIPAA Security Rule changes: what is actually law in 2026

The short answer: as of July 2026, the HIPAA Security Rule changes everyone is writing about are still proposed. HHS published a Notice of Proposed Rulemaking on 6 January 2025, the comment period closed on 7 March 2025, and no final rule has been issued. The regulatory timetable for final action has slipped into 2027. Multi-factor authentication and mandatory encryption are the direction of travel, not current law.

This matters because a striking number of vendor pages and LinkedIn posts now state flatly that "2026 HIPAA updates mandate MFA, AES-256 encryption and asset inventories." That is not accurate, and buying a compliance platform on the strength of a deadline that does not exist is a bad way to spend a budget. Here is what is actually proposed, what is actually enforceable today, and what a sensible healthcare team should do in the gap.

What the proposed rule would change

The NPRM is a genuine rewrite rather than a tidy-up. The single biggest structural change is the removal of the distinction between "required" and "addressable" implementation specifications.

Under the Security Rule as it stands, some safeguards are required and others are addressable, which means you assess whether the safeguard is reasonable and appropriate for your environment and, if it is not, you document why and implement an equivalent alternative. Encryption is the famous example: it has always been addressable, which is why a covered entity can lawfully run without encrypting ePHI at rest provided it reasoned the decision through and wrote it down.

The proposed rule collapses that flexibility. If finalized as drafted, it would make the following explicit requirements:

• Multi-factor authentication for access to systems holding ePHI.
• Encryption of ePHI both at rest and in transit, with the addressable designation removed.
• An asset inventory and a network map covering every system, device and data flow that touches ePHI.
• Defined restoration timelines for bringing critical systems back after an incident.
• Regular compliance audits and stronger verification of business associates' safeguards.

For business associates in particular this is a meaningful lift, because it converts a lot of "we assessed it as not reasonable and appropriate" reasoning into hard obligations.

Where the final rule actually stands

A final rule normally carries its own compliance runway after publication, so even once it lands you will not be expected to have MFA everywhere the following Monday. The practical implication is that anyone selling you urgency against a 2026 deadline is selling you something that has not been written yet.

What is enforceable right now

All of it, under the current rule. This is the part that gets lost in the noise about the rewrite: OCR is actively enforcing the Security Rule as it exists today, and the most commonly cited failure is not a missing encryption key. It is the risk analysis.

The Security Risk Analysis is a required implementation specification at 45 CFR 164.308(a)(1)(ii)(A). It must be accurate, thorough, and current with your actual systems. It is not an annual box to tick, and it is not something you can outsource to a questionnaire your vendor fills in for you. An inadequate or absent risk analysis remains among the most frequently cited deficiencies in OCR enforcement actions, and it is usually the first thing an investigator asks for after a breach report.

The rest of today's obligations have not moved either: Business Associate Agreements with every vendor that touches PHI, workforce training, the administrative, physical and technical safeguards, and the breach notification clock. Individuals must be notified no later than 60 days after discovery of a breach, and breaches affecting 500 or more people go to HHS inside that same window.

So what should you actually do in 2026?

Ignore the invented deadline, and do the work that pays off under either the current rule or the proposed one. Everything on this list is required today and would be required after the rewrite, so none of it is wasted.

• Fix the risk analysis first. It is required now, it is the top enforcement finding, and every other item depends on it. If yours is a spreadsheet from two acquisitions ago, start there.
• Build the asset inventory anyway. You cannot do a defensible risk analysis without knowing every system that touches ePHI. The proposed rule would make the inventory explicit, but you already need it to satisfy the requirement that exists.
• Turn on MFA and encryption. Not because a rule forces you to yet, but because they are the two controls that most reliably prevent the breach that triggers the investigation. Doing them now converts a future compliance scramble into a non-event.
• Get the BAAs in order. Know which vendors touch PHI, whether a signed agreement exists, and when it was last reviewed. This is ordinary vendor risk management work.
• Watch the Federal Register, or have something watch it for you. The final rule will land eventually, and it will carry a compliance runway that starts on publication day, not on the day someone forwards you a newsletter.

The AI question nobody has answered yet

One live issue worth flagging, because it is moving faster than the rule is. Healthcare teams are rapidly adopting AI assistants, scribes and copilots that touch clinical data, and the Security Rule was not drafted with them in mind. A model with broad access to your systems is, functionally, a workforce member with no training record and no offboarding process.

Nothing in HIPAA exempts an AI tool from the safeguards that apply to any other system handling ePHI: it needs to be in your asset inventory, in your risk analysis, and under a BAA if the vendor is a business associate. Teams deploying these tools into clinical environments increasingly put hard limits on what an AI agent is allowed to read and which tools it can call, which is the only practical way to keep an autonomous system inside the boundary your risk analysis actually assessed.

How we help

This article is a snapshot, and the whole point is that snapshots go stale. The final Security Rule will be published on some ordinary Tuesday, and the organizations that find out quickly will have months of advantage over the ones that find out late.

Complianceofficer watches what HHS, OCR and the Federal Register actually publish, checks each change against the policies and controls you already hold, and flags the ones a change just invalidated. Run the compliance scan at the top of this page with Healthcare and HIPAA selected: it returns your obligation register with the last twelve months of movement and the sources linked. The full picture is on our HIPAA compliance software page, and the general engine is described under regulatory change management.