HIPAA Security Rule 2026: What the Update Means

The HIPAA Security Rule is getting its most significant overhaul since the Omnibus Rule of 2013. The Department of Health and Human Services (HHS) Office for Civil Rights issued a Notice of Proposed Rulemaking (NPRM) on December 27, 2024 (published in the Federal Register on January 6, 2025) under docket HHS-OCR-2024-0020 (RIN 0945-AA22) that proposes sweeping changes to how healthcare organizations must protect electronic protected health information (ePHI).

These are not incremental updates. The proposed rule eliminates the distinction between “required” and “addressable” implementation specifications --- a framework that has allowed organizations to document why they chose not to implement certain safeguards. Under the new rule, every specification is required. Full stop.

For healthcare organizations, health IT vendors, and business associates, the proposed changes mean rethinking security programs that may have been built around the flexibility of “addressable” controls. This guide covers every major change in the proposed rule, what it means in practice, and how to start preparing now.

Why This Update Matters

The current HIPAA Security Rule was last meaningfully updated by the HITECH Act in 2009 (with the Omnibus Rule finalizing those changes in 2013). In the thirteen years since, the healthcare threat landscape has changed dramatically:

Ransomware attacks on healthcare organizations increased over 300% between 2018 and 2024. The Change Healthcare breach in early 2024 disrupted claims processing across the entire US healthcare system for weeks.
Healthcare data breaches now affect hundreds of millions of individuals annually. The HHS breach portal shows a clear upward trend in both the number and scale of reported breaches.
Connected medical devices and cloud services have expanded the attack surface far beyond what existed when the original Security Rule was written. IoT devices, telehealth platforms, and cloud-hosted EHR systems create data flows that the 2003-era rule never anticipated.
The “addressable” loophole has been widely exploited. Many organizations interpreted “addressable” as “optional,” using risk assessments to justify not implementing encryption, multi-factor authentication, and other controls that are standard practice in other regulated industries.

HHS explicitly cited these trends in the NPRM preamble. The proposed rule is a direct response to the reality that the current framework has not kept pace with the threats healthcare organizations face.

Key Changes at a Glance

Before diving into each change, here is a summary of the major provisions in the proposed rule:

Requirement	Current Rule	Proposed Rule
Implementation specifications	Required or Addressable	All Required
Multi-factor authentication	Addressable (often skipped)	Required for all ePHI access
Encryption at rest	Addressable	Required (AES-256)
Encryption in transit	Addressable	Required (TLS 1.3 minimum)
Disaster recovery timeline	No specific timeframe	72 hours maximum
Network segmentation	Not specified	Required
Penetration testing	Not specified	Annual, mandatory
Vulnerability scanning	Not specified	Every 6 months
Technology asset inventory	General requirement	Complete inventory with ePHI mapping
Risk analysis	Required (general)	Standardized methodology required
Business associate verification	BAA required	BAA + annual verification of compliance
Patch management	Implied	Explicit timeline requirements

Each of these changes has significant operational implications. The sections below cover the details.

Mandatory Multi-Factor Authentication

Perhaps the most impactful change for day-to-day clinical operations is the requirement for multi-factor authentication (MFA) on all systems that access ePHI. Under the current rule, MFA is an addressable specification --- meaning organizations can document why they chose not to implement it and substitute an alternative control. Many have done exactly that, particularly for clinical workstations where speed of access directly affects patient care.

The proposed rule eliminates this flexibility. MFA becomes a required specification for every user accessing ePHI, with no exceptions for clinical workflows.

What This Means in Practice

Clinical workstations. Nurses and physicians who currently log into EHR systems with a username and password will need a second factor. For clinical environments, this typically means proximity badge readers (tap-to-authenticate), biometric readers, or mobile push notifications. Shared workstation environments common in hospitals --- where clinicians log in and out dozens of times per shift --- will need solutions that minimize authentication friction while meeting the MFA requirement.

Remote access. Any VPN, remote desktop, or cloud application that provides access to ePHI must enforce MFA. This includes telehealth platforms, remote EHR access for on-call physicians, and cloud-hosted clinical applications. Most organizations already require MFA for VPN access, but the rule extends this to every remote access pathway.

Service accounts and system integrations. Machine-to-machine connections (integration engines, automated data feeds, scheduled batch processes) that access ePHI will need to be evaluated. While MFA as traditionally understood applies to human users, the proposed rule’s broader authentication requirements may require certificate-based authentication, API key rotation, or other compensating controls for system accounts.

