HIPAA Security Rule 2026: Engineering Prep for the Modernisation

Compliance

The proposed HIPAA Security Rule update finally writes MFA, encryption specifics, and asset inventory into the regulation. Healthcare engineering teams should start now, not when the final rule lands.

By Arjun Raghavan, Security & Systems Lead, BIPI · June 7, 2024 · 7 min read

The HIPAA Security Rule has been the same regulation since 2003. For 22 years it has been deliberately technology-neutral, which sounded enlightened in the early 2000s and has aged into a problem. Every Office for Civil Rights breach settlement reads the same way: the covered entity argued they had reasonable safeguards, OCR disagreed, the fine landed somewhere between 250,000 and 16 million dollars.

The Notice of Proposed Rulemaking published at the end of 2024 changes the posture. Instead of addressable specifications that organisations could rationalise away, the new rule writes specific technical controls into law. We have been advising three hospital systems and a clinical SaaS vendor on early preparation. The work is real and the timeline to compliance is short once the final rule lands.

MFA stops being optional

The current rule says you must implement procedures to verify identity. The proposed rule says multi-factor authentication for any access to electronic protected health information, with phishing-resistant methods required for privileged accounts. That is a hard line. SMS-based MFA will not satisfy the new requirement for admin access to EHR systems.

We worked with a regional health system that had MFA on email but not on their picture archiving and communication system. The PACS authenticated through a legacy SAML setup that did not enforce a second factor. Retrofitting that without breaking radiologist workflow took six months. Start the discovery work now.

Asset inventory becomes a compliance artifact

The proposed rule requires a written inventory of technology assets that touch ePHI, refreshed at least annually and after material changes. Most covered entities we have audited do not have this. They have a CMDB that is 60 percent accurate, a separate medical device registry, and a list of SaaS apps the procurement team maintains in a spreadsheet that has not been updated since 2023.

1. Build a unified inventory that includes servers, endpoints, medical devices, SaaS apps, and APIs that handle ePHI.
2. Tag each asset with data classification, business owner, and last review date.
3. Wire the inventory into your change management process so new assets get added at deployment, not at audit time.
4. Run a quarterly reconciliation between the inventory and your network discovery tools. Expect the first run to find 15 to 25 percent drift.

Encryption specifics

The rule has always said encryption was addressable. In practice, OCR has treated unencrypted laptops and unencrypted backup tapes as automatic findings. The new rule makes encryption explicit: data at rest using NIST-approved algorithms, data in transit using TLS 1.2 or higher with strong cipher suites.

The interesting work here is internal traffic. We see health systems with TLS on their public-facing services and clear-text traffic between internal microservices because the network is considered trusted. That is exactly the kind of finding that ages badly. Mutual TLS between internal services is a six-month project for a typical EHR integration platform; budget accordingly.

The vulnerability management requirement

Section 164.308 in the proposed rule introduces explicit vulnerability management language. You must perform vulnerability scanning at least every six months, plus after material changes. You must document remediation timelines based on severity. Critical findings get patched within 15 days, high within 30, and so on.

Most clinical environments cannot patch in 15 days because the medical devices are FDA-locked to specific OS versions. The rule anticipates this with compensating controls, but you have to document them. Network segmentation, allowlist proxies, and monitored deny-by-default firewall rules all qualify if you can prove they actually work.

What to do in the next two quarters

• Run a gap assessment against the proposed rule, not the current rule. The deltas are where your work lives.
• Stand up the asset inventory now. It is the longest pole in the tent.
• Pilot phishing-resistant MFA on one privileged user group and document the rollout playbook.
• Audit your encryption posture across compute, storage, backups, and inter-service traffic.
• Write a vulnerability management policy with explicit timelines tied to CVSS scores.

Final rules typically give 240 days for compliance after publication. That sounds like a lot until you try to retrofit MFA across 300 clinical applications. Treat the NPRM as a regulatory promise that will materialise; the teams that started in 2025 are sleeping better than the ones still waiting for clarity.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.