---
title: MDR Functional Safety: IEC 62443 and IEC 61508 for Devices
description: When functional safety concepts from IEC 61508 and IEC 62443 add value to MDR medical device development, and what you cannot claim about them.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: functional safety IEC 62443 IEC 61508 medical device
canonical_url: https://zechmeister-solutions.com/en/blog/functional-safety-iec-62443-iec-61508
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Functional Safety: IEC 62443 and IEC 61508 for Devices

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

> **IEC 61508 (generic functional safety) and IEC 62443 (industrial cybersecurity) are not harmonised under the MDR and cannot be used as presumption of conformity. For high-risk active medical devices, however, their concepts — Safety Integrity Levels, zone-and-conduit modelling, systematic capability — can sharpen the ISO 14971 risk file and support the GSPR argument when folded into the harmonised stack correctly.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- IEC 61508 is the generic functional safety standard; IEC 62443 is the industrial automation and control system cybersecurity series. Neither is harmonised under the MDR.
- For medical devices, the presumption-of-conformity stack for electrical safety and software remains EN 60601-1, EN 62304, EN ISO 14971, and EN IEC 81001-5-1:2022.
- Concepts from IEC 61508 (SIL, systematic capability, diagnostic coverage) and IEC 62443 (security zones, conduits, security levels) can inform your ISO 14971 risk analysis and your security architecture.
- You cannot claim a SIL rating as compliance with MDR Annex I §17.2. You can use SIL-style reasoning as input into your risk control rationale.
- The honest position in your technical documentation is: "informational reference, not harmonised standard." Anything else invites a Notified Body finding.

## Why this matters

Founders building high-risk active devices — robotic surgery platforms, closed-loop insulin systems, ventilators, neurostimulators — often come from industries where functional safety has a clean ruleset. A roboticist knows ISO 10218 and IEC 61508. An OT engineer knows IEC 62443 inside out. They arrive in MedTech expecting the same clarity and find a different stack: EN 60601-1, EN ISO 14971, EN 62304, and an MDR that talks about state-of-the-art risk control rather than SIL targets.

The temptation is to import what they know. "Our device is SIL 2, so we meet MDR." That sentence will not survive a Notified Body review. But throwing away the underlying engineering discipline would also be a waste — functional safety thinking genuinely strengthens a risk file when it is translated into the harmonised vocabulary the MDR actually uses.

This post is about that translation.

## What MDR actually says

The MDR does not mention IEC 61508 or IEC 62443. It talks about outcomes.

**Annex I General Safety and Performance Requirement 1** requires that devices "achieve the performance intended by their manufacturer and shall be designed and manufactured in such a way that, during normal conditions of use, they are suitable for their intended purpose. They shall be safe and effective and shall not compromise the clinical condition or the safety of patients."

**Annex I §14** covers construction of devices and interaction with their environment, including mechanical, thermal, and electrical risks.

**Annex I §17.2** requires that software be developed and manufactured "in accordance with the state of the art taking into account the principles of development life cycle, risk management, including information security, verification and validation."

The presumption of conformity route — the way you demonstrate you have met those GSPRs — goes through harmonised standards listed in the Official Journal. For electrical medical equipment and its programmable electrical medical systems (PEMS), that stack is:

- **EN 60601-1:2006+A1+A12+A2+A13:2024** for basic safety and essential performance, including Clause 14 on PEMS
- **EN ISO 14971:2019+A11:2021** for risk management
- **EN 62304:2006+A1:2015** for medical device software lifecycle
- **EN IEC 81001-5-1:2022** for health software security lifecycle

IEC 61508 and the IEC 62443 series are absent from that list. They are excellent standards. They are not harmonised for the MDR.

## Where IEC 61508 concepts add real value

IEC 61508 was written for generic electrical, electronic, and programmable electronic safety-related systems. Its core contribution is a quantitative framework for tolerable failure rates: Safety Integrity Levels 1 to 4, mapped to probabilities of dangerous failure per hour and per demand, with systematic capability requirements on the development process.

For a Class IIb or III active device, three IEC 61508 ideas can sharpen your ISO 14971 file:

**1. Quantitative failure rate targets for hardware.** ISO 14971 requires you to evaluate residual risk but does not mandate a specific quantitative method. IEC 61508's PFH (probability of dangerous failure per hour) calculations, with component failure rates from databases like SN 29500 or MIL-HDBK-217, give you defensible numbers for single points of failure in safety functions. You document this as "quantitative risk estimation method, informed by IEC 61508 Part 6, applied as input to the ISO 14971 risk analysis."

**2. Systematic capability and the distinction between random and systematic failures.** IEC 61508 forces you to separate random hardware failures from systematic design faults. That distinction already lives implicitly in EN 62304 (which addresses systematic software faults through lifecycle rigour) and in 60601-1 Clause 14 PEMS (which addresses the architecture). Making it explicit helps your team reason clearly about which risk controls address which failure mode.

