By the EHR Association Privacy & Security Workgroup

With the recent publication of the US Department of Health and Human Services’ (HHS) 2026 unified regulatory agenda, the HHS Office for Civil Rights (OCR) hit the snooze button on HIPAA Security Rule updates. Final rulemaking for the January 2025 HIPAA Security Notice of Proposed Rule Making (NPRM) was targeted for a May 2026 release in the previous unified agenda, but notably excluded from the current agenda. Instead, it was transitioned to a long-term action with a target date of July 2027.

While this delay buys time to get the rule right, it isn’t cost-free, as the cyberattack trend that justified the NPRM in the first place hasn’t paused. 

How We Got Here

When the NPRM was published in January 2025, OCR cited three reasons for the proposed updates: the sharp rise in cyberattacks, the extensive modernization of healthcare IT, and the need for clearer, more prescriptive requirements to address common misconceptions and compliance deficiencies.  Despite issues with specific proposed changes, most of the industry agreed an update was necessary. After all, the rule has gone largely unchanged since its initial adoption in 2003, save for updates from HITECH Act provisions implemented in the 2013 Omnibus HIPAA Final Rule.

A thorough analysis of the NPRM and initial reactions is available in EHRA’s 2025 blog series on the proposed rule (HIPAA Security Rule Part One: Proposed Overhaul Closes Some Gaps, Opens Others), but suffice it to say that the proposals are objectively deep and comprehensive. In June 2025, Paula M. Stannard was announced as Director of OCR, and initial signals suggested that the new regime might move forward with the rule largely as proposed. However, questions soon arose about whether the initial proposal aligned well with the Trump Administration’s deregulatory emphasis. Between that and the continued delays, it’s fair to wonder what might eventually emerge and whether it will look anything like the original NPRM.

…Questions soon arose about whether the initial proposal aligned well with the Trump Administration’s deregulatory emphasis. Between that and the continued delays, it’s fair to wonder what might eventually emerge and whether it will look anything like the original NPRM.

For OCR’s part, they have been largely tight-lipped on plans and intent. Director Stannard’s only public comments came during a presentation at HIMSS26, when she acknowledged the significant concerns voiced about the cost burden imposed by the proposal and emphasized the immense costs that cyberattacks and breaches impose on the industry.

One thing is clear: whatever the revised proposal is, it must still answer the three drivers of the original NPRM, or the delay becomes a step backward rather than a pause.

Industry Response and EHRA’s Recommendations

The industry response to the proposed rule was loud. More than 4,700 total public comments were submitted, with healthcare providers and trade associations alike raising overlapping concerns. Following are some of the overarching themes from submitted comments.

Cost and burden estimates were massively understated. 

OCR’s estimate of two hours of effort to conduct annual compliance audits was consistently highlighted as a particularly stark example of the massively understated cost and burden estimates. EHRA’s recommendation: OCR should re-estimate implementation burden using realistic inputs. Our analysis put the compliance effort for a single EHR developer at more than 12,700 hours — none of which the NPRM accounted for (see Appendix A of EHRA Comments on the OCR HIPAA Cybersecurity NPRM).

OCR’s estimate of two hours of effort to conduct annual compliance audits was consistently highlighted as a particularly stark example of the massively understated cost and burden estimates.

The framework wasn’t risk-based or scalable. 

While there was near-unanimous support for many of the principles advanced by the proposals, commenters highlighted a need for requirements that account for differences in organizational size, resources, and risk posture. EHRA’s recommendation: build in a risk-based methodology that concentrates effort on the highest-risk systems and treats lower-risk areas proportionately — smaller entities may have only a handful of staff, sometimes none dedicated to security compliance. 

Terminology diverged from NIST.

Several proposed definitions that set the scope of the entire rule (i.e., MFA, Threat, Security Incident, Vulnerability) depart from the widely accepted NIST definitions. EHRA’s recommendation: adopt the NIST definitions directly, so entities aren’t forced to reconcile competing versions of the same term across frameworks. 

“Relevant Electronic Information System” swept too broadly.

While the industry accepts that ancillary systems can affect the security of ePHI, the proposed definition could pull an entire enterprise into compliance if any single line of business touches ePHI. EHRA’s recommendation: narrow it to systems that either directly handle ePHI or materially affect its security. 

Timelines were unrealistic.