Third-party applications. Business associates whose applications access ePHI must also implement MFA. This cascades the requirement through the entire vendor ecosystem. Health IT vendors that have not yet implemented MFA will need to add it before the compliance deadline.

Implementation Approaches

Organizations that have not yet deployed MFA for clinical environments should evaluate these approaches:

Proximity badge + PIN. Integrates with existing hospital badge systems. Fast authentication (tap and enter PIN) with minimal workflow disruption. Requires badge reader hardware at each workstation.
FIDO2/WebAuthn security keys. Hardware tokens that support passwordless authentication. Phishing-resistant and fast, but require physical key management and a backup authentication method.
Mobile authenticator apps. Push notification or TOTP-based second factor. No additional hardware required, but clinicians must carry a registered mobile device.
Biometric authentication. Fingerprint or facial recognition as a second factor. Fast and convenient, but requires reader hardware and raises additional privacy considerations for workforce members.

The right approach depends on your clinical environment, existing infrastructure, and workforce workflows. Most hospitals will likely adopt a combination: proximity badges for shared clinical workstations, mobile authenticators for remote access, and certificate-based authentication for system integrations.

Encryption Requirements: No More “Addressable”

The proposed rule makes encryption mandatory for ePHI both at rest and in transit. This is one of the most talked-about changes because the current rule’s “addressable” status for encryption has been the source of significant confusion and, in many cases, noncompliance.

Encryption at Rest

All ePHI stored on any medium must be encrypted using AES-256 or an equivalent standard. This applies to:

Database storage. EHR databases, data warehouses, clinical repositories, and any database containing ePHI must use transparent data encryption (TDE) or application-level encryption with AES-256.
File systems. Shared drives, document management systems, and any file storage containing ePHI must be encrypted. Full-disk encryption (BitLocker, LUKS, FileVault) satisfies this for endpoint storage.
Backup media. Backup tapes, disk-based backups, and cloud backup repositories must be encrypted. This includes off-site and archive backups.
Portable devices. Laptops, tablets, USB drives, and any portable storage that may contain ePHI must be encrypted. Most organizations already require this, but the rule removes any flexibility to justify not encrypting portable media.
Cloud storage. S3 buckets, Azure Blob Storage, Google Cloud Storage, and any cloud object store containing ePHI must use server-side encryption with AES-256 keys. Customer-managed keys (CMK) are recommended over provider-managed keys for maximum control.

Encryption in Transit

All ePHI transmitted over any network must be encrypted using TLS 1.3 at minimum. The proposed rule specifically calls out TLS 1.3 as the minimum acceptable version, which is a notable change from the current guidance that generally references TLS 1.2.

This has implications for:

HL7 v2 interfaces. Traditional MLLP connections that transmit HL7 v2 messages in cleartext must be upgraded to MLLP over TLS (secure MLLP). Organizations running Mirth Connect or other integration engines should audit all channels for TLS configuration.
FHIR API endpoints. HTTPS is already standard for FHIR R4 APIs, but organizations must verify that TLS 1.3 is supported and that older protocol versions are disabled.
DICOM connections. Medical imaging workflows using DICOM must implement DICOM TLS. Many legacy PACS systems and modalities support only unencrypted DICOM or older TLS versions, which will require upgrades or replacement.
Internal network traffic. The rule does not exempt internal network communications. ePHI transmitted between systems on the same LAN must still be encrypted. This is a significant change for organizations that have relied on network segmentation as an alternative to encrypting internal traffic.

Impact on Legacy Systems

The encryption requirements will be particularly challenging for organizations running legacy clinical systems that do not support modern encryption standards. Older EHR platforms, medical devices with fixed firmware, and legacy interface engines may not support TLS 1.3 or AES-256.

For these systems, organizations will need to either upgrade to versions that support the required encryption standards, replace end-of-life systems that cannot be upgraded, or implement compensating controls such as encrypted VPN tunnels or TLS-terminating reverse proxies that wrap legacy traffic in compliant encryption.

72-Hour Disaster Recovery

The proposed rule introduces a specific, enforceable timeline for disaster recovery: critical systems must be restored within 72 hours of a disruption. The current rule requires a contingency plan and disaster recovery procedures but does not specify a recovery timeframe.

What “72 Hours” Means

The 72-hour requirement applies to the restoration of systems that are critical to ePHI access and clinical operations. This means:

