A wearable medical device under the MDR is simultaneously three things: a piece of body-worn electronics that must satisfy EN 60601-1:2006+A1+A12+A2+A13:2024 for basic safety, an embedded software system whose firmware must be developed under EN 62304:2006+A1:2015, and, in most cases, a companion mobile application that is itself software subject to Annex VIII Rule 11 and Annex I Section 17. Each layer carries its own obligations, and a compliant wearable is one where all three layers are documented coherently under a single intended purpose and a single risk-management file.

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

TL;DR

  • Wearable medical devices sit at the intersection of three regulatory layers: hardware electrical safety, embedded firmware lifecycle, and companion app software lifecycle. All three apply at the same time.
  • Electrical safety of the body-worn unit is governed by EN 60601-1:2006+A1+A12+A2+A13:2024, which applies to any medical electrical equipment with a patient-connected applied part.
  • Embedded firmware and the companion mobile app are both covered by MDR Annex I Section 17, and both commonly use EN 62304:2006+A1:2015 as the harmonised state-of-the-art lifecycle standard.
  • Classification under Annex VIII Rule 11 applies to the software side; for the combined wearable the hardware classification rules in Annex VIII apply in parallel, and the device class is the highest of the applicable rules.
  • Skin-contact materials invoke biocompatibility obligations under MDR Annex I Section 10, with EN ISO 10993-1:2025 as the reference standard for the evaluation process.
  • MDCG 2019-11 Rev.1 (June 2025) is the definitive guidance for software qualification and classification and it applies to the software elements of the wearable without modification.

Why wearables are the hardest category to scope cleanly

Wearable MedTech startups arrive with the most tangled regulatory position we see in practice. The reason is simple. A wearable is not a software product, and it is not a hardware product, and it is not a mobile app. It is all three at once, and each of the three has its own body of requirements, its own harmonised standards, and its own Notified Body review expectations. A founder who has read up on EN 62304:2006+A1:2015 because they come from a software background will be surprised by EN 60601-1:2006+A1+A12+A2+A13:2024. A founder who has shipped consumer electronics will be surprised by the software lifecycle demands. A founder who has built apps will be surprised that there is a body-worn electrical device in the regulatory file at all.

The trap is scoping the wearable as if it were only one of the three. We have seen startups build a clean mobile-app QMS and then realise the wristband itself has no electrical-safety documentation. We have seen hardware-first teams draft a beautiful mechanical and electrical file and then discover their companion iPhone app is Class IIa under Rule 11 and needs its own full lifecycle treatment. We have seen teams document the firmware to the level EN 62304:2006+A1:2015 Class B requires and then miss that the companion app is doing the interpretation and carries the higher software safety class.

Shipping a wearable under the MDR means holding all three layers in mind from day one and documenting them coherently. This post walks through what that looks like, what the regulation says about each layer, and where the common mistakes live.

The wearable scope — what the device actually is

Before any regulatory work, write down what the wearable actually is. A wearable under the MDR is typically a body-worn unit that senses one or more physiological signals, processes those signals in firmware, transmits the processed signals to a companion application, and presents the results to the user or a clinician. The intended purpose determines whether it is a medical device at all — a fitness tracker that measures heart rate for general wellness is not a medical device, while a wearable that monitors heart rate for arrhythmia detection is. Post 373 covers the intended-purpose gate in detail.

Assuming the intended purpose is medical, the device scope needs three components explicitly named: the body-worn hardware unit (sensors, electronics, battery, enclosure, skin-contact materials), the embedded firmware that runs on the body-worn unit, and the companion software that runs on a phone, tablet, cloud service, or clinician workstation. All three are part of the "device" as far as the MDR is concerned, and all three are in scope of the technical documentation under MDR Annex II.

Skipping any of the three from the scope is the single most common wearable mistake. If the companion app is not in the technical file, the technical file is incomplete. If the firmware is treated as "just software" outside the EN 62304:2006+A1:2015 process, the firmware is non-compliant. If the hardware unit is treated as an accessory, it is usually misclassified.

Hardware versus software — where to draw the boundary

