HIPAA Requirements for Connected Medical Device Companies
What HIPAA actually requires of a device maker or software vendor whose product touches patient data, not a hospital employee. Business Associate status, the Security Rule, and the BAA signal.
If your product creates, stores, or transmits protected health information (PHI) on behalf of a hospital, clinic, or insurer, you are typically a Business Associate under HIPAA, whether or not you think of your company as a healthcare business. That status brings the Security Rule's administrative, physical, and technical safeguards, and it usually shows up first as a Business Associate Agreement a customer asks you to sign.
Most HIPAA content online is written for hospital employees: can I get fired for a violation, do I need annual training, what counts as snooping in a chart. None of that is this post. This is for the founder, CTO, or engineering lead at a company that makes or sells a connected medical device, or a software vendor whose product touches patient data, who needs to know what HIPAA requires of them, as a vendor, not as staff at a covered entity. This post covers the vendor side; the pillar reference is our HIPAA framework page.
What triggers HIPAA for a device company?
The trigger is what your product does with PHI, not what industry you consider yourself in. If your device or software creates, receives, stores, or transmits protected health information on behalf of a covered entity, generally a hospital, clinic, physician practice, or health insurer, you are typically a Business Associate under HIPAA. A company that builds a remote patient monitor whose cloud stores patient vitals is a Business Associate. A company whose companion app lets a clinic message patients about their care is a Business Associate. Neither company needs to call itself a healthcare business for the law to apply; the trigger is the data flow, not the self-description on your website.
This catches teams off guard because device companies often think of themselves as hardware or software vendors first, healthcare-adjacent at most. HIPAA does not care about that framing. The moment PHI passes through a system you control on behalf of a covered entity, Business Associate obligations attach, and they attach whether or not anyone at your company has read the statute.
What does the Security Rule actually require?
The HIPAA Security Rule is the operational part that falls on a Business Associate, and it groups into three categories of safeguard, all of which need to exist for any system that touches PHI:
- Administrative safeguards. A designated security official, a documented risk assessment, workforce access management tied to job function, and a written incident response process that says who does what when something goes wrong.
- Physical safeguards. Controls over the facilities and devices where PHI lives or passes through, which for a cloud-hosted product mostly means your cloud provider's physical controls plus your own device and workstation policies.
- Technical safeguards. Access controls that tie every action to an identifiable user, encryption for PHI both in transit and at rest, and audit logging that can reconstruct who touched what data and when.
None of this is exotic if your team already builds with reasonable security hygiene. What HIPAA adds is the requirement to document it, apply it consistently to every system that touches PHI rather than just the obvious ones, and be able to produce evidence of it, not just describe it in a policy nobody follows. On top of the safeguards, a Business Associate needs BAAs in place with every subprocessor that also touches the data, and breach notification procedures that follow HIPAA's specific timelines rather than a generic "we will let you know" policy.
The BAA is the real-world signal, not the statute
Reading the statute is not how most device companies find out HIPAA applies to them. A hospital or clinic customer asking you to sign a Business Associate Agreement is. The BAA is the contract that makes a vendor's HIPAA obligations explicit, and a covered entity cannot legally share PHI with you until it is signed. If that request has landed in your inbox, HIPAA is not a future consideration to revisit before a bigger enterprise deal. It already governs how your product needs to be built and operated, starting now, because the customer asking for the signature is telling you, correctly, that the data is about to start flowing.
Treat a BAA request as a trigger to check your actual safeguards against the Security Rule, not just a document to route to legal for signature. Signing a BAA your infrastructure cannot back up is a bigger liability than the sales delay of getting the safeguards right first.
The gap device makers actually have: telemetry built for uptime, not PHI
The most common gap is not a missing policy document, it is architectural. Cloud telemetry pipelines for connected devices are usually built for uptime and observability: crash reports, performance metrics, error traces, support tooling that lets an engineer see what a customer's device is doing. Nobody set out to put PHI in an access log or a third-party analytics tool. It ends up there anyway, because a device's telemetry stream and its clinical data stream were never architecturally separated, and once patient vitals or identifiers flow through the same pipeline as debug logs, every downstream consumer of that pipeline, your analytics vendor, your support dashboard, your on-call engineer's laptop, is now a place PHI lives without anyone having decided it should.
This is the gap worth auditing first, before the policy documents: trace where PHI actually goes once it leaves the primary data store, including logs, analytics, and any tooling your support team uses to debug a customer issue, and check whether the same safeguards that protect the primary database are actually applied everywhere the data ends up.
How does this relate to the EU Cyber Resilience Act?
They are separate obligations, not overlapping ones, and this matters if your device sells into both the US and the EU. The Cyber Resilience Act explicitly carves out medical devices in favor of the EU's own Medical Device Regulation and In Vitro Diagnostic Regulation, so a connected medical device does not face CRA obligations on top of MDR or IVDR ones; it follows the sector-specific regime instead. Full detail on how that carve-out works, and who else is out of CRA scope, is in who does the CRA apply to and on the Cyber Resilience Act framework page.
HIPAA sits entirely outside that picture. It is a US federal law about patient health information, triggered by what your product does with PHI, regardless of what product-safety or cybersecurity regime it also falls under. A device maker selling a connected product in both the US and the EU can genuinely face HIPAA obligations on the US side and MDR/IVDR-plus-CRA-adjacent obligations on the EU side, addressing different questions with different regulators. Neither one substitutes for the other, and treating them as the same checklist is how gaps happen.
Frequently asked questions
Does HIPAA apply to my connected device company if we are not a hospital? Yes, if your product creates, stores, or transmits protected health information on behalf of a covered entity. That makes you a Business Associate under HIPAA, with real obligations, even though you are not a hospital, clinic, or insurer yourself.
What is a Business Associate Agreement? A BAA is the contract required before a covered entity can share PHI with a vendor. If a hospital or clinic customer asks you to sign one, HIPAA applies to your company now, not hypothetically.
What does the HIPAA Security Rule actually require of a vendor? Administrative, physical, and technical safeguards for any system that touches PHI: access controls, encryption in transit and at rest, audit logging, and a documented incident response process, plus BAAs with every subprocessor that also touches the data.
Does HIPAA replace the need for CRA compliance for a connected medical device? No. The EU Cyber Resilience Act explicitly excludes medical devices in favor of the EU MDR and IVDR regime. HIPAA is a separate, US-specific law about patient health information. A device sold in both markets can face obligations under both, addressing different questions.
What does HIPAA mean for cloud telemetry on a connected device? Any pipeline that touches protected health information, including access logs, analytics, and support tooling, needs the same Security Rule safeguards as the primary data store. This is the most common gap for device makers whose telemetry pipeline predates handling patient data.
How does a device maker know if HIPAA applies right now, versus hypothetically? The clearest real-world signal is a Business Associate Agreement request. If a hospital or clinic customer is asking your company to sign one, HIPAA is not a future consideration, it already governs how you build and operate today.
Last reviewed: 2026-07-12.
Where Scadable fits
HIPAA is the newest and narrowest framework Scadable covers, well behind the depth of our CRA or SOC 2 work today. What we do today is concierge, the same way every framework starts here: mapping where PHI actually moves through your product, from the primary data store out to logs, analytics, and support tooling, and closing the gap with the Security Rule safeguards and Business Associate Agreements that a signed BAA actually requires. If your product is medical-device-first and you are weighing HIPAA against CRA-adjacent obligations for the same device, or you have a covered-entity customer asking for a BAA right now, book a call and we will tell you honestly what current scope covers rather than assuming parity with our more mature frameworks.