EHR systems must be fully operational within 72 hours of a disruption, whether caused by ransomware, hardware failure, natural disaster, or any other event.
Integration engines that route clinical messages (ADT, orders, results) between systems must be recovered within the same timeframe, as they are critical to EHR functionality.
Clinical communication systems that carry ePHI (secure messaging, clinical alerting) fall under this requirement.
Backup and recovery systems themselves must be designed to meet the 72-hour RTO (Recovery Time Objective).

DR Planning Requirements

The proposed rule requires organizations to:

Document a disaster recovery plan that specifically addresses the 72-hour recovery requirement for all systems handling ePHI.
Test the DR plan at least annually. Tabletop exercises alone will not be sufficient --- the rule expects functional testing that demonstrates the ability to actually recover systems within the required timeframe.
Maintain immutable backups. In response to ransomware attacks that encrypt backup systems, the proposed rule requires backup copies that cannot be modified or deleted by an attacker who has compromised the production environment. Air-gapped or immutable cloud backups (S3 Object Lock, Azure immutable storage) satisfy this requirement.
Document recovery procedures for each critical system, including step-by-step restoration instructions, dependencies, and contact information for vendors and support resources.

Cloud DR Strategies

Organizations running clinical systems on healthcare cloud infrastructure have several advantages for meeting the 72-hour requirement:

Multi-region replication. Cloud providers offer built-in data replication across geographic regions, enabling rapid failover if the primary region is unavailable.
Infrastructure as Code. Cloud environments defined in code (Terraform, CloudFormation) can be rebuilt from scratch in hours rather than days.
Managed backup services. AWS Backup, Azure Backup, and similar services provide automated, encrypted, immutable backups with point-in-time recovery.
Regular DR testing. Cloud environments can be spun up for DR testing without affecting production, making annual (or more frequent) testing practical and cost-effective.

Network Segmentation

The proposed rule requires organizations to implement network segmentation that separates systems handling ePHI from general-purpose IT networks. This is the first time network segmentation has been explicitly required in the HIPAA Security Rule.

What’s Required

The proposed rule calls for:

Separation of clinical and administrative networks. Systems that process ePHI (EHRs, integration engines, clinical applications) must be on network segments isolated from general corporate networks (email, web browsing, administrative systems).
Medical device isolation. Connected medical devices must be segmented from both clinical and administrative networks. This aligns with FDA’s cybersecurity guidance for medical devices and addresses the risk of lateral movement from compromised devices.
Access controls between segments. Firewalls or equivalent controls must restrict traffic between network segments to only the specific ports, protocols, and source/destination pairs required for legitimate business purposes.
Monitoring of cross-segment traffic. Organizations must monitor traffic crossing segment boundaries for anomalous patterns that may indicate lateral movement or data exfiltration.

Micro-Segmentation and Zero Trust

While the proposed rule requires network segmentation, forward-thinking organizations should consider micro-segmentation and zero trust architecture as approaches that exceed the minimum requirement and provide stronger protection:

Micro-segmentation applies segmentation controls at the individual workload or application level, rather than at the network subnet level. Each application or service has its own security boundary, and traffic between services is explicitly allowed or denied regardless of network location.

Zero trust architecture extends this concept by assuming that no user, device, or network location is inherently trusted. Every access request is authenticated, authorized, and encrypted regardless of where it originates. Zero trust eliminates the concept of a “trusted internal network” that has been the foundation of traditional network security architectures.

For healthcare organizations, zero trust is particularly relevant because:

Clinical staff move between locations and devices frequently.
Third-party vendors and business associates need access to specific systems.
Cloud services and remote work have dissolved the traditional network perimeter.
Connected medical devices may run outdated or unpatched software that cannot be trusted.

Annual Penetration Testing

The proposed rule introduces explicit requirements for penetration testing and vulnerability scanning. Under the current rule, these practices are implicit in the general requirement for risk management, but they are not specifically mandated. The proposed rule changes that.

Penetration Testing Requirements

Organizations must conduct penetration testing at least annually. The proposed rule specifies that penetration tests must:

Be conducted by qualified professionals who are independent from the team responsible for the systems being tested. This does not necessarily require a third-party firm --- an internal red team can qualify if they are organizationally independent from the IT operations team.
Cover all systems that handle ePHI, including network infrastructure, web applications, APIs, cloud environments, and medical device networks.
Include both external and internal testing. External penetration testing simulates an attacker attempting to breach the network perimeter. Internal testing simulates an attacker who has already gained initial access (e.g., through phishing or a compromised device) and is attempting lateral movement.
Produce a written report documenting findings, severity ratings, and recommended remediation actions.
Be followed by remediation of identified vulnerabilities within defined timeframes based on severity.

