In December 2024, HHS proposed the most significant update to the HIPAA Security Rule in more than 20 years. In the months since, more than 100 hospital systems and provider associations have formally asked the Department to withdraw the proposal. Signatories include Cleveland Clinic, Yale New Haven Health System, Advocate Health, the American Medical Association, and the American Academy of Pediatrics. The rule remains on the regulatory agenda for May 2026 even after the pushback.

Table of Contents

Whether OCR finalizes the rule as proposed, narrows it, delays it, or withdraws it is not yet known. What is clear is that healthcare cybersecurity threats are increasing, OCR’s enforcement priorities have already shifted toward the controls the proposal would require, and many of the proposed measures reflect what reasonable security looks like in 2026 regardless of any rulemaking outcome.

This article walks through what the proposed update would actually change, where the points of dispute sit, and how covered entities and business associates can prepare in a way that protects ePHI today and reduces risk under whatever final rule eventually emerges.

Key takeaways

• What’s proposed: The first material overhaul of the HIPAA Security Rule since 2013, published as a Notice of Proposed Rulemaking on January 6, 2025. It is proposed, not final.
• Biggest structural change: The proposal would eliminate the “addressable” implementation specification category. Addressable has never meant optional; it has meant implementation could be tailored to an organization’s size and capabilities. The proposal would remove that tailoring, so most specifications would have to be implemented as firm requirements, with specific and limited exceptions.
• Proposed new mandates (sample): Multi-factor authentication, encryption of ePHI at rest and in transit, anti-malware protection, vulnerability scanning at least every six months, penetration testing at least once every 12 months, network segmentation, a technology asset inventory, and a network map showing how ePHI flows.
• If finalized as proposed, the clock: 60 days from Federal Register publication of the final rule until it takes effect. Compliance would be required 180 days after that. Total: 240 days.
• The estimated cost: HHS’s Regulatory Impact Analysis estimates approximately $9 billion in year-one industry cost if finalized as proposed, with annual costs of roughly $6 billion for years two through five.
• The pushback: A coalition of more than 100 organizations led by the College of Healthcare Information Management Executives (CHIME)  sent a December 8, 2025 letter to HHS Secretary Robert F. Kennedy Jr. urging full withdrawal.
• Current status (May 2026): The rule remains on OCR’s regulatory agenda. The agency continues reviewing approximately 4,745 public comments. The proposal’s final form, scope, and timing are uncertain.

Where things actually stand

The Office for Civil Rights announced the Notice of Proposed Rulemaking on December 27, 2024 (formally titled HIPAA Security Rule to Strengthen the Cybersecurity of Electronic Protected Health Information), and it was published in the Federal Register on January 6, 2025. The comment period closed on March 7, 2025. OCR Deputy Director for Health Information Privacy Timothy Noonan confirmed at the 42nd National HIPAA Summit that the agency received approximately 4,745 comments and was reading every one.

OCR’s Spring 2025 Unified Agenda listed May 2026 as the target for finalization, and OCR Director Paula M. Stannard confirmed at HIMSS 2026 that comment review was continuing. As of late May 2026, that target is still on the books. Federal agencies routinely go past deadlines, as these deadlines are not legally binding on an agency, and the proposed rule could move in any of several directions: finalized roughly as proposed, finalized with material changes after comments, delayed, republished, or withdrawn entirely. The current Security Rule remains in effect throughout, and OCR has stated that explicitly on its NPRM page.

The honest read of where this sits is that nobody outside HHS knows what the final rule will look like or when it will arrive. Reasonable planning accounts for several outcomes rather than betting on any one.

What the proposed rule would change

The proposal is not a cosmetic refresh. It would restructure how compliance is measured and what counts as adequate protection of electronic protected health information (ePHI). Six shifts in particular stand out. All requirements below are drawn directly from HHS OCR’s NPRM fact sheet, and all are proposed, not final.

1. The “addressable” implementation category would be eliminated

This is the change with the most legal nuance, and the most widely misunderstood. Worth slowing down on.

Under the current Security Rule, implementation specifications are categorized as either “required” or “addressable.” 45 CFR § 164.306(d) sets out what each category obligates:

