---
title: Software Updates Under MDR: When Does an Update Require a New Conformity Assessment?
description: Not every software update under MDR requires a new conformity assessment. Here is how to decide whether your update is significant under Annex IX.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: software updates MDR new conformity assessment
canonical_url: https://zechmeister-solutions.com/en/blog/software-updates-mdr-new-conformity-assessment
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Software Updates Under MDR: When Does an Update Require a New Conformity Assessment?

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A software update under MDR requires a new conformity assessment only when the change is significant — meaning it affects intended purpose, safety, performance, or the device's classification. Routine bug fixes, security patches, and non-significant enhancements do not trigger a new assessment, but every change must still be controlled through your QMS, evaluated against the significant change criteria in MDCG 2019-11 Rev.1, and handled through the change control process in EN 62304:2006+A1:2015. The decision is not about effort or code volume. It is about whether the change moves the device, in a regulatory sense, into territory the Notified Body has not seen.**

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

---

## TL;DR

- A new conformity assessment is required only for significant changes. MDCG 2019-11 Rev.1 provides the criteria for software and is the document every manufacturer needs to have open when making change decisions.
- Significant changes under MDR are framed through Annex IX Sections 2.4 and 4.10. For legacy devices still on the market under the MDR transition, Article 120 adds the separate question of whether a change is significant in design or intended purpose.
- The binary that matters is not "update yes or no" — it is "significant change yes or no." Security patches and defect fixes that restore intended behaviour are normally not significant.
- Every software change, significant or not, flows through the EN 62304:2006+A1:2015 change control process and your QMS. The change being "minor" does not mean the process is skipped.
- The cost of getting this decision wrong runs in both directions. Over-reporting drowns the Notified Body in noise and delays real changes. Under-reporting ships a changed device that the assessment no longer covers — which is a market access problem waiting to be found.

---

## Why this question keeps coming up

Almost every software medical device team asks the same question within the first year on the market. We shipped a patch. We fixed a defect. We added a feature a customer asked for. Do we now have to go back to the Notified Body?

The honest answer is that there is no universal yes or no, and the teams that try to build a simple flowchart end up either paralysed or reckless. Software changes do not fit a single mould. A two-line fix can be significant if it touches the algorithm that drives the intended purpose. A ten-thousand-line refactor can be non-significant if the behaviour visible to the user and the clinical claim stay identical. Classification rules, risk controls, and the boundary of what the Notified Body has already assessed — all of this sits behind the decision.

What makes this decision manageable is that the regulation and MDCG 2019-11 Rev.1 together give you a structured way to ask the question. The mistake is to treat the question as gut feeling. The discipline is to run every change through the same evaluation and to write down the answer with reasons. When the next audit comes, the auditor does not want to see an opinion. The auditor wants to see the evaluation record.

## The significant change concept

MDR uses the term "significant change" in several places, and it is worth being precise about which provision applies to which situation.

For new devices going through conformity assessment with Notified Body involvement, Annex IX Sections 2.4 and 4.10 require the manufacturer to inform the Notified Body about planned substantial changes to the approved quality management system, the product range covered, or the approved design. The Notified Body assesses the changes and either confirms the existing certificate remains valid or requires a supplementary assessment. This is the provision that governs the day-to-day question most software manufacturers face: we have a CE-marked device, we are about to ship an update, does this trigger additional Notified Body review.

For legacy devices that are still being placed on the market under the extended MDR transition arrangements, Article 120 adds a separate test. A legacy device may continue under its old certificate only if there are no significant changes in design or intended purpose. The significant change question in Article 120 is narrower and is tied to the transition itself — it is asking whether the device is still the same device that was certified under the earlier framework.

These two provisions overlap in spirit but sit in different places in the regulation and answer slightly different questions. For most software manufacturers in active maintenance, the Annex IX test is the one that matters. For teams still leveraging the Article 120 transition window for an older product, both tests apply in parallel.

## When Notified Body consultation is triggered

The trigger for Notified Body consultation is not the size of the update. It is whether the update changes something the Notified Body already assessed in a way that the existing assessment no longer covers.

A practical way to think about this: the Notified Body issued the certificate based on a specific picture of the device. That picture includes the intended purpose, the classification, the clinical claims, the risk controls, the software architecture at the level described in the technical documentation, and the verification and validation evidence. If an update changes any element of that picture in a way that a reasonable auditor would want to re-examine, the consultation is triggered. If the update leaves the picture intact, it is not.

The framing is not "did we change code." It is "did we change the device that was assessed." Those are very different questions, and teams that ask the first one over-report. Teams that ask the second one — properly, with the regulation in front of them — make the right call most of the time, and the few borderline cases become conversations with the Notified Body rather than surprises.

## The MDCG 2019-11 Rev.1 framing for software changes