The boundary between hardware and software on a wearable matters because it drives which standards apply to which component. The practical rule we use with founders is this. The body-worn electronic unit — the sensors, the analog front-end, the microcontroller, the battery, the charging circuit, the enclosure, the skin-contact materials — is medical electrical equipment and falls under EN 60601-1:2006+A1+A12+A2+A13:2024 if it has an applied part in contact with the patient. The firmware running on the microcontroller is medical device software and falls under MDR Annex I Section 17 and EN 62304:2006+A1:2015. The companion app running on a phone or tablet is separately medical device software, also under Annex I Section 17 and EN 62304:2006+A1:2015, and is classified under Annex VIII Rule 11 on its own terms.

EN 60601-1:2006+A1+A12+A2+A13:2024 is not optional for body-worn electronics that are patient-connected. The standard covers protection against electrical hazards, mechanical hazards, excessive temperatures, radiation, and the requirements for medical electrical systems. A wearable that contacts the skin and has a battery and an electronic circuit almost always needs to demonstrate conformity with EN 60601-1:2006+A1+A12+A2+A13:2024, usually in combination with EN 60601-1-2 for electromagnetic compatibility.

The boundary also matters for the risk-management file. EN ISO 14971:2019+A11:2021 runs across the whole device and does not care about hardware-software boundaries, but the hazards are different on each side. Electrical shock, burn, battery failure, mechanical pinch — these are hardware hazards. Incorrect arrhythmia classification, missed alerts, data loss across the wireless link — these are software hazards, some in firmware and some in the companion app. The risk file names the hazard, the source, and the control, and the control often lives in a different component than the hazard. Documenting the chain cleanly is what a Notified Body looks for.

EN 62304:2006+A1:2015 lifecycle for the embedded firmware

The firmware that runs on the wearable's microcontroller is medical device software. It is not "embedded code" exempt from the lifecycle obligations. MDR Annex I Section 17 requires software to be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, information security, and verification and validation. EN 62304:2006+A1:2015 is the harmonised standard that operationalises those requirements for the development of the firmware.

EN 62304:2006+A1:2015 introduces a software safety classification — Class A, Class B, Class C — that is distinct from the MDR device class under Rule 11. The firmware safety class depends on what the firmware could cause if it failed, before external risk controls. For most wearables, the firmware is doing signal acquisition, pre-processing, buffering, and wireless transmission. Whether the firmware is Class A, B, or C depends on how much interpretation it does and whether a firmware failure could directly harm the patient or prevent a clinically necessary action.

The lifecycle activities EN 62304:2006+A1:2015 requires scale with the software safety class. Planning, requirements analysis, architectural design, detailed design, implementation, integration and integration testing, system testing, release, problem resolution, configuration management, and maintenance all apply at every class. The depth and formality scale with the class, and some detailed-design and unit-test activities are only required at Class B and Class C.

A wearable firmware project that started as a consumer-electronics project and is being retrofitted to EN 62304:2006+A1:2015 is usually the hardest case we see. Reconstruction of requirements and design documentation after the fact is always more expensive than running the lifecycle from the first commit. Post 376 covers the software lifecycle expectations in depth; post 377 covers the software safety classification.

EN 62304:2006+A1:2015 for the companion app

The companion mobile application is a separate piece of software running on separate hardware. It is also subject to MDR Annex I Section 17 and also commonly uses EN 62304:2006+A1:2015. The companion app is where most of the clinical interpretation happens on modern wearables — it takes the raw or pre-processed signals from the body-worn unit, runs the algorithms that convert those signals into clinical information, presents the results to the user or clinician, and often transmits data onward to a cloud service.

Under Annex VIII Rule 11, the companion app is classified on its software intended purpose. If the app interprets physiological signals to provide information used for diagnostic or therapeutic decisions, the floor is Class IIa, escalating to IIb where the decisions could cause serious deterioration of health. If the app monitors physiological processes with immediate danger potential, it sits at IIb. MDCG 2019-11 Rev.1 (June 2025) is the definitive guidance and contains worked examples that apply directly to wearable companion apps. Post 081 and post 425 walk through Rule 11 for wearable-specific cases; post 375 covers mobile apps as medical devices in general terms.

The companion app runs on general-purpose consumer hardware — phones and tablets that the manufacturer does not control. MDR Annex I Section 17 requires the manufacturer to set out the minimum requirements concerning hardware, IT networks, and IT security measures, including protection against unauthorised access. Those minimum requirements become part of the labelling and the IFU. Post 511 covers cybersecurity for wearables and post 504 covers the IT network and hardware minimum requirements expectation.

