Cloud-Based Medical Devices & SaaS: Regulatory Compliance Guide (FDA, EU MDR 2026)

The Rise of Cloud-Based Medical Devices

The medical device industry is moving to the cloud. Remote patient monitoring platforms, AI-powered diagnostic services, cloud-connected imaging systems, and SaaS quality management tools are now mainstream. The global digital health market was valued at $56 billion in 2026, with software solutions holding approximately 46% revenue share, and projections point to $1 trillion by 2034.

But cloud-based medical devices introduce regulatory complexity that traditional hardware-only devices never faced. A cloud-connected device spans at least three regulatory domains: the physical device itself, the software running on it, and the cloud infrastructure processing patient data. Each layer has different requirements, and the interactions between them create additional obligations.

This guide covers the complete regulatory framework for cloud-based medical devices and SaaS health platforms in the US (FDA) and EU (MDR) as of 2026.

SaMD vs SiMD: Where Cloud Software Fits

The first regulatory question for any cloud-based medical device is classification: is the software Software as a Medical Device (SaMD) or Software in a Medical Device (SiMD)?

SaMD — Standalone Medical Software

SaMD is software intended to be used for one or more medical purposes that performs these purposes without being part of a hardware medical device. Cloud-based diagnostic algorithms, remote monitoring analytics platforms, and clinical decision support tools that run entirely in the cloud are typically SaMD.

Key characteristics:

• Runs on general-purpose computing infrastructure (cloud servers, not embedded in a physical device)

• Has its own medical intended purpose

• Is independently regulated as a medical device

• Requires its own technical documentation and conformity assessment

SiMD — Embedded Software

SiMD is software that is part of a physical medical device. The firmware controlling an infusion pump, the embedded software in an MRI machine, or the operating software in a surgical robot are SiMD.

The Cloud Hybrid

Many modern products are hybrids: a physical device (with SiMD firmware) connects to a cloud platform (SaMD) that performs additional analytics. A continuous glucose monitor (SiMD in the sensor/transmitter) that sends data to a cloud analytics platform (SaMD) for trend analysis and alerts is a hybrid. Both software components are regulated, but under different classification frameworks.

FDA Regulation of Cloud-Based Medical Devices

When Cloud Software Is a Medical Device

The FDA applies a function-based approach: it regulates software based on what it does, not where it runs. A cloud algorithm that diagnoses disease from medical images is regulated the same way as a locally installed algorithm that does the same thing. The platform does not determine the regulatory pathway; the intended use does.

The FDA's September 2022 guidance "Policy for Device Software Functions and Mobile Medical Applications" states that only software functions that (1) meet the device definition and (2) could pose a risk to patient safety if they fail to function as intended are subject to active regulatory oversight.

Cloud software functions that are typically regulated:

• Diagnostic algorithms (image analysis, signal processing, pathology detection)

• Treatment recommendation engines

• Remote patient monitoring with clinical alerting

• Dosage calculation software

• AI-powered clinical decision support that fails the CDS exclusion criteria

Cloud software functions that are typically not regulated (or subject to enforcement discretion):

• General wellness apps with no specific medical claims

• Electronic health record systems (regulated under ONC, not FDA)

• Administrative software (scheduling, billing)

• CDS software meeting all four statutory exclusion criteria under the 21st Century Cures Act

• Medical Device Data Systems (MDDS) — subject to enforcement discretion since 2015

Premarket Submission Content for Cloud Software

The FDA's June 2023 guidance "Content of Premarket Submissions for Device Software Functions" applies to cloud-based software. Key documentation requirements:

Software Description:

• Intended use and indications for use

• Software architecture (including cloud components)

• Level of concern (Basic or Enhanced, replacing the former Minor/Moderate/Major)

• Hardware and software requirements for cloud infrastructure

Cybersecurity Documentation (per June 2025 final guidance):

• Security risk analysis addressing cloud-specific threats

• Software Bill of Materials (SBOM) — now required under Section 524B

• Secure Product Development Framework (SPDF) evidence

• Threat modeling documentation

• Vulnerability management plan

• Patch management and update procedures

IEC 62304 Documentation:

• Software safety classification (Class A/B/C, or Level I/II under Edition 2)

• Software development plan

• Requirements specification

• Architecture design

• Verification and validation testing

• Release records

FDA CSA Guidance for Cloud QMS Tools

The FDA's September 2025 final guidance on Computer Software Assurance (CSA) applies to cloud-based tools used in production and quality systems. This includes cloud-based eQMS platforms, SaaS manufacturing execution systems, and cloud quality tools.

The CSA guidance introduces a risk-based validation approach:

• High-risk software features: Full scripted testing with detailed evidence

• Medium-risk features: Combination of scripted and unscripted testing

• Low-risk features: Unscripted testing with lean documentation

For SaaS QMS tools specifically, the guidance allows manufacturers to leverage vendor evidence (SOC 2 reports, ISO 27001 certifications, validation documentation) instead of independently re-validating every cloud platform function — a significant efficiency gain over traditional CSV approaches.

FDA Cybersecurity Requirements for Cloud Devices

