HIPAA Security Rule Proposed Changes: Status and What to Do

In late December 2024, the U.S. Department of Health and Human Services (HHS) announced the most significant proposed overhaul of the HIPAA Security Rule since 2013. It would turn many of today's "best practices" into hard requirements: multi-factor sign-in, encryption, a written inventory of every system that touches patient data, the ability to restore critical systems within 72 hours, regular vulnerability scans and penetration tests, and annual compliance audits.

Since then, practice managers have heard everything from "it's already law" to "it's dead." Neither is accurate. This article explains exactly where the proposal stands, what it would require, how it compares to the current rule, and, most usefully, which parts you should do now regardless of what happens in Washington.

Status as of October 5, 2026: The proposed rule has not been finalized. We checked the Federal Register on October 5, 2026 and found no final rule. The federal regulatory agenda on reginfo.gov lists the rulemaking (RIN 0945-AA22) as a long-term action with final action targeted for July 2027. The previous agenda had targeted May 2026. The current HIPAA Security Rule remains fully in effect and enforced. Rulemaking status can change quickly; check the Federal Register and HHS for the latest.

What is the HIPAA Security Rule NPRM?

It's a Notice of Proposed Rulemaking (NPRM), the formal first step federal agencies take to change a regulation. HHS's Office for Civil Rights (OCR), which enforces HIPAA, published it in the Federal Register on January 6, 2025 (90 FR 898) under the title "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information."

The HIPAA Security Rule (45 CFR Part 164, Subpart C) is the part of HIPAA that sets safeguards for ePHI, electronic protected health information. It applies to covered entities (providers, health plans and clearinghouses) and their business associates (vendors that handle PHI for them, including IT providers). It was last substantially updated in 2013, before ransomware became the dominant threat to healthcare.

An NPRM is a proposal, not a law. The process looks like this:

1. Proposed rule published with a public comment period.
2. Comments reviewed. The docket for this rule (HHS-OCR-2024-0020) shows 4,747 comments received.
3. Final rule drafted, reviewed inside the government (including the White House Office of Management and Budget), then published.
4. Effective date and compliance date set in the final rule.

The agency can finalize the rule as proposed, change it substantially, split it up, or withdraw it.

What is the current status of the proposed HIPAA Security Rule?

As of October 5, 2026, the proposal is pending and has not been finalized. It's listed on the federal regulatory agenda as a long-term action, with final action targeted for July 2027.

Here's the timeline as best we can document it:

What "long-term action" means

The Unified Agenda is the government's twice-yearly list of rules agencies plan to work on. Placing a rule on the "long-term actions" list generally signals the agency doesn't expect to finalize it within the next 12 months. The target date is an estimate, not a commitment. Dates in the agenda have slipped before, for this rule and many others.

What could happen next

There are four realistic outcomes:

1. Finalized largely as proposed, likely in 2027 or later.
2. Finalized with changes. Given the volume of comments about cost and burden, especially from small and rural providers, a scaled-back or phased version is plausible.
3. Delayed further.
4. Withdrawn. Possible, given industry opposition and a broader federal push to reduce regulatory burden, though HHS has kept the rule on its agenda.

We can't tell you which will happen. Nobody outside HHS can. What we can tell you is that the underlying threats haven't waited, and neither has OCR enforcement under the current rule.

When would it take effect if finalized?

The proposal says a final rule would be effective 60 days after publication, and regulated entities would have 180 days after the effective date to comply, roughly eight months from publication. There are also proposed transition provisions for updating existing business associate agreements. If HHS hit its July 2027 target, compliance would land around early 2028. Treat that as an estimate.

Why did HHS propose changing the Security Rule?

HHS pointed to a sharp rise in large healthcare breaches, mostly from hacking and ransomware, and to recurring compliance gaps it sees in its investigations. According to HHS's announcement of the proposal, reports of large breaches rose 102% from 2018 to 2023, and the number of individuals affected rose 1002%, mainly because of hacking and ransomware. HHS reported that over 167 million people were affected by large breaches in 2023, a record.

HHS also said the current rule's flexibility had been misread. Many organizations treated "addressable" as "optional," performed superficial risk analyses, or never documented their decisions. The proposal tries to close those gaps with specific, measurable requirements.

