The 2026 HIPAA Security Rule Update: What It Would Actually Require (And When)

The Short Answer

Current HIPAA rules set a floor of "reasonable and appropriate" safeguards, but they leave a lot of room for interpretation. HHS's Office for Civil Rights (OCR) has proposed a rule that would replace much of that flexibility with specific, mandatory requirements: named security controls, defined timelines, and minimum technical standards that covered entities must actually deploy. This is not a bill moving through Congress. It is a regulatory rulemaking under HHS's existing authority to update the HIPAA Security Rule, and as of this writing it still has not been finalized.

This article explains what current HIPAA requires, what the proposed rule would add, where the rulemaking actually stands, and what medical practices in the Greater Phoenix area should be checking right now regardless of when or whether a final rule is published.

Where the Rulemaking Actually Stands

HHS published a Notice of Proposed Rulemaking (NPRM) in December 2024 proposing the first major overhaul of the HIPAA Security Rule since 2013. The stated catalyst was the Change Healthcare breach of February 2024, which disrupted claims processing and billing for thousands of practices nationally and exposed data belonging to roughly 192.7 million people.

OCR originally targeted spring 2026 for a final rule. That deadline passed with nothing published. The rulemaking drew more than 4,700 public comments during its comment period, and a broad coalition of hospitals, health systems, and provider associations has formally asked HHS to withdraw or significantly soften the proposal, arguing that its cost and prescriptiveness are unworkable for small and rural providers in particular. The current target for a final rule is now around mid-2027, and the proposed rule itself includes a 240-day window (60 days to an effective date, plus a 180-day compliance period) after finalization before covered entities would actually need to comply. That points toward a realistic compliance deadline sometime in early 2028, assuming the current target holds.

Until a final rule is published in the Federal Register, none of this is binding. The current HIPAA Security Rule remains the law in force today.

A Framework for Comparing Old Rules to Proposed

Think of the gap between current HIPAA and the proposed rule across four dimensions:

• Specificity: What exactly must be in place versus what is left to judgment.
• Timelines: How fast the practice must act when something goes wrong.
• Verification: How often the practice must prove its controls actually work.
• Documentation: What evidence the practice must produce, and to whom.

Current HIPAA is strong on the first two dimensions in theory, but weak in practice because the standards are written in general terms. The proposed rule moves the needle sharply on all four.

What HIPAA Already Requires Today

The HIPAA Security Rule, which has been in force since 2005, covers electronically protected health information (ePHI). It organizes requirements into three categories: administrative safeguards (policies, training, workforce management), physical safeguards (facility and device controls), and technical safeguards (access controls, encryption, audit logs, transmission security).

The rule distinguishes between "required" and "addressable" implementation specifications. Required specifications must be implemented. Addressable specifications must be implemented unless the covered entity documents a reasonable alternative or determines the specification is not applicable. That addressable category has been a practical escape hatch for under-resourced practices for two decades — and it is the single biggest thing the proposed rule would eliminate for core technical controls.

On top of the Security Rule, the current Breach Notification Rule requires notifying affected individuals and HHS within 60 days of discovering a breach involving 500 or more individuals. Smaller breaches can be batched into an annual report. HIPAA enforcement today is complaint-driven and audit-triggered, not continuous — a practice can operate for years with significant security gaps and face no examination unless a breach or complaint brings HHS to its door.

What the Proposed Rule Would Change

The following reflects the direction of the proposed rule as published in the NPRM and reported in current industry coverage. Specific provisions could still change, be narrowed, or be dropped entirely before any final rule is published — this is an active, contested rulemaking, not a settled outcome.

1. Named, Mandatory Technical Controls (Eliminating "Addressable" Flexibility)

The most significant structural change: the proposed rule would eliminate the addressable-versus-required distinction for core technical controls and instead require covered entities to implement specific safeguards by name, including:

• Multi-factor authentication (MFA) for every system that accesses ePHI — EHR, billing, scheduling, imaging, secure messaging, and any file storage holding PHI.
• Encryption of ePHI at rest and in transit, with only limited exceptions, removing the general-guidance escape hatch that exists today.
• Network segmentation to isolate clinical systems from general-purpose networks.
• A current, documented asset inventory and network map.
• Vulnerability scanning (proposed at a semiannual cadence) and patch management on defined timelines.
• Annual penetration testing by a qualified third party.
• Audit logging with defined minimum retention periods.

Under current HIPAA, a practice could document that encryption is not reasonable and appropriate for a specific circumstance and skip it. Under the proposed rule, that flexibility would largely disappear for these core controls.

2. A Much Tighter Incident Response Window

The current 60-day window for notifying HHS of a significant breach would shrink dramatically. The proposed rule points toward a 72-hour window for significant incidents — some coverage describes this specifically as a restoration/initial-response window rather than a full investigative report. Either way, the direction mirrors notification timelines already in force in financial services regulation. For a medical practice, a 72-hour clock means the investigation and initial response work must happen in parallel, not sequentially, which requires having documented incident response procedures in place before a breach occurs, not written afterward under pressure.

