The 2026 HIPAA Security Rule Update — What Changed and What It Means for Video

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you build or operate a telemedicine product, this rulemaking defines the security floor that your next audit, your next enterprise sales call, and your next incident will be measured against. Hospital security teams already send questionnaires written against the proposal's language — mandatory MFA, asset inventories, 72-hour recovery — months before any compliance date exists. Most coverage of the update is written for hospital compliance officers; almost none of it answers the question a product team actually has: which line item hits which component of my video stack? This article walks the proposed change set requirement by requirement and pins each one to the place it lands in a real telemedicine platform. It assumes you know the current rule's basics; if not, start with HIPAA in plain English for product teams and come back.

Where the rule stands as of June 11, 2026

Regulations move in stages, and this one is mid-flight. A proposed federal rule, called a Notice of Proposed Rulemaking (NPRM), is a draft published for public comment — it binds nobody. The Department of Health and Human Services (HHS) issued this NPRM through its Office for Civil Rights (OCR) on December 27, 2024; it appeared in the Federal Register on January 6, 2025 (90 FR 898), and the comment period closed on March 7, 2025.

The current state, verified against primary sources on June 11, 2026:

• No final rule has been published. OCR's regulatory agenda targeted spring 2026; that window has passed without a final rule, and OCR has not committed to a date.
• OCR received more than 4,700 comments and was still working through them as of the HIMSS conference in March 2026, per OCR Director Paula M. Stannard.
• Industry pushback is loud. A coalition of more than 100 hospital systems and provider associations asked HHS to withdraw the proposal outright, citing cost and an "unreasonable" timeline.
• OCR defends the substance. Stannard's public framing: the core requirements are sound practice, and "there is a high cost of doing nothing."
• The current Security Rule remains fully in effect while the rulemaking proceeds. Nothing in the proposal excuses today's obligations — including the risk analysis OCR keeps fining organizations for skipping.

So why plan against a draft? Because every technical requirement in it — encryption, MFA, inventories, scanning, segmentation, tested backups — is already mainstream security practice and already appears in the questionnaires your hospital customers send. The rule may slim down, gain longer deadlines, or stall. The direction will not reverse. Build to the proposal and the worst case is that you are early; ignore it and the best case is a panicked 240-day retrofit.

Figure 1. The rulemaking so far, and the 240-day clock that starts the day a final rule publishes. The only dated milestones today are behind us; everything right of "final rule" is arithmetic, not prophecy.

Why HHS moved: the numbers behind the rewrite

The Security Rule's technical safeguards (45 CFR §164.312) have not changed since 2013. The threat landscape has. The NPRM's own preamble carries the justification, and the numbers are stark. Between 2018 and 2023, large breaches reported to HHS — those affecting 500 or more people — grew 100 percent, the number of individuals affected grew 950 percent, breaches from hacking grew 260 percent, and breaches from ransomware grew 264 percent. In 2023 alone, breaches of 500+ records exposed the data of more than 160 million people — a record at the time (90 FR 898, preamble).

Then came the event that made the record look small. The February 2024 ransomware attack on Change Healthcare, a claims clearinghouse that touches a large share of US health transactions, ultimately affected 192.7 million people — the figure Change Healthcare reported to OCR on July 31, 2025, and the largest healthcare breach ever recorded. The entry point, by public reporting and congressional testimony, was a remote-access portal without multi-factor authentication. Read the proposal's mandatory-MFA section with that in mind and the regulatory logic explains itself.

One more preamble statistic matters to this section of Learn specifically: telemedicine adoption among office-based physicians went from 15 percent in 2018–2019 to 87 percent in 2021 (90 FR 898, citing ONC data). Every one of those video visits generates electronic protected health information — ePHI, any identifiable health data in electronic form. The rule's authors know perfectly well that clinical video is now part of healthcare's attack surface. Your platform is exactly what this rewrite is aimed at.

The headline change: the end of "addressable"

The current Security Rule sorts its implementation specifications into two bins. Required means implement it, full stop. Addressable means assess whether the safeguard is reasonable and appropriate for your environment; implement it if so, and if not, document why and adopt an equivalent measure (45 CFR §164.306(d)). Addressable was never optional — we covered the mechanics in the anchor article — but it gave organizations a documented exit ramp, and in practice the ramp was abused. Encryption of ePHI is, today, an addressable specification (§164.312(a)(2)(iv) for storage, §164.312(e)(2)(ii) for transmission). So is multi-factor authentication, which is not named in the current rule at all.

