The Department of Health and Human Services’ Office for Civil Rights published a notice of proposed rulemaking in December 2024 that would be the most significant update to the HIPAA Security Rule since the rule’s original publication in 2003. OCR identified May 2026 as its target month for finalizing that rule in the federal government’s regulatory agenda. As of this writing, a final rule has not published.

Whether it publishes this month, later in 2026, or is delayed further under the Trump administration’s stated preference for regulatory reduction rather than expansion, the compliance implications are the same. The proposed rule represents OCR’s current enforcement posture. Its substantive requirements reflect where the agency believes the baseline for adequate ePHI protection sits. Organizations that plan toward the proposed requirements now are substantially better positioned than those that wait for the final rule to start gap analysis.

This article summarizes the key proposed changes, explains the current publication uncertainty, and describes what covered entities and business associates should be doing right now.

The State of the HIPAA Security Rule Before the Proposed Update

The original HIPAA Security Rule was finalized in February 2003. The technology landscape it was written for — dial-up internet, local area networks, on-premise servers, desktop workstations — bears limited resemblance to the current healthcare IT environment of cloud infrastructure, mobile devices, remote clinical access, and third-party vendor ecosystems.

The rule’s “required versus addressable” framework has been one of its most consequential structural features, and one of its most criticized. Addressable safeguards are not optional — organizations must implement them or document why they are not reasonable and appropriate given their specific circumstances, and implement an equivalent alternative. But in practice, the “addressable” designation has been used by some covered entities to defer or avoid controls — particularly encryption and multi-factor authentication — that are now considered table stakes in any reasonable security program.

The proposed rule ends that ambiguity for the most critical controls.

Key Proposed Changes

Mandatory Multi-Factor Authentication

Under the proposed rule, multi-factor authentication is required for all access to electronic protected health information systems. This is not an addressable safeguard with an equivalence alternative — it is a required specification.

The mandate covers:

  • Remote access to all systems containing ePHI
  • Access to ePHI applications from internal networks where access traverses a wireless connection
  • Administrative and privileged account access to all systems

The proposed rule acknowledges that some clinical devices — embedded systems, legacy medical equipment — may not support MFA at the application layer. For those systems, the rule requires compensating controls: network-level access controls, device authentication, and documented risk acceptance.

For most healthcare organizations, this requirement will drive significant changes to clinical application access, remote desktop infrastructure, and vendor access management. A meaningful portion of the clinical application ecosystem — particularly legacy EMR modules and departmental software — does not currently support modern MFA methods without middleware or gateway solutions.

Mandatory Encryption

The proposed rule eliminates the addressable designation for encryption of ePHI. Encryption at rest and in transit becomes required for all ePHI, with no distinction between production systems, backup environments, or archival storage.

Current state in most organizations: encryption of ePHI in transit (TLS) is broadly implemented for internet-facing systems. Encryption at rest is inconsistently applied, particularly to:

  • Backup media and tape
  • File shares on internal networks
  • Medical device storage (some devices do not support native encryption)
  • Legacy database systems
  • Endpoint local storage on clinical workstations

The proposed rule would require each of these to be addressed. For medical devices and legacy systems that cannot be encrypted natively, compensating controls and documented risk management are required — but “this system is too old to encrypt” is not a compliant answer without additional mitigation.

Annual Penetration Testing

The proposed rule requires covered entities to conduct penetration testing at least annually, using either internal qualified personnel or external third parties. Penetration testing must cover:

  • Network infrastructure
  • Applications containing ePHI
  • Authentication and access control mechanisms
  • Wireless network security

Additionally, vulnerability scanning — automated identification of known vulnerabilities — must occur on a defined regular cadence. The proposed rule does not specify a minimum scanning frequency but expects that critical and high-severity findings are remediated within defined timeframes.

This is a departure from the current standard, which requires a risk analysis but does not mandate penetration testing as a distinct required activity. Many organizations conduct penetration tests as part of vendor requirements or voluntary frameworks (SOC 2, HITRUST) but have not structured them specifically to the HIPAA requirement.

Network Segmentation

The proposed rule introduces network segmentation as a required administrative and technical safeguard. Clinical networks containing devices and systems that process ePHI must be segmented from general IT networks, internet-facing services, and vendor access pathways.

This requirement addresses one of the most consistently exploited attack paths in healthcare ransomware: initial access through a phishing email against an IT workstation on a flat network, followed by lateral movement to clinical systems with no network controls preventing the traversal.

Implementing segmentation in established healthcare facilities is expensive and operationally complex. It requires coordination between IT, clinical operations, and facilities management, and typically involves a phased rollout over twelve to eighteen months. Organizations that have not yet begun this work cannot complete it within a standard compliance period.

Technology Asset Inventory

The proposed rule requires covered entities to maintain a current, accurate inventory of all technology assets — hardware and software — that create, receive, maintain, or transmit ePHI. The inventory must document:

  • Device identification and location
  • Operating system version and patch level
  • Network connectivity
  • ePHI data flows to and from the asset

