Navigating the 2026 HIPAA Security Rule Changes

HIPAA’s Security Rule changes so little that it’s easy to set your compliance strategy on autopilot and let it coast. However, one of the rare changes to these requirements is happening soon. 

What does soon mean? It’s hard to say—but industry experts believe the changes will take effect in late 2026 or early 2027 because some key milestones have been completed that indicate a final rule publication is coming. While that seems far off, in the world of business that’s right around the corner. 

And these aren’t minor changes. They’re significant and may require a great deal of work, especially if you take advantage of HIPAA’s many “optional” requirements and exceptions. What does significant mean? Think mandatory encryption, required multifactor authentication, and the elimination of the long-standing "addressable" safeguard category that many organizations lean on to avoid implementing certain controls. 

This article walks through 10 of the most important proposed changes, what they mean in plain terms, and what your organization may need to do to remain compliant once the updated final rule takes effect. 

1. The End of "Addressable" Safeguards 

The HIPAA Security Rule has always divided its implementation specifications into two categories: "required" and "addressable." 

• Required specifications must be implemented.

• Addressable specifications give organizations flexibility. They can choose not to implement a control as written, as long as they document why an alternative approach sufficiently mitigates the risk or why the specification is not reasonable and appropriate for their environment. 

Today: In practice, the addressable designation has become a significant loophole. Many organizations use it to defer controls like MFA, encryption, and automatic logoff, sometimes with legitimate justification. 

Proposed: OCR would eliminate the required versus addressable distinction. Under the proposed rule, all implementation specifications become required, with only limited, narrowly defined exceptions. This represents a fundamental shift for organizations that heavily rely on the addressable category to justify gaps in their security program. It’s likely that the days of documenting your way around a control are nearing their end. 

2. Multifactor Authentication (MFA) 

Multifactor authentication (MFA) continues to spread across all industries as a baseline requirement—requiring users to verify their identity using at least two distinct factors before gaining access to a system. Studies show that MFA is one of the most effective controls available for preventing unauthorized access to systems containing sensitive data. 

Today: Under the current HIPAA Security Rule, unique user identification is required, meaning every user must have their own login credentials. But MFA falls under the addressable category. Organizations are expected to implement MFA if it is reasonable and appropriate for their environment, but they can document an alternative approach if they believe it sufficiently addresses the risk. 

Proposed: OCR would require MFA across all systems, with limited exceptions. This moves MFA from a best practice and a risk-based decision to a baseline compliance requirement. For organizations that have not yet broadly deployed MFA, this represents one of the most significant changes in the proposed rule. Implementing MFA across clinical systems, EHRs, remote access tools, email, and administrative platforms takes time, planning, and vendor coordination. 

3. Encryption at Rest and in Transit 

Encryption has also become a baseline standard across many industries and compliance frameworks, both at rest for data stored on devices, servers, and in the cloud, and in transit when data moves across networks such as with emails, file transfers, or API calls between systems. 

Today: Surprisingly, the current HIPAA Security Rule does not explicitly mandate encryption. Instead, it’s an addressable safeguard under both access control and transmission security specifications. Organizations evaluate whether encryption is reasonable and appropriate—and many of those organizations document alternatives. 

Proposed: OCR would require encryption of ePHI both at rest and in transit, with limited exceptions. This closes one of the most consequential gaps in the current HIPAA Security Rule framework. For healthcare organizations running legacy systems, older hardware, or applications that do not natively support encryption, this change will require meaningful investment. It also has implications for backup systems, portable devices, and any third-party platforms that store or transmit ePHI. 

4. Asset Inventory and Network Mapping 

A technology asset inventory is a documented list of all hardware, software, and systems in your environment. A network map shows how those assets connect and how ePHI flows through them. Together, they give an organization visibility into where sensitive data lives and how it moves. 

Today: The current HIPAA Security Rule does not explicitly require a continuously maintained technology asset inventory or network map. In practice, this means many organizations have a spreadsheet last updated during their most recent compliance review, or a network diagram that reflects what their environment looked like two years ago. We often find that the gap between an organization’s documented environment and their actual environment is substantial. 

Proposed: OCR would require a technology asset inventory and network map updated automatically or at frequent intervals, specifically showing how ePHI moves through your systems. The principle behind this change is simple: you cannot secure what you cannot see. If you do not know which systems touch ePHI, you cannot apply appropriate controls to them, and you cannot accurately assess your risk. 

5. A More Rigorous Risk Analysis 

A Security Risk Analysis (SRA) is the foundational requirement of the HIPAA Security Rule—identifying threats and vulnerabilities to ePHI, assessing the likelihood and impact of those threats, and using that assessment to drive your security program. OCR has consistently cited failure to conduct an adequate risk analysis as one of the most common HIPAA violations. 