The proposal deletes the distinction. All implementation specifications would be required, with specific, limited exceptions written into the rule text itself — not left to each organization's self-assessment. Think of it as the difference between a building code that says "install smoke detectors if your risk assessment finds them appropriate" and one that says "install smoke detectors; here are the two floor plans exempted." The flexibility that remains lives inside narrow, named exceptions rather than inside your own paperwork.

Figure 2. The structural change beneath every headline: self-assessed flexibility out, named exceptions in.

For a product team the practical translation is short: every "we documented why we didn't" in your current compliance file becomes a to-do item. The two highest-profile promotions from addressable to mandatory:

Encryption of ePHI at rest and in transit becomes its own standard (proposed §164.312(b)), required with limited exceptions — for example, when the patient themselves requests their data in an unencrypted form. "We encrypt the database but the recordings bucket is internal-only" stops being an arguable position.

Multi-factor authentication (MFA) — proof of identity using at least two of something you know, have, or are — becomes required across systems touching ePHI (proposed §164.312(f)), with narrow exceptions for legacy systems and FDA-authorized medical devices predating March 2023, and only alongside a written migration plan.

The full change set, grouped so you can reason about it

The NPRM runs to roughly 400 Federal Register pages. Grouped by what they ask of you, the proposals form five families. Citations are to the proposed rule structure in 90 FR 898; all of it is subject to change in the final rule.

1. Know your estate. A written technology asset inventory and a network map showing how ePHI moves through your systems, refreshed at least every 12 months and after any relevant change (proposed §164.308(a)(1)). The risk analysis — already the most-enforced requirement in HIPAA — gets express content requirements: it must start from that inventory and map, identify reasonably anticipated threats and vulnerabilities, and assign a risk level to each pair (proposed §164.308(a)(2)).

2. Harden by default. Mandatory encryption at rest and in transit (proposed §164.312(b)). Mandatory MFA (proposed §164.312(f)). Configuration management as a named standard: consistent secure baselines, anti-malware, removal of extraneous software, disabling of unused network ports (proposed §164.312(c)). Network segmentation — dividing the network so an intruder in one zone cannot roam into others (proposed within the technical safeguards).

3. Keep checking. Vulnerability scanning at least every six months and penetration testing at least every 12 (proposed §164.312(h)). A patch-management standard with deadlines: critical-risk patches within 15 calendar days, high-risk within 30 (proposed §164.308(a)(4)). Audit-trail and system-log controls as an explicit technical standard (proposed §164.312(d)).

4. Survive the hit. Written procedures to restore critical electronic information systems and data within 72 hours of loss, a criticality analysis ranking what gets restored first, exact retrievable backup copies of ePHI, and separate technical controls for backup and recovery systems (proposed §§164.308(a)(13), 164.312(i)–(j)). Written, tested security-incident response plans. Business associates must notify covered entities within 24 hours of activating a contingency plan — and within 24 hours of a workforce member's access change or termination at the organizational level, with access cut no later than one hour after employment ends.

5. Prove it, annually. A compliance audit against every Security Rule standard at least once every 12 months (proposed §164.308(a)(14)). Business associates must deliver an annual written verification to each covered-entity customer — an analysis of their technical safeguards performed by a subject-matter expert, plus a written certification of its accuracy (proposed §164.308(b)). Security measures, incident plans, and workforce procedures all acquire annual review-and-test cycles.

Figure 3. The proposed change set as five jobs rather than forty line items. Every later section of this article maps one family onto the video stack.

The compressed comparison, current rule versus proposal:

What each change means for a telemedicine video platform

Generic HIPAA guidance treats "the system" as one box. A telemedicine platform is not one box — it is a patient app, a signaling service, TURN relays (the fallback servers that forward media when devices cannot connect directly), an SFU (Selective Forwarding Unit, the media server that routes video streams in multi-party calls), a recordings pipeline, transcripts, an EHR bridge, and a stack of vendors. The proposal lands differently on each. This mapping is the part no compliance blog writes, so we will take it slowly.

Figure 4. Where the proposal lands on a real telemedicine video platform. Every pin is a proposed requirement; every component is something you already run.

The inventory and the map: your media pipeline is now a compliance document