MDCG 2019-11 Rev.1 is the guidance document that operationalises the significant change concept for medical device software. Rev.1 was published in June 2025 and is the version every team should be working from. It sets out specific criteria for when a software change is significant in the MDR sense, including changes to the intended purpose, changes to the algorithm that drives the clinical decision support, changes to the user interface that affect how outputs are interpreted, and changes to the operating environment or the interoperability claims.

The pattern in the guidance is consistent. Changes that touch the regulatory identity of the device — what it does, for whom, in what context, and with what clinical claim — are candidates for significant. Changes that preserve that identity while improving performance, reliability, or security are candidates for non-significant. "Candidates" is the right word because every change must still be evaluated on its merits, and the guidance does not remove the obligation to document the reasoning.

Two categories deserve particular attention because they get misjudged the most. Cybersecurity patches: normally not significant, because they restore the device to the secure state that was intended, and the Notified Body expects manufacturers to keep the device secure throughout the lifecycle under MDR Annex I Section 17. Performance improvements to an existing algorithm: often significant, because "better performance" implies a different clinical claim, and changed clinical claims are exactly what the significant change concept is designed to catch.

## The change control process under EN 62304:2006+A1:2015

EN 62304:2006+A1:2015 is the harmonised standard for medical device software life-cycle processes, and it contains the change control process every software manufacturer must follow regardless of whether a change is significant. The standard does not distinguish between major and minor changes in the way the regulation does — it requires every change to be evaluated, planned, implemented, verified, and released under a controlled process, with traceability back to the requirements, risks, and architecture.

This is important to hold separate from the MDR significant change question. EN 62304 change control is always required. It runs for the one-line fix as much as for the new feature. The question "is this a significant change for the Notified Body" is a separate question that sits on top of the EN 62304 process and uses the outputs of that process — the impact analysis, the regression test results, the risk re-evaluation — as inputs to the decision.

Teams that conflate the two end up in one of two bad states. Either they treat EN 62304 change control as something that only applies to big changes, which is a non-conformity waiting to happen. Or they treat every change that goes through EN 62304 as a significant change under MDR, which floods the Notified Body and grinds maintenance releases to a halt. The correct model is two layers: EN 62304 underneath, always running; MDR significant change evaluation on top, selectively triggering Notified Body consultation.

## When to notify the Notified Body, and when not

The practical decision rule is straightforward once the two layers are separated.

Notify the Notified Body when the change meets the significant change criteria in MDCG 2019-11 Rev.1 and Annex IX Sections 2.4 or 4.10 — typically, a change to intended purpose, a change in classification rule applicability, a change to the clinical decision algorithm that alters the claim, a change to the user-facing interpretation of outputs that affects safety, or a change that invalidates key elements of the clinical evaluation. Notification happens before the change is released.

Do not notify for changes that are non-significant under the guidance — defect corrections that restore intended behaviour, cybersecurity patches that maintain the intended secure state, performance optimisations that do not change the clinical claim, infrastructure and deployment changes that leave the device as assessed unchanged, or documentation-only changes. In these cases, the change is handled entirely inside your QMS, documented under EN 62304, and evaluated on the significant change checklist with a written record of why it was judged non-significant.

The record is the key artefact. An auditor will not argue with a defensible non-significant decision that has a clean evaluation behind it. An auditor will absolutely open a finding if the decision was made informally, without reference to the MDCG criteria, or without a written rationale.

## Common mistakes teams make

The first mistake is treating software updates the way hardware teams treat engineering changes — with a single ECO form and a binary "needs NB or not" checkbox. Software changes often cluster in a release, and each change in the release needs its own significant change evaluation before the release ships. The decision is per-change, not per-release.

The second mistake is using the size of the diff as a proxy for significance. There is no correlation. Small diffs can be highly significant if they touch the algorithm. Large diffs can be non-significant if they refactor without changing behaviour.

The third mistake is skipping the MDCG 2019-11 Rev.1 criteria and substituting internal judgment. Internal judgment is fine as an input; it is not acceptable as the sole basis for a decision the Notified Body may review.

The fourth mistake is forgetting to update the technical documentation after a non-significant change. Non-significant for Notified Body purposes does not mean invisible — the technical file, the risk management file, and the post-market surveillance plan must all reflect the current version of the device, and EN 62304:2006+A1:2015 requires traceability to be maintained continuously.

The fifth mistake is the opposite: over-reporting to the Notified Body on everything, which drains your consultancy budget, slows down your releases, and damages the relationship with the Notified Body because they start treating your submissions as noise.

## The Subtract to Ship angle

Subtract to Ship applied to software change control is about the difference between a process that runs and a process that exists on paper. The instinct in regulated environments is to add layers: change control boards that meet weekly, multi-stage sign-off workflows, long template forms, duplicate evaluations. Each layer looks like rigour and each layer slows the actual work without improving the compliance position.

The lean version traces directly to the obligations. EN 62304:2006+A1:2015 requires a change control process with impact analysis, verification, and traceability. MDR Annex IX Sections 2.4 and 4.10 together with MDCG 2019-11 Rev.1 require a significant change evaluation before release. Annex I Section 17 requires that the software remain fit for the intended purpose throughout the lifecycle, including being kept secure. These are the things that have to happen. Everything else — the boards, the templates, the ceremonial reviews — is optional and should exist only if it makes the required steps happen more reliably.