This addresses the persistent problem of shadow IT and inventory gaps that are revealed in almost every OCR breach investigation. Organizations frequently do not know the full scope of their ePHI footprint until an incident forces a discovery exercise.

Enhanced Business Associate Oversight

The proposed rule requires covered entities to verify, not merely document, that their business associates have implemented required security safeguards. A signed BAA is no longer sufficient. Covered entities must conduct — or obtain — actual security assessments of BAs with access to significant volumes of ePHI.

The specific requirements include:

  • Annual compliance attestations from BAs
  • Risk-based verification for BAs with access to large volumes of ePHI (defined in the proposed rule as above 100,000 individuals)
  • Incident notification updates: BAs must notify covered entities within 24 hours of discovering a security incident, reduced from the current undefined “without unreasonable delay” standard

The Publication Uncertainty

OCR set May 2026 as the target publication date for the final rule in the Unified Regulatory Agenda, which is the federal government’s public planning document for regulatory activity. That target has not been met as of mid-May.

Several factors contribute to the uncertainty:

Trump administration regulatory reduction posture. The current administration has expressed a general preference for reducing regulatory burden on businesses, including healthcare organizations. Whether this philosophy will result in the HIPAA Security Rule update being substantially softened, delayed, or withdrawn is not known. The administration has not publicly indicated an intent to pull the proposed rule, and HHS has continued to treat it as an active rulemaking.

OMB review timeline. Final rules from executive branch agencies must complete Office of Management and Budget review under Executive Order 12866 before publication. This review can take several months and is not publicly visible until complete. OCR may have submitted the final rule to OMB without public announcement.

Comment volume. The December 2024 NPRM generated a substantial volume of public comments, many from healthcare industry associations raising concerns about implementation timelines and the cost of required controls. The final rule must address those comments, which takes time.

The practical implication: the final rule may publish in May, in the summer, or later in 2026. It may be substantively similar to the proposed rule or may include modifications. It may be delayed until a new administration — but the risk analysis for that scenario favors preparation, since OCR enforcement of the existing Security Rule is ongoing and accelerating, and the proposed requirements reflect what OCR already expects to see in a compliant security program.

What to Do Regardless of Timing

The compliance rationale for acting now is straightforward. The proposed requirements — MFA, encryption, penetration testing, segmentation, asset inventory, BA oversight — are baseline security practices that any reasonable security program should already include. OCR’s enforcement of the existing Security Rule has been moving toward these standards for years. Organizations that complete the gap analysis and begin remediation now gain:

  1. Reduced ransomware exposure — MFA, segmentation, and patching directly address the attack chains used in most healthcare ransomware campaigns
  2. Better OCR investigation posture — organizations with documented, current risk analyses, remediation plans, and completed controls are treated materially differently than those without them
  3. A shorter compliance sprint — if the final rule publishes with a 240-day compliance window, organizations that have already begun remediation will meet the deadline; those starting from scratch likely will not

Step 1: Assess MFA coverage. Map every ePHI application and access pathway. Identify which have MFA implemented, which are capable of MFA but not configured, and which require gateway or middleware solutions. Build a remediation timeline.

Step 2: Audit encryption posture. Inventory backup media, file shares, endpoint storage, and medical device storage for unencrypted ePHI. Prioritize remediation by data volume and sensitivity.

Step 3: Schedule a penetration test. If you have not had an external penetration test in the past twelve months, schedule one against your current infrastructure. Use findings to prioritize patching and configuration hardening.

Step 4: Assess network segmentation. Engage your network team on the current topology between clinical and IT networks. Identify where clinical devices share network segments with general-purpose workstations or internet-facing systems. Develop a segmentation roadmap.

Step 5: Update the asset inventory. If your current inventory is incomplete or more than twelve months old, run a network discovery exercise and reconcile against known device lists. Document ePHI data flows for each asset.

Step 6: Review business associate agreements. Every BA with ePHI access should have a current BAA. Begin assessing whether your highest-volume BAs have security controls commensurate with their access.

Conclusion

The HIPAA Security Rule overhaul is coming. Whether the final rule publishes in May, in the fall, or later, the direction of enforcement is established by the proposed rule’s content and by OCR’s existing enforcement pattern. Organizations that wait for the final rule to begin compliance planning will face a compressed implementation window against requirements that are technically and operationally demanding.

The proposed changes — mandatory MFA, mandatory encryption, annual penetration testing, network segmentation, asset inventory, and enhanced BA oversight — are not novel requirements invented by the rulemaking. They are baseline security controls that have been recommended by every major security framework for a decade. The rule makes them mandatory. The time to implement them is now.

This article is provided for informational purposes only and does not constitute legal advice. Organizations should consult qualified legal counsel and cybersecurity professionals regarding their specific HIPAA compliance obligations.