The asset inventory and ePHI network map sound like paperwork until you try to draw one for a video platform. Where does ePHI exist during a consult? In the patient's browser and the clinician's. In flight through the SFU — decrypted at the SFU boundary in standard WebRTC topologies, a fact your map must show. Possibly through a TURN relay, which forwards encrypted packets it cannot read — your map should say so, because it changes the risk rating. In the recordings bucket, in transcripts, in chat history, in the signaling database, in logs if you have been careless (a classic mistake), and across every vendor in the chain. If you already maintain the PHI boundary diagram we recommend, you are most of the way there: the proposed map is that diagram plus an asset list with owners and update dates. If you cannot draw it today, that — not the rulemaking — is your first problem.

Encryption: in transit you are mostly done; at rest is where products fail

WebRTC, the browser-native real-time stack underneath almost every telemedicine product, encrypts media by default: DTLS-SRTP key exchange and SRTP payload encryption are mandatory in the standard — there is no plaintext mode to misconfigure. (Protocol details live in our Video Streaming section: WebRTC security: DTLS and SRTP.) Signaling and APIs ride TLS. For media in transit, a competently built WebRTC platform already meets the proposed standard.

At rest is a different story, and it is where telemedicine products actually fail audits. The proposed encryption standard covers the recordings store, the transcripts database, chat archives, cached attachments, backups, and the laptops of anyone who can export them. Two patterns to check this week: recordings written to object storage with bucket-level encryption but world-readable signed URLs that never expire, and "temporary" composing buffers on SFU recording nodes that persist plaintext media to local disk. Encryption choices, key management, and the E2EE question get their own article: encryption for telemedicine.

MFA without losing the patient

MFA on the clinician side is a solved problem — providers live in SSO ecosystems, and your job is to integrate the hospital's identity provider rather than invent one (identity architecture). The hard question is the patient side, and product teams should start the design work now rather than after a final rule. A 78-year-old joining a video visit from an emailed link is one mis-typed one-time code away from a no-show. The proposed rule's exceptions cover legacy systems and certain pre-2023 FDA-authorized devices — not user inconvenience. Workable patterns exist: MFA at account level with device binding afterwards, magic-link plus possession-factor flows, and step-up authentication that protects record access with a second factor while letting a verified session join its scheduled call. Decide deliberately; the worst outcome is bolting SMS codes onto every login the month before a compliance date and watching visit-completion rates fall.

Do not forget the unglamorous logins: your cloud console, your SFU orchestration dashboard, your support tooling, your CI/CD. The proposal does not care that a console "isn't the product." If it can reach ePHI, it authenticates with MFA.

Segmentation, scanning, patching: the media fleet becomes a managed estate

Network segmentation for a video platform has a natural shape: the media plane (SFU and TURN nodes), the signaling/control plane, the data plane (recordings, transcripts, EHR bridge), and corporate IT, each in its own zone with controlled crossings. If a compromised marketing workstation can route to the recordings store today, the proposal exists because of you. Segmentation here is also cheap insurance: media nodes are the most internet-exposed machines you run, by design.

Which is why the scanning and patching deadlines bite hardest exactly there. TURN servers listen on public UDP and TCP ports; that is their job. SFU nodes terminate encrypted media from arbitrary networks. A critical vulnerability in your TURN implementation, your SFU runtime, or the kernel under either starts a 15-calendar-day clock under the proposal — calendar days, not business days, and the clock does not pause for your release train. The operational consequences are concrete: an automated, repeatable rebuild for media nodes (image-based deploys, not hand-patched long-lived servers), the ability to drain and rotate an SFU fleet without dropping live consults, and a vulnerability-scan scope that includes the media plane rather than politely stopping at the web tier. If draining an SFU node mid-day terrifies you, that is a reliability gap wearing a compliance costume — see connection reliability.

72 hours to rebuild: recovery gets a stopwatch

The proposal requires written procedures to restore critical systems and data within 72 hours, ranked by a criticality analysis. For a telemedicine platform the ranking question is clinical, not technical: tomorrow's appointment schedule and the ability to hold a consult probably outrank last month's recordings archive. A useful exercise we run with clients: assume your cloud account is gone at 09:00 Monday — region failure, ransomware, fat-fingered Terraform. What is the documented, tested path to holding your first consult again, and is it shorter than 72 hours? Signaling state, TURN credentials, SFU images, DNS, the EHR bridge's certificates — each undocumented step is an hour you do not have. The 24-hour vendor notification requirement also cuts both ways: as a business associate you owe your covered-entity customers notice within 24 hours of activating your contingency plan, so your incident runbook needs a communications page, not just a technical one (incident response and breach notification).

The annual proof cycle: your vendors, your customers, and you

