link rel="stylesheet" href="https://unpkg.com/@phosphor-icons/web@2.1.1/src/regular/style.css"

The HIPAA Security Rule Just Changed

What Healthcare Organizations Need to Know.
Brian Gallagher
President, Koniag Cyber
min. read
June 24, 2026
View on Original Source
min. read

For most of its existence, HIPAA compliance came with a built-in escape hatch.

The Security Rule divided its requirements into two categories: "required" and "addressable." Required meant required. Addressable was more complicated. Technically, it did not mean optional, but the rule allowed organizations to document a reason why a particular safeguard was not "reasonable and appropriate" for their environment and move on. Multi-factor authentication, network segmentation, and encryption at rest were addressable. In practice, many healthcare organizations documented their reasoning, filed it away, and considered the matter closed.

That approach made a certain kind of sense in 2003, when the original Security Rule was published. Healthcare IT environments were simpler. Ransomware was not yet a crisis. The idea of threat actors specifically targeting hospitals to maximize pressure and payout was not yet a mainstream concern.

That was then.

What has changed, and why has it taken this long

Ransomware attacks on hospitals have become so frequent that they barely make headlines anymore. Clearinghouse outages, vendor-targeted attacks, and credential theft through unprotected remote access- the threat landscape that healthcare organizations navigate today looks nothing like the one HIPAA was designed for. In December 2024, HHS published a Notice of Proposed Rulemaking signaling that significant changes were coming. The direction was unmistakable even then: the "addressable" era was ending.

The final rule is now here. And the core change is simple to state, even if the implementation work is anything but: every safeguard is now mandatory. The addressable distinction is gone. You cannot document a reason for skipping MFA. You cannot decide that network segmentation is not "reasonable and appropriate" for your organization. The requirements are requirements.

The other changes are equally significant. Annual penetration testing moves from a risk-based judgment call to a hard requirement. Business continuity plans must demonstrate a tested, documented ability to restore critical systems within 72 hours — not theoretically, but in practice. Encryption of ePHI, both in transit and at rest, is no longer optional under any circumstances.

Why these changes are actually important

It would be easy to read this as regulators adding paperwork. That would miss the point.

The shift from "addressable" to "mandatory" reflects something real about where cyber risk in healthcare has landed. The organizations that treated MFA as optional and network segmentation as a nice-to-have did not do so because they were reckless. They did it because the old framework gave them room to make that call. The new framework removes that room because the cost of those gaps, in breach exposure, patient safety risk, and operational disruption, has proven too high.

Consider what a flat network actually means during a ransomware attack. If your ePHI environment sits on the same network as general office productivity tools, a successful attack on one is effectively an attack on both. Segmentation is not a bureaucratic checkbox — it is the difference between a contained incident and a facility-wide crisis. The same logic applies to MFA. A single service account running without MFA is an entry point. In healthcare environments connected to EHR systems, billing platforms, and imaging tools, that entry point carries significant consequences.

The 72-hour recovery requirement is perhaps the most operationally honest addition. Having backup infrastructure is not the same as being able to recover from it under pressure, within a defined timeframe. The rule is asking organizations to actually test that claim — not just assert it.

What this means for organizations running Microsoft 365

Here is something worth knowing: if your organization runs Microsoft 365 and Azure, you likely already have most of the tools needed to meet these requirements. Microsoft Entra ID, Purview, Defender for Cloud, Intune, Azure Backup, these capabilities exist in your environment. The challenge is not acquiring new technology. It is configuring, enforcing, and documenting what you already have.

That gap between "tool exists in our environment" and "tool is correctly configured and documented for HIPAA compliance" is exactly where organizations get into trouble. Service accounts are running without MFA enforcement. SharePoint and OneDrive with encryption settings that have never been reviewed. DR documentation that references systems from three years ago. These are not exotic failures. They are the norm.

The compliance window is shorter than it looks

The final rule's effective date puts the compliance deadline in late 2026. That sounds like sufficient runway until you map out the actual work: gap assessment, remediation planning, MFA and encryption implementation, network architecture review, penetration testing, tabletop exercises, documentation updates. Done methodically, this is a 6-9 month program. Organizations that wait until fall will be compressing that into weeks.

We have been working with healthcare clients on HIPAA readiness since well before the final rule was published. The organizations that are in the best position right now started their gap assessments early, before they knew exactly what the final rule would say, because the direction was clear enough to act on.

To help healthcare organizations cut through the complexity of what the final rule actually requires and how it maps to a Microsoft 365 environment, we put together a practical guide. It covers the specific requirements, a compliance readiness checklist, real-world examples of what these gaps look like in practice, and a recommended action timeline for the rest of 2026.

If you are a healthcare organization trying to figure out where you stand and what to do next, it is a good starting point.

Koniag Cyber is a Microsoft Cloud Solution Provider with extensive experience supporting healthcare organizations, defense contractors, and GovCon entities. For questions about HIPAA readiness or to schedule a complimentary briefing, contact us at info@koniagcyber.com.

About the resource
What you'll learn
Who is this resource for?
Download The HIPAA Security Rule Just Changed
Download Resource
Thank you and enjoy the resource
View Resource
Oops! Something went wrong while submitting the form.