In January 2025, the Department of Health and Human Services proposed the first major rewrite of the HIPAA Security Rule since 2013. The proposal would make multi-factor authentication, encryption, and network segmentation mandatory, remove the long-standing distinction between "required" and "addressable" safeguards, and add specific deadlines for incident response and recovery. Almost two years later, the rule still has not been finalized, and HHS has pushed final action back to mid-2027. For software teams building or maintaining healthcare applications, that gap between "proposed" and "final" is exactly where planning mistakes happen. This article explains what the proposal actually says, where it stands today, and what to build regardless of when (or if) it takes effect.
What the 2025 Proposal Actually Changes
The Notice of Proposed Rulemaking, titled "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information," was published in the Federal Register on January 6, 2025, with a 60-day public comment period that closed in March 2025. It amends the technical, administrative, and organizational requirements in 45 CFR Part 164. The core structural change is the one that matters most to engineering teams: it eliminates the "addressable" category entirely. Every implementation specification becomes required, with only a small number of specific exceptions.
The specific technical requirements proposed include:
- Encryption of electronic protected health information (ePHI) at rest and in transit, with limited exceptions
- Multi-factor authentication for access to systems containing ePHI, with limited exceptions
- Network segmentation to limit how far an attacker can move after an initial compromise
- Annual asset inventories and network maps showing how ePHI flows through systems
- A more detailed risk analysis that reviews those inventories and maps, identifies specific threats and vulnerabilities, and assigns a risk level to each one
- Vulnerability scanning at least every six months and penetration testing at least annually
- Anti-malware deployment, removal of unnecessary software, and disabling of unused network ports based on risk analysis findings
- Incident response plans that restore critical systems within 72 hours, prioritized by system criticality, with written testing and revision
- An annual compliance audit against the Security Rule's requirements
- Written documentation for every Security Rule policy, procedure, plan, and analysis
- Notification between covered entities and business associates within 24 hours of a workforce member's termination or an access change affecting ePHI
Business associates would face additional obligations: notifying covered entities within 24 hours of activating a contingency plan, and providing annual written certification from a subject matter expert that required technical safeguards are actually in place. If your company builds software for healthcare clients as a vendor rather than a covered entity, that certification requirement is worth reading twice, because it shifts from "we say we're secure" to "a named expert attests to it in writing, every year."
Where the Rule Stands Now: Delayed, Not Dead
As of late 2026, this remains a proposal. HHS's regulatory agenda now lists the rule under "long-term actions" with a projected final action date of July 2027, pushed back from an earlier May 2026 target. Placement on the long-term agenda generally signals that the agency does not expect to finalize the rule within the next twelve months. HHS has not published a public explanation for the delay, though the volume of public comments (reportedly in the thousands) is a reasonable factor.
What this means practically: nothing in the proposal is enforceable today. The current Security Rule, including the "addressable" category, remains in effect, and the Office for Civil Rights continues to enforce it as written. Software teams sometimes treat a pending NPRM as a reason to wait on hardening work, on the theory that the final requirements might change. That reasoning gets the risk backwards. The proposal describes controls that are already considered baseline good practice in any application handling sensitive data, HIPAA-regulated or not. Waiting for a 2027 deadline to arrive doesn't reduce your current breach risk or your current liability under the existing rule.
"Addressable" Has Never Meant Optional
This is the misunderstanding that causes the most damage, and it predates the 2025 proposal entirely. Under the current Security Rule, when an implementation specification is marked "addressable," a covered entity or business associate must still do one of three things: implement it as written, implement a reasonable and appropriate alternative, or document a clear reason why neither is necessary given the organization's risk analysis. "Addressable" was never a synonym for "skip this." It was a built-in flexibility mechanism for organizations with genuinely different risk profiles, not a loophole for organizations that simply didn't get around to encryption.
Encryption of ePHI at rest is a clear example. It has been addressable since 2003. Most OCR enforcement actions and breach settlements that cite missing encryption do not argue that encryption was secretly required all along, they argue that the organization never completed a risk analysis that could justify skipping it, or that the alternative it chose wasn't actually reasonable for the data involved. The 2025 proposal would simply remove the judgment call. Teams that already treat addressable specifications as required, which is the only defensible engineering posture, will find the proposed rule changes almost nothing about their actual architecture.
What This Means for Teams Building Healthcare Software
Whether or not the rule is finalized in 2027, the specific controls in the proposal map directly onto decisions a development team makes early in a project, not late.
Authentication
Multi-factor authentication for anything touching ePHI should be the default state of a new build, not an optional setting enabled later for "enterprise" customers. The complication is accessibility: mandatory MFA that assumes a smartphone and reliable cell service can lock out exactly the patient population, often older or lower-income, that a provider most needs to reach. We covered this tradeoff and some workable alternatives (backup codes, caregiver-assisted access, hardware tokens) in our piece on accessible patient portal authentication.
Encryption and network design
Encrypting data at rest and in transit, and segmenting networks so that a compromised component (a reporting dashboard, a third-party widget, a staging environment) cannot reach the full ePHI store, are architecture decisions, not patches. Retrofitting segmentation into a system that was built as one flat network is far more expensive than designing tenant and service boundaries up front. Our HIPAA-conscious cloud hosting checklist goes through the specific controls major cloud providers do and don't cover under a signed BAA.
Audit logging and risk analysis
The proposed rule's more detailed risk analysis requirement (reviewing a current asset inventory, naming specific threats, and assigning risk levels) only works if the underlying system actually produces usable logs and a current inventory to analyze. A risk analysis written from memory, disconnected from what the system actually logs and exposes, won't survive an OCR audit today and definitely won't satisfy the proposed annual compliance audit requirement. We go into log design specifics in our article on audit logging in healthcare software.
Vendor and business associate obligations
If your company is the vendor rather than the covered entity, the proposed 24-hour notification windows and annual certification requirement are worth building into your contracts and your incident response runbook now, independent of the rule's final text, because clients are increasingly asking for this in their BAAs regardless of federal timing. See our guide to HIPAA business associate agreements for what a BAA needs to cover today.
A Practical Checklist to Build Toward Now
None of the following requires waiting for a final rule. Each one reduces real breach risk under the current Security Rule and happens to anticipate the proposed one:
- Encrypt ePHI at rest and in transit by default, with no configuration path that silently disables it
- Require multi-factor authentication for administrative and clinical-staff access today; plan an accessible path to it for patient-facing accounts
- Maintain a current inventory of systems, data flows, and third-party integrations that touch ePHI, not a diagram from the original project kickoff
- Segment networks and services so a breach in one component has a bounded blast radius
- Write a risk analysis tied to that inventory, with specific threats and documented decisions, and revisit it when the architecture changes, not once a year on a calendar reminder
- Build audit logging that records who accessed what ePHI and when, in a format someone could actually review during an incident
- Write and test an incident response plan, including realistic recovery time targets for the systems that matter most
- Run vulnerability scans and, if budget allows, periodic penetration testing rather than a one-time pre-launch assessment
What to Do While You Wait
Treat the proposed rule as a credible preview of where enforcement is heading, not as a deadline to plan around. Three practical steps: first, don't let "it's not final yet" become an excuse to defer controls your risk analysis already says you need. Second, if you're negotiating a BAA or vendor contract now, it's reasonable to reference the proposed requirements (annual certification, 24-hour notification) as a forward-looking standard, even though neither party is legally bound to them yet. Third, keep an eye on the regulatory agenda rather than news cycles. Projected dates on long-term agendas slip regularly, and the next update could move the timeline again in either direction.
This article is general information about a federal rulemaking process and existing regulatory text, not legal advice. HIPAA compliance depends on your specific risk analysis, your organizational safeguards, your contracts, and your infrastructure, and a qualified healthcare attorney or compliance professional should review your specific situation, especially before you finalize contract language tied to a rule that hasn't been finalized.
If you're planning a healthcare product and want the security architecture decided correctly the first time rather than retrofitted later, our team can walk through your specific risk profile on a strategy call, or you can read more about how we approach security and compliance on our healthcare security and HIPAA page.
Frequently Asked Questions
Is the HIPAA Security Rule changing in 2026?
Not yet. The proposed changes from the January 2025 NPRM have not been finalized. HHS's regulatory agenda now projects final action in July 2027, and that date is a planning estimate, not a guarantee.
Does "addressable" mean a safeguard is optional today?
No. Under the current rule, an addressable specification must still be implemented, replaced with a documented reasonable alternative, or excused by a specific, documented justification in a completed risk analysis. It has never meant "skip it."
Will multi-factor authentication become legally required?
It's proposed as mandatory, with limited exceptions, but it is not yet final. Many healthcare organizations already require it for administrative and clinical access as a practical security measure, independent of the rule's status.
Should we wait for the final rule before investing in these controls?
No. Every control in the practical checklist above reduces risk under the Security Rule that is in effect right now and is unlikely to become less relevant once the rule is finalized, whenever that happens.