• Required specifications must be implemented as written.
• Addressable specifications must be assessed for whether each is reasonable and appropriate in the regulated entity’s environment. If reasonable and appropriate, the specification must be implemented. If it is not, the entity must either implement an equivalent alternative measure or document why no alternative is reasonable and appropriate. Either way, the underlying standard still has to be met.

“Addressable” has never meant optional. What it has provided is implementation flexibility tied to the size, complexity, and capabilities of the regulated entity. A small specialty practice and a national health system have never been expected to deploy identical controls, and the addressable framework has given regulated entities room to meet each standard with proportionate measures.

OCR has expressed concern that the addressable framework has been misinterpreted in practice, with some regulated entities treating addressable specifications as discretionary and failing to either implement them or properly document equivalent alternatives.

The proposal would remove the addressable designation, converting most implementation specifications into firm requirements with limited exceptions. The substance of the obligations is not entirely new (OCR has long expected most addressable specifications to be implemented in most circumstances ), but the formal flexibility to document an alternative approach or opt out entirely would largely disappear. Size and operating context would still inform how requirements are met, but no longer whether they apply.

2. Specific technical controls would become uniformly required

Controls that the existing Security Rule treats as addressable, or that have been industry best practice without being directly specified, would become explicitly required, including:

• Multi-factor authentication for access to ePHI, with limited exceptions.
• Encryption of ePHI at rest and in transit, with limited exceptions that must be justified and documented.
• Anti-malware protection on relevant electronic information systems.
• Network segmentation to limit lateral movement, implemented in a manner informed by the entity’s risk analysis.
• Consistent configuration management of workstations and other relevant systems, including removing extraneous software and disabling network ports per the risk analysis.
• Dedicated backup and recovery controls for ePHI, addressed as explicit standalone requirements rather than folded into general contingency planning.

If your organization currently uses the addressable pathway to implement equivalent alternatives or to document why a specification is not reasonable and appropriate for your environment, that flexibility would be substantially reduced if the rule is finalized as proposed.

3. A documented asset inventory and network map would be required

Regulated entities would be required to maintain two new written documents: a technology asset inventory covering every component of their electronic information systems that may affect the confidentiality, integrity, or availability of ePHI, and a network map illustrating how ePHI moves through those systems. Both would need to be reviewed and updated at least once every 12 months and whenever there is a change in the entity’s environment or operations that may affect ePHI – – including, for example, adoption of new technology assets, newly recognized threats, mergers or consolidations, security incidents, or relevant changes in law.

For many organizations, building and maintaining the inventory across all relevant technology assets would be one of the more labor-intensive new requirements.

4. Testing intervals would become explicit

The proposal would set explicit cadences for what are currently loose obligations:

• Vulnerability scans at least every six months.
• Penetration testing at least once every 12 months.
• Annual compliance audit to verify the entity’s Security Rule compliance.
• Annual review and testing of the effectiveness of certain security measures.
• Risk analysis as a written assessment, refreshed at least annually and whenever conditions change.

5. Tighter timelines and verification for business associates

The proposal would compress time-bound obligations across the covered entity and business associate relationship. Notable elements include:

• 24-hour notification to certain regulated entities when a workforce member’s access to ePHI is changed or terminated.
• 24-hour notification from business associates (and subcontractors) upon activation of their contingency plans.
• 72-hour written restoration procedures for the loss of certain relevant electronic information systems and data.
• Annual business associate verification: Covered entities must obtain written verification at least once every 12 months that each business associate has deployed the technical safeguards required by the Security Rule. Business associates must provide that verification, in the form of a written analysis performed by someone with appropriate knowledge of generally accepted cybersecurity principles and a written certification by someone authorized to act on the business associate’s behalf.

For organizations that work with even a handful of vendors touching ePHI (billing services, transcription, telehealth platforms, cloud EHR hosts, AI scribes), annual BA verification would become a meaningful, recurring workflow.

6. Written documentation of everything

The proposal would require written documentation of all Security Rule policies, procedures, plans, and analyses. The existing Security Rule already imposes documentation obligations, but the proposed rule would expand and standardize them.

Why 100+ hospital systems want it withdrawn