The FDA's June 2025 final cybersecurity guidance (updated February 2026) establishes lifecycle cybersecurity expectations for all connected devices, including cloud-based systems:

1. Secure Product Development Framework (SPDF): Manufacturers must implement a structured approach to cybersecurity throughout the product lifecycle

2. SBOM: Required for all device software, including cloud components

3. Threat modeling: Must address cloud-specific threats (data breaches, unauthorized access, API vulnerabilities, supply chain attacks)

4. Vulnerability management: Continuous monitoring and coordinated disclosure

5. Patch management: Documented process for deploying security updates, including cloud-side updates

6. Section 524B compliance: Since March 2023, manufacturers must submit a cybersecurity plan with premarket applications

EU MDR Classification of Cloud-Based Devices

Classification Rules

Under the EU MDR, standalone software is classified using Rule 11 (Annex VIII, Chapter III):

"Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: death or an irreversible deterioration of a person's health, in which case it is in class III; or a serious deterioration of a person's health or a surgical intervention, in which case it is classified as class IIb."

This means most cloud-based SaMD is at minimum Class IIa in the EU — a higher baseline than the US, where many equivalent products may qualify for 510(k) exemption or enforcement discretion.

Cybersecurity Under EU MDR

The EU MDR GSPR (Annex I, Section 17.2) requires that devices incorporating software be developed and manufactured in accordance with the state of the art, including IT security measures and protection against unauthorized access. Notified Bodies expect:

• Cybersecurity risk management integrated into ISO 14971 risk management

• IEC 81001-5-1 compliance for secure software lifecycle

• MDCG 2019-16 guidance on cybersecurity for medical devices

• Post-market cybersecurity surveillance plan

• Vulnerability monitoring and incident response procedures

EU Cyber Resilience Act and NIS2

Two additional EU regulations affect cloud-based medical devices:

Cyber Resilience Act (CRA): Adopted in 2024, the CRA requires all products with digital elements sold in the EU to meet cybersecurity requirements. Medical devices are covered by sector-specific legislation (MDR/IVDR), but the CRA may apply to cloud infrastructure components that are not themselves medical devices.

NIS2 Directive: Effective October 2024, NIS2 imposes cybersecurity risk management and reporting obligations on essential and important entities, including medical device manufacturers and health infrastructure operators.

EU AI Act Implications

For cloud-based SaMD that incorporates AI/ML:

• High-risk AI systems under the EU AI Act must comply with risk management, data governance, transparency, and human oversight requirements

• The MDCG published guidance (MDCG 2025-6) on the interplay between MDR/IVDR and the AI Act

• Cloud AI systems used in clinical settings likely qualify as both high-risk AI (AI Act) and medical devices (MDR)

• Dual compliance requires mapping AI Act requirements onto existing MDR technical documentation

IEC 62304 Edition 2 and Cloud Software

IEC 62304 is the foundational standard for medical device software lifecycle processes. Edition 2, in ballot as of 2026, introduces significant changes relevant to cloud-based devices:

New Software Process Rigor Levels

Edition 2 replaces the three safety classes (A/B/C) with two rigor levels:

This simplification reduces the "gray area" between Classes B and C and streamlines documentation requirements for cloud software that previously fell into borderline classifications.

Expanded Scope

Edition 2 explicitly extends to:

• All health software (not just software in medical devices)

• AI/ML lifecycle management

• Cloud-deployed software

• Software-as-a-Service models

Integration with IEC 81001-5-1

IEC 81001-5-1 (cybersecurity for health software) complements IEC 62304 by adding security-by-design principles:

• Threat modeling and risk assessment

• Secure coding standards

• Vulnerability management

• SBOM governance

• Secure update mechanisms

For cloud-based devices, both standards should be applied together: IEC 62304 for safety lifecycle and IEC 81001-5-1 for cybersecurity lifecycle.

Data Integrity and Validation Challenges

Cloud Validation Requirements

Cloud-based medical devices present unique validation challenges:

Infrastructure variability: Cloud providers update infrastructure continuously. Unlike on-premise software running on fixed hardware, cloud software operates on infrastructure the manufacturer does not fully control. Validation must account for:

• Cloud provider change management processes

• Service-level agreements and uptime commitments

• Data residency and sovereignty requirements

• Disaster recovery and business continuity

Multi-tenancy: SaaS platforms often serve multiple customers on shared infrastructure. Validation must demonstrate:

• Data isolation between customers

• Access control enforcement

• Audit trail integrity across tenants

• Performance under varying loads

Continuous deployment: Cloud software is typically updated more frequently than embedded software. The validation strategy must include:

• Risk-based regression testing for each deployment

• Automated CI/CD pipeline validation

• Rollback procedures for failed deployments

• Change control documentation aligned with ISO 13485

FDA CSA Approach to Cloud Validation

Under the FDA's CSA guidance, cloud QMS and production software can be validated using a streamlined approach:

1. Identify intended use: Define what the cloud software does in your quality system

2. Assess risk: Determine the risk level of each software feature (high/medium/low)

3. Determine assurance activities: Select appropriate testing strategies based on risk

4. Execute assurance activities: Perform testing and document results

