HHS's Office for Civil Rights reported 663 large healthcare data breaches to Congress for 2024, exposing roughly 242.9 million individuals' protected health information — a number inflated by the Change Healthcare incident but still equivalent to roughly seven in ten Americans having their records touched in a single year. On January 6, 2025, OCR published a Notice of Proposed Rulemaking in the Federal Register to rewrite the HIPAA Security Rule for the first time in over a decade, drawing 4,745 public comments before the March 7, 2025 close and remaining on OCR's active regulatory agenda for finalization. Separately, since October 1, 2023, the FDA has had statutory authority under Section 524B of the FD&C Act to refuse premarket submissions for "cyber devices" that lack adequate cybersecurity documentation — including a Software Bill of Materials. Neither of these facts shows up in a generic OWASP Top 10 checklist, and that gap is the point of this post: healthtech engineering teams are being held to software supply-chain and lifecycle-documentation standards that a standard AppSec program was never built to produce. This piece walks through what's actually changing, what FDA reviewers expect to see, and how reachability-based findings and living SBOMs turn compliance paperwork into an artifact your pipeline generates instead of one your team writes by hand every audit cycle.
What does the 2025 HIPAA Security Rule proposal actually change?
The NPRM's most consequential change is eliminating the current rule's "addressable vs. required" distinction for implementation specifications. Under the 1990s-era Security Rule still in force today, controls like encryption of ePHI at rest and multi-factor authentication are "addressable" — meaning a covered entity can document why an alternative measure is reasonable and skip it. OCR's 2025 proposal would make nearly all of these mandatory: encryption, MFA, network segmentation, regular vulnerability scanning, and periodic penetration testing move from "consider and justify" to "implement, full stop." For engineering teams, that converts vulnerability scanning and pen testing from a once-a-year compliance exercise into an expected continuous control, and it raises the bar on what "reasonable safeguards" means when a breach investigation asks what your CI pipeline actually enforced. OCR's regulatory agenda had targeted a final rule for spring 2026, but that window has passed with no final rule published and no confirmed new timeline — a coalition of over 100 hospital systems and provider associations has even petitioned HHS to withdraw the proposal outright. The rule's fate remains genuinely uncertain, but the direction of travel is clear enough that teams shouldn't wait for finalization to close the gap between addressable and required.
Why do FDA submissions require an SBOM, and what breaks if you don't have one?
FDA's final guidance, "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," first took effect September 27, 2023, and was updated June 27, 2025 to align with the agency's Quality Management System Regulation and add a section addressing Section 524B directly. Under Section 524B, the guidance makes an SBOM a required element of 510(k), PMA, De Novo, and HDE submissions for devices meeting the "cyber device" definition — any device with software that can connect to the internet and has cybersecurity vulnerabilities. The SBOM must follow the NTIA's minimum-elements framework (supplier, component name, version, dependency relationships, and more) plus support and end-of-support dates for each component. Since October 1, 2023, FDA reviewers can issue a "Refuse to Accept" determination on submissions with inadequate cybersecurity documentation before substantive review even begins — meaning a missing or stale SBOM doesn't just slow down review, it can bounce the filing outright. A device team generating an SBOM manually at submission time is generating a snapshot that's already outdated by the time engineering ships the next patch.
What SDLC standards apply to medical device software that generic AppSec skips?
Generic AppSec tooling checks code for vulnerabilities; medical device regulation additionally requires proof of how that code was built, tested, and controlled across its lifecycle. IEC 62304 governs the medical device software development lifecycle itself — requiring documented risk classification (Class A/B/C based on potential harm), traceability from requirements to tests, and formal change control. FDA 21 CFR Part 11 separately governs electronic records and signatures for any system touching regulated data, requiring audit trails that are secure, computer-generated, and time-stamped, plus validated access controls. GxP practices (GMP, GLP, GCP) impose parallel validation requirements depending on whether the software supports manufacturing, lab, or clinical trial processes. None of these are vulnerability-management standards — they're process and evidence standards — but a security finding that can't be traced to a requirement, a test, and a signed-off remediation record doesn't satisfy an IEC 62304 or Part 11 auditor even if the code itself is now fixed.
How does HITRUST CSF relate to HIPAA, and is it required?
HITRUST CSF isn't a legal requirement under HIPAA, but it has become the de facto framework healthtech vendors use to demonstrate HIPAA compliance to enterprise customers and business associates, because HIPAA itself specifies required outcomes without prescribing specific controls. HITRUST maps its control set directly to the HIPAA Security Rule's administrative, physical, and technical safeguards, then layers on prescriptive, auditable requirements — specific encryption standards, specific access-review cadences — that a covered entity's own risk analysis might otherwise leave ambiguous. Many hospital systems and payers now require HITRUST CSF certification (r2, the current assessment level for most vendors) as a contractual precondition for handling ePHI, effectively making it required in practice even though OCR never mandates a named framework. That gap between "HIPAA requires reasonable safeguards" and "HITRUST requires this specific control implemented this specific way" is exactly where engineering teams get surprised late in a vendor security review.
How Safeguard Helps
Safeguard's compliance module maps assessments directly to the frameworks healthtech teams are actually held to — HIPAA Security Rule, HIPAA/HITECH, HITRUST CSF, FDA Medical Device guidance, FDA 21 CFR Part 11, and GxP (GMP/GLP/GCP) — with per-control scoring rather than a generic pass/fail. On the technical side, Safeguard's first-party SAST and DAST trace findings from source to sink with a full dataflow trail and CWE/OWASP mapping, and DAST only runs against targets you've verified ownership of, under enforced rate limits and non-destructive safety modes — evidence that maps cleanly to both HIPAA's proposed mandatory vulnerability-scanning requirement and an FDA reviewer's expectation of documented, repeatable security testing. Safeguard also generates CycloneDX SBOMs automatically on every build, validated against NTIA minimum elements, so the artifact an FDA submission needs is current at filing time rather than reconstructed from memory — and the same SBOM answers "are we affected" the next time a new CVE lands in a device's dependency tree.