In January 2025, HHS published a proposed overhaul of the HIPAA Security Rule — the first major update to rules written in an era before cloud infrastructure and ransomware-as-a-business. The comment period closed in March 2025. As of this writing, no final rule has been published, and the federal regulatory agenda now lists final action as a long-term item with a projected date of July 2027. Some founders read that as permission to wait. That is the wrong conclusion. This brief is for healthtech founders and engineering leads who handle electronic protected health information, directly or as a business associate. It is product and engineering guidance, not legal advice; your counsel and compliance lead own the final interpretation.
What is in force today
The existing Security Rule remains in effect and enforced. It already requires a risk analysis, risk management, access controls, audit controls, integrity protections, and transmission security, with some specifications “addressable” — meaning you assess whether a safeguard is reasonable and appropriate and document your decision. Encryption is one of those addressable specifications today. In practice, hospital security reviewers already expect encryption and strong authentication, regardless of how the regulation labels them.
What the proposal would change
The 2025 proposal would remove much of the addressable flexibility and make specific controls explicit. Among them: encryption of ePHI at rest and in transit with limited exceptions, multi-factor authentication with limited exceptions, a written technology asset inventory and network map, and more structured testing and review of security controls. Industry commenters flagged the short proposed compliance window after a final rule as a major concern for complex changes like MFA everywhere. Whatever the final text says, the direction is clear, and the controls are ones enterprise healthcare buyers already ask about.
Build the asset inventory and data-flow map
Start with the control that makes every other control possible: knowing where ePHI lives and moves. Inventory every system that stores or processes it — databases, object storage, queues, search indexes, analytics pipelines, logging tools, backups, and every vendor that touches it. Draw the data flows, including integrations with EHRs and third-party services. Keep it in version control and update it in the same pull request that adds a new system. Teams that cannot answer “where is PHI?” in a few minutes struggle in every security review.
# Illustrative entry in a versioned ePHI asset inventory
- id: patient-notes-db
type: postgres
environment: production
contains_ephi: true
encryption_at_rest: kms-managed
encryption_in_transit: tls
access: [clinical-api, on-call-break-glass]
owner: platform-team
vendor_baa: requiredMake encryption and MFA unexceptional
Encrypt ePHI at rest and in transit everywhere by default, including internal service traffic and backups, and document any exception with a reason and an owner. For authentication, require MFA for all workforce access to systems with ePHI — cloud consoles, admin panels, databases, support tools — and support strong MFA for clinician users of your product. Prefer phishing-resistant methods for privileged roles. Retrofitting MFA onto internal tools is usually harder than teams expect, which is exactly why to start before a deadline exists.
Prove controls work, not just that they exist
The proposal leans toward evidence: testing, reviews, and documentation. Build that habit now. Run periodic access reviews for production systems, test backup restores on a schedule, rehearse incident response with a tabletop exercise, and run vulnerability scanning on your infrastructure. Store the outputs — a dated record of a restore test is worth more in a review than a policy that says you test restores.
Business associates and vendors
Most healthtech startups are business associates, and their vendors are subcontractors. Keep business associate agreements current, know which vendors receive ePHI, and avoid quietly adding new tools — an AI service, a session replay script, a log analytics product — that receive PHI without an agreement. The proposal also addresses business associate verification, so expect customers to ask for more structured evidence from you, and plan to ask the same of your vendors.
Plan for a short runway
Proposed compliance timelines after a final rule were short. Treat the regulatory delay as runway rather than relief: build a gap assessment against the proposal now, prioritize the expensive items such as MFA on legacy tools and network segmentation, and schedule them into your roadmap. When the final rule lands, you want a diff to review, not a program to start.
Network segmentation without a platform rewrite
The proposal also points toward network segmentation, which sounds expensive for a startup. In cloud environments it is mostly configuration discipline: separate production from staging and development accounts or projects, keep databases with ePHI in private networks without public endpoints, restrict service-to-service access with security groups or policies scoped to what each service needs, and route administrative access through audited, MFA-protected paths. Document the design in the same repository as your infrastructure code so the network map and the actual configuration cannot drift apart.
Translate it for the sales cycle
Hospital and payer security teams send long questionnaires. Keep a maintained security overview that maps your controls to the questions they ask — encryption, MFA, logging, backups, incident response, vendor management — with dates of the last test for each. A crisp, current answer is often the difference between a pilot starting this quarter or next.
Founder takeaway
The HIPAA Security Rule update is delayed, not cancelled, and the current rule is enforced today. Build the controls the proposal describes because buyers already expect them: a living asset inventory and data-flow map, encryption everywhere, MFA for all workforce access, tested backups and incident response, and disciplined vendor agreements. That turns regulatory uncertainty into a sales advantage with hospital security teams.
Sources and related reading: the proposal is published in the Federal Register , and the current timetable is in the federal regulatory agenda entry . If you are scoping a healthtech product now, read building healthtech MVPs without getting burned by compliance , and if you are working on claims or payer integrations, prior authorization APIs due January 2027 covers the next hard deadline. Want a second pair of eyes on your ePHI architecture? Talk to the CodeFlamme team .