Today: The current rule requires a risk analysis but provides significant flexibility in how it’s conducted. OCR has published guidance on what a thorough risk analysis looks like, but the rule itself uses broad language and emphasizes a "flexibility of approach" framework. In practice, this has led to wide variation in risk analysis quality across healthcare organizations. 

Proposed: Organizations would need to create a more detailed, written risk analysis with explicit required elements, including assigning specific risk levels to identified threats and vulnerabilities. This shifts the risk analysis from a general assessment exercise to a structured, documented methodology with defined outputs. This change will raise the bar significantly for organizations where their current risk analysis process is informal or inconsistently applied. 

6. Expanded Documentation Requirements 

The HIPAA Security Rule requires documentation demonstrating that an organization has implemented all required and addressable security controls—but the quality of that documentation can vary. 

Today: Required documentation varies enormously in depth and consistency across healthcare organizations. Many organizations rely on institutional knowledge where the compliance program lives in the heads of a few key people rather than meticulously written down. Others created documentation many years ago and have not updated it to reflect changes in their environment, technology, or workforce. 

Proposed: OCR would require written documentation of all Security Rule policies, procedures, plans, and analyses—with each element of the security program existing in writing, kept current, and accessible for review. For organizations operating informally, this represents a significant governance shift. It also means that staff turnover (a persistent challenge in healthcare) can no longer quietly erode your compliance posture when people take undocumented knowledge out the door. 

7. Vulnerability Scanning and Penetration Testing

Sometimes, confusion exists about the differences between vulnerability scanning and penetration testing—and their purpose within a security strategy. 

• Vulnerability scanning is an automated process that identifies known weaknesses in your systems such as unpatched software, misconfigured settings, and zero-day threats.

• Penetration testing is when an authorized cyber team actively attempts to identify and exploit vulnerabilities to determine whether they can be used to gain unauthorized access. 

Today: The current HIPAA Security Rule requires organizations to continuously safeguard ePHI and identify security vulnerabilities through ongoing risk analysis, but it does not mandate vulnerability scanning or penetration testing. As a result, many healthcare organizations, particularly smaller ones, conduct these activities infrequently or not at all. 

Proposed: OCR would require vulnerability scanning at least every six months and penetration testing at least annually. This introduces specific, measurable timelines for two activities historically left to organizational discretion—and may lead to unexpected costs and operational preparation. 

8. Network Segmentation 

With network segmentation, organizations divide a computer network into smaller, isolated sections so that traffic between them is controlled and monitored. In a healthcare context, it typically means separating systems that handle ePHI from general office networks, guest Wi-Fi, medical devices, and other systems that do not need access to sensitive data. 

Today: The current HIPAA Security Rule treats network segmentation as a risk-based design decision. Many healthcare organizations, especially smaller practices, operate flat networks where all devices can communicate with each other, creating significant exposure if any one device is compromised. 

Proposed: OCR would explicitly require network segmentation, reflecting hard lessons learned since ransomware began to heavily affect the healthcare industry. When a network is flat and an attacker gains a foothold, they can move laterally across the entire environment, encrypting or exfiltrating data from every connected system. Segmentation limits that lateral movement, contains incidents, and reduces the blast radius of a breach. 

9. Incident Response and Contingency Planning 

Incident response is the process your organization follows when a security incident occurs. It includes detection, containment, remediation, recovery, post-incident review, and contingency planning—with the goal of ensuring your organization can continue operating and recover its systems and data after a disruptive event. 

Today: The current HIPAA Security Rule requires contingency planning and related policies, but the requirements have historically allowed significant flexibility. Organizations are expected to have plans in place, but the rule does not specify recovery timeframes or prescribe the level of detail those plans must contain. 

Proposed: OCR would strengthen incident response and contingency planning requirements to include written procedures for restoring certain critical systems and data within 72 hours. This is a significant shift from flexible planning to time-bound recovery obligations. A 72-hour recovery window requires organizations to know exactly which systems are critical, establish and test backup and restoration procedures, and put the infrastructure in place to actually meet that timeline. 

10. Annual Compliance Audits and Stronger Vendor Accountability 

Compliance audits involve formal reviews of an organization's security program to assess whether required controls are in place and operating effectively. Vendors that handle an organization’s ePHI must also maintain appropriate safeguards. 

Today: The current HIPAA Security Rule requires business associate agreements (BAAs) but not annual compliance audits or independent verification of vendor controls. In practice, vendor oversight is often a paperwork exercise: get a signed BAA, file it, and assume the vendor is handling their obligations. 

