A Rule That Was Written Before the iPhone Existed
Let me put something in perspective for you.
The HIPAA Security Rule (the regulation that governs how covered entities and their vendors protect electronic protected health information, or ePHI) was originally promulgated in 2003. Its last meaningful update was in 2013 and did not even substantially revise the Security Rule’s core technical requirements and was largely built around a threat landscape that isn’t the same as the one we’re operating in today.
In 2003, ransomware wasn’t nearly as common of a threat as it is today. Cloud computing wasn’t yet a commercial reality. Most healthcare organizations weren’t outsourcing their entire IT operations to Managed Service Providers (MSP). And the idea that a single ransomware attack could affect over 100 million patients at once would have sounded like fiction. By 2024, that’s exactly what happened: the Change Healthcare ransomware attack affected an estimated 100 million individuals, almost a third of the U.S. population whose data was potentially exposed.
Fast forward to today, and that last part isn’t fiction anymore; it’s an HHS statistic. According to HHS’s Office for Civil Rights (OCR), large breach reports increased 102% between 2018 and 2023, and the number of individuals affected by those breaches jumped by 1,002% during the same period. In 2023 alone, over 167 million individuals were affected by large breaches, a new record. Hacking and ransomware incidents have driven most of that increase, rising 89% and 102% respectively since 2019.
HHS noticed. And on December 27, 2024, OCR issued a Notice of Proposed Rulemaking (NPRM), published in the Federal Register on January 6, 2025 at 90 FR 898, to do something about it.
This blog is about what that something looks like: the major changes proposed, the timeline from the official sources, and what all of it means for covered entities and their MSPs.
The Biggest Shift: “Addressable” Is No Longer a Hall Pass
If you’ve spent any time in HIPAA compliance, you know the current rule divides implementation specifications into two buckets: “required” and “addressable.” Required means you must do it. Addressable means you assess whether it’s reasonable and appropriate for your organization, and if you determine it isn’t, you can implement an equivalent alternative or document why neither is necessary.
Having spent a lot of time consulting in the GRC world, it’s not hard to presume one big problem with this approach: that “addressable” specifications would easily become “optional” for many organizations. Encryption too costly? Welp, it’s addressable so document it and move on. MFA too disruptive to your workflow? Thank goodness it’s addressable. The result, as OCR describes in the NPRM preamble, is that regulated entities’ compliance with Security Rule requirements has been “inconsistent” and the rule hasn’t kept pace with “changes in the health care environment.”
The proposed rule’s single biggest structural change is the elimination of that distinction entirely. Per the official HHS Fact Sheet for the NPRM, the proposal would “remove the distinction between ‘required’ and ‘addressable’ implementation specifications and make all implementation specifications required, with specific, limited exceptions.” No more writing your way out of encryption or MFA with a well-crafted risk assessment narrative. If the rule is finalized as proposed, the hall pass is gone.
What the HIPAA Security Rule Changes Actually Require: Straight from the NPRM
Here’s what the proposed rule puts on the table, sourced directly from the HHS NPRM Fact Sheet and the Federal Register publication (90 FR 898):
Encryption of ePHI at Rest and In Transit. The NPRM proposes to “require encryption of ePHI at rest and in transit, with limited exceptions.” Under the current rule, encryption is addressable. Under the proposed rule, it becomes a hard requirement. Every piece of ePHI (on servers, laptops, mobile devices, in transit across networks) must be encrypted using prevailing cryptographic standards, specifically NIST-approved algorithms.
Multi-Factor Authentication (MFA). The proposed rule would “require the use of multi-factor authentication, with limited exceptions,” including a carve-out for certain FDA-approved medical devices that architecturally cannot support MFA. For everything else, password-only access to systems containing ePHI would be a no-no.
Technology Asset Inventory and Network Map. Per the NPRM, regulated entities would be required to establish and maintain a technology asset inventory and a network map showing how ePHI flows through their environment, with both reviewed and updated at least annually. This becomes the foundation for the risk analysis, because you cannot assess what you cannot see.
Specific Technical Controls. The proposed rule would “require regulated entities to establish and deploy technical controls for configuring relevant electronic information systems in a consistent manner,” including deploying anti-malware protection, removing extraneous software from relevant systems, and disabling network ports in accordance with the entity’s risk analysis.
Network Segmentation. The NPRM introduces an explicit network segmentation requirement, requiring regulated entities to establish, implement, and maintain policies and procedures to ensure that ePHI is segmented to limit system access in a reasonable and appropriate manner, specifically to reduce lateral movement during a cyber incident.
Vulnerability Scanning and Penetration Testing. Regulated entities would be required to conduct vulnerability scanning at least every six months and penetration testing at least once every 12 months. The current rule has no specific cadence requirement for either.
72-Hour System Restoration Requirement. The proposed rule introduces defined timeframes for contingency planning. Specifically, regulated entities would be required to restore critical systems within 72 hours of contingency plan activation.
Annual Compliance Audit. In place of the current general requirement to “maintain” security measures, regulated entities would be required to conduct a formal compliance audit at least once every 12 months.
Enhanced Risk Analysis Requirements. The proposed rule would require “greater specificity for conducting a risk analysis,” tying the analysis to the technology asset inventory, documented threat and vulnerability identification, and documented reasonable determinations of likelihood and impact.
SIDE NOTE: Though all of these are incredibly important, this last change is a BIG ONE in my humble opinion. Specificity in the Risk Assessment world seems to me to be one of the weakest parts of most compliance frameworks and certifications. CMMC/NIST SP 800-171, for example, also has a very generic Risk Assessment Requirement and we’ve seen incredibly shallow and inconsistent implementations pass muster during a formal assessment. Having a more rigid outline for the analysis of risk like this, though cumbersome in many ways, is a really good thing for health care organizations to have to start doing.
The Timeline: What the Official Record Says
Though there’s a lot of speculation on the timing of these changes, let’s look at what we actually know.
Here is the official timeline based on HHS.gov and the Federal Register:
December 27, 2024: HHS/OCR issued the NPRM.
January 6, 2025: Published in the Federal Register at 90 FR 898 (Docket No. RIN 0945-AA22).
March 7, 2025: Public comment period closed. 4,747 comments were received at Regulations.gov, including a CHIME-led coalition of over 100 hospital systems and provider organizations calling on HHS to withdraw the rule, citing the projected ~$9 billion year-one implementation cost and arguing the timeline was unreasonable.
Present: OCR is reviewing comments. Per OCR’s Spring 2025 Unified Agenda, finalization was targeted for May 2026. As of the time of writing this blog, OCR has not confirmed that date, nor has it indicated intent to withdraw the rule, so we’re past the expected timeline. Again, there’s no formally scheduled date for its finalization so, at this point, we’re in “we’ll see” mode.
If and when a final rule is published, the Federal Register NPRM indicates the following compliance structure: the effective date would be 60 days after Federal Register publication of the final rule (normal timeline for published final rule to go into effect.) Regulated entities would then have until the “compliance date” (180 days after the effective date) to achieve compliance with new and modified requirements. That’s 240 days from publication, total. Business Associate Agreements would generally have up to one year from the effective date to be updated, or earlier upon renewal.
If the rule finalizes in the next few months, organizations are looking at a compliance deadline somewhere in mid 2027.
Side Note: The current HIPAA Security Rule remains fully in force while rulemaking is ongoing. This is not a moment to disengage from current obligations while waiting to see what the final rule looks like.
What the HIPAA Security Rule Changes Mean for Covered Entities
Though it would be naïve to presume anything here, most of what’s in the proposed rule represents controls that responsible organizations should already have in place. Encryption at rest and in transit. MFA across the board. Regular vulnerability scanning. An accurate asset inventory. These aren’t new ideas; they’ve been cybersecurity best practices for years, and they show up in frameworks like the NIST Cybersecurity Framework and HHS’s own voluntary Healthcare and Public Health Cybersecurity Performance Goals (HPH CPGs) that OCR published in January 2024.
If your organization has been operating the way a mature security program should, your compliance lift here is mostly about formalization, documentation, and filling in the specific gaps the proposed rule introduces, like the defined testing cadences and the annual audit requirement.
If, on the other hand, your organization has been relying on the “addressable” flexibility to avoid encryption, skip MFA, or defer penetration testing indefinitely, this might be a pretty big operational leap for you. The gap between where you are and where the proposed rule requires you to be is pretty wide, it takes time to close, and the 240-day compliance window after final publication is not generous for organizations starting from scratch.
My practical advice: start your gap assessment now, against the proposed rule as written. It’s specific enough that you can benchmark your current posture and understand the work ahead. Build your technology asset inventory. That single artifact is the foundation of the risk analysis, the network map, the testing scope, and everything else. Don’t wait for the final rule to begin implementing the requirements.
If you’d rather not start from a blank page, we can run a gap assessment against the NPRM as written so you know exactly the gaps are before the final rule drops.
Lets talk
The MSP Conversation Nobody Is Having Loudly Enough
Here’s the part that I think deserves more attention in the healthcare compliance conversation: what the proposed rule means for Managed Service Providers and other business associates.
Under the current rule, HHS has historically maintained that covered entities are not required to actively oversee how their business associates implement HIPAA safeguards, beyond obtaining substantial assurances through a Business Associate Agreement (BAA). For a lot of MSPs, that’s meant the BAA gets signed as a business formality without a deep operationalization of the underlying requirements.
The proposed rule tightens that relationship significantly. Per the NPRM, business associates would be required to notify covered entities “without unreasonable delay, but no later than 24 hours” after activating their contingency plans. Subcontractors would face the same notification obligation to the business associates they support. And per the NPRM’s organizational requirements section, covered entities must obtain written verification from a subject-matter expert confirming that business associates have deployed the required technical safeguards.
If you’re an MSP managing IT for healthcare clients, this is your cue to take a hard look at your own security posture. Not just whether you’ve signed the BAA, but whether you can actually attest to the technical controls the rule will require. Annual penetration testing. Encryption of any ePHI in your environment. MFA across the board. A tested contingency plan with a documented notification workflow. These become your direct obligations, not just your client’s.
The MSPs who treat this as an opportunity, building credible and documented compliance into their service delivery model and making it visible to clients, will have a real competitive advantage in the healthcare market as this rule moves toward enforcement.
At the End of the Day…
The proposed HIPAA Security Rule update is the regulation playing catch-up with a threat environment that has been ahead of it for years. The data from OCR’s own breach reporting portal makes the case plainly: the current framework, as written, hasn’t been enough. HHS is proposing to fix that by replacing flexible, self-assessed guidance with specific, mandatory, auditable controls.
Will every provision of the proposed rule survive the comment process intact? Maybe; maybe not. There were nearly 5,000 comments submitted, including significant pushback from the industry, and the final rule may look somewhat different than what was proposed. But the direction is pretty clear. The controls the proposed rule requires have been best practices for a long time so I wouldn’t bet on the requirements being loosened.
If you’re a covered entity or an MSP supporting healthcare clients and you want to work through what the proposed rule means for your specific environment (gap assessment, risk analysis, policy development, BAA review), reach out to us at IntelliGRC. We’d genuinely love to help. You can find us at https://intelligrc.com/contact or connect with me directly on LinkedIn.
Happy Implementing!
If you’re a covered entity or an MSP supporting clients and want to work through what this means for your specific environment- gap assessment, risk analysis, policy development- we’d genuinely love to help. Find us at IntelliGRC.com or connect with me on LinkedIn.
Steven Molter
IntelliGRC