The Instructions for Use (IFU) under MDR is a regulated deliverable governed by Annex I Chapter III Section 23.4 of Regulation (EU) 2017/745. A compliant IFU lists every item Section 23.4 requires, is written in language the intended user can understand, matches the intended purpose declared in the technical documentation, is validated through usability engineering under EN 62366-1:2015+A1:2020, and is supplied in every Member State language required where the device is placed on the market. An IFU that auditors accept and users actually understand is written by the regulatory lead and the clinical lead together, not by the marketing team at the end of the project.

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

TL;DR

  • The legal anchor for the IFU is Annex I Chapter III Section 23.4 of Regulation (EU) 2017/745. Every item that Section 23.4 requires must appear in the IFU, or the IFU is non-compliant on its face.
  • Article 10(11) makes manufacturers responsible for ensuring the device is accompanied by the information required by Annex I Chapter III Section 23, in the official Union language(s) determined by the Member State where the device is made available.
  • The IFU must be validated through usability engineering under EN 62366-1:2015+A1:2020. An IFU that the intended user cannot follow is a use-related risk, not a document problem.
  • Electronic IFU is allowed only under the narrow conditions set out in Commission Implementing Regulation (EU) 2021/2226, as amended by Commission Implementing Regulation (EU) 2025/1234. eIFU is not a default option.
  • The IFU is a subset of the technical documentation. Every claim in the IFU has to be consistent with the intended purpose, the clinical evaluation, and the labels. Contradictions between the IFU and any other part of the file are nonconformities.

Why the IFU is harder than founders expect

The IFU looks like a writing task. That is the first trap. Founders assign it to whoever has time. Often a junior engineer or an outside technical writer who has never read Annex I. The document comes back in the structure that person found most natural, in the language they thought would be clearest, with the warnings they thought were important. Then the Notified Body opens Section 23.4 of Annex I and starts checking items. Half the mandatory elements are missing or are scattered across sections that do not match the order Section 23.4 lays out. The warnings are generic. The contraindications are vague. The residual risks from the ISO 14971 file are not in the document at all. The clinical user the IFU is supposedly written for would not be able to use the device from it.

The IFU is not a writing task. It is the surface where the technical file, the risk management file, the clinical evaluation, and the usability engineering file all meet the user. Every one of those files has to drive what the IFU says. If the IFU is written in isolation from them, the gaps are guaranteed and the audit will find them.

What Annex I Chapter III Section 23.4 actually requires

Section 23.4 of Annex I is a list. The list is long. Every item on it is mandatory unless the manufacturer can justify. In the technical documentation. Why a specific item is not relevant for the device in question. The required contents of the IFU include, among other items: the device name, the manufacturer's details, the intended purpose with clear specification of users and intended patients, indications and contraindications, the target patient groups, a specification of what the user and/or patient should know about any warnings, precautions, side-effects, and contraindications, information allowing the user to verify whether the device is appropriate and to select the corresponding software and accessories, any residual risks and undesirable side-effects, instructions in case of damage to the sterile packaging, details of any preparatory treatment or handling before the device is ready for use, installation and calibration information where applicable, the level of training or qualifications required of users, information needed to verify correct installation and safe use, information on the nature and frequency of preventive and regular maintenance, information for the safe disposal of the device, the date of issue or the latest revision of the IFU, a notice for the user and/or patient that any serious incident that has occurred in relation to the device should be reported to the manufacturer and the competent authority, and. For devices incorporating electronic programmable systems. Minimum requirements concerning hardware, IT network characteristics and IT security measures. (Regulation (EU) 2017/745, Annex I, Chapter III, Section 23.4.)

The list above is not exhaustive and it is not the order Section 23.4 uses verbatim. Read the full text of Section 23.4 directly and use it as the table of contents for your IFU. Do not invent your own structure. The auditor will check items against Section 23.4 in the order Section 23.4 is written.

Plain-language discipline

Section 23.1 of Annex I sets the general principle for all information supplied with the device: it must be provided in a form that is easily understood by the intended user, taking account of their training and knowledge. (Regulation (EU) 2017/745, Annex I, Chapter III, Section 23.1.) For a device used by clinicians, the level of technical vocabulary can follow the clinical register. For a device used by patients or lay users, that default fails. And Section 23.1 explicitly references taking training and knowledge into account, which for a lay user means plain language at a reading level a non-specialist can actually follow.

