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

How cloud-based medical devices and SaaS health platforms are regulated in the US and EU — FDA and EU MDR classification of cloud-connected devices, SaMD vs SiMD distinction for cloud software, IEC 62304 Edition 2 lifecycle requirements, cybersecurity (SPDF, SBOM, IEC 81001-5-1), FDA CSA guidance for QMS cloud tools, EU Cyber Resilience Act impact, data integrity and validation challenges, and practical compliance strategies for manufacturers.

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.

Dimension	SaMD (Cloud)	SiMD (Embedded)
Runs on	Cloud servers, general computing	Dedicated hardware
Medical purpose	Independent medical purpose	Part of device function
Regulatory pathway	Own 510(k)/De Novo/PMA or CE	Part of device submission
IEC 62304	Applies	Applies
Cybersecurity	FDA SPDF + cloud-specific	FDA SPDF + device-specific
Updates	Can be deployed OTA via cloud	May require coordinated roll-out

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:

Secure Product Development Framework (SPDF): Manufacturers must implement a structured approach to cybersecurity throughout the product lifecycle
SBOM: Required for all device software, including cloud components
Threat modeling: Must address cloud-specific threats (data breaches, unauthorized access, API vulnerabilities, supply chain attacks)
Vulnerability management: Continuous monitoring and coordinated disclosure
Patch management: Documented process for deploying security updates, including cloud-side updates
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.

Cloud SaMD Function	Typical EU MDR Class
Simple data display or trending	Class I (if no diagnostic purpose)
Clinical decision support for non-critical conditions	Class IIa
Diagnostic algorithm for serious conditions	Class IIb
Treatment planning for life-threatening conditions	Class III

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:

Old Classification	New Rigor Level	Description
Class A	Level I (Low)	No injury or harm possible
Class B	Level II (High)	Non-serious injury possible
Class C	Level II (High)	Serious injury or death possible

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:

Identify intended use: Define what the cloud software does in your quality system
Assess risk: Determine the risk level of each software feature (high/medium/low)
Determine assurance activities: Select appropriate testing strategies based on risk
Execute assurance activities: Perform testing and document results
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:

Principle	Cloud Implementation
Attributable	User authentication (MFA), audit trails with unique user IDs
Legible	Consistent data formats, export capabilities, human-readable logs
Contemporaneous	Real-time timestamping with synchronized clocks
Original	Source data preservation, no overwrite without audit trail
Accurate	Input validation, data verification, error checking
Complete	No partial records, all data fields populated
Consistent	Chronological ordering, no out-of-sequence entries
Enduring	Durable storage with backup and disaster recovery
Available	Retrieval within reasonable time, query capabilities

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

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.
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.
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.
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.
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.
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)