Every activity you put into your change control process should trace back to one of those provisions. If it does not, cut it. The change control process that survives this test is small enough to run on every release and rigorous enough to defend in an audit.

## Reality Check — Where do you stand?

1. Do you have a written significant change evaluation procedure that explicitly references MDCG 2019-11 Rev.1 and Annex IX Sections 2.4 and 4.10?
2. For your last five software releases, can you show the significant change evaluation record for each individual change in the release?
3. Does your EN 62304:2006+A1:2015 change control process run independently of the MDR significant change decision, or have the two become conflated?
4. Are non-significant changes being reflected in the technical file, risk management file, and PMS plan, or are they only recorded in the code repository?
5. If a Notified Body auditor asked you today to defend the non-significant classification of your last cybersecurity patch, could you point to the documented rationale?
6. Is your team over-reporting to the Notified Body because "safer to ask" has become the cultural default?
7. If your device is still on the market under the Article 120 legacy route, are you running the separate Article 120 significant change test alongside the Annex IX test for every update?

## Frequently Asked Questions

**Does every software update under MDR require a new conformity assessment?**
No. A new conformity assessment is only required for changes that meet the significant change criteria in MDCG 2019-11 Rev.1 and in Annex IX Sections 2.4 and 4.10. Routine defect fixes, security patches, and non-significant enhancements are handled entirely inside the manufacturer's QMS and EN 62304:2006+A1:2015 change control process, with a documented rationale showing why the change is not significant.

**Is a cybersecurity patch a significant change?**
Normally no. MDR Annex I Section 17 requires the device to remain secure throughout its lifecycle, and a patch that restores or maintains the intended secure state is consistent with that obligation rather than a deviation from it. The evaluation should still be documented against the MDCG 2019-11 Rev.1 criteria, because edge cases exist — for example, a patch that changes how the device authenticates users or that materially alters interoperability claims may cross the significance threshold.

**What happens if we release a significant change without notifying the Notified Body?**
The updated device is technically no longer covered by the existing conformity assessment, which creates a market access and vigilance exposure. The corrective path is to stop the release, run the significant change evaluation properly, and engage the Notified Body. The reputational cost of being caught in an audit doing this informally is much higher than the cost of the evaluation itself.

**How does the Article 120 significant change test relate to the Annex IX test?**
They answer different questions. Article 120 asks whether a legacy device is still the same device it was when the earlier certificate was issued, and is relevant for manufacturers leveraging the extended MDR transition. Annex IX Sections 2.4 and 4.10 ask whether a change to an MDR-certified device still fits inside the existing assessment. A manufacturer with a legacy device in transition may need to run both tests for the same update.

**Does EN 62304:2006+A1:2015 require a change control process for every change?**
Yes. EN 62304:2006+A1:2015 requires every software change to go through a controlled process with impact analysis, verification, and traceability, independent of whether the change is significant in the MDR sense. The standard does not carve out "minor" changes as exempt. The significant change decision is a separate layer that runs on top of the EN 62304 process using its outputs as inputs.

## Related reading

- [MDR Design Changes and Iterations: What Requires Re-Assessment](/blog/mdr-design-changes-iterations) — the hardware-side companion to this post, with the same significant change logic applied outside software.
- [MDR Software Maintenance Under IEC 62304](/blog/mdr-software-maintenance-iec-62304) — the maintenance process that sits beneath software change control.
- [Software as a Medical Device: The MDCG 2019-11 Classification Framework](/blog/samd-mdcg-2019-11-classification) — how classification itself can be affected by software changes.
- [Cybersecurity Updates and MDR Annex I Section 17](/blog/cybersecurity-updates-mdr-annex-i-17) — the specific case of security patches and why they normally are not significant.
- [Notified Body Consultations for Software Changes](/blog/notified-body-consultations-software-changes) — how to structure the conversation with your Notified Body when a change is borderline.
- [Post-Market Surveillance for Software Medical Devices](/blog/pms-software-medical-devices) — how update decisions feed back into the PMS system.
- [Risk Management Updates After a Software Change](/blog/risk-management-software-change) — the ISO 14971 side of every change control action.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind the lean change control approach described above.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 120 (transitional provisions, including significant changes to legacy devices), Annex I Section 17 (electronic programmable systems and software, including security lifecycle), Annex IX Section 2.4 and Section 4.10 (changes to the approved quality management system and approved design, and the obligation to inform the Notified Body). Official Journal L 117, 5.5.2017.
2. MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR, October 2019, Revision 1 June 2025.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), including the software change control process.

---

*This post is part of the Software as a Medical Device series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The significant change decision is one of the most consequential and most commonly mishandled calls a software manufacturer makes under MDR — get the framework right once, and every release after that runs on the same defensible process.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*