What would the proposed rule change?

The proposal would make nearly every safeguard mandatory, require specific technical controls, and set fixed timeframes for testing and review. Here's a side-by-side summary of the major changes, based on the NPRM and HHS's fact sheet.

Let's look at the ones that matter most for a small practice.

No more "addressable"

Under the current rule (45 CFR 164.306(d)), "addressable" specifications let you decide whether something is reasonable and appropriate, and document an alternative if not. The proposal would remove most of that flexibility. Encryption, for example, would simply be required, with narrowly defined exceptions.

For practices that already treat "addressable" as "do it unless there's a documented reason," this changes little. For those that skipped addressable items, it changes a lot.

Technology asset inventory and network map

A technology asset inventory is a written list of every device, application and service that creates, stores, receives or transmits ePHI. A network map shows how ePHI moves between them: from the front desk PC to the practice management server, to the cloud EHR, to the clearinghouse, to the billing company.

The proposal would require both, reviewed at least every 12 months and whenever something significant changes. In our experience, this is the single most revealing exercise a practice can do. It's usually where we find the forgotten Windows 7 PC attached to the panoramic X-ray machine, or the old NAS in the closet with ten years of scanned records.

Multi-factor authentication

Multi-factor authentication (MFA) means proving your identity with two different kinds of evidence, usually a password plus a code or prompt on your phone. The proposal would require it for access to systems containing ePHI, with limited exceptions such as certain legacy systems and older FDA-authorized medical devices, where the organization would need a migration plan. Our MFA guide explains the options.

Encryption at rest and in transit

Encryption at rest protects stored data, such as a laptop's hard drive or a backup. Encryption in transit protects data moving across a network, such as email or a connection to a cloud EHR. The proposal would require both, with limited exceptions (for example, when a patient asks to receive their information unencrypted). See our email encryption guide for how that works with patients today.

Vulnerability scanning and penetration testing

A vulnerability scan is an automated check for known weaknesses, such as missing patches or misconfigured services. A penetration test is a deliberate, authorized attempt by a security professional to break in, which shows whether weaknesses can actually be exploited. The proposal would require scans at least every six months and penetration tests at least every 12 months.

Patching within set timeframes

The proposal would require written patch management policies that set timeframes based on risk. Discussion of the proposal has pointed to timeframes such as 15 days for critical risks and 30 days for high risks. CISA's Known Exploited Vulnerabilities catalog is a useful list of flaws attackers are actively using, and a good place to start prioritizing.

Restoring critical systems within 72 hours

The proposal would require written procedures to restore the loss of critical systems and data within 72 hours, with restoration prioritized by how critical each system is. For a small practice, "critical" usually means the practice management system, the EHR, imaging, email and phones.

This is the requirement that most often exposes a gap. Many practices have backups but have never timed a full restore. Our backup and disaster recovery guide and EHR downtime and failover plan cover how to test this.

Annual compliance audits

The proposal would require a compliance audit at least every 12 months, internal or external. Today the rule requires "periodic" technical and non-technical evaluation without fixing an interval.

Faster access termination

When someone leaves, their access would need to end no later than one hour after their employment or work arrangement ends, and other regulated entities would need to be told within 24 hours if that person had access to their systems.

Tighter business associate oversight

Business associates, including IT providers, billing companies and cloud vendors, would need to verify at least once a year, in writing, that they have the required technical safeguards in place, and notify covered entities within 24 hours of activating a contingency plan. Our BAA guide covers what to ask vendors today.

What does the current Security Rule already require?

More than many practices realize. A lot of the proposal makes explicit what OCR already expects under today's rule. If you're measured against the current rule after a breach, these are the requirements that come up first:

1. Risk analysis (45 CFR 164.308(a)(1)(ii)(A)) is a required specification. It must be "accurate and thorough" and cover the risks to the confidentiality, integrity and availability of all the ePHI you hold. In practice, that already means knowing where your ePHI is, which is most of an asset inventory.
2. Risk management is required: you must implement measures that reduce the risks you found to a reasonable level.
3. Information system activity review is required: regularly reviewing records like audit logs and access reports.
4. Security awareness training for all workforce members is required.
5. Contingency planning is required, including a data backup plan, a disaster recovery plan and an emergency mode operation plan. Testing and revising those plans is currently addressable.
6. Evaluation is required: periodic technical and non-technical evaluation of how well your safeguards meet the rule.
7. Business associate agreements are required with every vendor that handles your ePHI.
8. Unique user identification is required; shared logins don't meet it.
9. Audit controls and person or entity authentication are required technical standards.