The companion app is usually the highest-classified component of the wearable stack, which means the overall device class is driven by the app. Founders who assumed the hardware drove the class are often surprised by this when the Rule 11 analysis lands.

EN 60601-1:2006+A1+A12+A2+A13:2024 for the wearable electronics

The body-worn electronic unit is medical electrical equipment. EN 60601-1:2006+A1+A12+A2+A13:2024 is the general standard for basic safety and essential performance of medical electrical equipment, and it applies to wearables with a patient-connected applied part. The standard covers protection against electrical shock, energy hazards, mechanical hazards, excessive temperatures, fire, and radiation, as well as requirements for marking, accompanying documents, and testing.

The practical consequence for a wearable is that the body-worn unit has to be type-tested against EN 60601-1:2006+A1+A12+A2+A13:2024 at a competent test house. This is not a document-review exercise. It is a physical test campaign that includes electrical tests, thermal tests, mechanical tests, and EMC tests under EN 60601-1-2. The tests require working samples of the final hardware — not prototypes — which means the schedule has to account for a hardware freeze before the test campaign can start. Startups that underestimate this are almost always the ones whose wearable launch slips by months.

Essential performance is the concept EN 60601-1:2006+A1+A12+A2+A13:2024 uses for the performance of a clinical function whose loss or degradation beyond specified limits would result in an unacceptable risk. For a wearable, essential performance typically includes the accuracy of the physiological measurement, the reliability of alert generation, and the behaviour of the device in the presence of EMC disturbances. The essential performance definition feeds into the risk management file and into the clinical evaluation — another reason the three layers have to be held together coherently. Post 501 covers EN 60601-1:2006+A1+A12+A2+A13:2024 for wearables in depth.

Biocompatibility for skin contact

Any wearable whose materials contact the skin falls under MDR Annex I Section 10 on the chemical, physical, and biological properties of materials, including biocompatibility. The reference standard for the biological evaluation process is EN ISO 10993-1:2025, which is the current edition and supersedes EN ISO 10993-1:2020.

EN ISO 10993-1:2025 does not, by itself, tell you which tests to run. It defines the evaluation process — material characterisation, hazard identification, selection of endpoints based on nature and duration of contact, and risk-based decision-making on whether additional testing is needed. For most wearables, the contact is classified as intact-skin contact of prolonged or long-term duration, which drives a specific set of biological endpoints the evaluation must address.

The biocompatibility file is often the last thing a wearable startup builds, and it is often underestimated. A change in the wristband material late in development can invalidate earlier biocompatibility work. The file needs to be locked in parallel with the hardware freeze, not after it. Post 671 covers biocompatibility for wearables and skin-contact devices in more depth.

Common mistakes wearable startups make

  • Treating the companion app as "just the UI" and skipping the Rule 11 analysis. The companion app is almost always the software that carries the highest device class on a wearable. It needs its own intended purpose, its own Rule 11 analysis, and its own EN 62304:2006+A1:2015 lifecycle.
  • Assuming consumer-electronics certifications (FCC, CE-RED) cover EN 60601-1:2006+A1+A12+A2+A13:2024. They do not. Medical electrical safety testing is a separate campaign and requires working samples of the final design.
  • Running the firmware lifecycle informally because "it is just embedded code." Firmware is medical device software under MDR Annex I Section 17 and needs EN 62304:2006+A1:2015-compatible documentation from the first commit.
  • Locking the hardware design before the biocompatibility strategy is set. A late material change invalidates earlier work and usually triggers re-testing.
  • Writing one intended purpose for the companion app and a different one for the body-worn unit. The wearable has one intended purpose that covers the whole device. Two conflicting intended purposes are a red flag at the Notified Body review.
  • Missing that the minimum IT requirements for the phone and the network belong in the labelling. Annex I Section 17 requires these to be set out explicitly.

The Subtract to Ship angle for wearables

Wearables are where Subtract to Ship gets tested hardest, because there are three layers to get wrong and each layer tempts a startup into over-scoping. The framework applies layer by layer. Purpose Pass: what is the wearable actually for, and is it a medical device at all, or can Phase 1 run as a wellness product while evidence is gathered? Classification Pass: what is the lowest defensible class under Rule 11 for the software and under the relevant hardware rules in Annex VIII, and what conformity assessment route follows? Evidence Pass: what harmonised standards cover the established components — EN 60601-1:2006+A1+A12+A2+A13:2024 for the electronics, EN 62304:2006+A1:2015 for the firmware and the companion app, EN ISO 10993-1:2025 for biocompatibility — and where is new evidence actually required? Operations Pass: how small can the QMS be, given the class, while still covering every required process?

