The Industry Fought Back and the Rule Is Still Moving Forward - What the May 2026 Finalization Target Means for Your Organization Right Now

Picture this. You are the sole IT person at a 20-bed Critical Access Hospital. You are running Active Directory, managing an aging EHR, patching workstations when you can, and hoping the backup job finishes before someone calls about a printer. Somewhere in a stack of unread industry newsletters is a mention of proposed changes to the HIPAA Security Rule. You skimmed it once. It looked like a big deal, but big deals come and go in Washington. Maybe this one goes away too.

It is not going away. The Office for Civil Rights (OCR) received 4,745 comments on the proposed rule, many of them sharply critical, and the finalization target has not moved. As of the most recent regulatory agenda, OCR still lists a May 2026 final action date for RIN 0945-AA22. That is not a guarantee, but it is the current benchmark, and it means the clock is already running for organizations that have not started preparing. Most small health care organizations have not.

How We Got Here

On January 6, 2025, OCR published a Notice of Proposed Rulemaking (NPRM) in the Federal Register proposing the first major overhaul of the HIPAA Security Rule since the Omnibus Final Rule of 2013. The comment period closed on March 7, 2025. OCR confirmed it received 4,745 comments, and the volume and tone of those comments made one thing clear: the industry had concerns.

The opposition was real and organized. A coalition of industry associations led by the College of Healthcare Information Management Executives (CHIME) formally petitioned HHS to withdraw the proposed rule, arguing that the scope of the requirements combined with an aggressive compliance timeline would impose unsustainable costs on hospitals and health systems already operating on thin margins. The National Rural Health Association (NRHA) submitted comments specifically emphasizing that the proposed requirements present what it called insurmountable challenges for rural health care providers. Small clinics, Critical Access Hospitals (CAHs), and resource-limited organizations were a recurring theme across the comment period.

Despite that pushback, OCR has kept the rule on its regulatory agenda. The current target for final action remains May 2026. To be clear, this is a regulatory agenda target, not a confirmed publication date. Final rules can slip, and the scope of the final rule may differ from the NPRM based on comment review. But as of this writing, there is no indication that OCR intends to shelve or significantly delay the rulemaking. The current HIPAA Security Rule (45 CFR Part 164, Subpart C) remains fully in effect while OCR works toward finalization.

The Core Shift: The End of "Addressable"

If you have worked in health care IT for any length of time, you know the word "Addressable." You have probably had a conversation that went something like: "We looked at encrypting those workstations, but it was not reasonable for our environment, so we documented why and called it Addressable." That conversation, and the regulatory framework that allowed it, is on its way out.

Under the current Security Rule, implementation specifications fall into two categories: Required and Addressable. This framework is defined in 45 CFR 164.306(d). A Required specification must be implemented. An Addressable specification requires the organization to assess whether the specification is reasonable and appropriate for its environment. If it is not, the organization must document why and implement an equivalent alternative measure, or document why the specification is not applicable. The standard itself must still be met - "Addressable" has never actually meant "optional," a distinction that has been widely misunderstood across the industry for two decades.

The NPRM proposes to eliminate the Addressable designation entirely by revising 45 CFR 164.306. Under the proposed rule, all implementation specifications would become Required, with only specific, limited exceptions. This is not a subtle definitional change. It fundamentally alters how organizations approach compliance across three major sections of the Security Rule.

Consider the practical impact on 45 CFR 164.312 (Technical Safeguards). Today, encryption and decryption of electronic protected health information (ePHI) at rest is an Addressable specification under 164.312(a)(2)(iv). Automatic logoff is Addressable under 164.312(a)(2)(iii). Transmission security encryption is Addressable under 164.312(e)(2)(ii). Integrity controls under 164.312(c)(2) are Addressable. Under the current framework, an organization can assess these specifications, document why full implementation is not reasonable for a particular system or environment, and implement alternative measures or accept the risk with documentation.

Under the proposed rule, that file you have been maintaining - the one that explains why certain workstations are not encrypted, why that legacy clinical application does not support automatic logoff, why that older medical device transmits data without encryption - would no longer satisfy compliance. The specification becomes Required. You implement it or you are out of compliance. Full stop.

The same shift applies across 45 CFR 164.308 (Administrative Safeguards) and 45 CFR 164.310 (Physical Safeguards). Administrative Safeguards currently include Addressable specifications for workforce clearance procedures, termination procedures, security reminders, protection from malicious software, log-in monitoring, and password management, among others. Physical Safeguards include Addressable specifications for facility security plans, access control and validation procedures, maintenance records, and data backup and storage. All of these would become Required under the proposed rule.