So when people say "the new rule will require a risk analysis and backups," that's not quite right. Those are already required. What the proposal adds is specificity: how often, how fast, in what format, and with what evidence.

What should a technology asset inventory include?

A useful inventory lists each system, what ePHI it touches, who's responsible, and how it's protected. It doesn't need special software. A spreadsheet works fine for a small practice, as long as someone keeps it current. Here's the format we use:

The value comes from the "ePHI involved" and "Key protections" columns. When a row has ePHI but weak protections, that's a risk your analysis needs to address. Defender for Business and Intune can export much of the device list for you; the cloud services, medical devices and the "network map" arrows are where human knowledge comes in.

How to write a 72-hour restore plan

A restore plan says which systems come back first, how, from where, and who does it, and it's proven by a test. The 72-hour target in the proposal is a useful benchmark even if the rule never becomes final, because three days is about as long as most small practices can operate on paper before patient care and cash flow suffer.

1. List your critical systems in priority order. For most practices: internet and phones, practice management or EHR access, email, imaging, then everything else.
2. For each, write down where its backup lives (local appliance, cloud, vendor-hosted), how recent it typically is, and who has the credentials to restore it.
3. Estimate the restore time, then test it. Restoring a full server image from the cloud can take far longer than people expect over a typical small-office internet connection.
4. Plan for the attacker scenario. In ransomware, your normal admin accounts and connected backups may be compromised. At least one backup copy should be offline or immutable, meaning it can't be changed or deleted for a set period.
5. Write down how the practice runs in the meantime. Paper schedules, printed day sheets, phone forwarding to cell phones, and how you'll check in patients.
6. Assign roles. Who calls the IT provider, who calls the cyber insurer, who talks to staff and patients.
7. Test at least annually, and after major changes. Record the date, what you restored, how long it took and what went wrong.

That last row is typical: tests almost always reveal a step nobody thought of. Better to find it on a quiet Friday afternoon than during an outage. Our hurricane preparedness guide covers the same planning for Florida storm season.

Medical devices and legacy systems: what about the exceptions?

The proposal recognizes that some systems can't meet every requirement, and asks for a documented plan rather than a blanket pass. HHS proposed limited MFA exceptions for certain legacy systems and for some older FDA-authorized medical devices, with an expectation that organizations plan a migration away from them.

That's how we'd treat these systems today anyway:

1. List them in the asset inventory with the reason they can't be updated or protected normally (for example, the imaging vendor doesn't support a newer operating system).
2. Isolate them on a separate network segment so that if they're compromised, the attacker can't reach the rest of the practice.
3. Restrict their use. No email, no web browsing, no general file sharing from those machines.
4. Monitor them with endpoint protection if the vendor allows it.
5. Ask the vendor in writing for their roadmap and support dates, and keep the answer.
6. Budget for replacement, and record the planned date in your risk analysis.

Our dental imaging network and computer guide goes into how to set this up for X-ray sensors, pans and cone-beam CT units.

Questions to ask your IT provider now

If you work with an IT provider, these questions show whether they're ready to support you under either the current or proposed rule:

1. Can you produce a current inventory of every device and cloud service that touches our patient data?
2. Do we have a network diagram showing where patient data flows?
3. Is MFA enforced on every account with access to ePHI, including admin and service accounts?
4. Is every laptop and PC encrypted, and can you show me the report?
5. How quickly are critical patches applied, and how do you track it?
6. When did we last do a timed restore test, and how long did it take?
7. Is at least one backup copy immutable or offline?
8. When was our last vulnerability scan? Have we ever had a penetration test?
9. How fast is access removed when someone leaves?
10. Will you sign a BAA, and would you be able to give us written confirmation of your own safeguards each year?

How much would the proposed rule cost?