The wearables we have seen ship cleanly are the ones where the founders ran all four passes before the hardware freeze, not after it. Post 065 covers the framework in full.

Reality Check — Where do you stand on your wearable's compliance stack?

  1. Have you named the three components of your wearable — body-worn unit, embedded firmware, companion app — and confirmed that each one is in the technical documentation scope?
  2. Have you written one intended purpose that covers the whole wearable, and does it match every public claim on your website, app store listing, and marketing materials?
  3. Have you identified which rules in Annex VIII apply to the hardware side and which apply to the software side, and have you determined the overall device class as the highest of the applicable rules?
  4. Have you planned the EN 60601-1:2006+A1+A12+A2+A13:2024 test campaign at a competent test house, with the hardware freeze date that the campaign requires?
  5. Is the firmware being developed under an EN 62304:2006+A1:2015-compatible lifecycle from the first commit, with a documented software safety class?
  6. Is the companion app being developed under its own EN 62304:2006+A1:2015 lifecycle, with a Rule 11 analysis documented in writing?
  7. Has the biocompatibility strategy been set under EN ISO 10993-1:2025 before the hardware design is locked?
  8. Does your risk management file under EN ISO 14971:2019+A11:2021 cover hazards across all three layers and show the controls wherever they live?

Frequently Asked Questions

Is a wearable automatically a medical device under the MDR? No. A wearable is a medical device only if its intended purpose meets MDR Article 2(1). A fitness tracker marketed for general wellness is not a medical device. The same hardware marketed for arrhythmia detection is. The qualification is driven by the stated intended purpose, not by the sensor stack. Post 373 covers the intended-purpose gate.

Does my wearable need EN 60601-1:2006+A1+A12+A2+A13:2024 if it runs on a small battery? Generally yes, if the wearable has a patient-connected applied part. Battery voltage does not exempt a device from EN 60601-1:2006+A1+A12+A2+A13:2024 — the standard covers basic safety across electrical, mechanical, thermal, and radiation hazards, and battery-powered wearables with skin contact fall squarely within scope. The test campaign is scoped to the specific hazards of the device.

Can the companion app be a separate CE marking from the wearable hardware? In principle, stand-alone software can be CE-marked as its own medical device, and there are architectures where the companion app and the body-worn unit are separate devices that interoperate. In most wearable startups, however, the two components are marketed and used together as a single system, and the simpler and more defensible path is to CE-mark the system as one device with technical documentation covering both components.

How does MDCG 2019-11 Rev.1 apply to the firmware inside the wearable? MDCG 2019-11 Rev.1 covers qualification and classification of medical device software under the MDR. The firmware inside the wearable is medical device software when the wearable itself is a medical device, and the software elements of the device are considered under Annex VIII Rule 11 together with the companion app. The guidance document provides the decision tree and the worked examples; the outcome for a specific wearable depends on the intended purpose and the clinical information the software produces.

Do I need EN 62304:2006+A1:2015 for both the firmware and the companion app? Yes. Both are medical device software under MDR Annex I Section 17, and both commonly use EN 62304:2006+A1:2015 as the harmonised lifecycle standard. Each component has its own software safety class, its own lifecycle documentation, and its own verification and validation evidence. The two sets of documentation can reference each other, but they cannot be merged into a single lifecycle file that blurs the boundaries.

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, hardware, IT networks, and IT security); Annex VIII Rule 11 (software classification). 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. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).
  4. EN 60601-1:2006+A1+A12+A2+A13:2024 — Medical electrical equipment — Part 1: General requirements for basic safety and essential performance.
  5. EN ISO 10993-1:2025 — Biological evaluation of medical devices — Part 1: Requirements and general principles for the evaluation of biological safety within a risk management process.
  6. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

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 — EN 62304:2006+A1:2015, EN 60601-1:2006+A1+A12+A2+A13:2024, and EN ISO 10993-1:2025 are the harmonised tools that provide presumption of conformity with the corresponding MDR Annex I requirements, not independent authorities. For startup-specific regulatory support on wearable device qualification, classification, and lifecycle work, Zechmeister Strategic Solutions is where this work is done in practice.