Today, vendor diligence under HIPAA is mostly contractual: sign the Business Associate Agreement — the contract that makes a vendor legally responsible for the patient data it handles — and rely on its "satisfactory assurances" (the BAA article covers the anatomy). The proposal turns diligence into an annual evidence exchange. Your covered-entity customers must obtain from you, every 12 months, a written analysis of your technical safeguards verified by a subject-matter expert, plus a certification that it is accurate. And you must obtain the same thing from every subcontractor that touches ePHI: your cloud, your CPaaS or self-hosted media layer, your transcription API, your storage, your observability stack if it sees ePHI (it should not).

Count the recurring obligations for a mid-size platform with six ePHI-touching vendors, walking the arithmetic out loud: two vulnerability scans per year, plus one penetration test, plus one compliance audit, plus one risk-analysis refresh, plus one incident-response plan test, plus one inventory-and-map refresh, plus six vendor verifications collected and one produced for your customers equals thirteen scheduled compliance events every year — against the one or two most teams run today. That is a calendar and an owner, or it is thirteen findings.

There is a commercial upside hiding in this: a telemedicine vendor that can hand a hospital an SME-certified safeguards analysis on request will close enterprise deals faster than one that cannot. The proposal effectively standardizes the security questionnaire you already lose weeks to. Treat the verification package as a sales asset and the mandate becomes a feature.

The clock, walked out loud

The proposal keeps HIPAA's standard timing machinery (45 CFR §160.105): a final rule takes effect 60 days after publication, and compliance is due 180 days after that — about 240 days total — with a longer transition only for amending existing BAAs (proposed §164.318). HHS explicitly declined to propose a longer general runway, reasoning that most obligations restate what a competent risk analysis already implies.

Walk one hypothetical so the arithmetic is concrete. Suppose the final rule publishes on September 1, 2026. Sixty days later is October 31, 2026 — the effective date: September contributes its remaining 29 days, and October's 31 complete the 60. The compliance clock then runs 180 days: November's 30 leaves 150, December's 31 leaves 119, January's 31 leaves 88, February's 28 leaves 60, March's 31 leaves 29, and 29 days into April lands on April 29, 2027. Every requirement above — fleet rebuild automation, MFA UX, the audit, the vendor verifications — would be enforceable that day. Industry comments asked OCR to stretch the 180 days, and the final rule may oblige; plan against the statutory floor, because the floor is what is written down. HHS's own regulatory impact analysis put first-year industry costs at roughly $9 billion, with about $6 billion annually in years two through five — figures the hospital coalition wields in its withdrawal demand, and a useful sanity check that nobody considers this update small.

Common mistake: treating "proposed" as either "law" or "noise"

Two failure modes, same root. Teams in the first group read a vendor blog, conclude mandatory encryption is already in force, and burn a quarter chasing the wrong deadline — sometimes buying "HIPAA 2026 compliance" tooling for a rule that does not exist yet. Teams in the second group hear "only proposed" and shelve the whole topic, forgetting that the current Security Rule already requires a risk analysis most startups cannot produce, that OCR's Risk Analysis Initiative is actively fining that exact gap, and that 2026 penalties run up to $73,011 per violation with an annual cap of $2,190,294 per provision (HHS inflation adjustment, effective January 28, 2026). The correct posture holds both ideas: comply with the current rule today, and build the proposal's technical substance on your own schedule — because it is sound engineering — rather than on OCR's. State precisely which rule you are claiming when you tell customers you are "compliant." Conflating the two in a sales deck is how legal teams end up un-sending emails.

What could still change before a final rule

Read the comment record and the likely pressure points are visible. The 4,700+ comments concentrate on cost (the $9 billion first-year estimate), the 180-day runway, MFA and encryption burdens on small and rural providers (the American Medical Association asked OCR to restore addressable-style flexibility for small practices), and the annual vendor-verification load. Plausible outcomes range from finalize-mostly-as-proposed with a longer compliance period, through a slimmed rule that keeps encryption and MFA but relaxes cadences, to an indefinite stall — with the administration's deregulatory posture making the middle and last scenarios real possibilities. Watch three signals: the Unified Agenda's next target date for RIN 0945-AA22, OCR public statements (Stannard has defended the core requirements while conceding the administration "may have a different view" on burdens), and any HHS move to re-open comment. None of the plausible outcomes changes the engineering advice above; they change only the date and the paperwork.

Your migration plan, in one page