HHS estimated about $9 billion in costs across regulated entities in the first year, and about $6 billion per year for years two through five. Industry groups that asked for the rule to be rescinded called that estimate inadequate and argued the costs would fall hardest on small and rural providers.

For a single small practice, the cost depends almost entirely on where you start:

Rather than guessing at dollar figures for your practice, our managed IT cost guide explains what typically drives cost for a 5 to 50 person office.

Do these now anyway: the practical case

Almost every control in the proposal is already expected by someone: OCR when it investigates a breach, your cyber insurer when it underwrites your policy, or attackers when they look for an easy target. Waiting for a final rule is a poor reason to delay controls that reduce real risk today.

Three reasons to act now:

1. OCR enforces the current rule, and the risk analysis is its first question. OCR's resolution agreements in 2025 and 2026 repeatedly cite the lack of an accurate and thorough risk analysis, often discovered after a ransomware attack or phishing incident. Several have come under its Risk Analysis Initiative.
2. Cyber insurers already ask. Applications commonly ask about MFA on email and remote access, endpoint detection and response, backups and patching. A "no" can mean higher premiums, exclusions or no coverage. See our cyber insurance requirements checklist.
3. The controls work. MFA blocks the large majority of password-based account takeovers. Encrypted laptops turn theft into a non-event. Tested backups are the difference between a bad week and a closed practice after ransomware.

Priority list for small practices

Here's how we'd prioritize the proposal's requirements for a 5 to 50 person practice, and how each maps to tools most practices already have.

A 90-day plan to get ahead of the proposed rule

You can cover the highest-value items in about three months without disrupting patient care. Here's a realistic sequence for a small practice.

Days 1–30: Know what you have and close the biggest holes

1. Build the asset inventory. List every computer, server, phone, tablet, medical device with a computer inside, cloud service and app that touches patient data. Include who owns it and where it lives.
2. Draw the network map. A one-page diagram is fine: internet connection, firewall, Wi-Fi networks, PCs, server, imaging devices, cloud services, and the arrows showing where patient data flows.
3. Turn on MFA everywhere it's missing, starting with email, remote access and admin accounts.
4. Confirm disk encryption on every laptop and PC.
5. Check offboarding. Find any accounts belonging to people who've left and disable them.

Days 31–60: Prove you can recover

1. Review backups. What's backed up, how often, where, and is at least one copy offline or immutable?
2. Do a timed restore test of your most critical system. Write down how long it took.
3. Write the restore order: which systems come back first, who does what, and how you'll run the practice while they're down.
4. Review your incident response plan, or write one. Our HIPAA breach response plan article has a template.

Days 61–90: Test and document

1. Run a vulnerability scan, internal and external, and fix critical and high findings.
2. Update the risk analysis with the inventory, network map, scan results and restore test.
3. Review business associates. Confirm you have a current BAA with each, and ask your IT provider and key cloud vendors to describe their security safeguards in writing.
4. Schedule the next scan (six months), the next penetration test and compliance review (12 months), and the next restore test (quarterly is ideal).

Our free HIPAA security checklist tool is a quick way to see where your practice stands before you start.

Scenario walk-throughs

A five-person dental office with a local server

The practice runs its practice management and imaging software on a server in a back closet. Email is in Microsoft 365 Business Standard. Two front desk PCs share a login.

Where the proposal would hit hardest: shared logins (unique user IDs are already required today), no MFA on the server, no device management, backups to a USB drive that hasn't been checked in a year, and no network map. The X-ray sensor PC runs an older version of Windows because of the imaging software.

What to do now: separate logins, MFA on email and remote access, move to Business Premium for device management and encryption, a proper backup with an offsite immutable copy and a timed restore test, and isolate the imaging PC on its own network segment with documentation explaining the exception. Our dental office IT guide covers the imaging side, and our dental practice case study shows a practice that moved to encrypted cloud storage, managed devices and MFA, and kept running through internet outages with cellular failover.

A 25-person medical practice on a cloud EHR

Two locations, a cloud EHR with its own MFA, Microsoft 365 Business Premium, and an outside billing company.

Where the proposal would hit hardest: documentation and testing more than technology. The practice likely needs a written asset inventory and network map, a 72-hour restore plan for local systems and email (the EHR vendor handles its own platform, but the practice needs to know how it would work without it), scheduled scans, an annual penetration test, and annual written confirmation from its billing company and IT provider.