Plain language is not dumbed-down language. It is precise language built with words the user already knows. Short sentences. Active voice. One instruction per step. No abbreviations that are not spelled out on first use. No internal codenames. No marketing adjectives. No sentences that say two things at once. Every warning phrased so the user understands both the hazard and the action to take.

The test for plain-language discipline is not "does this read well to us." It is "can a representative member of the intended user group, with the training and knowledge we assumed in our use specification, follow this without external help." That is a usability engineering question, and it is why Section 23.4 and EN 62366-1 are not two separate topics.

Warnings, precautions, contraindications

Warnings and contraindications are the pieces of the IFU that most directly connect to the risk management file. Every residual risk identified in the ISO 14971 risk file that is controlled by "information for safety" is a warning that must appear in the IFU. The one-way traceability runs from the risk file into the IFU. If a residual risk has an information-for-safety control listed in the risk file, the IFU has to contain the corresponding warning, or the risk control is not implemented.

Contraindications flow from the clinical evaluation. Every patient group, condition, or circumstance under which the device must not be used is a contraindication. Vague contraindications. "not for use in patients with underlying conditions". Do not pass audit. Specific ones do. "not for use in patients with active implantable cardiac devices." The specificity comes from the clinical evaluation, not from imagination.

Precautions sit between warnings and general information. The principle is the same: each one traces to something in the technical file. A precaution that does not map to the risk file, the clinical evaluation, or the design evidence is either missing a source or does not belong in the IFU.

IFU usability validation under EN 62366-1

The harmonised standard for usability engineering for medical devices is EN 62366-1:2015+A1:2020. It is the standard that maps to the usability-related general safety and performance requirements in Annex I (notably Sections 5 and 22 of Annex I). The process the standard requires has several stages, but the step that matters most for the IFU is summative evaluation. The validation step that tests whether representative users, performing the intended tasks in the intended use environment with the IFU in front of them, can accomplish those tasks safely.

The summative evaluation is where a bad IFU fails honestly. Users sit down with the document and the device and attempt to use them together. Use errors are recorded. Use errors that connect to hazards become findings. A warning buried in a block of text that users miss is a use error. A contraindication written in vocabulary the user does not understand is a use error. A step that omits a precondition the user has to know is a use error. The summative evaluation reveals, in a way that a document review cannot, whether the IFU actually supports safe use.

Startups skip or shortcut the summative evaluation more often than any other usability step. The cost of that shortcut is that the first audit surfaces use errors the team did not know existed, and the IFU has to be rewritten after the fact. Running summative evaluation while the IFU is still in draft is cheaper, faster, and produces an IFU that survives audit. EN 62366-1:2015+A1:2020 is the standard that formalises this.

Multi-language requirements

Article 10(11) of Regulation (EU) 2017/745 requires the manufacturer to ensure that the device is accompanied by the information required under Section 23 of Annex I in an official Union language or languages determined by the Member State in which the device is made available to the user or patient. (Regulation (EU) 2017/745, Article 10(11).) Each Member State publishes its own language requirement. Some accept English for professional users; most do not accept English for lay users; several require the national language regardless of user group.

There are two planning implications. First, translation is a regulated activity. The translated IFU has to match the master IFU in content and claims, and the translation process has to be under document control per EN ISO 13485. A translation introduced without document control is a document control finding. Second, every language you add multiplies the cost of every future change. Every time the IFU is revised, every language version has to be revised, validated, and re-shipped. The subtract-to-ship discipline on the IFU has a direct economic dimension: a shorter IFU is cheaper to translate, faster to update, and less likely to contain contradictions between language versions.

The eIFU option. Narrow and conditional

Electronic instructions for use (eIFU) are allowed only for specific device categories and under specific conditions. The governing text is Commission Implementing Regulation (EU) 2021/2226, as amended by Commission Implementing Regulation (EU) 2025/1234. These implementing regulations define which devices may use eIFU, what the manufacturer must do to make the eIFU available, how users must be informed that the IFU is electronic, what version management and backup obligations apply, and what the risk assessment for choosing eIFU must cover.