3. Enhanced Business Associate Oversight

The proposed rule would tighten expectations around how covered entities verify — not just contractually attest to — their business associates' security postures, including their use of encryption and MFA. A signed Business Associate Agreement alone would not be treated as sufficient evidence of oversight.

4. Security Assessments on a Defined Cycle

HIPAA requires a risk analysis today, but not on a specific schedule or against a specific standard. The proposed rule points toward requiring more frequent, standardized risk assessments — closing the gap where a practice's last documented risk analysis is several years old and cannot demonstrate what has changed since.

Side-by-Side Comparison

What This Means for a Phoenix Medical Practice Right Now

Whether this specific proposal is finalized on schedule, delayed further, or narrowed in response to industry pushback, its direction reflects where federal healthcare security policy is heading, and has been heading since the Change Healthcare breach made the current rule's gaps impossible to ignore. Waiting for a final rule before acting is not the lower-risk path — especially given that the rulemaking has already missed one deadline and could easily miss another.

For a practice administrator or physician owner, the practical question is whether your current IT program could already demonstrate the controls the proposed rule would require. The checklist maps closely to what a properly structured managed IT and cybersecurity program already delivers:

• MFA on every system that touches ePHI. Your EHR, your email platform, your patient portal, and your billing system. If any of those access points lack MFA, that gap exists under current HIPAA's "addressable" standard too — the proposed rule would just make it unambiguously non-negotiable.
• Encryption at rest and in transit. Full-disk encryption on every laptop and workstation, plus encrypted transmission for anything that carries patient data outside the office network.
• Patch management on a defined schedule. Operating systems and clinical applications patched on a documented cycle, not on a when-we-get-to-it basis.
• Audit logging with retention. Activity logs from endpoints and Microsoft 365 retained for a period that satisfies both your HIPAA program obligations and whatever the eventual final rule requires. HIPAA already requires retention of program documentation for six years — a longer obligation than a standard one-year endpoint SIEM baseline. Your HIPAA program and your managed IT provider should align on what retention your specific situation requires.
• A documented incident response plan. Written, tested, and capable of producing an initial response within a compressed window if needed. Not a template sitting in a drawer.
• A current risk assessment. Updated at least annually, or whenever a significant change in the environment occurs (a new EHR, a new location, a merger).

The Division of Responsibility Your Practice Needs to Understand

One point the proposed rule would make more explicit, but that applies equally today: the practice owns its HIPAA compliance program. No IT vendor, managed service provider, or software platform makes a practice compliant. What a managed IT provider does is implement, operate, monitor, and document the technical safeguards that support that program. The physician owner or administrator remains responsible for ensuring the program is complete and current.

This matters when evaluating what an IT provider is actually doing for your practice. The questions worth asking:

• Is MFA enforced on all ePHI-adjacent systems, or just recommended?
• Are endpoint devices encrypted, and can that encryption status be reported on demand?
• Is patch compliance documented, and how quickly are critical patches applied?
• Is there a documented incident response plan, and when was it last tested?
• Has a formal risk assessment been conducted in the past 12 months?
• Are audit logs retained in a way that supports your HIPAA program's six-year documentation requirement?

If those questions do not have clear, documented answers, a final rule will not create those answers on its own. The practice's operations will, with the right operational support behind them.

A Note on Planning Costs

For a Phoenix-area medical practice evaluating what properly managed IT and cybersecurity should cost, Onsite Technical Services uses a planning benchmark of approximately $200 to $250 per user per month for the managed IT and security program appropriate for a medical practice operating under HIPAA. That figure covers the managed IT labor and security stack, on a per-user basis. It is planning guidance, not a quote. Microsoft 365 licensing, EHR-specific integrations, hardware, and project work such as a formal risk assessment are separate costs. The right number for your practice depends on your user count, your clinical technology environment, and the specific operational responsibilities involved.

What that range buys, in operational terms: a team responsible for the daily technical work (patching, monitoring, identity management, backup verification, security alerting, and helpdesk support), the tooling to deliver it, and the documentation that supports your HIPAA program when questions arise.

The Bottom Line

The proposed HIPAA Security Rule update is not law, is not moving through Congress, and has already missed one finalization target. But the direction of federal healthcare cybersecurity policy is clear regardless of this specific rulemaking's fate: more specific controls, faster incident response, and more documentation to prove safeguards are actually operating, not just written down. The practices best positioned for whatever comes next are the ones that have stopped treating HIPAA as a paperwork exercise and started treating it as an operational discipline supported by technical work that happens every day, not just when a final rule — or an auditor — asks.

A breach does not wait for a rule to finalize. Neither should the controls designed to prevent one.

Book a Consult