Other than proposed transition provisions for updates to business associate agreements, all newly proposed requirements would take effect just 180 days after the effective date of the final rule — a point which was nearly unanimously highlighted as problematic. The short runway was particularly concerning for more complex proposals, such as applying MFA to all technology assets, an endeavor that could require significant overhauls and/or full replacements of some assets for covered entities. EHRA’s recommendation: allow at least 18 months from publication of the final rule to the compliance deadline for requirements of that scope. 

Technical mandates were sound but too rigid. 

Broad opinion supported new mandates such as encryption, MFA, and network segmentation controls, but many commenters voiced concern about the lack of necessary flexibility and exceptions. The encryption requirement was a recurring pain point; it references “prevailing cryptographic standards” and “authoritative sources” without naming any, leaving entities guessing what will be judged compliant. EHRA’s recommendation: preserve technology neutrality, but establish a defined, official source (potentially through sub-regulatory guidance) for the cryptographic standards entities are expected to meet. 

The encryption requirement was a recurring pain point; it references “prevailing cryptographic standards” and “authoritative sources” without naming any, leaving entities guessing what will be judged compliant.

Business associate verification was duplicative. 

The NPRM’s proposal to require covered entities to obtain annual written verification from business associates that they have deployed all technical safeguards was widely viewed as an unnecessary administrative burden that would heavily weigh on covered entities and business associates alike. EHRA’s recommendation: let recognized third-party attestations — SOC 2, ISO 27001, or comparable independent assessments — satisfy the requirement in place of a standalone annual verification exercise. 

Incident-response and restoration deadlines were counterproductive.

Several proposed requirements for universal cyberincident reporting and restoration timelines were widely viewed as counterproductive, as they may reward premature reporting or restoration of systems prior to completing necessary investigations and related activities. EHRA’s recommendation: focus these requirements on genuine, concerted threats and reasonable restoration steps rather than fixed clocks that fight the investigation. 

EHRA’s Call to Action for OCR

Given these and numerous other areas of concern with the NPRM, we believe the most appropriate action from OCR at this stage is to go back to the drawing board and publish a revised NPRM that considers public commentary on these key topics. Attempting to move forward with final rulemaking in another year could result in either (1) an overly burdensome and costly HIPAA Security Rule update that is unrealistic for the majority of covered entities and business associates to successfully comply with, or (2) a significantly scaled-down update that does not move the needle on improving security posture across the industry. Neither outcome serves patients or the industry; dialing the requirements back far enough to be painless would also dial back their effectiveness at a moment when cyber risk to ePHI has never been higher. While striking the right balance between what’s achievable and what’s actually needed is difficult, it’s the job in front of OCR. 

While striking the right balance between what’s achievable and what’s actually needed is difficult, it’s the job in front of OCR. 

 We also encourage OCR to address the following specific topics with revised proposals for the industry to consider:

• “Maintenance” expectations need definition. Several requirements added a maintenance specification obliging entities to review and test policies annually or after “environmental or operational changes.” Which changes trigger that obligation remains unspecified — exactly the kind of gap a fresh proposal and comment cycle should close. 
• Refine audit trail and system log controls specifications. Expanding audit controls is a step in the right direction, but a revised proposal should explicitly separate traditional security audit logs and routine system logging used for system performance and troubleshooting. Applying the same rigor to both would impose costs far beyond what OCR appears to anticipate.
• AI needs expanded, non-binding guidance. The NPRM’s treatment of AI essentially says existing obligations apply to AI as they do to any software — true, but unhelpful given how much AI complicates technical-safeguard compliance. Covered entities and business associates need more explicit, non-binding guidance on best practices here. 

Committed to Closing the Security Gap

Until OCR issues a revised proposal, covered entities and business associates are left operating under Security Rule requirements that have barely changed since 2003, against a threat environment that bears no resemblance to that year. That gap is exactly why an update remains necessary, even as the industry continues to push back on how the January 2025 NPRM proposed to close it.

The EHRA remains committed to working with OCR toward a final rule that holds both things true at once: requirements substantive enough to meaningfully reduce risk to ePHI, and requirements practical enough for organizations of every size to actually implement. We’ll continue tracking OCR’s progress toward the July 2027 target and sharing updates as rulemaking moves forward – including a closer look at AI-specific guidance, which we’ll cover in an upcoming post. 

The snooze button can only get hit so many times before the risk it was meant to address catches up with the industry.