Vulnerability Scanning Requirements

In addition to annual penetration testing, organizations must conduct vulnerability scanning at least every six months. Vulnerability scanning differs from penetration testing in that it uses automated tools to identify known vulnerabilities (missing patches, misconfigurations, default credentials) without actively exploiting them.

The proposed rule requires:

Authenticated scanning that logs into systems to identify vulnerabilities not visible from an unauthenticated perspective.
Coverage of all systems in the ePHI environment, including servers, workstations, network devices, and medical devices where technically feasible.
Remediation tracking with documented timelines for addressing identified vulnerabilities based on severity (critical, high, medium, low).

For organizations that need help establishing or enhancing their penetration testing and vulnerability assessment programs, working with a healthcare-specialized security firm ensures that testing covers the unique attack surfaces and compliance requirements of clinical environments.

Technology Asset Inventory

The proposed rule requires organizations to maintain a complete, current inventory of all technology assets that create, receive, maintain, or transmit ePHI. While the current rule includes a general provision for hardware and software inventories, the proposed rule significantly expands and specifies what must be documented.

Inventory Requirements

The technology asset inventory must include:

All hardware that processes, stores, or transmits ePHI: servers, workstations, laptops, mobile devices, network equipment, and medical devices.
All software that creates, receives, maintains, or transmits ePHI: operating systems, applications, databases, middleware (including integration engines), and firmware on network devices and medical devices.
Network topology documentation showing how assets are connected, including network diagrams that reflect the segmentation requirements described above.
Data flow maps showing how ePHI moves between systems, including integration interfaces, API connections, and data feeds.
IoT and medical device inventory. The proposed rule specifically calls out Internet of Things devices and connected medical devices, reflecting the growing attack surface these devices represent. Each device must be cataloged with its software version, network location, and the ePHI it accesses.

Why This Matters

A complete asset inventory is the foundation for every other security control. You cannot protect what you do not know you have. The Change Healthcare breach, the Ascension Health ransomware attack, and numerous other healthcare incidents have demonstrated that organizations often have blind spots in their technology inventories --- unmanaged devices, shadow IT, legacy systems that “nobody owns,” and forgotten integrations that still have access to ePHI.

The inventory requirement is designed to eliminate those blind spots. It also enables more effective risk analysis (you can assess risks to assets you know about), incident response (you can determine what was affected if you know what you have), and vulnerability management (you can patch systems you have inventoried).

Compliance Timeline

The proposed rule was published as an NPRM in late 2024. The path from NPRM to enforceable regulation follows a defined process:

Comment period. The NPRM included a public comment period during which healthcare organizations, industry groups, and individuals could submit feedback. This period has closed.
HHS review. HHS reviews all comments and may revise the proposed rule based on feedback. This process typically takes 6-18 months.
Final rule publication. HHS publishes the final rule in the Federal Register. Based on typical timelines and the current administration’s regulatory priorities, the final rule is expected in mid-to-late 2026.
Effective date. The proposed rule specifies that most provisions take effect 180 days after the final rule is published.
Small entity compliance. Smaller organizations (those meeting the Small Business Administration’s definition of a small entity in healthcare) may receive an extended compliance timeline, potentially 360 days after publication.

Expected Timeline (as of May 2026)

Milestone	Status
NPRM published in Federal Register	January 6, 2025 ✓
Comment period closed	March 7, 2025 ✓ (4,745 comments received)
Final rule expected	Originally May 2026 target — status uncertain as of mid-2026
Effective date (large orgs)	~180 days after final rule publication
Effective date (small entities)	~360 days after final rule publication

OCR received more than 4,700 comments in response to the NPRM. As of May 2026, OCR Director Paula M. Stannard has not confirmed whether the proposed rule will progress to a final rule per OCR’s original schedule. The current administration may have a different view on the proposed burdens and benefits than the administration that drafted the NPRM, so industry analysts now treat the May 2026 target as a planning date rather than a confirmed publication date.

Operationally, this means two things for organizations: First, you cannot wait for certainty — the 180-day compliance window after final-rule publication is too short to start from scratch. Second, the changes proposed in the NPRM align with mainstream security best practices regardless of the regulatory outcome, so investments made now (MFA deployment, encryption upgrades, network segmentation, penetration testing programs) are sound security spending whether or not the rule is finalized as drafted.

What This Means for Planning

