A medical device delivered as Software-as-a-Service is still a medical device under Regulation (EU) 2017/745. The deployment model does not change qualification or classification, but it changes everything about how the manufacturer runs release control, change management, post-market surveillance, and cybersecurity. Multi-tenant SaaS, continuous deployment, and shared infrastructure introduce obligations that a traditional packaged-software manufacturer does not face — and missing them is the most common way a SaaS MDSW startup fails its first Notified Body audit.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • SaaS delivery does not change whether software is a medical device under MDR Article 2(1). Qualification and Rule 11 classification apply the same way whether the software runs on a hospital workstation or a multi-tenant cloud.
  • What SaaS changes is the operational shape of compliance: release cadence, change control, PMS data flows, cybersecurity posture, and the boundary between the device and the infrastructure it runs on.
  • MDR Annex I Section 17 requires the minimum hardware, IT network, and IT security requirements to be specified for software devices. For SaaS, that includes the cloud infrastructure the manufacturer controls, not only the client side.
  • Continuous deployment is compatible with EN 62304:2006+A1:2015, but only if the change-control, verification, and release process is documented and every deployed version is traceable. "Ship to production whenever main goes green" is not a release process that survives audit.
  • MDR Article 83 PMS obligations for SaaS are richer than for packaged software because the manufacturer sees every use of the device in real time. What the manufacturer sees, the manufacturer is expected to act on.
  • MDCG 2019-11 Rev.1 (June 2025) confirms that cloud-hosted and multi-tenant deployments are in scope of MDSW when their intended purpose meets Article 2(1). The guidance does not create a separate regime for SaaS — it extends the existing one.

Why SaaS is the operational question, not the regulatory one

The first sentence founders usually say when they start a SaaS MDSW conversation is some version of "we are SaaS, so the MDR is different for us." It is not. The MDR treats SaaS as a deployment model, not as a category of device. Qualification runs through Article 2(1). Classification runs through Annex VIII Rule 11. Lifecycle obligations run through Annex I Section 17 and EN 62304:2006+A1:2015. The same rules that apply to software shipped on a USB stick apply to software shipped as a web app.

What is different is how those rules land when the software is continuously deployed, multi-tenant, and operated by the manufacturer on behalf of every customer at once. Packaged software is shipped and then observed from a distance. SaaS is operated. The manufacturer carries responsibility for infrastructure, uptime, data handling, release management, and the real-time behaviour of the system across every customer, at the same time. None of those responsibilities are new to the MDR — they are all traceable to Annex I and to Article 83 — but they show up with an intensity that packaged software manufacturers never faced.

This post is the translation layer. Not a separate regulatory framework, because there is no separate framework. The operational playbook for running a SaaS medical device inside the existing one.

What makes SaaS regulatory-unique

Four things make SaaS meaningfully different in practice, even though none of them change the underlying regulation.

First, the manufacturer operates the device. On a traditional packaged device the manufacturer ships code and the user runs it. On SaaS the manufacturer runs the code. This collapses the boundary between "placing on the market" and "providing a service." Every logged-in user session is a use of the device that the manufacturer is directly enabling. That turns a lot of what would be user-responsibility on a desktop product into manufacturer-responsibility on SaaS — uptime, availability, data integrity, session management, identity management, and the behaviour of the software under load.

Second, the release cadence is continuous. SaaS teams ship weekly, daily, or in some cases multiple times per day. A packaged medical device typically has releases measured in months. The MDR and EN 62304:2006+A1:2015 do not forbid fast cadence — but they do require that every change with a safety impact is controlled, verified, and traceable. Fast cadence and controlled changes are not incompatible, but they do not coexist by accident.

Third, the infrastructure is shared. Multi-tenant SaaS means many customers share the same database, the same application servers, and the same code path. A deployment that fixes a bug for one customer fixes it for all customers — and a regression introduced for one customer affects all customers. The blast radius of a change is larger than it is for single-tenant or on-premise software, and the isolation of patient data across tenants becomes an engineering and compliance problem rather than a customer problem.

Fourth, the manufacturer has unprecedented PMS visibility. A packaged-software manufacturer waits for complaints. A SaaS manufacturer has production logs, telemetry, error rates, usage patterns, and performance metrics for every session. Under MDR Article 83 the manufacturer is required to have a PMS system. When the manufacturer sees every event in real time, the definition of "systematically collected" data becomes much richer — and the expectation of what the manufacturer should have noticed becomes much higher.