We compressed this article into a printable worksheet: the five requirement families, each with the video-platform checkpoints from the mapping above and a status column to mark gaps. Run it against your platform in an afternoon; the unchecked boxes are your backlog, ordered top to bottom.

Download the HIPAA 2026 migration checklist for video platforms (PDF)

Where Fora Soft fits in

Fora Soft has built video software since 2005 — telemedicine platforms, video conferencing, streaming, surveillance, e-learning — and the compliance boundary work this article describes is the unglamorous half of every healthcare engagement we take. We design telemedicine architectures where the proposed requirements are properties of the system rather than retrofits: encrypted recording pipelines, segmented media planes, image-based SFU fleets that rotate without dropping consults, and audit evidence that exists because the architecture produces it. When the final rule lands, our clients' migration list should already be mostly checkmarks. If you are scoping a build or staring at a retrofit, that is exactly the conversation to have with our team.

What to read next

• Business Associate Agreements: the contract that makes or breaks your stack
• Encryption for telemedicine: in transit, at rest, end-to-end
• The compliance architecture pattern: how to wrap a video stack in HIPAA

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your 2026 hipaa security rule plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the HIPAA 2026 Migration Checklist for Video Platforms — One page: the five proposed requirement families mapped to telemedicine video components — inventory and map, encryption, MFA, fleet hardening, recovery, and the annual proof cycle — as a gap checklist.

References

1. HHS OCR — HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM), 90 FR 898, January 6, 2025. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information — proposed change set, applicability and 180-day compliance reasoning, breach and telemedicine statistics in the preamble. Tier 1. (Status re-verified 2026-06-11: no final rule published.)
2. HHS OCR — HIPAA Security Rule NPRM Fact Sheet, December 27, 2024. https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet/index.html — the Department's own itemization of the proposals; confirmation the current rule remains in effect. Tier 2.
3. 45 CFR §164.312 — current Security Rule technical safeguards (eCFR, read 2026-06-11). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 — addressable status of encryption today. Tier 1.
4. 45 CFR §164.306 — Security standards: general rules, incl. (d) required vs addressable. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306 Tier 1.
5. 45 CFR §160.105 — compliance dates for new or modified standards (the 180-day floor). https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.105 Tier 1.
6. HHS — Annual Civil Monetary Penalties Inflation Adjustment, effective January 28, 2026. https://www.federalregister.gov/documents/2026/01/28/2026-01688/annual-civil-monetary-penalties-inflation-adjustment — 2026 penalty tiers cited in the common-mistake section. Tier 1.
7. NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (2024). https://csrc.nist.gov/pubs/sp/800/66/r2/final — the control-level companion for building to the proposal. Tier 1.
8. HHS OCR breach portal / Change Healthcare notification of July 31, 2025 — 192.7 million individuals affected; widely reported, e.g., Healthcare IT News. https://www.healthcareitnews.com/news/new-numbers-change-healthcare-data-breach-193-million-affected Tier 2 (figure), Tier 6 (outlet).
9. The HIPAA Journal — Final Rule Implementing HIPAA Security Rule Updates Edges Closer, March 20, 2026. https://www.hipaajournal.com/final-rule-implementing-hipaa-security-rule-updates-edges-closer/ — status, 4,700+ comments, hospital-coalition withdrawal demand, Stannard quotes. Tier 6.
10. Bradley Arant (Reuters Legal) — Top 10 takeaways from the new HIPAA security rule NPRM, March 14, 2025. https://www.bradley.com/insights/publications/2025/03/top-10-takeaways-from-the-new-hipaa-security-rule-nprm — MFA exception scope, 1-hour termination, 240-day arithmetic; cross-checked against the NPRM. Tier 5.
11. TechTarget — OCR director defends HIPAA updates: "The cost of doing nothing is very high" (HIMSS 2026 coverage). https://www.techtarget.com/healthtechsecurity/feature/OCR-director-defends-HIPAA-updates-The-cost-of-doing-nothing-is-very-high Tier 6.
12. HHS — Healthcare Sector Cybersecurity concept paper, December 2023. https://aspr.hhs.gov/cyber/Documents/Health-Care-Sector-Cybersecurity-Dec2023-508.pdf — the strategy document that announced mandatory cybersecurity rulemaking. Tier 2.

Where lower-tier summaries disagreed with the rule text (e.g., one consultancy claiming a 72-hour critical-patch deadline), the NPRM's 15/30-calendar-day patching proposal was followed and the discrepancy noted here.