5. Maintain evidence: Retain records per 21 CFR Part 820 / QMSR requirements

Vendor evidence (SOC 2 Type II reports, ISO 27001 certifications, cloud provider audit reports) can supplement but not replace your own assurance activities.

Data Integrity (ALCOA+ Principles)

Cloud-based medical devices must maintain data integrity per ALCOA+ principles:

Cloud Provider Considerations

Choosing a Cloud Provider for Medical Devices

Key factors when selecting a cloud infrastructure provider:

Regulatory readiness:

• Willingness to sign a Business Associate Agreement (BAA) if handling PHI

• SOC 2 Type II certification

• ISO 27001 certification

• Compliance with regional data residency requirements (GDPR for EU, HIPAA for US)

Security capabilities:

• Encryption at rest and in transit (AES-256, TLS 1.2+)

• Identity and access management (IAM) with MFA

• Network segmentation capabilities

• Intrusion detection and prevention

• Vulnerability management programs

• Incident response capabilities

Operational characteristics:

• Service-level agreements (uptime, latency, recovery time)

• Data center locations and availability zones

• Disaster recovery and business continuity capabilities

• Audit logging and monitoring

• API availability and versioning policies

Contractual protections:

• Data ownership and portability rights

• Data breach notification timelines

• Right to audit

• Data deletion and retention policies

• Subprocessor transparency and control

Major Cloud Provider Medical Device Programs

All three major cloud providers have specific programs for healthcare and medical device workloads:

• AWS: AWS HealthLake, HIPAA-eligible services, BAA program, FedRAMP authorization

• Azure: Azure Health Data Services, Microsoft Cloud for Healthcare, HITRUST certification

• GCP: Cloud Healthcare API, HIPAA compliance, PHI-capable infrastructure

These programs provide infrastructure-level compliance, but the device manufacturer remains responsible for validating that the cloud deployment meets medical device requirements.

Practical Compliance Strategy

Step 1: Classify Your Cloud Software

• Determine if your cloud component is SaMD, SiMD, or non-device software

• Classify under FDA (level of concern) and EU MDR (Rule 11)

• Document the classification rationale

Step 2: Build Your Technical Documentation

• Software requirements specification (including cloud architecture)

• Architecture design documentation

• IEC 62304 lifecycle documentation

• Cybersecurity risk analysis and threat model

• SBOM for all software components (cloud and device)

• Clinical evaluation (for EU MDR)

Step 3: Implement Cybersecurity Controls

• Deploy the SPDF across the entire cloud-device ecosystem

• Implement encryption at rest and in transit

• Establish identity and access management with MFA

• Set up vulnerability scanning and monitoring

• Create incident response and vulnerability disclosure procedures

• Document patch management processes

Step 4: Validate the Cloud Deployment

• Apply FDA CSA principles for risk-based validation

• Conduct end-to-end data flow testing

• Verify security and access controls

• Test disaster recovery and failover

• Validate under expected load conditions

• Document all validation evidence

Step 5: Establish Lifecycle Management

• Implement change control for cloud deployments

• Maintain SBOM currency

• Monitor cloud provider changes and assess impact

• Conduct periodic re-validation after significant changes

• Track post-market cybersecurity intelligence

• Update risk management documentation continuously

Key Takeaways

1. Platform does not determine regulation: The FDA regulates based on function and intended use, not whether software runs in the cloud or on a device.

2. EU MDR sets a higher baseline: Most cloud-based SaMD is at minimum Class IIa under Rule 11, regardless of risk level that might qualify for enforcement discretion in the US.

3. Cybersecurity is a lifecycle obligation: Both FDA and EU MDR treat cybersecurity as an ongoing requirement, not a one-time submission checkbox. The SPDF, SBOM, and vulnerability management must span the entire product lifecycle.

4. IEC 62304 Edition 2 modernizes the standard: The new two-level rigor system, expanded scope to all health software, and AI/ML lifecycle provisions align the standard with cloud-first development realities.

5. Cloud validation requires a new approach: The FDA's CSA guidance allows manufacturers to leverage vendor evidence and apply risk-based validation strategies, reducing the burden compared to traditional CSV while maintaining patient safety assurance.

6. Shared responsibility is the model: Cloud providers secure the infrastructure; device manufacturers secure the application, data, and configuration. Both parties have compliance obligations, and the manufacturer retains ultimate regulatory responsibility.

Sources and Further Reading

• FDA Policy for Device Software Functions and Mobile Medical Applications (September 2022)

• FDA Content of Premarket Submissions for Device Software Functions (June 2023)

• FDA Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (June 2025, updated February 2026)

• FDA Computer Software Assurance for Production and Quality System Software (September 2025)

• IEC 62304 Edition 2 Draft (2026 ballot)

• IEC 81001-5-1: Health Software and Health IT Systems — Cybersecurity

• EU MDR 2017/745, Annex VIII Classification Rules, Rule 11

• MDCG 2019-16: Guidance on Cybersecurity for Medical Devices

• MDCG 2025-6: Interplay between MDR/IVDR and the EU AI Act

• EU Cyber Resilience Act (2024)