Multi-tenant considerations — where shared infrastructure meets medical software

Multi-tenancy is where the sharpest SaaS-specific questions land. Several are worth naming explicitly.

Data isolation between tenants. MDR Annex I Section 17 requires minimum hardware, IT network, and IT security requirements to be specified. For multi-tenant SaaS, tenant isolation is a direct safety and security requirement. A patient record leaking from one hospital into another is not a business problem — it is a clinical safety incident and a data-protection incident at the same time. The technical documentation has to show how isolation is architected, tested, and monitored. "Row-level security in the database" is a valid answer only if it is documented, verified, and covered by the risk file under EN ISO 14971:2019+A11:2021.

Shared release across tenants. When a new version is deployed, every tenant receives it at the same moment. This is an operational advantage and a regulatory weight. The change evaluation has to hold for every tenant at once. If one tenant uses the software in an edge-case configuration — different language, different integration, different user permissions — the verification plan has to cover that configuration before the change ships.

Configuration versus code. Multi-tenant SaaS often exposes tenant-level configuration: toggles, feature flags, custom thresholds, white-labelled branding. The line between "configuration" and "a change to the medical device" is not intuitive. If a tenant-level configuration changes the clinical behaviour of the software — for example, a different alerting threshold for a vital-sign metric — the configuration is part of the device's intended purpose and has to be controlled accordingly. The technical file must specify which configuration surfaces are in scope of the device and which are administrative.

Shared cybersecurity surface. EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1 apply to every medical software manufacturer. On multi-tenant SaaS they apply more sharply because a single cybersecurity vulnerability affects every tenant at once. The security architecture, patch management, and vulnerability disclosure process are device-level obligations, not infrastructure hygiene.

Continuous deployment vs release control

This is the place most SaaS MDSW conversations get stuck. The engineering team wants to ship continuously. The regulatory reading of EN 62304:2006+A1:2015 sounds, on first pass, like every release needs a formal release note signed in triplicate. Neither extreme is correct.

EN 62304:2006+A1:2015 is process-neutral. The standard requires that software changes be planned, analysed for impact, verified, documented, and released under configuration control. It does not say at what cadence this has to happen or whether the ceremony must be human or automated. A well-designed continuous-deployment pipeline satisfies every requirement of the standard, if the pipeline itself produces the evidence the standard expects.

In practice this means the release process has to answer four questions for every deployment: what changed, what could break, what was verified, and who approved the release. For a CI/CD pipeline these answers can be produced automatically — version control provides "what changed," a documented impact-analysis rule set and test coverage provide "what could break" and "what was verified," and an automated or human approval gate provides "who approved." The documentation lives in the pipeline, the commit history, and the release artefacts, not in a separate Word document that nobody reads.

The non-negotiable parts are these. Every version that reaches production must be traceable to the exact source code and dependencies that produced it. Every change with a potential safety impact must go through an impact analysis before it ships. Every change must be covered by verification that matches the risk class of the affected functionality. Every release must be recoverable — a rollback path has to exist and has to have been tested. And the risk management file under EN ISO 14971:2019+A11:2021 has to stay current as changes land — a file that is updated annually cannot describe a system that changes weekly.

"Ship to production when CI is green" is a valid slogan for a non-medical product. For a medical device it is a valid slogan only if CI encodes the full change-control and verification discipline the standard requires. Most SaaS teams do not start there. They can get there, and the sooner in a product's life the pipeline is set up this way, the cheaper it is.

Versioning and the scope of conformity assessment

Conformity assessment under the MDR is performed on a specific version of the device, with a specific intended purpose, specific technical documentation, and specific clinical evaluation. SaaS creates a version-management question that packaged software does not face: at what granularity is the device versioned for regulatory purposes?

Two approaches work in practice. The first is a release-version model: every production release gets a medical-device version number (for example, 2.4.3), the technical file is kept current for that version, and changes between versions are managed as device changes under the QMS. This works well when releases happen weekly or less often. The second is a baseline-plus-change-log model: the manufacturer maintains a regulatory baseline version, every change is logged and assessed against that baseline, and the technical file is re-stamped as a new baseline when the accumulated changes cross a materiality threshold. This works for higher-cadence environments but requires a disciplined change log and a clear definition of what counts as material.