Proposed: OCR would require organizations to conduct compliance audits at least annually. More significantly, third-party vendors would be required to annually verify, through written analysis and expert certification, that required safeguards are in place. This shifts vendor oversight from paperwork to evidence. This means signed BAAs will no longer be sufficient on their own. For organizations with large vendor ecosystems, this change will require a more systematic approach to vendor management than most currently have in place. 

Common Questions about HIPAA’s 2026 Rule Changes 

When do the HIPAA Security Rule changes take effect? 

The proposed changes are expected to be finalized and take effect in late 2026 or early 2027, although the exact timeline depends on when OCR publishes the final rule. 

Are these changes final? 

No. At the time of this writing, the proposed changes have not been finalized. However, OCR has signaled these as major upgrades, and the direction of the rule is clear. 

What’s changing with "required" and "addressable" safeguards? 

Required safeguards must be implemented as written. Addressable safeguards, which are going away, give organizations flexibility to implement an alternative measure or document why the specification is not reasonable and appropriate for their environment. 

What’s changing with encryption? 

Under the current rule, encryption is listed as an addressable safeguard, meaning organizations can choose not to implement it if they document an alternative approach. Under the new rule, encryption for data at rest and in transit will be mandatory. 

What’s changing with MFA? 

MFA falls under the addressable category in the current rule. The proposed rule would make MFA a required control across all systems, with limited exceptions. 

How often would penetration testing and vulnerability scanning be required under the proposed rule? 

Penetration testing at least annually. Vulnerability scanning would be required at least every six months. 

What does the proposed 72-hour recovery requirement mean for my organization? 

It means you would need written procedures and tested capabilities to restore certain critical systems and data within 72 hours of a disruptive incident. 

What are the proposed changes for vendor management? 

Third-party vendors that handle ePHI would be required to annually verify, through written analysis and expert certification, that required safeguards are in place. A signed business associate agreement alone would no longer be sufficient. 

What should my organization do right now? 

Start with an honest assessment of where your current compliance program stands relative to the proposed changes. Identify gaps, prioritize gaps based on risk, and begin closing those gaps before the final rule takes effect. 

Is HIPAA compliance a one-time project or an ongoing program? 

It is an ongoing program. The proposed changes reinforce this by requiring annual audits, frequent vulnerability scanning, regularly updated asset inventories, and continuous documentation. Organizations that treat compliance as a periodic project will struggle to meet the new requirements. 

HIPAA Compliance: Not a DIY Project 

As you read through these 10 proposed changes, a few things start to become clear. 

1. The proposed rule shifts HIPAA compliance from a flexible, principles-based framework toward a more prescriptive, evidence-based one. The days of documenting your way around a control or relying on institutional knowledge to satisfy an auditor are ending.

2. The cumulative scope of these changes is substantial. MFA deployment, encryption implementation, network segmentation, penetration testing programs, asset inventory systems, tightened vendor oversight, and 72-hour recovery procedures are not items you can knock out in a weekend.

3. The organizations that will struggle most when the final rule takes effect are the ones that wait. Compliance gaps do not close themselves. When OCR enforcement activity increases, as it historically does following major rule changes, the organizations without documented, operational programs are the ones that face penalties. 

HIPAA compliance requires expertise across cybersecurity, healthcare operations, regulatory interpretation, and vendor management. Most healthcare organizations do not have all that expertise in-house. Attempting to build and maintain a compliant program without that expertise is not just difficult. It is genuinely risky. 

The organizations that navigate these changes successfully will be the ones that treat compliance as an ongoing program, not a periodic project, and that have access to the right expertise to keep that program current as the regulatory landscape continues to evolve. If your organization does not have that infrastructure in place today, now is the time to build it. 

Need help? Reach out to us today. 

TL;DR 

The HHS Office for Civil Rights (OCR) has proposed the most significant overhaul of the HIPAA Security Rule since it was first enacted. Key changes include eliminating the "addressable vs. required" distinction, mandating MFA and encryption, requiring continuous asset inventories, and setting specific timelines for vulnerability scanning, penetration testing, and incident recovery. While the final rule is not yet published, healthcare organizations that wait to act risk scrambling to close major gaps under deadline pressure. Now is the time to assess where you stand. 

Important Disclaimer: All proposed changes discussed in this post are not yet final. The Health and Human Services (HHS) Office for Civil Rights (OCR) has signaled these as major upgrades, but the final rule language may differ. That said, the direction is clear, and the gap between where most organizations sit today and where the rule will head is real. Waiting for OCR’s finalization before beginning to take action is a huge risk.