Every few weeks a practice asks us whether the new HIPAA Security Rule has taken effect and whether they need multifactor authentication on everything by a certain date. The answer, as of this month, is that there is no new rule. There is a proposal, published in the Federal Register on January 6, 2025, with a comment period that closed March 7, 2025. Thirteen months later, HHS has not finalized it.
That does not mean nothing has changed. The Office for Civil Rights has been enforcing the existing Security Rule more actively than at any point in its history, with a specific focus on the risk analysis requirement. And most of what the proposal would require is what a competent security program does anyway. So the practical question is not whether to wait for the rule. It is which of the proposed requirements to adopt now because they are cheap, sensible and likely to survive in some form.
Key takeaways
- The HIPAA Security Rule rewrite proposed on January 6, 2025 is still a proposal as of February 2026; the regulatory agenda target of May 2026 is a target, not a date.
- OCR is enforcing the current rule now, and the risk analysis is the requirement that appears in nearly every settlement.
- Most of what the proposal would require (asset inventory, MFA, encryption, tested 72-hour restores, patching windows) is what a competent security program does already.
- Adopt the cheap items this quarter; defer only large projects scheduled around a compliance date that does not exist.
- Start asking business associates for written descriptions of their safeguards now; the proposal would make it an annual requirement.
Where the proposal stands
The Spring 2025 federal regulatory agenda listed a target of May 2026 for final action. Targets on that agenda move often. Hospital and provider associations, including a coalition of more than a hundred health systems and associations led by CHIME that wrote to the HHS Secretary on December 8, 2025, have formally asked HHS to withdraw or substantially narrow the proposal, arguing that HHS underestimated compliance costs for small and rural providers. Vendors and security professionals have generally supported it. Our reading is that some version will eventually be finalized, that the timelines will be longer than proposed, and that the core technical requirements will remain. But that is a reading, not a fact, and we would not build a budget on any specific date.
What the proposal would require
The proposal would remove the distinction between "required" and "addressable" implementation specifications, making everything required unless a specific exception applies. The main additions:
| Proposed requirement | What it means in a practice | Do it now? |
|---|---|---|
| Written technology asset inventory and network map, updated at least annually | A list of every device and system that touches ePHI and how data moves between them | Yes; you cannot do a real risk analysis without it |
| Risk analysis with specified elements | Identify threats and vulnerabilities per asset, assess likelihood and impact, document | Yes; this is already required and is OCR's top enforcement target |
| Multifactor authentication | MFA on access to systems containing ePHI, with limited exceptions | Yes; most EHRs and email systems already support it at no cost |
| Encryption of ePHI at rest and in transit | Encrypted laptops, phones, servers, backups and email | Yes; a lost unencrypted laptop is a reportable breach, an encrypted one is not |
| Vulnerability scanning every six months and penetration testing annually | Automated scans of your network and a third-party test | Scanning yes; penetration testing depends on size and budget |
| Restore critical systems within 72 hours | Tested backups and a written recovery plan | Yes; ransomware makes this a business survival question |
| Patching within defined windows (15 days for critical, 30 for high) | A patch schedule and someone responsible for it | Yes, or as close as your vendors allow |
| Annual compliance audit | An internal or third-party review against every specification | Reasonable; many practices already do a version of this |
| Annual written verification from business associates | Each vendor confirms in writing it has the required safeguards | Start collecting; it changes the BA conversation |
| Network segmentation | Separating clinical systems from guest Wi-Fi, IoT devices and general office use | Yes for guest Wi-Fi at minimum |
What OCR is enforcing today
OCR announced a risk analysis enforcement initiative in late 2024 and has announced a steady series of settlements under it since, many with small and mid-sized providers, and many following a ransomware incident. The pattern in the resolution agreements is consistent: the organization either had no risk analysis, had one that was years old, or had one that did not cover all systems containing ePHI. The financial penalties vary; the corrective action plans, which run for years and require OCR review of policies, are the expensive part.
The lesson for a practice is that the current rule already requires a thorough, current risk analysis, and that "we had our IT vendor run a scan" is not one. A risk analysis identifies where ePHI is, what could go wrong, how likely it is and how bad it would be, and what you are doing about it. It is documented, dated, and updated when something changes.
A practical way to tell whether yours would hold up: open it and look for three things. Does it list the systems by name, including the practice management system, the email platform, the phone system if it stores voicemail transcriptions, and the imaging or lab interfaces? Does each identified risk have a likelihood, an impact and a decision, even if the decision is to accept the risk? And is there a date on it from the last twelve months, with a note of what changed since the prior version? A document that answers all three is a risk analysis. A vendor's network scan report, a signed HIPAA policy binder or a completed questionnaire from a cyber insurance application is not, although each is useful input to one.
What this means for a small practice budget
The compliance cost argument from the provider coalition is about hospitals and health systems with thousands of devices. For a practice with fifteen workstations, four laptops and a cloud EHR, most of the proposed requirements are configuration work rather than spending. MFA is a setting in the EHR, the email tenant and the remote access tool. Full-disk encryption is built into current Windows and macOS. A tested restore is an afternoon with your IT vendor and a written result. The items that cost real money are penetration testing, network segmentation beyond guest Wi-Fi, and a formal annual audit, and those are the ones where a small practice can reasonably wait to see what the final rule requires and on what timeline. We would not spend on them in 2026 because of the proposal; we would spend on them if the risk analysis says the practice needs them.
A note on vendors
Revelrex handles protected health information for the practices we bill for, and we maintain HIPAA compliant and SOC 2 compliant operations for that reason. When a practice asks us for written verification of our safeguards, we provide it, and we think every business associate should be able to. If a vendor cannot describe its safeguards in writing, that is information. The full list of what we do for practices is on the medical billing page, and practices that want a second opinion on their own security documentation before an OCR inquiry can book a call.
Questions we hear
If the rule is not final, can OCR penalize us for not having MFA?
Not for the absence of MFA as such, because the current rule does not name it. But OCR can and does find that a practice failed to implement reasonable safeguards identified in its own risk analysis, and MFA is the reasonable safeguard for remote access to ePHI in almost every analysis. In practice, a breach through a remote login without MFA is treated as a risk management failure under the existing rule.
Should we wait for the final rule before spending on security?
No. The items in the checklist above cost little, are required in substance today, and would be required by any version of the final rule. What we would defer is a large project driven by a specific proposed timeline, such as a full network redesign scheduled around a compliance date that does not yet exist.
Our IT vendor says they handle HIPAA for us. Is that enough?
No. The IT vendor is a business associate and can implement safeguards, but the covered entity is the practice, and the risk analysis, the policies and the decisions about accepted risk are the practice's obligations. OCR settlements routinely involve practices whose IT was outsourced. Ask the vendor for the written risk analysis they say they performed; if it does not exist as a document with your practice's name and systems in it, it was not done. Then decide together who owns each item in the checklist above.
What to do this month
- Build or update the asset inventory: every workstation, laptop, phone, server, medical device, cloud service and vendor system that stores or transmits ePHI.
- Complete or refresh the risk analysis against that inventory and date it. If the last one is more than a year old or does not list your current EHR, it is not current.
- Turn on multifactor authentication for the EHR, email, remote access and the practice management system. This is usually a settings change, not a purchase.
- Confirm full-disk encryption on every laptop and phone that could touch ePHI, and encryption on backups.
- Test a restore from backup and time it. If you cannot restore the EHR and the practice management system in three days, fix that before anything else.
- Collect current business associate agreements and ask each vendor for a written description of their safeguards. The SOC 2 report or an equivalent attestation is the usual answer.
