HIPAA Security Rule 2026 Changes: What Healthcare Organizations Need to Know

The Department of Health and Human Services (HHS) proposed the most significant update to the HIPAA Security Rule since its original adoption in 2003. For covered entities and business associates, this isn't a minor revision — it's a fundamental shift from flexible, scalable security standards to more prescriptive technical requirements.

This guide summarizes the key proposed changes, the implementation timeline, what it means for your organization, and what you should be doing now to prepare.

Why the update is happening

The current HIPAA Security Rule was written when electronic health records were an emerging concept. Two decades later, the threat landscape has changed fundamentally:

• Healthcare is the most breached sector. Over 700 major health data breaches were reported in 2025 alone, affecting hundreds of millions of individuals.
• Ransomware specifically targets healthcare. Hospital systems, health plans, and clearinghouses are prime targets because of the urgency to restore operations and the value of health data.
• The "addressable" vs. "required" distinction failed. The original rule let organizations decide whether certain safeguards were "reasonable and appropriate" for their environment. In practice, many organizations used "addressable" as an excuse not to implement controls that should have been standard.
• Technology has advanced. Encryption, multi-factor authentication, and network segmentation are no longer expensive or exotic. The rule needs to reflect current technical capabilities.

Key proposed changes

1. Elimination of "addressable" vs. "required" distinction

The biggest structural change. Under the current rule, many safeguards are "addressable," meaning organizations can implement alternatives or document why the safeguard isn't reasonable. Under the proposed rule, all implementation specifications would be required, with limited exceptions requiring documented justification.

Impact: If you've been treating encryption at rest as "addressable" and not implementing it because of legacy system constraints, that exception goes away. You'll need to implement it or have a very specific, documented reason why you can't.

2. Mandatory encryption for ePHI at rest and in transit

Encryption moves from an addressable specification to a required one. All electronic protected health information (ePHI) must be encrypted both in transit (TLS 1.2+) and at rest (AES-256 or equivalent), with no exceptions for internal network traffic.

Impact: Organizations running legacy systems with unencrypted databases or internal HTTP traffic will need to implement encryption or migrate. This affects EHR systems, medical devices, and internal APIs that may currently transmit ePHI in plaintext.

3. Mandatory multi-factor authentication

MFA becomes required for all access to systems containing ePHI, not just remote access. This includes local workstation logins, EHR application access, and administrative access to health IT infrastructure.

Impact: Significant for clinical environments where MFA has been avoided due to workflow concerns. Organizations will need MFA solutions that work in clinical settings — badge-tap, proximity-based, or biometric solutions that don't slow down patient care.

4. Technology asset inventory and network mapping

Organizations must maintain a complete, current inventory of all technology assets that create, receive, maintain, or transmit ePHI, including network diagrams showing how ePHI flows between systems.

Impact: Many organizations lack a comprehensive asset inventory, especially for medical devices, IoT devices, and shadow IT. This requirement demands ongoing inventory management, not a one-time audit.

5. Network segmentation requirements

The proposed rule adds specific requirements for network segmentation, separating systems containing ePHI from general-purpose networks. This includes technical enforcement (not just policy), regular validation, and documented network architecture.

Impact: Flat networks where clinical systems, administrative systems, and guest networks share the same infrastructure will need redesign. This is one of the most operationally expensive changes for large healthcare networks.

6. Vulnerability management and patching timelines

Specific timelines for vulnerability remediation: critical vulnerabilities patched within 15 days, high-severity within 30 days. Regular vulnerability scanning is required, not just recommended.

Impact: Organizations that patch on a quarterly cycle will need to accelerate. Medical device patching, which often involves vendor coordination, becomes particularly challenging under these timelines.

7. Incident response and 72-hour notification

The proposed rule strengthens incident response requirements, including mandatory incident response testing (tabletop exercises), 72-hour notification to HHS for certain incidents, and documented forensic capabilities.

Impact: Organizations need tested IR plans with specific runbooks for ransomware, data exfiltration, and insider threats. The 72-hour clock is aggressive and requires automated detection capabilities.

8. Business associate compliance verification

Covered entities must verify — not just contractually require — that business associates comply with Security Rule requirements. This includes reviewing business associate security documentation and receiving attestations of compliance.

Impact: Healthcare organizations with dozens or hundreds of business associates will need a structured BA monitoring program. Contracts alone are no longer sufficient.

Timeline

What to do now: a preparation checklist

1. Conduct a gap analysis. Compare your current Security Rule implementation against the proposed requirements. Focus on the areas that changed from addressable to required — encryption, MFA, network segmentation. Our HIPAA program page outlines the framework we use for this analysis.
2. Build your asset inventory. If you don't have a complete, current inventory of every system that touches ePHI, start now. Include medical devices, IoT devices, and cloud services. This is foundational for every other requirement.
3. Assess encryption readiness. Inventory every system that stores or transmits ePHI and document its encryption status. Identify legacy systems that can't support encryption and start planning migrations or replacements.
4. Deploy MFA. If MFA isn't already universal for ePHI access, start deployment planning now. Clinical workflow concerns are real, but there are solutions (proximity-based auth, badge-tap, biometric) that balance security with usability.
5. Map your network. Document your network architecture, identify where ePHI flows, and plan segmentation. If your network is flat, engage a network architect to design CUI/ePHI enclaves.
6. Review business associate agreements. Update BA agreements to reflect new compliance verification requirements and establish a process for ongoing BA monitoring.
7. Test your incident response. Run a tabletop exercise. If you haven't done one in the past year, schedule one now. Focus on ransomware and data exfiltration scenarios with the 72-hour notification clock.
8. Budget for compliance. The proposed changes will require investment, especially in encryption, network segmentation, and asset management tooling. Start building the business case now. See our detailed HIPAA 2026 changes analysis for cost impact estimates.

How grc.engineering helps

We're building the same compliance-as-code infrastructure for HIPAA that we've deployed for CMMC. For healthcare organizations, that means:

• Automated evidence collection against HIPAA Security Rule requirements, mapped to both current and proposed safeguards
• Per-facility compliance dashboards for multi-location healthcare networks
• Gap analysis tooling that compares your current posture against proposed 2026 requirements
• Remediation tracking with automated POA&M generation

See also: HIPAA Readiness Quiz · HIPAA 2026 Changes — Full Analysis · Breach Cost Calculator · HIPAA Compliance Program