What to do now: document what's already in place, test failover for internet outages, and add the scan and audit schedule. See our medical office IT guide.

A business associate: a billing company or IT provider

Business associates would carry new obligations directly: annual written verification of safeguards and 24-hour notification of contingency plan activation.

What to do now: be ready to answer your healthcare clients' questions in writing. Covered entities are already asking vendors for this information, especially after high-profile incidents at large healthcare vendors.

How the proposal lines up with existing guidance

Very little in the proposal is new to anyone who follows existing federal healthcare security guidance. It largely takes controls HHS and NIST have recommended for years and makes them mandatory. That's useful, because it means you can work from free, published resources rather than waiting for final rule text.

• NIST SP 800-66 Revision 2 (February 2024), "Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide," walks through each Security Rule standard with practical activities and maps them to the NIST Cybersecurity Framework. It's the most detailed free guide to doing a HIPAA risk analysis properly.
• HHS 405(d) Health Industry Cybersecurity Practices (HICP) is a joint industry and government publication with separate guidance for small, medium and large organizations. Its ten cybersecurity practices cover email protection, endpoint protection, access management, data protection and loss prevention, asset management, network management, vulnerability management, incident response, medical device security and cybersecurity oversight and governance. That list overlaps heavily with the proposal.
• HHS's voluntary Healthcare and Public Health (HPH) Cybersecurity Performance Goals, released in January 2024, set out "essential" and "enhanced" goals such as MFA, basic email security, vulnerability mitigation and asset inventory.
• Cyber insurance applications ask about many of the same controls, often with more specific wording than HIPAA ever used.

If you align with NIST SP 800-66r2 and the 405(d) small-practice practices today, and keep your documentation current, you'll be well positioned whatever form a final rule takes.

A note on "HIPAA certified" vendors

There's no government certification for HIPAA compliance, and that won't change under the proposed rule. A vendor claiming to be "HIPAA certified" means it has done its own or a third party's assessment, not that HHS has approved it. What matters is the vendor's BAA, its actual safeguards, and its willingness to describe them in writing. That written description is exactly what the proposal would require from business associates each year, so it's reasonable to start asking for it now.

Mistakes to avoid while the rule is pending

1. Treating the proposal as law. Vendors sometimes market "2025 HIPAA compliance" packages as if the rule were final. It isn't. Your obligations today come from the current rule.
2. Treating the proposal as dead. It's delayed, not withdrawn. And the controls in it are what investigators and insurers already look for.
3. Buying tools before doing the inventory. Start with what you have. Many practices already pay for Microsoft 365 features they haven't turned on.
4. Ignoring documentation. Under both the current and proposed rules, "we do it but didn't write it down" is a finding.
5. Forgetting medical devices. Imaging PCs, lab analyzers and other connected equipment are often the oldest, least-patched systems in a practice.
6. Not testing restores. A backup you've never restored is a hope, not a plan.

How to track the rule's status yourself

You don't need to rely on vendor blogs (including this one). The authoritative places to check are:

1. The Federal Register document for the proposed rule (2024-30983). A final rule would appear as a new Federal Register document.
2. Reginfo.gov, searching for RIN 0945-AA22, which shows the agenda stage and target dates.
3. HHS's HIPAA Security Rule NPRM page and OCR's announcements.
4. Regulations.gov docket HHS-OCR-2024-0020, for the public comments.

We'll update this article when the status changes.

The bottom line

The proposed HIPAA Security Rule is a clear signal of where healthcare cybersecurity expectations are heading: MFA, encryption, a real inventory, tested recovery, regular testing and documentation. As of October 5, 2026, it's still a proposal, with final action targeted for July 2027, and the current rule remains the law you're measured against.

The practical move is the same either way: do a real risk analysis, turn on MFA and encryption, know what systems you have, prove you can restore them, and write it all down. If the rule is finalized, you'll be most of the way there. If it isn't, you'll still be far harder to breach and far easier to defend.

If you'd like help building your asset inventory, testing your restore plan, or mapping your current setup against the proposed requirements, see our compliance services and healthcare IT services, or book a free 20-minute call.