eIFU is not the default. It is a specific option for specific device categories (primarily devices for professional users and fixed installed devices, subject to the conditions in the implementing regulation). A startup that assumes "we will just put the IFU on the website" has not read the implementing regulation. A startup that chooses eIFU deliberately, runs the required risk assessment, and meets every condition in Commission Implementing Regulation (EU) 2021/2226 as amended by (EU) 2025/1234, has a perfectly valid option. For the device categories where it applies.

Common IFU failure modes

The pattern repeats across the audits we have seen. The same handful of failure modes produces most IFU findings.

  • Section 23.4 items missing. A mandatory element of the list is absent. Almost always the date of issue, the serious-incident reporting notice, or the cybersecurity information for devices with electronic programmable systems.
  • Structure invented rather than adopted. The IFU is organised by whatever structure the writer felt made sense, not by Section 23.4. Auditors lose patience fast.
  • Warnings disconnected from the risk file. The risk file has information-for-safety controls that do not appear as warnings in the IFU, or the IFU has warnings that correspond to no risk in the file.
  • Vocabulary above the intended user. Clinical-register vocabulary in a lay-user IFU, or terms that assume training the use specification does not assume.
  • Contradictions with the technical documentation. The IFU describes the intended purpose slightly differently from the technical documentation, or lists indications that the clinical evaluation does not substantiate.
  • Translation drift. The English master says one thing; a translated language version says subtly different. Version control has broken somewhere.
  • No usability validation of the IFU itself. The device was usability-tested, but the IFU in its shipped form was never put in front of a user during summative evaluation.
  • eIFU used without meeting the implementing regulation conditions. A web-hosted PDF described as an eIFU without the required risk assessment, availability obligations, or version management.

Every one of these is preventable. Each one has a direct mapping to a clause in Section 23.4, Section 23.1, EN 62366-1:2015+A1:2020, or Commission Implementing Regulation (EU) 2021/2226 (as amended).

The IFU is a subset of the technical documentation, not a separate claim surface

Every claim in the IFU has to match the intended purpose declared in the technical documentation, the conclusions of the clinical evaluation, the residual risk profile from the ISO 14971 file, and the labels on the device and its packaging. The IFU is not a place to say something more than the technical file supports. An IFU that claims a benefit the clinical evaluation does not substantiate is a misleading-claim finding under Article 7 as well as a Section 23.4 finding. An IFU that says the device is suitable for a patient group the intended purpose does not include is a scope drift. The one-file rule is: the IFU is a view into the technical documentation, never a separate source of claims.

This connects the IFU directly to the technical documentation under MDR pillar and to misleading claims under MDR. The CE marking obligation under Article 20 also touches the IFU: the CE mark and, where applicable, the Notified Body number appear on the label and, per the same article, on the IFU and on any sales packaging in a visible, legible and indelible form. (Regulation (EU) 2017/745, Article 20.)

The Subtract to Ship approach to the IFU

The IFU invites bloat. Every team member wants to add their warning, their caveat, their just-in-case instruction. The accumulated effect is a document too long for the user to read, too expensive to translate, and full of redundant or contradictory statements that create audit risk by their mere existence.

Subtract to Ship for the IFU is the opposite discipline. Every sentence in the IFU has to trace to one of four sources: a specific Section 23.4 item, a specific risk control from the ISO 14971 risk file, a specific conclusion from the clinical evaluation, or a specific requirement from a harmonised standard. If a sentence traces to none of these, it comes out.

Apply the Subtract to Ship framework page by page. A disciplined subtraction pass on a typical startup IFU removes 20 to 30 percent of the text without losing a single required element. What remains is shorter, clearer, cheaper to translate, and easier for the intended user to follow. A shorter IFU also validates more cleanly under EN 62366-1:2015+A1:2020 summative evaluation, because there is less text for the user to get lost in.