Either approach must answer the Notified Body's question: when you say "the device," which deployed code are you referring to, and what evidence do you have that that code matches the technical file? If the answer involves hand-waving, the conformity assessment is compromised.

Significant changes — under MDR Article 120(3) and more broadly under manufacturer change control — may trigger a new conformity assessment. MDCG guidance defines significant change for software in the specific context of legacy device transitions; for a device already under MDR certification, the manufacturer's own change-control procedure determines when a change is significant enough to require Notified Body involvement. The procedure must be written before it is needed, not after.

Post-market surveillance for a SaaS device

MDR Article 83 requires every manufacturer to plan, establish, document, implement, maintain, and update a post-market surveillance system, proportionate to the risk class of the device. For SaaS this is the article that most often surprises startups. The obligation is not new — packaged software is also subject to Article 83 — but the data the manufacturer has access to is categorically different.

A SaaS manufacturer can, in principle, see every error, every latency spike, every unusual input pattern, every failed login, every edge case the device hits in production. MDCG 2025-10 (December 2025) describes the PMS system and the PMS plan in terms that clearly cover this kind of telemetry. The practical consequence is that the PMS plan should specify which telemetry the manufacturer collects, how it is analysed, what thresholds trigger review, and how findings feed into the risk file, CAPA, and vigilance under MDR Article 87.

What this looks like operationally: automated dashboards for error rates and clinical alerts, a scheduled review of production logs against pre-defined safety signals, an incident-classification process that distinguishes IT incidents from device incidents, and a documented flow from detected safety signal to risk management update to CAPA to vigilance report when the thresholds of Article 87 are met.

The inverse risk is important. A manufacturer that has access to production telemetry and does not use it cannot later claim it "did not know." The PMS obligation under Article 83 is an active one. SaaS visibility raises the floor of what "active" means.

Cybersecurity and uptime as safety obligations

MDR Annex I Section 17 and MDCG 2019-16 Rev.1 treat cybersecurity as a safety obligation for connected medical software. EN IEC 81001-5-1:2022 is the harmonised standard that operationalises the lifecycle security activities. For SaaS, three cybersecurity questions are more acute than they are for packaged software.

Vulnerability response time. A vulnerability in a SaaS application can be patched centrally and fast — which is an advantage, and also an expectation. The vulnerability management process should define response-time targets by severity, and the security architecture should allow patches to be deployed without long release cycles.

Availability as a safety concern. Some medical SaaS applications are used in real-time clinical workflows. If the application is unavailable during a clinical use, that is potentially a safety event. The risk file has to address availability, the technical documentation has to specify the uptime expectations set for the user, and the incident response plan has to cover downtime as a clinical scenario, not only as an IT scenario.

Third-party infrastructure dependencies. SaaS runs on cloud providers. The cloud provider is a supplier under EN ISO 13485:2016+A11:2021 and the manufacturer remains responsible for the device as a whole. This overlaps directly with the cloud-services topic covered in post 394.

Common mistakes SaaS MDSW startups make

  • Treating deployment as out of scope of the device. The infrastructure the manufacturer operates is part of the device for MDR purposes when it affects clinical behaviour, data integrity, or availability.
  • Shipping continuous deployments without a documented change-control process the pipeline actually implements. The audit question is not whether the team ships fast; it is whether every shipped version is traceable and verified.
  • Leaving tenant isolation undocumented in the risk file. Multi-tenant architecture is a risk control and has to appear as one.
  • Conflating IT incidents with device incidents, and missing the clinical-safety signal inside operational noise.
  • Under-specifying minimum client-side requirements. The user's browser, connection, and device are part of the "minimum hardware, IT networks and IT security measures" that Annex I Section 17 requires to be specified.
  • Assuming cloud provider compliance certifications cover the manufacturer's obligations. They do not. The manufacturer remains the manufacturer.
  • Collecting production telemetry and not feeding it into the PMS system. Data the manufacturer has access to is data the manufacturer is expected to use.

The Subtract to Ship angle for SaaS MDSW

SaaS is the category where Subtract to Ship has the sharpest edge. Traditional regulatory consultants often describe SaaS MDSW compliance as if every deployment needed a packaged-release-style ceremony. It does not. The Regulation does not require ceremony. It requires traceability, verification, change control, and documented process — all of which can live inside a well-designed engineering pipeline.

