---
title: Labeling for Software as a Medical Device: Digital Label Requirements
description: MDR labeling requirements apply to SaMD as much as to physical devices. Here is how to deliver MDR-compliant labels and IFU through a digital interface.
authors: Tibor Zechmeister, Felix Lenhard
category: Technical Documentation & Labeling
primary_keyword: labeling software medical device
canonical_url: https://zechmeister-solutions.com/en/blog/labeling-software-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Labeling for Software as a Medical Device: Digital Label Requirements

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

> **Software as a Medical Device is labeled through its digital interface. Annex I Chapter III Section 23 of Regulation (EU) 2017/745 applies to SaMD just as it applies to physical devices — every mandatory label element and every IFU item must be delivered to the user somewhere in the software itself, typically through a splash screen, an about screen, and in-app help. Article 10(11) language obligations apply to the software's user interface. Article 27 UDI obligations apply to software as a distinct UDI carrier rule. Commission Implementing Regulation (EU) 2021/2226 governs electronic instructions for use where the manufacturer relies on eIFU. A SaMD that has no about screen, no version display, and no in-app UDI is non-compliant on its face, regardless of how elegant the rest of the product is.**

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

---

## TL;DR

- Annex I Chapter III Section 23 of Regulation (EU) 2017/745 applies to SaMD. There is no carve-out for software. Every mandatory label element must appear somewhere the user can see it inside the software.
- The label for a SaMD typically lives on a splash screen at launch and on an about screen reachable from the main menu at any time. The IFU typically lives in an in-app help system, a built-in PDF, or an eIFU web page under Commission Implementing Regulation (EU) 2021/2226.
- Article 10(11) language obligations apply to the user interface, not only to the printed IFU. The language the software runs in is a labeling question.
- Article 27 requires a UDI for every device. For software, the UDI assignment rules treat software as a specific case — version changes that affect safety or performance generate a new UDI-DI, and the UDI must be accessible within the software itself.
- A SaMD without an about screen, a version display, a UDI carrier inside the software, and a reachable IFU is not MDR-compliant, no matter how good the underlying clinical performance is.

---

## Why SaMD labeling is the quiet failure mode

Hardware devices teach founders that labeling means a printed label and a printed IFU in a box. SaMD teams inherit that mental model and then find that their product has no box. The conclusion many teams jump to is wrong: that Annex I Chapter III Section 23 somehow does not apply, or that "we will handle labeling at the end, it is just some text." The conclusion Notified Bodies reach at audit is the one that counts: Section 23 applies to SaMD, every mandatory element must be delivered through the digital interface, and a SaMD that cannot show its manufacturer, its UDI, its version, and its intended purpose on a reachable screen is failing a basic conformity check.

The failure is quiet because it does not break anything functionally. The product works. Clinicians use it. Engineering ships features. The about screen is nobody's priority because it has no users and produces no feature metrics. Then the technical documentation review happens, the auditor opens the software, and the first thing they look for is the version number and the UDI. The rest of the review does not go well if those are missing.

This post is how to get SaMD labeling right from the start — not as an afterthought, but as a first-class part of the software architecture. The rules come from the same place as for hardware: Annex I Chapter III Section 23 is the North Star. The implementation is different because the delivery channel is different.

## Annex I Chapter III Section 23 applied to software

Section 23 of Annex I does not split its scope between hardware and software. The general principle in Section 23.1 is that the information supplied with the device must be provided on the device itself, on the packaging, or in the IFU, taking account of training and knowledge of the intended user. Section 23.2 sets out the mandatory contents of the label on the device and its packaging. Section 23.4 sets out the mandatory contents of the IFU. (Regulation (EU) 2017/745, Annex I, Chapter III, Section 23.)

For a SaMD, "on the device itself" means inside the software. There is no packaging in the physical sense. There is no separate printed label. The user's entire surface of contact is the user interface. So every Section 23.2 label element that applies to the device must be surfaceable through the user interface, and every Section 23.4 IFU element that applies must be reachable from within the software or through an eIFU that meets Commission Implementing Regulation (EU) 2021/2226.

The specific Section 23.2 elements that always apply to SaMD include: the name or trade name of the device; the manufacturer name and registered place of business; the details strictly necessary to identify the device, the contents of the packaging, and, where it is not obvious for the intended user, the intended purpose; the UDI carrier; an indication if the device is intended for single use (not usually applicable to software but worth checking); the version and, where relevant, the release date; any warnings or precautions that need to be brought to the immediate attention of the user. Section 23.2 also requires the CE marking where applicable. For SaMD the CE mark is displayed inside the software, typically on the about screen, not on a physical sticker.

## Where the label lives in a SaMD