Reality Check. Where do you stand?

  1. Does your IFU table of contents mirror Annex I Chapter III Section 23.4 item by item, or does it follow a structure your team invented?
  2. For every information-for-safety risk control in your ISO 14971 risk file, is there a corresponding warning in the IFU with matching language?
  3. Can a representative member of your intended user group. With the training and knowledge defined in your use specification. Read your IFU and complete the intended tasks without external help?
  4. Have you run a summative evaluation under EN 62366-1:2015+A1:2020 on the shipped IFU, not just on the device?
  5. Does the IFU contain the serious-incident reporting notice, the date of issue or latest revision, and (for devices with electronic programmable systems) the IT security information?
  6. Does every language version of the IFU match the master in content, and is every translation under document control?
  7. If you are using eIFU, have you verified against Commission Implementing Regulation (EU) 2021/2226 (as amended by (EU) 2025/1234) that your device category qualifies and that every condition is met?
  8. Is every claim in the IFU traceable to the intended purpose, the clinical evaluation, the risk file, or a harmonised standard requirement. And is anything that is not traceable cut?

Frequently Asked Questions

Does every medical device need an IFU under MDR? Annex I Chapter III Section 23.1 requires information supplied with the device in a form that is easily understood by the intended user. For most devices that means an IFU. Section 23.1 allows an IFU to be omitted or abbreviated only where the device can be used safely and as intended without any such instructions. A narrow exception that applies to very simple devices. For any device with non-trivial use, an IFU is mandatory. (Regulation (EU) 2017/745, Annex I, Chapter III, Section 23.1.)

What language does the IFU have to be in? Article 10(11) requires the manufacturer to supply the information in an official Union language or languages determined by the Member State where the device is made available. Each Member State sets its own rule. In practice, for devices intended for lay users or patients, most Member States require the national language; for professional users, some Member States accept English but many do not. Check the requirement for every Member State you place the device on the market in.

Can we just put the IFU on our website as an eIFU? Only if the device falls within the categories eligible for eIFU and every condition in Commission Implementing Regulation (EU) 2021/2226 (as amended by Commission Implementing Regulation (EU) 2025/1234) is met. Including the risk assessment, information of users that the IFU is electronic, availability obligations, version management, and the requirement that users can obtain a paper version on request within a specified time. eIFU is a deliberate regulatory choice, not a shortcut for skipping printed IFUs.

Where do warnings and contraindications come from? Warnings come from the ISO 14971 risk file. Specifically from residual risks where the risk control strategy includes information for safety. Contraindications come from the clinical evaluation. The patient groups, conditions, or circumstances where the device must not be used based on the clinical data. If a warning or contraindication does not trace back to one of these two sources, it does not belong in the IFU and it has no defensible basis.

Does the IFU need to be validated in usability testing? Yes, in practical terms. EN 62366-1:2015+A1:2020 requires summative evaluation of the user interface, and the IFU is part of the user interface when the device is intended to be used with an IFU. Validating the device without validating the IFU is a gap that audits will expose. The summative evaluation has to put the IFU in the hands of representative users in the intended use environment and observe whether they can use the device safely with it.

How does the IFU relate to the label and to the technical file? Annex I Chapter III Section 23.2 governs the label, Section 23.3 governs packaging that maintains sterility, Section 23.4 governs the IFU, and Section 23.1 sets the general principles across all of them. The label, packaging information, and IFU together make up "information supplied with the device". One regulated whole. That whole sits inside the technical documentation under Annex II, Section 2 (information to be supplied by the manufacturer). The IFU is not a standalone asset; it is a controlled section of the technical file.

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 20 (CE marking of conformity), Annex I, Chapter III, Section 23.1 (general principles for information supplied with the device), Section 23.4 (information in the instructions for use). Official Journal L 117, 5.5.2017.
  2. EN 62366-1:2015+A1:2020. Medical devices. Part 1: Application of usability engineering to medical devices (IEC 62366-1:2015 + IEC 62366-1:2015/A1:2020).
  3. 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.

This post is part of the Technical Documentation & Labeling cluster in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Tibor has reviewed IFUs on both sides of the Notified Body table. As the lead auditor checking them against Section 23.4 and as a founder writing them for his own devices. A short, disciplined IFU almost always outperforms a long one at audit, in translation, and in the hands of the user who actually has to follow it.