HIPAA Security Rule 2026 Modernization: What Covered Entities and Business Associates Must Implement

The Department of Health and Human Services published a Notice of Proposed Rulemaking in January 2025 to update the HIPAA Security Rule for the first time since 2013. The proposed changes reflect more than a decade of evolving cyber threats against the healthcare sector - and they come in the context of record-breaking breach volumes. In 2023 alone, over 133 million Americans had their protected health information exposed in reported breaches.

The proposed rule replaces much of the "addressable" specification language that allowed organizations to substitute equivalent alternatives for mandatory controls. Many of the practices that were previously optional guidance are now proposed as mandatory requirements.

Note: As of this writing, the rule is in the proposed rulemaking stage. Final implementation timelines will be established after the comment period closes and HHS publishes a final rule. Organizations should begin gap assessments now given the expected implementation timeline.

The End of "Addressable" for Core Technical Controls

The original HIPAA Security Rule divided implementation specifications into "required" and "addressable" categories. Required specifications must be implemented. Addressable specifications allow covered entities and business associates to either implement as specified, implement an equivalent alternative, or document a reason why neither is reasonable and appropriate.

The proposed rule eliminates the addressable designation for several technical safeguard requirements, converting them to mandatory requirements. This is significant because many organizations have used the addressable framework as justification for deferring controls they found inconvenient.

Multi-Factor Authentication

The proposed rule would require multi-factor authentication for all user access to electronic protected health information (ePHI). This eliminates the ability to satisfy this requirement through alternative means.

The scope is broad: any system that accesses, processes, stores, or transmits ePHI must have MFA implemented for user authentication. This includes:

• Electronic health record systems
• Clinical imaging systems
• Practice management software
• Business associate systems with ePHI access
• Remote access solutions (VPN, remote desktop, clinical portals)

For most healthcare organizations, MFA deployment is the largest single remediation workload. Organizations with legacy clinical systems that do not support modern authentication protocols will need to either upgrade those systems, implement authentication proxies, or pursue compensating controls with documented justification.

Healthcare IT environments are notoriously heterogeneous, with medical devices and legacy clinical applications that were never designed with strong authentication in mind. The proposed rule includes provisions for recognizing practical limitations, but organizations should not assume legacy systems create permanent exceptions.

Encryption of ePHI

The proposed rule would make encryption of ePHI at rest and in transit a mandatory requirement, removing the current addressable designation that allowed alternatives.

At rest: All ePHI stored on servers, workstations, mobile devices, removable media, and backup systems must be encrypted. This is not a new technical requirement - most mature healthcare organizations have implemented encryption broadly. But organizations with legacy storage infrastructure, medical imaging archives, or clinical workstations that have not been fully upgraded may have gaps.

In transit: All ePHI transmitted across networks must be encrypted using current standards. This includes transmissions between covered entities and business associates, transmissions to patients through patient portals, and any other electronic exchange of ePHI.

TLS 1.2 or higher is the current minimum for in-transit encryption; organizations should be planning for TLS 1.3 as TLS 1.2 approaches end of support in various compliance frameworks.

The 72-Hour Breach Notification Obligation

The proposed rule includes a significant change to breach notification timelines. Current requirements allow covered entities up to 60 days to notify affected individuals and HHS following discovery of a breach. The proposed rule would require notification to HHS within 24 hours of discovery and notification to affected individuals within 72 hours.

This represents a fundamental change to incident response program requirements.

What 72 Hours Actually Means for IR Programs

Seventy-two hours from discovery is a very short window for a forensic investigation, impact assessment, and notification drafting process. Healthcare organizations that lack the internal security capability to quickly assess breach scope will face the choice between notifying before scope is determined or risking a compliance violation.

Incident response programs must be redesigned around this timeline. Key changes required:

Immediate containment and triage protocols. The first 24 hours after discovery must be structured to rapidly determine whether a breach has occurred, contain the incident to prevent additional exposure, and preserve forensic evidence.

Preliminary scope assessment capability. Organizations need the ability to quickly assess what data was potentially accessed or exfiltrated, which affected individuals are involved, and what the regulatory notification obligations are. This requires adequate logging, incident response tooling, and experienced response personnel.

Pre-approved notification templates. Drafting breach notification letters under a 72-hour clock while simultaneously managing incident response is operationally unrealistic. Organizations should develop and legally review notification templates in advance, parameterized for different breach scenarios.

On-call security response. Healthcare organizations that rely on Monday-through-Friday security operations coverage will face challenges meeting a 72-hour notification obligation for incidents discovered on Friday evening. Security operations coverage must address off-hours and weekend discovery scenarios.

Risk Analysis and Asset Inventory Requirements

The proposed rule strengthens requirements around risk analysis and technology asset inventory. Current risk analysis requirements are high-level; the proposed rule includes more specific requirements for:

Technology asset inventory. Organizations must maintain an inventory of all technology assets that create, receive, maintain, or transmit ePHI. This inventory must be reviewed and updated at least annually and whenever technology assets are changed.

Network mapping. The proposed rule would require a map of how ePHI moves across networks, including connections to business associates and third-party systems. This is closely related to the asset inventory but extends to data flows, not just static inventory.

For many organizations, these requirements will require significant documentation work. The combination of asset inventory and network mapping is a prerequisite for a meaningful risk analysis - you cannot assess risk to ePHI you have not identified.

Business Associate Compliance

The proposed changes extend equally to business associates handling ePHI on behalf of covered entities. Business associates should not assume that HIPAA modernization is a covered entity problem.

Critically, the proposed 72-hour breach notification requirement creates a compliance dependency: if a breach occurs at a business associate, the covered entity's 72-hour notification clock may be triggered at the point of discovery by the business associate, not when the business associate notifies the covered entity.

Business associate agreements (BAAs) should be reviewed to ensure notification obligations from business associates to covered entities are clearly defined and tight enough to allow covered entities to meet their own obligations.

What This Means for Your Organization

Whether your organization is a covered entity or a business associate, the proposed HIPAA Security Rule modernization requires proactive preparation. The gap between current-state programs and proposed requirements is significant for many organizations - and closing it takes time.

DarkRock's healthcare compliance team assists covered entities and business associates with HIPAA Security Rule gap assessments, MFA deployment planning for healthcare environments, incident response program development, and ongoing compliance support. Our HIPAA Guard platform automates evidence collection and tracks compliance posture against both current requirements and proposed updates.

Start your gap assessment now - the compliance window is shorter than you think. Contact DarkRock to schedule an initial consultation.