On December 8, 2025, CHIME (the College of Healthcare Information Management Executives) led a coalition letter to HHS Secretary Robert F. Kennedy Jr. asking that the rule be withdrawn. Signatories included Cleveland Clinic, Yale New Haven Health System, Advocate Health, WakeMed Health and Hospitals, the American Medical Association, and the American Academy of Pediatrics, among dozens of state and specialty associations.

Their core objections:

1. Cost. HHS’s own Regulatory Impact Analysis estimates approximately $9 billion in year-one industry cost, with recurring annual costs of roughly $6 billion in years two through five. Coalition members argue those figures understate the real burden, particularly for rural hospitals, federally qualified health centers, and small independent practices.
2. Timeline. 240 days to operationalize asset inventories, network maps, MFA, encryption coverage, segmentation, testing cadences, BA verifications, and documentation across an entire enterprise is, in the coalition’s framing, not realistic for under-resourced providers.
3. Loss of tailoring. CHIME’s leadership has argued publicly that removing the addressable framework substitutes rigid technical mandates for the current implementation flexibility, adding cost and complexity without proportionate improvement in security outcomes.
4. Political alignment. The coalition argues the rule is incompatible with the current administration’s deregulatory posture, and that an earlier model, which incentivized adoption of recognized cybersecurity best practices rather than mandating them, would be more effective.

The criticism is substantive and well-organized. Whether OCR will respond to it with significant changes to the proposal, modest tweaks, or no change at all is one of the open questions about how the rulemaking concludes.

Why preparing for the proposed direction makes sense, whatever the outcome

A few realities argue for taking the proposal seriously as a planning input, even though it may not be finalized as written:

• The threat environment is real and getting worse. Healthcare was the most-targeted U.S. critical infrastructure sector for cyber incidents in 2024 according to the FBI’s Internet Crime Report. The Change Healthcare ransomware attack ultimately affected approximately 192.7 million people, making it the largest healthcare data breach in U.S. history. Ascension’s May 2024 ransomware incident affected operations at its 142 hospitals; the organization later confirmed 5.6 million patients and employees were exposed, with the entry point attributed to an employee opening a malicious file. The proposed controls (MFA, encryption, segmentation, asset inventory, testing) directly map to the failure modes seen in these incidents.
• OCR enforcement under the existing rule has already moved in this direction. Throughout 2025 and into 2026, OCR has emphasized risk analysis and risk management failures, asset-inventory deficiencies, and missing MFA in its enforcement communications and audits. Investments in those controls reduce exposure under the current Security Rule, not just a hypothetical future one.
• A revised final rule would likely keep the same direction. Even commentators sympathetic to the coalition’s objections expect that if OCR softens the proposal, it would be more likely to adjust timelines or scope than to restore the broad addressable framework. The general trajectory of healthcare cybersecurity regulation, federally and at the state level, is toward more specificity.
• State law is moving on similar themes. Several states already have healthcare cybersecurity statutes or are advancing new ones. Federal action or no federal action, state-level obligations are independently increasing.

The reasonable working assumption is therefore not “the rule will pass exactly as written” or “the rule is dead,” but “the threat environment, OCR’s enforcement focus, and the policy direction all justify continued investment in the controls the proposal describes.”

What this could cost, if finalized as proposed

HHS’s own Regulatory Impact Analysis estimates approximately $9 billion in year-one industry-wide costs under the proposal as written, with recurring annual costs of roughly $6 billion in years two through five. The agency did not publish official per-entity cost figures by size class, and what any individual organization would actually spend depends heavily on existing posture. For example, an entity that has already deployed MFA, maintains a current asset inventory, and conducts annual penetration testing will face a very different incremental burden than one starting from scratch.

As a budgeting reference, current published industry guides on overall HIPAA compliance spending suggest the following ballpark ranges. Read these as total compliance program cost under today’s rules, not the incremental cost of the proposed rule alone:

• Small independent practice (1 to 25 staff): Roughly $5,000 to $25,000 per year, depending on stack and existing posture.
• Mid-size group / specialty clinic (26 to 250): Roughly $15,000 to $85,000 initial program build-out; $10,000 to $50,000 per year ongoing.
• Hospital system / large enterprise (250+): Six figures to stand up a mature program; mid-to-high five figures and up annually to sustain, before factoring in network segmentation projects, full pen testing, and enterprise-wide MFA rollouts.