The NPRM explicitly acknowledges scalability concerns for small and rural organizations. But acknowledging the concern and providing relief are different things. The proposed rule removes the flexibility mechanism that many smaller organizations have relied on for years. Whether the final rule introduces any alternative compliance pathways for resource-limited entities remains to be seen.

The New Mandates That Will Hit Your Desk First

Beyond eliminating Addressable, the NPRM introduces new requirements that do not exist in the current Security Rule at all. These are the items most likely to create immediate operational impact for health care IT teams, particularly at smaller organizations.

Multi-Factor Authentication (MFA)

The NPRM proposes a mandatory MFA requirement tied to access controls under 164.312(a) and authentication standards under 164.308(a). This is new. The current Security Rule does not mention MFA by name. Under the current rule, person or entity authentication under 164.312(d) is a Required standard, but the specific mechanism is left to the organization. The NPRM changes that by defining MFA as a named requirement and applying it to both user and technology asset access.

For organizations that have already deployed MFA across their environment, this is a non-event. For organizations still running single-factor authentication on EHR portals, remote access, and administrative accounts, this is a significant project. The practical challenge in small health care environments is not the MFA platform itself - Microsoft Entra ID (formerly Azure AD) Conditional Access with Microsoft Authenticator, Duo, or similar solutions are well-established and available at reasonable cost. The challenge is the legacy clinical applications that do not support modern authentication, the shared workstations in clinical areas where workflow disruption is a serious concern, and the medical devices that authenticate with local credentials or no credentials at all.

If you are at a smaller organization, start testing MFA now. Pick a pilot group, ideally your IT and administrative staff, and work through the enrollment process, the user experience, and the exception handling before you are doing it under a compliance deadline.

Encryption at Rest and in Transit

The NPRM elevates encryption from Addressable to Required, both for ePHI at rest under 164.312(a)(2)(iv) and ePHI in transit under 164.312(e). The current rule's flexibility, where an organization could document why encryption was not reasonable and appropriate for a particular system, would be eliminated.

For most modern environments, encryption at rest is straightforward. BitLocker on Windows endpoints, FileVault on Macs, encrypted volumes on servers. The challenge surfaces with legacy systems, older medical devices that store data locally, and clinical applications running on platforms that do not support full-disk encryption without performance degradation or vendor support issues.

Encryption in transit is a similar story. TLS for web-based systems, encrypted email for ePHI in transit, VPN tunnels for site-to-site communication - these are well-understood. But internal network traffic between clinical systems, HL7 interfaces, and medical device communication often runs unencrypted, and retrofitting encryption onto those pathways is not always simple.

Start by identifying every system that stores or transmits ePHI and documenting its current encryption status. That inventory is going to be the foundation for your compliance effort regardless of the final rule text.

Annual Technology Asset Inventory and ePHI Network Mapping

The NPRM proposes a new requirement under 164.308(a)(1) that organizations maintain a technology asset inventory and a network map documenting the movement of ePHI through their electronic information systems. This inventory and map must be reviewed and updated at least annually and whenever the organization's environment or operations change in a way that may affect ePHI.

The current Security Rule already requires a risk analysis under 164.308(a)(1)(ii)(A) that is "accurate and thorough," but it does not prescribe the methodology to this level of specificity. Many organizations conduct risk analyses without a formal, maintained technology asset inventory. The NPRM would change that by making the inventory and network map explicit prerequisites for a compliant risk analysis.

This is where organizations that have been treating asset inventory, risk analysis, and disaster recovery planning as separate exercises may want to rethink their approach. A comprehensive technology asset inventory does not just satisfy the NPRM's proposed inventory requirement - it also feeds directly into your risk analysis and your contingency planning under 164.308(a)(7). Organizations that build these efforts on a shared foundation can advance multiple compliance requirements through a single operational effort instead of running three separate documentation projects that cover the same ground. One recently published framework that takes this integrated approach is ABC HIPAA, which maps configuration items and their dependencies as the basis for both risk analysis and disaster recovery planning simultaneously.

For an 11-bed CAH with 5 servers, 60 workstations, a handful of medical devices, and maybe a few printers and network switches, this is manageable work. For a multi-facility health system, it is a significant ongoing effort. Either way, the time to start building that inventory is now, not when the final rule drops and the compliance clock starts.

Physical Safeguards and Device Controls

The NPRM also strengthens requirements under 164.310 for physical safeguards, including more prescriptive documentation for facility access controls and device and media controls. Several specifications currently classified as Addressable, such as the facility security plan, access control and validation procedures, and maintenance records, would become Required. Organizations will need to demonstrate that physical access to areas containing ePHI systems is controlled, documented, and reviewed, not just that a policy exists on paper.