The 180-day compliance window is aggressive given the scope of the changes. Organizations that wait for the final rule to begin planning will almost certainly miss the deadline. The time to start preparing is now --- while the rule is still being finalized.

Investments made now (MFA deployment, encryption upgrades, network segmentation, penetration testing programs) are sound security practices regardless of the final rule’s exact provisions. The regulatory requirement simply adds urgency to what should already be on every healthcare organization’s security roadmap.

Preparation Checklist: 10 Steps to Take Now

Do not wait for the final rule to begin preparing. The following steps address the proposed rule’s most significant requirements and represent sound security practices regardless of the final regulatory outcome.

1. Conduct a Gap Assessment

Compare your current security posture against the proposed rule’s requirements. Identify where you have gaps in MFA deployment, encryption coverage, network segmentation, and testing programs. A HIPAA compliance assessment provides a structured framework for this analysis.

2. Deploy Multi-Factor Authentication

If MFA is not already required for all ePHI access, begin deployment now. Start with remote access (VPN, cloud applications) if you have not already, then extend to clinical workstations. Evaluate proximity badge, FIDO2, and mobile authenticator options for clinical environments where authentication speed matters.

3. Audit Encryption Coverage

Inventory all systems that store or transmit ePHI and verify encryption status. Check for unencrypted database storage, cleartext HL7 v2 interfaces, DICOM connections without TLS, and legacy systems that do not support modern encryption standards. Plan upgrades or replacements for systems that cannot meet AES-256 and TLS 1.3 requirements.

4. Build a Complete Asset Inventory

Document every system, device, and application that touches ePHI. Include medical devices, integration engines, cloud services, and third-party applications. Map data flows between systems. This inventory is the foundation for every other compliance activity.

5. Assess Network Segmentation

Evaluate your current network architecture against the segmentation requirements. Document which systems are on which network segments, what traffic flows between segments, and where gaps exist. Plan for clinical/administrative separation and medical device isolation.

6. Establish a Penetration Testing Program

If you do not already conduct annual penetration testing, engage a qualified firm to perform your first test now. Use the results to establish a baseline and begin remediation. Implement vulnerability scanning on a regular cadence (quarterly or more frequently).

7. Test Your Disaster Recovery Plan

Conduct a functional DR test --- not just a tabletop exercise --- that measures your ability to restore critical systems within 72 hours. If you cannot meet the 72-hour target, identify the bottlenecks and invest in improvements (cloud DR, immutable backups, automated recovery procedures).

8. Review Business Associate Agreements

The proposed rule requires annual verification that business associates comply with the Security Rule. Review your BAA portfolio, identify business associates with access to ePHI, and establish a process for annual compliance verification. Our HIPAA BAA checklist provides a structured review framework.

9. Document Everything

The proposed rule increases documentation requirements across the board. Ensure that your security policies, risk assessments, asset inventories, network diagrams, DR plans, and testing results are current, complete, and accessible. Documentation that exists only in someone’s head or in an outdated SharePoint site will not withstand an OCR audit.

10. Budget for Compliance

The proposed changes will require investment. MFA hardware and software, encryption upgrades, network segmentation infrastructure, penetration testing engagements, and staff training all have costs. Begin building the business case now so that budget is allocated before the compliance deadline arrives. For sense of magnitude, our healthcare app development cost guide breaks down the HIPAA compliance investments for a typical healthcare software build — most of those line items get larger under the proposed rule.

The 2026 HIPAA Security Rule update represents the most significant change to healthcare data protection requirements in over a decade. The elimination of “addressable” specifications, mandatory MFA, required encryption, and explicit testing requirements raise the compliance bar substantially.

But these changes also reflect security best practices that the healthcare industry should have been adopting all along. Organizations that have invested in strong security programs will find much of the proposed rule familiar. Those that have relied on the flexibility of “addressable” controls to defer investment will have the most work to do.

The 180-day compliance window leaves little room for procrastination. Start your gap assessment now, prioritize the highest-impact changes (MFA and encryption), and build toward full compliance before the final rule takes effect.

For help assessing your readiness or implementing the changes required by the proposed rule, explore our related services:

HIPAA Compliance Services --- Risk assessments, security program development, and ongoing compliance monitoring
Healthcare Cybersecurity --- Penetration testing, vulnerability assessments, and security architecture
Healthcare Security --- Comprehensive security covering HIPAA, cloud, and compliance
HITRUST vs SOC 2: Which Does Your Org Need? --- Compare certification paths for healthcare compliance