Separate from implementation costs, the enforcement stakes under the existing rule are also rising. Civil monetary penalties under HIPAA were inflation-adjusted by HHS effective January 28, 2026, with the calendar-year maximum cap rising to $2,190,294 for “willful neglect, not-timely-corrected” violations of an identical provision. Penalties apply to violations of the current Security Rule today.

What the proposed 240-day compliance window would look like in practice

For a multi-site practice or a hospital department, here is what eight months would actually have to absorb:

• A complete, evidence-backed risk analysis aligned to the final-rule control set
• A documented technology asset inventory across every ePHI-touching system, including AI tools and SaaS vendors
• A network map showing ePHI flow, including transfers to business associates
• MFA deployed on all systems accessing ePHI
• Encryption gaps remediated (at rest, in transit, with exceptions documented)
• Policies and procedures rewritten and approved
• Workforce training updated and delivered
• Penetration testing scheduled, scoped, and executed
• BA renegotiation and annual verification workflow stood up
• Incident response, contingency, and recovery plans rewritten and tested

That is roughly a 12 to 18 month program if it had to be done from a standing start. Organizations that have already invested in these controls under the current Security Rule, or that started gap planning in 2025, are in a substantially better position to absorb a tighter window if one materializes.

What to do in the next 90 days, regardless of outcome

The work below pays off whether the final rule lands as proposed in May 2026, lands later in a different form, or never lands at all. All of it reduces audit and breach exposure under the current Security Rule and reflects what reasonable healthcare cybersecurity looks like in 2026.

1. Run or refresh a current-state risk analysis. OCR’s existing enforcement actions cite inadequate risk analysis as the single most common Security Rule failure. This is required under today’s rule.
2. Build or update a complete asset inventory. Every system, every vendor, every AI tool that touches ePHI. If you cannot list it, you cannot protect it, and you cannot document compliance.
3. Close MFA and encryption gaps. Both are among the most-cited unmet controls in recent OCR settlements. Both are already addressable specifications, meaning your organization should either have them deployed, have an equivalent alternative in place, or have documentation explaining why neither is reasonable and appropriate.
4. Audit your BAAs. Identify business associates touching ePHI, confirm contracts are current, and consider designing a workflow that can produce annual verification documentation if a future rule requires it.
5. Document everything. Policies, procedures, decisions, and addressable-specification analyses. The current rule already requires documentation of addressable-specification decisions; the proposed rule would expand that obligation.
6. Consider a gap assessment against the proposed rule. Even if the proposal is modified, the work products (an asset inventory, a documented risk analysis, an MFA and encryption map) are useful inputs to current compliance and to whatever final rule eventually emerges.

The bottom line

The proposed HIPAA Security Rule update would, if finalized, be the most significant change to ePHI protection in 20 years. The healthcare industry has pushed back substantively, and the proposal’s final form, scope, and timing remain uncertain.

The argument for preparing is not that the rule will definitely pass as proposed. It is that the controls the proposal describes (MFA, encryption, segmentation, asset inventory, testing, documentation) reflect where the threat environment, OCR enforcement, and state-level regulation are all heading, with or without any single rulemaking. Organizations investing in those controls now are reducing exposure under the rule that exists today, not just the one that might exist tomorrow.

The 240-day clock has not started, and may never start in the form currently proposed. The work that would protect your patients, your operations, and your reputation under any plausible regulatory outcome is available to begin now.

How Compliancy Group helps

Our compliance software, The Guard, includes self assessments and templated policies and procedures that are heavily built upon NIST CSF guidance and best practices—the same foundation that the proposed rule itself is built on. Organizations using The Guard to meet current Security Rule requirements are already working within the framework that OCR has signaled it expects to see reflected in their security programs, regardless of where the proposed rule ultimately lands.

What’s more, The Guard is always updated with the latest rules and expectations as they emerge, and it passes those updates directly through to your compliance program in the form of new training, policies, and guided assessments. This is the easiest way to ensure complete protection for your organization and those it serves.

Start your gap assessment today. Or talk to a compliance expert. [Secondary CTA → /demo]

This article is informational and does not constitute legal advice. Consult qualified legal and compliance counsel for guidance specific to your organization.