**3. Diagnostic coverage and proof-test intervals.** If your device has a self-test routine or a watchdog, IEC 61508's concept of diagnostic coverage gives you a structured way to argue what fraction of dangerous faults you actually detect. That argument belongs in your risk file and in your 60601-1 Clause 14.2 PEMS risk management documentation.

What you cannot do: write "SIL 2" on your Declaration of Conformity or claim presumption of conformity against IEC 61508. That is not how MDR conformity works.

## Where IEC 62443 concepts add real value

IEC 62443 is the leading industrial automation security standard series. For medical devices, cybersecurity conformity runs through **EN IEC 81001-5-1:2022** (health software security lifecycle), MDR Annex I §17.2 and §17.4, and **MDCG 2019-16 Rev.1** on cybersecurity for medical devices.

But IEC 62443 introduced two modelling concepts that 81001-5-1 and MDCG 2019-16 do not replace:

**Zones and conduits.** IEC 62443-3-2 requires you to partition your system into security zones with defined trust levels and to document the conduits (interfaces) between them. For a device that includes a medical gateway, a clinician workstation, a cloud backend, and a hospital network connection, this partitioning is a genuinely useful way to draw your attack surface. Your threat model, required by MDCG 2019-16, becomes much easier to defend when you have an explicit zone-and-conduit diagram.

**Security Levels (SL 1 to 4).** These map target resilience against classes of attacker capability. They are not required by the MDR. They can be a useful internal shorthand when discussing which subsystem needs which defensive depth — as long as nobody on your team believes an SL rating substitutes for the 81001-5-1 lifecycle activities.

The rule of thumb: use IEC 62443 as a modelling language for your threat model and security architecture document. Deliver conformity through 81001-5-1 and MDCG 2019-16.

## A worked example

A team is building a Class IIb closed-loop anaesthesia delivery system. It combines a programmable drug pump, a patient monitoring module, and an algorithm that adjusts infusion rate based on vital signs. The lead engineer came from rail signalling and wants to set a SIL 2 target for the dosing control loop.

Here is how that SIL 2 thinking folds into the MDR stack without overclaiming:

1. The ISO 14971 risk analysis identifies the hazard "unintended overinfusion leading to respiratory depression." The team sets a quantitative risk acceptance criterion: dangerous failure rate of the closed-loop control function below 10⁻⁷ per hour. This criterion is informed by IEC 61508 SIL 2 PFH ranges but documented as "risk acceptance criterion per ISO 14971 Clause 4.4, using quantitative method." IEC 61508 is cited as an informational reference.
2. The 60601-1 Clause 14 PEMS development lifecycle documentation includes a hardware FMEDA (Failure Modes, Effects and Diagnostic Analysis) producing a quantitative PFH estimate. The FMEDA methodology references IEC 61508-2, again as informational input.
3. The software is developed under EN 62304 Class C (death or serious injury possible). IEC 61508-3 systematic capability concepts are used internally as a checklist to ensure nothing in the 62304 lifecycle is weaker than what the rail engineer would expect — but the lifecycle artefacts are 62304 artefacts, not 61508 artefacts.
4. Cybersecurity follows EN IEC 81001-5-1:2022 and MDCG 2019-16 Rev.1. The threat model uses IEC 62443-3-2 zone-and-conduit notation and discusses Security Levels as an internal target. Conformity evidence is against 81001-5-1.
5. The technical documentation lists harmonised standards in the standard conformity matrix. IEC 61508 and IEC 62443 appear in a separate section labelled "Non-harmonised standards used as informational references."

That structure survives a Notified Body review. "We are SIL 2 certified" does not.

## The Subtract to Ship playbook

**Start with the harmonised stack, always.** EN 60601-1 plus EN ISO 14971 plus EN 62304 plus EN IEC 81001-5-1 is your baseline for a programmable electrical medical device. If you cannot clearly map your argument to those standards, importing IEC 61508 or IEC 62443 will not rescue you.

**Ask a single question before reaching for IEC 61508.** Does my ISO 14971 risk file have a hazard where residual risk depends on a quantitative failure rate that I cannot argue convincingly without structured hardware reliability calculations? If yes, IEC 61508 Part 6 methods belong in your file as an informational input. If no, you do not need them.

**Ask a single question before reaching for IEC 62443.** Does my system have multiple trust boundaries — device, gateway, cloud, hospital network — that my current threat model does not cleanly represent? If yes, IEC 62443-3-2 zone-and-conduit modelling is a useful notation. If no, do not add another standard to your bookshelf.

**Write one paragraph in your technical file, not a chapter.** Under "Standards used," list harmonised standards with presumption-of-conformity effect. Under a separate heading, list any non-harmonised standards used as informational references, state which clauses you drew from, and state explicitly that you do not claim presumption of conformity against them. This transparency is what an experienced auditor wants to see.

