2nd Healthcare data breaches reported to the HHS Office for Civil Rights totaled 319 incidents affecting 500 or more individuals between January 1 and May 31, 2026, according to the HHS OCR breach portal. A growing share traces back to cloud-hosted systems: remote patient monitoring platforms, cloud-connected imaging systems, or SaaS quality management tools storing device data offsite. Cloud medical device compliance has become the point where two separate regulatory regimes meet, and getting it wrong on either side creates exposure that a purely on-premise device never faced.
The financial penalty structure reinforces the stakes. Effective January 28, 2026, HHS raised the annual civil monetary penalty cap to $2,190,294 per violation tier, as published in the HHS OCR HIPAA enforcement penalty schedule. HIPAA and FDA compliance for medical devices is no longer a technical afterthought bolted on late in development. It is a shared obligation spanning the cloud provider, the manufacturer, and the healthcare organization, and each party’s responsibilities need to be documented, not assumed.
Talk to Qualysec about assessing your device’s cloud compliance posture – today!
Why Cloud-Connected Devices Create a Different Compliance Problem
A traditional standalone medical device has one system boundary: the device itself. A cloud-connected device spans at least three layers, and HIPAA and FDA compliance for medical devices have to account for all of them together.
1st Layer – The device – Firmware, embedded software, local storage, and the communication module that sends data off the device.
2nd Layer – The Cloud Infrastructure – AWS, Azure, GCP or Specialized Healthcare Cloud Platform where the data is housed, processed, and rendered available to authorized systems.
3rd Layer – Application & Integration Layer – including APIs, Mobile Companion Apps, Clinician Dashboards, Hospital EHR System Connections consuming data.
A compliance gap at any one layer can undermine the other two. Encrypting data on the device is meaningless if the cloud storage bucket holding that same data is misconfigured. A well-secured cloud environment does not help if the API connecting the device to a clinician’s dashboard has no authentication. The full chain has to be treated as a single system, which is exactly the model that FDA’s guidance and HHS’s Security Rule both expect.
The Shared Responsibility Model: Who Owns What
Cloud providers secure the infrastructure. Device manufacturers secure the application, data handling, and configuration built on top of it. Both carry compliance obligations, but the manufacturer retains ultimate regulatory responsibility to the FDA and, where PHI is involved, to HHS. This division of ownership is the foundation on which cloud medical device compliance is built.
| Responsibility Area | Cloud Provider | Device Manufacturer | Healthcare Organization |
| Physical data center security | Yes | No | No |
| Infrastructure patching (hypervisor, network) | Yes | No | No |
| Application-level access controls | No | Yes | Shared |
| Encryption key management | Shared | Yes | No |
| SBOM for cloud-hosted components | Partial | Yes | No |
| Business Associate Agreement | Yes | Yes | Yes |
| Incident response for the device system | No | Yes | Shared |
| User authentication at the clinical endpoint | No | No | Yes |
A recurring finding in FDA cybersecurity submissions is manufacturers treating “the cloud provider handles it” as an adequate control without documenting the actual split. Reviewers expect a documented RACI-style mapping between the manufacturer, the platform, and the operator, backed by evidence, not a general statement of trust in the vendor’s reputation.
HIPAA Requirements That Apply to Cloud Medical Device Data
The Business Associate Agreement Is Non-Negotiable
If you’re a cloud provider that stores, processes, or transmits PHI for a covered entity or its business associate, then your organization will need to sign a Business Associate Agreement. Most major cloud providers do have a selection of BAA-eligible services available, but not all are automatically covered. A manufacturer using a non-BAA-eligible storage or analytics service to handle PHI creates a HIPAA violation regardless of how well the underlying infrastructure is secured.
The Security Rule’s Three Safeguard Categories
- Administrative safeguards: Risk analysis, workforce training, access management policies, and a designated security official responsible for the cloud environment.
- Physical safeguards: Largely delegated to the cloud provider for the data center itself, but device manufacturers remain responsible for the physical security of the device and any local storage components.
- Technical safeguards: Encryption at rest and in transit, audit logging, automatic logoff, and unique user identification for anyone accessing PHI through the cloud application.
Breach Notification Obligations
Under the HIPAA Breach Notification Rule, a breach affecting 500 or more individuals must be reported to HHS OCR without unreasonable delay and no later than 60 days following discovery. For cloud-hosted data, discovery is complicated by unclear ownership: if a breach occurs at the provider level, BAA terms determine who is responsible for detection and notification timing. Ambiguous BAA language here is a common source of delayed reporting.
FDA Requirements That Apply to Cloud-Connected Devices
Cyber Device Classification Still Applies
If a device connects to the internet, including through a cloud backend, it meets the “cyber device” definition under Section 524B(c) of the FD&C Act. Cloud connectivity does not exempt a device from the FDA’s cybersecurity documentation requirements. It expands them, since the cloud layer becomes part of the system that must be documented in the security architecture and threat model.
The Software Bill of Materials Must Cover Cloud Components
The SBOM requirement extends to software components running in the cloud environment that support the device’s function, not only the embedded firmware. Manufacturers using managed cloud services still need to account for the vendor’s disclosed components and known vulnerabilities in their own SBOM documentation, even when the cloud provider handles the underlying patching.
Computer Software Assurance for Cloud Validation
FDA’s Computer Software Assurance (CSA) guidance allows manufacturers to leverage vendor-supplied evidence and apply a risk-based validation approach for cloud-hosted systems, rather than repeating validation testing the provider has already performed. This reduces duplication but does not remove the obligation to validate that the complete system remains secure after infrastructure changes.
Post-Market Surveillance Extends to the Cloud Layer
FDA’s postmarket cybersecurity management plan requirements apply to the full device system. If a vulnerability is discovered in a cloud-hosted component, the manufacturer’s 30-day notification obligation under Section 524B applies just as it would for a vulnerability in on-device firmware.
A Practical Compliance Checklist for Cloud-Connected Devices
| Step | Action | Owner |
| 1 | Confirm BAA coverage for every cloud service handling PHI | Manufacturer / Provider |
| 2 | Map the full data flow across device, cloud, and application layers | Manufacturer |
| 3 | Document the shared responsibility split with evidence, not assumptions | Manufacturer |
| 4 | Extend the SBOM to cover cloud-hosted software components | Manufacturer |
| 5 | Verify encryption at rest and in transit across all three layers | Manufacturer / Provider |
| 6 | Test incident response procedures across the full system, not just the device | Manufacturer / Healthcare Org |
| 7 | Conduct independent penetration testing covering cloud APIs and interfaces | Manufacturer |
| 8 | Reconfirm validation after any cloud infrastructure change | Manufacturer |
Cloud medical device compliance breaks down most often at step 3. Manufacturers document their own controls thoroughly but leave the cloud provider’s responsibilities as an assumption rather than a verified, evidenced split. That gap is exactly what both FDA reviewers and HHS OCR investigators look for first.
How Qualysec Helps With Cloud Medical Device Compliance
Manufacturers building cloud-connected devices face a documentation challenge that on-premise devices never had: proving compliance across a system they only partially control. Qualysec closes that gap before it becomes an FDA deficiency or an HHS OCR finding.
Cloud Architecture Security Assessment
Qualysec reviews the complete data flow across the device, cloud infrastructure, and application layers, identifying encryption, access control, and logging gaps at each boundary. The assessment produces a documented shared responsibility matrix mapped to the specific cloud services in use.
SBOM and Threat Model Extension for Cloud Components
Qualysec extends existing threat models and SBOM documentation to properly account for cloud-hosted software components, ensuring the full system, not just the device firmware, is represented in FDA-facing documentation.
Independent Penetration Testing of Cloud-Connected Systems
CVSS-scored penetration test results for Qualysec’s scope of work, which included testing the security of cloud APIs, authentication mechanisms and other interfaces between the device and its connection to clinical applications. These are also suitable for submission by medical device manufacturers to the Food and Drug Administration (FDA) as part of their cybersecurity submissions and/or to document HIPAA Security Risk Analysis requirements. Ensure FDA & HIPAA compliance with Qualysec.
Conclusion
Cloud medical device compliance sits at the intersection of two regulatory frameworks that were not designed with each other in mind. HIPAA governs how PHI is protected once it leaves the device. FDA governs how the device itself, including its cloud-connected components, is documented for cybersecurity. As you think about getting HIPAA and FDA compliant for your medical devices, consider these breaches as lessons from the past to guide how to treat the device, its cloud infrastructure, and application layer – all working together as part of a continuous system instead of separate components.
Not only were there 319 breaches that got reported to HHS OCR in just the first five months of this year (2026), but also note the increased penalty ceiling up to $2,190,294 for each breach tier. All indicate there’s still much work to be done at the seams of today’s technology ecosystem. Manufacturers who document the shared responsibility split explicitly, extend their SBOM and threat models to the cloud layer, and validate the complete system after every infrastructure change are the ones positioned to withstand both an FDA review and an HHS OCR investigation.
Book a consultation with Qualysec to strengthen your cloud medical device compliance programme!
Frequently Asked Questions
1. What is cloud medical device compliance?
Cloud medical device compliance refers to meeting both HIPAA and FDA regulatory requirements for a medical device that stores, processes, or transmits data through cloud infrastructure. It requires securing the device, the cloud environment, and the application layer, connecting them as a single system, with documented evidence of the shared responsibility split between the cloud provider, the device manufacturer, and the healthcare organization operating the device.
2. Does HIPAA apply when my medical device data is in the cloud?
If your medical device data contains Protected Health Information (PHI), then yes – HIPAA’s Security Rule and Breach Notification Rule apply irrespective of where you’ve stored that data. This means that any cloud provider that has PHI being handled by them on behalf of your company or their business associate needs to have signed a Business Associate Agreement with you. Using a non-BAA-eligible cloud service to handle PHI constitutes a HIPAA violation regardless of how good security controls are at an underlying level.
3. Will having a connection to the cloud change the FDA’s cybersecurity requirements for my medical device?
Cloud connectivity does not exempt a device from FDA’s cybersecurity documentation requirements under Section 524B of the FD&C Act. It expands the scope of what must be documented. Cloud-hosted components should be incorporated into the device’s threat model, SBOM, and security architecture. Manufacturers have the responsibility to demonstrate that their entire system is secure to the FDA. This includes all infrastructure-level controls managed by the cloud provider.
4. In case of a data breach in a cloud-hosted medical device system, who has ultimate liability?
This depends on where the breach began and what your Business Associate Agreement covers with respect to responsibilities. As a general rule, however, the party hosting your infrastructure will assume primary responsibility for maintaining infrastructure-level security. Manufacturers are responsible for application security, data handling, and configuration. Ambiguous BAA language on breach detection and notification responsibilities is a common source of delayed reporting, so this allocation should be explicitly defined in the contract rather than assumed.
5. How can manufacturers validate a cloud-hosted medical device system for FDA submission?
FDA’s Computer Software Assurance guidance allows manufacturers to leverage cloud vendor evidence and apply a risk-based validation approach rather than repeating validation that the provider has already performed. Manufacturers still need to validate that the complete system, including cloud components, performs as intended and remains secure, and must re-validate after any cloud infrastructure change that could affect device function or security.