A SaMD label is not one file. It is a set of screens and surfaces inside the software that, taken together, display every mandatory Section 23.2 element to the user in a form the user can actually find. The standard pattern we see on well-built SaMD is this.

**The splash screen at launch.** A short screen the user sees every time the software starts. It carries the device name, the manufacturer name, the CE mark, and the software version. It is not a marketing screen. It is a regulatory surface. The user sees it briefly, and that is enough to satisfy "immediately visible" for the elements on it.

**The about screen.** A dedicated screen reachable from the main menu or help menu at any time. The about screen carries the full label set: device name, manufacturer name and registered address, UDI-DI and UDI-PI, software version, release date, intended purpose summary, CE mark, Notified Body number (where applicable), contact details, reference to the IFU, and the serious-incident reporting notice that Section 23.4 requires. The about screen is the canonical home of the SaMD label. If an auditor asks where the label is, the about screen is the answer.

**The main menu or help menu.** A persistent navigation element that links to the about screen and to the IFU from anywhere in the software. The label elements must be reachable in a small number of clicks — hiding the about screen five menus deep is a finding.

**In-app contextual help and warnings.** Warnings and precautions that Section 23.4 requires often need to appear at the point of use, not only in the IFU. A SaMD that only shows its contraindications in a PDF nobody opens is not meeting Section 23.4 in spirit or in practice.

## The splash screen and about screen approach

The pattern is deliberate. Splash screens carry the minimum elements that must be visible every time the user launches the software — device name, manufacturer, version, CE mark. The about screen carries the full Section 23.2 content, laid out in the order the regulation specifies it, with the UDI carrier and the reference to the IFU.

Three design choices keep this from becoming a burden on the product team.

First, the about screen is a single template rendered from the regulatory file, not a hand-coded set of strings. The device name, manufacturer details, intended purpose summary, UDI, CE mark, Notified Body number, and IFU link are fields in a configuration file that the QMS owns. Engineering renders the about screen from those fields. When the label changes, the configuration changes, not the code.

Second, the splash screen is short. Two or three seconds is enough. Users will complain if it is ten. The regulation does not require an uncomfortable delay — it requires the information to be visible.

Third, the about screen is linked from a persistent "Help" or "About" item in the main menu. Users rarely look for it, which is fine. Auditors look for it every time, which is why it must be findable in seconds.

## In-app warnings and IFU access

The IFU is a separate deliverable from the label, and Section 23.4 governs it. For a SaMD the IFU has three common delivery forms.

**In-app help.** A built-in help system accessed from the main menu, containing every Section 23.4 element. The advantage is that the IFU ships with the software and is always available, which satisfies the "supplied with the device" principle cleanly. The disadvantage is that every IFU update requires a software release — which for regulated software is not a small thing.

**Built-in PDF.** The IFU is a PDF file bundled with the software, viewable through an in-app viewer or openable in the host system's PDF reader. Same trade-off as in-app help, with slightly less integration.

**eIFU under Commission Implementing Regulation (EU) 2021/2226.** The IFU lives on a web page maintained by the manufacturer. The software links to it from the about screen. The advantage is that the IFU can be updated without shipping a new software version. The disadvantage is that eIFU is only available for specific device categories under Commission Implementing Regulation (EU) 2021/2226 (as amended by (EU) 2025/1234), and every condition in that regulation must be met — including the risk assessment, the availability obligations, the version management, and the paper-on-request guarantee. The full rules are covered in [post 233 on eIFU](/blog/mdr-eifu-electronic-instructions).

Whichever form the IFU takes, in-app warnings still matter. A warning in the IFU is not enough if the user never opens the IFU. Warnings tied to specific user actions — "this classifier has not been validated on paediatric data, do not apply to patients under 18" — belong in-app, at the point where the user performs the action, as well as in the IFU. This is both a Section 23 question and a usability engineering question under EN 62366-1:2015+A1:2020.

## Multi-language for digital interfaces

Article 10(11) of Regulation (EU) 2017/745 requires the manufacturer to ensure that the information supplied with the device is in an official Union language determined by the Member State where the device is made available. (Regulation (EU) 2017/745, Article 10(11).) For a SaMD this applies to the user interface, not only to a printed IFU — because the user interface is where the information is supplied.

The practical consequences are three. First, the software has to support every Member State language that its market access requires, at the user interface level. A SaMD that ships only in English cannot be placed on a market that requires the national language for the user group in question. Second, the about screen, the in-app help, and the in-app warnings all fall under the language obligation — every regulatory surface, not only the IFU. Third, every translation is under document control per EN ISO 13485 and has to match the master in content and claims. Machine translation of a medical warning is a document control finding waiting to happen.

For startups, the translation cost compounds with language count. Subtract to Ship logic applies here directly — a shorter, cleaner label and IFU translates more cheaply, updates more cleanly, and contains fewer opportunities for drift between language versions. The language question is one more reason to keep the regulatory surface small.