**Train your team on the distinction.** The engineer who shouts "we are SIL 2" at a Notified Body audit has made your life harder. The engineer who says "our quantitative risk estimation method is informed by IEC 61508 but conformity is demonstrated through ISO 14971 and 60601-1 Clause 14" has made your life easier.

**Do not pay for a certification you do not need.** A separate IEC 61508 or IEC 62443 certification from a functional safety assessor does not give you MDR conformity. It can be useful if customers in adjacent markets (industrial, mobility) demand it. It is not an MDR deliverable.

## Reality Check

1. Can you name the harmonised standards that give you presumption of conformity for your device's electrical safety, software, risk management, and cybersecurity? If not, fix that before importing anything else.
2. Does your ISO 14971 risk file have at least one hazard where you believe a quantitative failure rate target is necessary? What is that target and how did you derive it?
3. If you are using IEC 61508 concepts, is that use documented as informational input or as a conformity claim? Read your technical file and check the exact wording.
4. Does your threat model cleanly represent every trust boundary in your system, including cloud and hospital network interfaces? Could you redraw it as zones and conduits in an hour?
5. If a Notified Body auditor asked "why did you cite IEC 62443 in your technical file when it is not harmonised for MDR," could you answer in two sentences without contradicting yourself?
6. Has someone on your team confused Safety Integrity Level with EN 62304 Software Safety Class? These are not the same. Make sure everybody knows that.
7. Is your team shipping engineering discipline or shipping standards-shopping? If you are reaching for a new standard every time a gap appears, the gap is probably in the harmonised work, not the standards library.

## Frequently Asked Questions

**Is IEC 61508 harmonised under the MDR?**
No. IEC 61508 is not in the list of harmonised standards for Regulation (EU) 2017/745. It cannot give you presumption of conformity. It can be cited as an informational reference for methods used within your ISO 14971 and 60601-1 Clause 14 documentation.

**Can we claim SIL 2 on our Declaration of Conformity?**
No. The EU Declaration of Conformity cites the regulation, applicable annexes, and the harmonised standards you applied. SIL ratings have no status in that document. Making that claim risks a Notified Body nonconformity and, in a market surveillance inspection, a finding of misleading information.

**Is IEC 62443 required for medical device cybersecurity?**
No. MDR Annex I §17.2 and §17.4 require a state-of-the-art security lifecycle. The harmonised route is EN IEC 81001-5-1:2022 together with MDCG 2019-16 Rev.1. IEC 62443 can be a useful modelling reference, especially for devices with complex network topologies, but it is not the conformity route.

**Do Notified Bodies accept IEC 61508 work?**
Experienced auditors accept IEC 61508-informed methods in your risk file as long as the conformity argument is anchored in the harmonised stack. They do not accept IEC 61508 as a substitute for EN 60601-1 Clause 14 or EN 62304. Ask your Notified Body lead reviewer in writing before you invest significantly.

**Our robotics background is all IEC 61508. How do we bridge to MDR?**
Map your existing safety argument to the 14971 hazard analysis and the 60601-1 Clause 14 PEMS lifecycle. Keep your FMEDA and failure rate calculations; relabel them as quantitative risk estimation. Run your software through EN 62304, not IEC 61508-3. Treat it as a vocabulary translation, not a rewrite.

**When would a separate IEC 62443 certification be worth pursuing?**
When your device is also sold into industrial or critical infrastructure contexts where customers demand it contractually, or when you are building a platform that non-medical products will also use. For pure MedTech, it adds cost without adding MDR conformity.

## Related reading

- [MDR Electrical Safety Requirements](/blog/mdr-electrical-safety-requirements) — the harmonised baseline for Annex I §14 and §17 that your device must meet first.
- [PEMS and IEC 60601-1](/blog/mdr-pems-iec-60601-1) — Clause 14 is where systematic hardware-software safety reasoning actually lives for medical devices.
- [Basic Safety and Essential Performance in IEC 60601-1](/blog/basic-safety-essential-performance-iec-60601-1) — the conceptual anchor for what your safety argument needs to protect.
- [Software Safety Classification under IEC 62304](/blog/software-safety-classification-iec-62304) — do not confuse Software Safety Class with Safety Integrity Level; they answer different questions.
- [MDR Annex I GSPR](/blog/mdr-annex-i-gspr) — the outcome-based requirements that every standard you cite ultimately serves.

## Sources

1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I General Safety and Performance Requirements, in particular GSPR 1–9, §14, §17.2, §17.4.
2. EN 60601-1:2006+A1+A12+A2+A13:2024 — Medical electrical equipment — Part 1: General requirements for basic safety and essential performance, Clause 14 (PEMS).
3. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.
4. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes.
5. 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.
6. MDCG 2019-16 Rev.1 — Guidance on Cybersecurity for medical devices.

---

*This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) 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).*