--- title: Cybersecurity for Medical Devices Under MDR: A Startup Guide for 2026 description: The 2026 startup guide to cybersecurity medical devices MDR, covering Annex I Section 17, MDCG 2019-16 Rev.1, EN IEC 81001-5-1:2022, and EN ISO 14971. authors: Tibor Zechmeister, Felix Lenhard category: AI, ML & Algorithmic Devices primary_keyword: cybersecurity medical devices MDR startup 2026 canonical_url: https://zechmeister-solutions.com/en/blog/cybersecurity-medical-devices-startup-guide-2026 source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Cybersecurity for Medical Devices Under MDR: A Startup Guide for 2026 *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Cybersecurity for medical devices under MDR rests on four pillars: Annex I Section 17.4 (IT security as a General Safety and Performance Requirement), MDCG 2019-16 Rev.1 (the guidance document), EN IEC 81001-5-1:2022 (the security lifecycle standard), and EN ISO 14971:2019+A11:2021 (risk management integration). A 2026 startup building any connected device must treat all four as non-optional.** **By Tibor Zechmeister and Felix Lenhard.** ## TL;DR - MDR Annex I Section 17.4 makes IT security a General Safety and Performance Requirement for devices that incorporate programmable systems. - MDCG 2019-16 Rev.1 (December 2019, revised July 2020) is the authoritative guidance document and maps closely onto EN IEC 81001-5-1:2022. - EN IEC 81001-5-1:2022 defines the secure software development lifecycle notified bodies expect to see during certification audits. - Cybersecurity is not a launch milestone. It is a continuous lifecycle obligation tied to post-market surveillance and vigilance. - The most underestimated aspect in startup files Tibor has audited is the failure to plan for vulnerability disclosure and patching after the CE mark is issued. ## Why this matters for a 2026 startup In Tibor's audits over the last three years, one pattern has become unmistakable. Wearables, smart wearables, connected monitors, and app-plus-hardware combinations keep growing as a share of the pipeline. Encryption, data protection, and penetration testing remain under-invested. Vulnerabilities keep getting discovered by curious security researchers and, occasionally, by less curious actors. The gap between how much these devices rely on software and how little many startups budget for security is the cybersecurity story of the current MDR era. This is the context every 2026 founder needs to internalize. A device with Bluetooth, Wi-Fi, a mobile companion app, cloud sync, or an over-the-air update channel is not "a device with some software inside". It is a connected medical system whose attack surface is now part of the product's safety profile. The regulator sees it that way. The notified body sees it that way. The only place where this sometimes does not land is inside the startup itself, where security keeps getting pushed to "after CE". Felix has watched this play out across coaching engagements. Founders invest six figures in electrical safety testing and usability summative evaluation, then try to finish cybersecurity in the final four weeks before the technical documentation freeze. By that point, retrofitting a proper secure development lifecycle into a nearly-finished product means either re-opening design controls or producing a file the notified body will visibly distrust. Neither is cheap. ## The four pillars of MDR cybersecurity MDR cybersecurity does not live in a single article. It is distributed across legislation, guidance, and harmonised standards. For a startup planning a 2026 submission, four pillars carry almost all the weight. ### Pillar 1: MDR Annex I Section 17.4 (IT security) Annex I Section 17 covers electronic programmable systems and software. Section 17.2 requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management, and verification and validation. Section 17.4 specifically addresses IT security: for devices that incorporate electronic programmable systems or software, manufacturers must set out minimum requirements concerning hardware, IT network characteristics, and IT security measures, including protection against unauthorised access. This is not a standalone chapter. It is a General Safety and Performance Requirement (GSPR). A GSPR finding is not a paperwork comment. It is a fundamental non-conformity. ### Pillar 2: MDCG 2019-16 Rev.1 MDCG 2019-16 Rev.1 (December 2019, revised July 2020) is the official guidance document on cybersecurity for medical devices under MDR and IVDR. It sets out minimum IT requirements, verification and validation expectations for security, risk assessment, and the post-market surveillance and vigilance considerations specific to security. In Tibor's experience reviewing notified body expectations, this document is the one auditors reach for first. ### Pillar 3: EN IEC 81001-5-1:2022 EN IEC 81001-5-1:2022 is the security lifecycle standard for health software. It defines the activities a manufacturer must carry out across the entire software lifecycle: secure design, threat modelling, secure coding, verification, vulnerability handling, and end-of-life security communication. MDCG 2019-16 Rev.1 and EN IEC 81001-5-1:2022 map closely onto each other. A startup that builds its security process against EN IEC 81001-5-1:2022 will automatically cover most of what MDCG 2019-16 Rev.1 asks for. Note the naming: "EN IEC 81001-5-1:2022" is the correct European reference. Unlike the 60601 and 62304 families, where the "IEC" prefix is dropped in European publication, this standard retains the EN IEC form. ### Pillar 4: EN ISO 14971:2019+A11:2021 integration Security risks are safety risks. EN ISO 14971:2019+A11:2021 is the risk management standard harmonised under MDR, and security hazards belong inside the same risk management file as mechanical, electrical, biological, and usability hazards. A cybersecurity risk assessment that lives in a separate document, disconnected from the 14971 file, is a finding waiting to happen. A confidentiality breach that leaks diagnostic results is a patient-safety-relevant event. The risk file must reflect that. ## A worked example: the wearable cardiac monitor Consider a 2026 startup building a Class IIa wearable cardiac monitor. Bluetooth Low Energy link to a companion app. App syncs to a cloud backend. Firmware is updatable over the air. Target market: the European Union, starting in Germany and Austria. A credible cybersecurity package for this device covers: - A threat model built against EN IEC 81001-5-1:2022, identifying assets (patient data, firmware integrity, clinical measurements), threat actors (opportunistic, targeted, insider), and attack vectors (BLE, OTA channel, cloud API). - A secure development lifecycle documented in the software development plan required by EN 62304:2006+A1:2015, with the security activities from EN IEC 81001-5-1:2022 layered on top. - A cybersecurity risk assessment integrated into the EN ISO 14971:2019+A11:2021 risk management file. Security hazards traced to potential harm. Risk controls traced to verification evidence. - Penetration testing against the BLE stack, the OTA update path, and the cloud backend. Results documented and dated. Any findings closed or justified. - A software bill of materials, maintained as part of the EN 62304 configuration item list, with vulnerability monitoring per library. - A post-market surveillance plan that explicitly covers cybersecurity incidents and CVE monitoring for the SBOM components. - A vulnerability disclosure process with a public contact point and an internal triage procedure. That is the minimum a 2026 notified body reviewer will expect to see. Anything less and the file gets sent back. ## The Subtract to Ship playbook The Subtract to Ship approach to cybersecurity is not to do less. It is to stop doing the wrong things and do the right things once, properly. Felix has watched too many startups write a cybersecurity Word document "to satisfy the notified body" while leaving the actual product insecure. That is the opposite of Subtract to Ship. **Step 1.** Decide as early as possible whether the device is connected. Bluetooth, Wi-Fi, cellular, wired Ethernet, or removable media that crosses into a network all count. If any of these are present, EN IEC 81001-5-1:2022 applies. **Step 2.** Build the threat model during architecture, not during documentation. Threat modelling done after the system is built is archaeology, not engineering. **Step 3.** Pick a secure development lifecycle that maps to EN IEC 81001-5-1:2022 and embed its activities in the same software development plan that already covers EN 62304. One plan, two standards, zero duplication. **Step 4.** Integrate the security risk assessment into the EN ISO 14971:2019+A11:2021 file from day one. Do not create a parallel security risk document. **Step 5.** Budget penetration testing as a line item. In Tibor's experience, even startups that missed EN IEC 81001-5-1:2022 during development can rescue the notified body conversation with a credible third-party pentest result. It is rarely wasted money. **Step 6.** Build the software bill of materials from the 62304 configuration item list. Wire it into vulnerability monitoring. Decide now who watches the CVE feed after launch. **Step 7.** Write the vulnerability disclosure process and publish the contact channel before CE marking, not after the first researcher email lands in the general support inbox. ## Reality Check Answer honestly. Each "no" is a gap worth closing before the technical documentation is submitted. 1. Is the device connected in any way, including Bluetooth, Wi-Fi, cellular, or USB that touches a networked host? 2. Is there a documented threat model that identifies assets, actors, and attack vectors? 3. Is the secure development lifecycle traceable to EN IEC 81001-5-1:2022 clause by clause? 4. Are security hazards represented inside the EN ISO 14971:2019+A11:2021 risk management file, not in a separate document? 5. Has an independent penetration test been completed and its findings closed or justified? 6. Does the software bill of materials exist and is it updated on every software release? 7. Is there a named person responsible for monitoring CVEs affecting SBOM components after market launch? 8. Is the vulnerability disclosure process published and tested? ## Frequently Asked Questions **Does MDR cybersecurity apply to non-connected devices?** If the device has genuinely zero wireless and zero wired network capability, the attack surface is much smaller, but MDR Annex I Section 17.2 still requires state-of-the-art software development. If the microcontroller has Bluetooth or Wi-Fi capability that is merely disabled, proof is needed that the radio cannot be re-enabled maliciously. **Is EN IEC 81001-5-1:2022 legally mandatory?** EN IEC 81001-5-1:2022 is a harmonised standard. Compliance gives a presumption of conformity with the relevant GSPRs, but alternative approaches are permitted if equivalent. In practice, notified bodies use EN IEC 81001-5-1:2022 as their reference, so deviating from it creates explanation burden. **How does MDCG 2019-16 Rev.1 differ from EN IEC 81001-5-1:2022?** MDCG 2019-16 Rev.1 is a guidance document from the Medical Device Coordination Group. EN IEC 81001-5-1:2022 is a harmonised standard. The two documents align closely on substance. In Tibor's reading, a process built against EN IEC 81001-5-1:2022 will cover the vast majority of MDCG 2019-16 Rev.1 expectations. **Can a small startup afford a secure development lifecycle?** The up-front cost of doing it correctly is lower than the cost of re-opening design controls after CE. Every cybersecurity decision deferred now becomes a change control process with notified body re-engagement later. **What happens if a vulnerability is discovered after launch?** It is handled through post-market surveillance and the change control procedure. A credible CVE monitoring process and a documented vulnerability response plan are both expected by the notified body at certification time. **Is a penetration test a substitute for a secure development lifecycle?** No. It is complementary evidence. A pentest is a point-in-time external verification. The secure development lifecycle is the ongoing process that makes the pentest worth doing. ## Related reading - [MDR Annex I Section 17: Cybersecurity Requirements](/blog/mdr-annex-i-section-17-cybersecurity), for the regulatory text deep dive. - [MDCG 2019-16: Guidance on Cybersecurity for Medical Devices](/blog/mdcg-2019-16-cybersecurity-guidance), to walk through the guidance document in detail. - [SBOM for Medical Devices under MDR](/blog/sbom-medical-devices-mdr), for the software bill of materials piece. - [MDR Software Lifecycle: IEC 62304](/blog/mdr-software-lifecycle-iec-62304), to see where the security lifecycle attaches to the software lifecycle. ## Sources 1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, Chapter II, Section 17 (Electronic programmable systems, software), including §17.2 and §17.4. 2. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices (December 2019, revised July 2020). 3. 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. 4. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices. 5. EN 62304:2006+A1:2015, Medical device software, Software life cycle processes. --- *This post is part of the [AI, ML & Algorithmic Devices](https://zechmeister-solutions.com/en/blog/category/ai-ml-devices) 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).*