In February 2024, a single compromised Citrix portal without multi-factor authentication took down Change Healthcare, the clearinghouse that processes roughly 1 in 3 U.S. patient records. The resulting breach exposed protected health information on an estimated 190 million people — the largest healthcare data breach in U.S. history — and cost UnitedHealth Group over $3 billion in response costs by mid-2025. The root cause wasn't a novel zero-day. It was a missing access control, the kind HIPAA's Security Rule has required in some form since 2005.
For engineering teams building healthcare software, HIPAA compliance isn't a paperwork exercise handled by legal after the fact. It's a set of technical requirements — encryption, access logging, vulnerability management, vendor risk tracking — that have to be designed into the SDLC. The rules are also changing: HHS's January 2025 proposed update to the Security Rule would make many of today's "optional" controls mandatory. Here's what that means in practice.
What does HIPAA actually require from software teams?
HIPAA's Security Rule (45 CFR §164.312) requires four technical safeguard categories: access control, audit controls, integrity controls, and transmission security. Concretely, that means unique user identification for every account touching ePHI, automatic session logoff, encryption of data in transit (TLS 1.2 or higher in practice), audit logs that record who accessed what and when, and mechanisms to detect unauthorized alteration of health data. Since 2005, these specifications have been split into "required" and "addressable" — addressable items could be satisfied with an equivalent alternative or documented as not reasonable. In practice, this ambiguity let some organizations skip encryption or MFA and simply document a justification, which is exactly the gap regulators are now closing. Software teams building EHR integrations, patient portals, or claims-processing pipelines are on the hook for implementing these controls at the code and infrastructure level, not just the policy level.
How do open-source vulnerabilities create HIPAA exposure?
They create exposure because a HIPAA risk analysis under §164.308(a)(1)(ii)(A) requires an accurate inventory of every system — including third-party and open-source components — that touches ePHI, and unpatched components are a documented, foreseeable risk. The 2023 MOVEit Transfer vulnerability (CVE-2023-34362) is the clearest recent example: Progress Software's file-transfer tool was exploited via SQL injection, and the fallout hit dozens of healthcare payers and providers, including Delta Dental, Genworth, and several state Medicaid systems, contributing to a breach total exceeding 93 million individuals across all affected sectors. Log4Shell (CVE-2021-44228) posed the same problem for hospital systems running Java-based clinical applications in December 2021 — organizations that couldn't quickly answer "where is Log4j deployed, and is it reachable from the internet?" were flying blind during active exploitation. Under HIPAA, "we didn't know we had that dependency" is not a defensible answer to OCR; the risk analysis requirement exists precisely to prevent that gap.
What happens when a HIPAA business associate gets breached?
Liability follows the data, not just the covered entity, because HIPAA's 2013 Omnibus Rule made business associates — including SaaS vendors, cloud hosts, and software providers who create, receive, or transmit ePHI — directly liable for Security Rule compliance. Change Healthcare is the canonical case: as a business associate to thousands of providers and payers, it was contractually bound by Business Associate Agreements (BAAs) to protect ePHI, and its breach triggered notification obligations, OCR investigations, and litigation against both Change Healthcare and the covered entities that relied on it. If your company sells software to hospitals, health plans, or clinical labs, you are almost certainly a business associate under 45 CFR §160.103, and your customers' BAAs will require you to demonstrate the same technical safeguards a hospital IT department must meet — including proof of vulnerability management and incident response capability, often via a SOC 2 report or HITRUST certification.
What's changing with the 2025 HIPAA Security Rule update?
The proposed rule would eliminate the "addressable" category entirely, making nearly every technical safeguard mandatory with only narrow, documented exceptions. Published as a Notice of Proposed Rulemaking on January 6, 2025, the update would require encryption of ePHI at rest and in transit (with limited exceptions), multi-factor authentication for all systems accessing ePHI, network segmentation, a written technology asset inventory and network map updated at least annually, vulnerability scanning at least every six months, and penetration testing at least once every 12 months. It also proposes that access for terminated workforce members be revoked within one hour. For engineering organizations, this shifts vulnerability management and asset inventory from "best practice" to an explicit, auditable compliance requirement — the kind of continuous SBOM and dependency visibility that manual spreadsheet tracking can't sustain at the twice-yearly scanning cadence the rule proposes.
How much do HIPAA violations actually cost engineering organizations?
They cost millions in direct penalties alone, before litigation and remediation. OCR's tiered civil monetary penalty structure tops out above $2 million per violation category, per calendar year, for violations due to uncorrected willful neglect. Recent settlements show the range: Anthem paid $16 million in 2018 following a 2015 breach of 79 million records tied to a phishing-enabled network intrusion; Premera Blue Cross paid $6.85 million in 2020 after attackers sat undetected in its network for nine months in 2014; and Excellus Health Plan paid $5.1 million in 2021 for a similar prolonged, undetected intrusion. In nearly every large OCR settlement, the enforcement narrative centers on the same two failures: an incomplete risk analysis and unpatched or unmonitored systems — both squarely software and infrastructure problems, not administrative ones.
How Safeguard Helps
Safeguard maps HIPAA's technical safeguard and risk-analysis requirements directly onto your codebase and pipelines, starting with automated SBOM generation and ingest so you have the accurate, continuously updated asset inventory the Security Rule (and its 2025 update) demands. Reachability analysis determines which vulnerable dependencies — like a Log4Shell- or MOVEit-style flaw — are actually exploitable in your running application, so engineering teams can prioritize the handful of findings that create real ePHI exposure instead of triaging every CVE equally. Griffin AI, Safeguard's agentic remediation engine, investigates flagged issues in context and opens auto-fix pull requests that patch vulnerable dependencies without breaking builds, helping teams hit the six-month scanning and rapid-remediation timelines regulators now expect. Together, these capabilities turn HIPAA's risk-analysis and vulnerability-management requirements into a continuous, evidence-backed process your compliance team can point to during an OCR audit — rather than a point-in-time spreadsheet exercise.