The HIPAA Security Rule update is a proposed overhaul of the safeguards protecting electronic protected health information (ePHI), and it is the most significant change to the rule since it took effect in 2005. The Department of Health and Human Services Office for Civil Rights (HHS OCR) published a Notice of Proposed Rulemaking (NPRM) in the Federal Register on 6 January 2025, and it would remove the long-standing distinction between "addressable" and "required" specifications, mandate encryption and multi-factor authentication, and impose rapid recovery obligations (HHS OCR, 2025). One point to be clear about from the outset: as of mid-2026 this is still a proposed rule, not law. The comment period closed on 7 March 2025, OCR is working through more than 4,700 comments, and the original spring-2026 finalisation target has passed with no final rule published.
Status check (mid-2026): the HIPAA Security Rule update remains a proposed rule. OCR has not issued a final rule, the requirements below could still change, be delayed, or be withdrawn, and there is no confirmed date for finalisation. Treat this as advance planning, not a live compliance deadline (HHS OCR, 2025).
Background: what the current Security Rule requires
The existing Security Rule organises safeguards for ePHI into three categories — administrative, physical, and technical — each with a set of implementation specifications. Some of those specifications are "required" (they must be implemented), while others are "addressable" (they must be implemented if reasonable and appropriate, or an equivalent measure adopted and the decision documented). This flexibility was deliberate when the rule was written, allowing a small clinic and a national health plan to comply at proportionate cost. In practice, though, the addressable label has been widely misread as optional, and the flexibility that was meant to enable proportionality has instead produced inconsistent security across the sector. We covered the operational reality of the current rule in our HIPAA implementation roadmap, and the recurring failure points — stale risk analyses, missing business associate agreements, absent training records — in our piece on HIPAA compliance in modern healthcare operations.
Why HHS is updating the rule now
The driver is a documented surge in large healthcare breaches, ransomware campaigns against hospitals, and attacks that have disrupted clinical operations and exposed the records of hundreds of millions of individuals. OCR has concluded that the current rule, largely unchanged for two decades, no longer reflects the threat environment or established cybersecurity practice. Its stated intention is to raise the baseline: to specify the safeguards it now expects every regulated entity to have, rather than leaving core protections such as encryption to a case-by-case reasonableness analysis (HHS OCR, 2025). In OCR's framing, the addressable category has become a loophole, and closing it is central to the proposal.
The key proposed changes
The NPRM is detailed, but the changes that would most affect day-to-day security programmes are concentrated in a handful of areas. The proposed requirements include the following (HHS OCR, 2025):
- Removing the addressable-versus-required distinction, so nearly all implementation specifications become mandatory with only narrow exceptions
- Mandatory encryption of ePHI both at rest and in transit, with limited documented exceptions
- Mandatory multi-factor authentication for access to systems handling ePHI, with limited exceptions
- Network segmentation to limit lateral movement and contain intrusions
- A written technology asset inventory and an up-to-date network map showing how ePHI moves through systems, reviewed at least every 12 months and after material changes
- Annual compliance audits and more frequent, better-documented risk analyses
- Written procedures to restore the loss of critical electronic information systems and data within 72 hours
- Vulnerability scanning, penetration testing at defined intervals, and removal of extraneous software from relevant systems
A point worth clarifying, because it is widely misread: the 72-hour figure is an internal restoration and response objective for critical systems, not a new breach-notification deadline. The existing obligation to notify affected individuals within 60 days under the Breach Notification Rule would remain unchanged. If your organisation has already adopted controls of the kind described in our guide to encryption fundamentals for security engineers, much of the encryption mandate will feel like documentation of practice you already follow rather than net-new engineering.
What it means for covered entities and business associates
Both covered entities and business associates fall within scope, and the proposal would tighten the relationship between them. Business associates would face direct obligations to verify and, in some formulations, attest to the technical safeguards they have deployed, giving covered entities documented assurance rather than a contractual promise. For large, well-resourced organisations, most of these requirements formalise controls that mature security programmes already run. For smaller providers, rural facilities, and lean business associates, the shift from flexible to prescriptive is more consequential — encryption everywhere, MFA everywhere, annual audits, and asset inventories represent real cost and staffing. That tension is why a coalition of hospital and provider associations has asked HHS to withdraw or substantially narrow the proposal, arguing that the prescriptiveness is unworkable for smaller entities. Whether OCR moderates the final rule in response is one of the open questions.
The proposed compliance clock is generous but finite: if finalised as drafted, the rule would take effect 60 days after publication of the final rule, with a compliance date 180 days after that — roughly 240 days from publication (HHS OCR, 2025). Organisations that wait for the final rule before starting will have well under a year to implement encryption, MFA, segmentation and recovery testing at scale.
Timeline and current status
To summarise where things stand: the NPRM was published on 6 January 2025 and the public comment period closed on 7 March 2025 (HHS OCR, 2025). OCR is reviewing the comments received, and its regulatory agenda had pointed to a spring-2026 final rule, but that window has passed with nothing published and no confirmed replacement date. A final rule could still arrive later in 2026 or beyond, could be revised in response to comments, or could be delayed or shelved. We recommend treating the proposal as the clearest available signal of OCR's direction of travel, while planning on the assumption that the exact requirements and dates may shift.
How to prepare now
The pragmatic move is to close the gap between your current programme and the proposed baseline in the areas that take longest to implement, while avoiding irreversible spending on requirements that could still change. The following sequence lets you make defensible progress under either outcome:
- Build or refresh your ePHI asset inventory and network map now — this underpins almost every other requirement and always takes longer than expected
- Deploy encryption of ePHI at rest and in transit wherever it is not yet universal, and document any exceptions
- Roll out multi-factor authentication across all access to ePHI systems, starting with remote and privileged access
- Refresh the Security Rule risk analysis so it is specific to your actual environment, current, and evidence-backed
- Test your ability to restore critical systems and data, and write down recovery procedures against a 72-hour objective
- Introduce network segmentation and a defined schedule for vulnerability scanning and penetration testing
- Update business associate agreements and start collecting assurance about the technical safeguards your vendors run
- Track the rulemaking so you can move quickly once the final rule and its dates are confirmed
Most of these steps map cleanly onto established frameworks, which is a useful way to make the work do double duty. Encryption, MFA, asset inventories, segmentation and recovery testing all correspond to controls in the NIST Cybersecurity Framework, and teams already moving to CSF 2.0 — a transition we walked through in our guide to moving from CSF 1.1 to 2.0 — will find the proposed HIPAA requirements largely map onto work already underway. Approaching the update as an acceleration of good security practice, rather than a standalone compliance scramble, is the difference between a calm implementation and a rushed one if and when OCR finalises the rule.