## UDI display in software

Article 27 of Regulation (EU) 2017/745 sets the UDI system. For software the UDI rules have specific features. The UDI-DI (device identifier) changes when the software change is significant enough to affect safety or performance — which for SaMD is more frequent than for hardware. MDCG 2019-11 Rev.1 covers the software change rules that drive UDI-DI updates.

The UDI carrier for software is inside the software. Typically the UDI-DI and UDI-PI are displayed on the about screen, in a format the user can read and, where applicable, the system can read machine-side. The UDI must be accessible when the software is running — it cannot live only in an external file the user never sees. For server-side SaMD the UDI is displayed in the user-facing interface that the clinician interacts with, not only in a backend log.

The version display on the splash and about screens is closely related but not the same as the UDI-PI. The UDI-PI (production identifier) encodes the software version at the regulatory level. The displayed version string is what the user reads. They should match — and the discipline of making them match is managed through the QMS and the release process, not through ad-hoc string updates in code.

## Common SaMD labeling mistakes

The pattern of findings in this area is consistent across audits. The same handful of mistakes account for most of the non-conformities we see.

- **No about screen at all.** The software ships with no dedicated regulatory surface. The auditor asks where the label is and the team cannot point to one.
- **About screen buried.** The about screen exists but is reachable only through six menu levels. The Section 23 principle that information must be supplied with the device is not met in practice if the user cannot find it.
- **Version display missing or wrong.** The software has no visible version, or the displayed version does not match the version in the technical documentation and UDI-PI. This is also a configuration management finding under EN 62304:2006+A1:2015.
- **UDI not displayed inside the software.** The UDI lives only in the technical file. The Article 27 requirement that the UDI carrier be on the device — which for SaMD means inside the software — is not met.
- **IFU hosted as a web PDF without meeting eIFU rules.** The IFU is linked to a web page, but the manufacturer has not run the risk assessment, the availability obligations, or the other conditions required by Commission Implementing Regulation (EU) 2021/2226. This is a false eIFU implementation.
- **Warnings only in the IFU.** Safety-critical warnings live in a document the user does not open. Section 23.4 and EN 62366-1:2015+A1:2020 together require the warnings to reach the user at the point of use.
- **Language mismatch.** The user interface runs in English in a market that requires the national language for the user group. Article 10(11) is not met.
- **CE mark placement.** The CE mark is missing from the about screen, or is displayed on marketing pages without the required form. The CE mark has to be visible, legible, and indelible in the regulatory surface of the software, per Article 20 and the Section 23.2 label elements.

## The Subtract to Ship angle for SaMD labeling

The temptation in SaMD labeling is to defer. The about screen is not a feature users request. The IFU is not a growth driver. The UDI display is not on any roadmap. Every one of these surfaces is dismissible until the Notified Body opens the software, and then all of them are mandatory at once.

Subtract to Ship for SaMD labeling inverts the default. Build the regulatory surface once, build it right, and keep it small. A single about screen rendered from a configuration file that the QMS owns. A single in-app help system tied to the IFU master. A single language selection mechanism that drives both the UI and the IFU. A single release process that updates the version display, the UDI-PI, and the technical documentation in lockstep. What you subtract is the scatter: ad-hoc strings in code, manually maintained version numbers, translations done outside document control, warnings written by whoever had time.

Every piece of the regulatory surface should trace to a specific Section 23 element, an Article 10(11) language obligation, an Article 27 UDI rule, or a Commission Implementing Regulation (EU) 2021/2226 eIFU condition. Pieces that do not trace come out. See [the Subtract to Ship framework for MDR](/blog/subtract-to-ship-framework-mdr) for the four passes applied at the project level — the labeling surface is an Operations Pass concern.

## Reality Check — Where do you stand?

1. Can a user of your SaMD reach a screen showing the device name, manufacturer name, CE mark, version, and UDI from any state of the software in three clicks or fewer?
2. Does the splash screen display the device name, manufacturer, version, and CE mark every time the software starts?
3. Is every Section 23.2 label element that applies to your device rendered on the about screen in the order Section 23 specifies?
4. Is your IFU reachable from inside the software — as in-app help, built-in PDF, or eIFU — and does the delivery form match Commission Implementing Regulation (EU) 2021/2226 if you rely on eIFU?
5. Do your safety-critical warnings appear at the point of user action inside the software, not only in the IFU?
6. Does the user interface run in every official Union language required by the Member States you place the device on the market in?
7. Is the UDI-DI and UDI-PI displayed inside the software in a form a user can read, and does the displayed version match the technical documentation?
8. Is the regulatory surface (about screen, splash, help, language selection) rendered from a configuration file under document control, or is it hand-coded strings scattered across the codebase?