Subtract the parts that are theatre: duplicate release documentation that nobody reads, manual sign-offs that mirror automated gates, Word-document change logs that mirror Git history, separate QMS binders that mirror the CI/CD pipeline. Keep the parts that are load-bearing: the impact analysis, the risk file, the verification evidence, the rollback plan, the PMS signal flow, the cybersecurity lifecycle. The result is a compliance posture that matches how SaaS engineering teams actually work, with every activity traceable to a specific MDR obligation. This is the four-pass framework from post 065 applied to SaaS.

Reality Check — Where do you stand on SaaS compliance?

  1. Is your SaaS deployment pipeline documented in a way an auditor could read without help from your engineering team?
  2. Can you point at any production version and trace it back to the exact source code, dependencies, and verification evidence that produced it?
  3. Does your risk management file under EN ISO 14971:2019+A11:2021 reflect the current deployed architecture, or is it six months stale?
  4. Is tenant isolation a documented risk control, with verification evidence and monitoring?
  5. Does your PMS plan under MDR Article 83 specify which production telemetry you collect, how it is reviewed, and how findings reach CAPA and vigilance?
  6. Is your change-control process written and followed, or written and ignored?
  7. Can you name the EN 62304:2006+A1:2015 activities that happen at every deployment, and point at where the evidence lives?
  8. Do you have a rollback plan that has been tested on production at least once?

Frequently Asked Questions

Does MDR treat SaaS differently from packaged medical software? No. MDR qualification and classification are driven by intended purpose, not by deployment model. What changes for SaaS is the operational shape of compliance — change control, release cadence, PMS data flows, and cybersecurity — not the underlying regulatory regime. MDCG 2019-11 Rev.1 (June 2025) confirms that cloud-hosted and multi-tenant software is in scope when its intended purpose meets Article 2(1).

Can a SaaS medical device use continuous deployment under EN 62304:2006+A1:2015? Yes, provided the pipeline encodes the change-control, impact-analysis, verification, and release-management activities the standard requires. EN 62304:2006+A1:2015 is process-neutral. The documentation can live in the pipeline, the commit history, and the release artefacts — as long as the evidence is real, traceable, and sufficient for the risk class.

How does multi-tenancy affect the technical file? Tenant isolation must be documented as a risk control under EN ISO 14971:2019+A11:2021. The technical file must describe the architecture that enforces isolation, the verification that proves it, and the monitoring that detects failure. Multi-tenancy does not trigger a new rule in the MDR — it raises the bar on what "IT security measures" under Annex I Section 17 must cover.

Does production telemetry count as PMS data under MDR Article 83? Yes, when the manufacturer collects and has access to it. MDCG 2025-10 (December 2025) describes PMS in terms that clearly cover telemetry-style data sources. A SaaS manufacturer who collects production logs is expected to analyse them against safety signals and feed findings into the risk file, CAPA, and vigilance processes under MDR Article 87.

Is the cloud provider a supplier under EN ISO 13485:2016+A11:2021? Yes. Any third party whose services affect the quality, safety, or performance of the device is a supplier, and the manufacturer has supplier-control obligations. The cloud provider's own compliance certifications do not substitute for the manufacturer's QMS — they feed into the supplier-evaluation process as evidence, not as a replacement for it. Post 394 covers cloud-service dependencies in depth.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I Section 17 (software and IT security requirements), Article 10(9) (QMS proportionality), Article 83 (post-market surveillance system), Article 87 (vigilance reporting). Official Journal L 117, 5.5.2017.
  2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
  3. MDCG 2019-16 — Guidance on Cybersecurity for medical devices. First published December 2019; Revision 1, July 2020.
  4. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices, December 2025.
  5. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).
  6. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes.
  7. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.
  8. EN IEC 81001-5-1:2022 — Health software and health IT systems safety, effectiveness and security — Part 5-1: Security — Activities in the product life cycle.

This post is part of the Software as a Medical Device Under MDR series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — the standards referenced here provide presumption of conformity with specific Annex I requirements, not independent authority. For startup-specific regulatory support on SaaS MDSW compliance, Zechmeister Strategic Solutions is where this work is done in practice.