## Frequently Asked Questions

**Does Annex I Chapter III Section 23 really apply to software with no physical form?**
Yes. Section 23 applies to every device placed on the market under Regulation (EU) 2017/745, including SaMD. There is no text in Section 23 that carves out software. The delivery channel is different — the label is rendered in the user interface instead of printed on a box — but every mandatory element must still reach the user.

**Where exactly does the label go in a SaMD?**
The industry pattern is a splash screen at launch carrying a short set of critical elements (device name, manufacturer, version, CE mark) plus a dedicated about screen reachable from the main menu at any time carrying the full Section 23.2 set. The about screen is the canonical home of the SaMD label.

**Do I have to ship my SaMD in every EU language?**
You have to ship in the official Union language or languages required by each Member State where you place the device on the market, per Article 10(11) of Regulation (EU) 2017/745. The requirement is per Member State, not EU-wide, and it depends on the intended user group. For a lay-user SaMD, most Member States require the national language; for a professional-user SaMD, the requirement varies.

**Where does the UDI go in a SaMD?**
The UDI-DI and UDI-PI are displayed inside the software — typically on the about screen — in a form the user can read. Article 27 requires the UDI carrier to be on the device, and for SaMD the device is the software itself. The UDI also lives in the technical documentation and in Eudamed, but the in-software display is the Article 27 carrier for a SaMD.

**Can I use eIFU for my SaMD instead of bundling the IFU with the software?**
Only if your device category falls within Commission Implementing Regulation (EU) 2021/2226 (as amended by Commission Implementing Regulation (EU) 2025/1234) and every condition in that regulation is met. eIFU is available for specific device categories and requires a risk assessment, availability obligations, version management, and the guarantee that users can obtain a paper version on request. A web-hosted PDF without those controls is not a compliant eIFU.

**Does the CE mark have to appear inside the software?**
Yes, where CE marking applies to the device. The CE mark has to be visible, legible, and indelible on the regulatory surface of the software — typically the about screen and, where the device is Class IIa or higher, followed by the Notified Body number. Displaying the CE mark only on the marketing website does not satisfy the Article 20 requirement.

## Related reading

- [Labels Under MDR: Section 23.2 Requirements in Practice](/blog/mdr-label-requirements-section-23-2) — the label side of Section 23 for all devices, including the elements that apply to SaMD.
- [Symbols and ISO 15223-1 on Medical Device Labels](/blog/mdr-symbols-iso-15223-1) — harmonised symbols and how they render in digital surfaces.
- [The Instructions for Use (IFU) Under MDR](/blog/instructions-for-use-mdr-compliant) — the full IFU requirements under Section 23.4, which apply to SaMD through in-app help or eIFU.
- [Common Labelling Mistakes Startups Make Under MDR](/blog/common-labeling-mistakes-startups-mdr) — the label-side failure modes across device types.
- [Translation and Multi-Language IFUs Under MDR](/blog/mdr-multi-language-ifu-translation) — the Article 10(11) mechanics that apply equally to SaMD user interfaces.
- [Electronic Instructions for Use (eIFU) Under MDR](/blog/mdr-eifu-electronic-instructions) — the full rules of Commission Implementing Regulation (EU) 2021/2226 as amended.
- [UDI System Under MDR Article 27](/blog/mdr-udi-article-27) — the UDI rules and how they apply to software versions and changes.
- [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) — the pillar post on SaMD qualification and classification that precedes the labeling question.
- [SaMD Release Management and Change Control](/blog/samd-release-management-change-control) — how version displays and UDI-PI updates connect to the release process.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind keeping the regulatory surface small and maintainable.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10(11) (language of information supplied with the device), Article 27 (UDI system), Annex I, Chapter III, Section 23 (information supplied with the device), Section 23.2 (label), Section 23.4 (instructions for use). Official Journal L 117, 5.5.2017.
2. Commission Implementing Regulation (EU) 2021/2226 of 14 December 2021 laying down rules for the application of Regulation (EU) 2017/745 as regards electronic instructions for use of medical devices, as amended by Commission Implementing Regulation (EU) 2025/1234 of 25 June 2025.
3. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. Revision 1, June 2025.
4. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes.
5. EN 62366-1:2015+A1:2020 — Medical devices — Part 1: Application of usability engineering to medical devices.

---

*This post is part of the Technical Documentation & Labeling cluster in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. A SaMD with a disciplined about screen, a clean in-app IFU, and a regulatory surface rendered from a single configuration file costs almost nothing to maintain and survives audit without drama. Scattering the same content across ad-hoc strings in code costs a lot and fails at the first Notified Body review.*

---

*This post is part of the [Technical Documentation & Labeling](https://zechmeister-solutions.com/en/blog/category/technical-documentation) 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).*