The NIS-2 Directive (Directive (EU) 2022/2555) is the EU framework for a high common level of cybersecurity across essential and important entities. It applies to hospitals and other healthcare providers, not directly to medical device manufacturers. For a MedTech startup, NIS-2 matters because the hospitals that buy your device are regulated entities under NIS-2 and will push their obligations into their procurement requirements. MDR cybersecurity under Annex I Sections 17.2 and 17.4 and MDCG 2019-16 Rev.1 is the manufacturer-facing side of the same problem.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • The NIS-2 Directive is Directive (EU) 2022/2555. It replaces the original NIS Directive and raises the cybersecurity bar for essential and important entities across the EU.
  • NIS-2 lists the healthcare sector as an essential sector, which means hospitals, laboratories, and certain other healthcare providers are in scope. Medical device manufacturers are generally not listed as essential entities under NIS-2 in their capacity as manufacturers, but some fall in scope via other sector designations (for example, manufacturers of certain medical devices have been named in sector-specific annexes).
  • MDR cybersecurity obligations under Annex I Sections 17.2 and 17.4 and MDCG 2019-16 Rev.1 are the manufacturer-facing rules. NIS-2 is the operator-facing rules. The two meet in hospital procurement.
  • NIS-2 introduces incident notification obligations for in-scope entities, with an early warning within 24 hours and a formal incident notification within 72 hours of awareness.
  • For a MedTech startup, the practical impact is that customers will demand evidence of manufacturer-side cybersecurity: SBOM, CVD policy, incident response plan, and contractual support for the hospital's own NIS-2 obligations.
  • The Subtract to Ship response is to build one evidence pack that satisfies both MDR Annex I Section 17 and the most common NIS-2-driven procurement questions.

Why this matters

Tibor has watched this pattern develop over the last two years. Hospitals in Germany, Austria, and France started handing MedTech startups a 40-page cybersecurity procurement questionnaire that none of the marketing decks had prepared the founders for. The questionnaires come out of the hospital's own regulatory stack, which now includes NIS-2 and its national transpositions. The hospital has new obligations and pushes them up the supply chain. The manufacturer gets the questionnaire.

Felix has coached founders who lost deals because they could not answer basic questions about SBOM, vulnerability disclosure, or incident notification support. Losing a deal on a regulatory misunderstanding is one of the most avoidable failures a MedTech startup can make. NIS-2 awareness is now part of the commercial readiness checklist, not just the compliance checklist. An incident that the manufacturer has to report under MDR Article 87 is often the same incident the hospital has to report under NIS-2, and coordinating those reports is the difference between a clean response and a public relations disaster.

What the regulations actually say

MDR side. MDR Annex I 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 including information security, and verification and validation. Section 17.4 requires manufacturers to set out minimum requirements concerning hardware, IT network characteristics, and IT security measures including protection against unauthorised access. MDCG 2019-16 Rev.1 interprets these obligations and aligns them with EN IEC 81001-5-1:2022.

NIS-2 side. Directive (EU) 2022/2555 is the NIS-2 Directive, adopted in December 2022. Member States were required to transpose it into national law by 17 October 2024. The directive establishes cybersecurity risk management measures and incident reporting obligations for entities identified as essential or important, organised by sector. The healthcare sector is listed as an essential sector, and in-scope entities include healthcare providers and, in some member state transpositions, manufacturers of specific medical devices identified by the Commission or by national legislators.

Where they meet. MDR is product-facing. NIS-2 is operator-facing. A hospital using a connected medical device is covered by NIS-2 in its operations. The manufacturer of that device is covered by MDR in its design, manufacture, and post-market activities. A cybersecurity incident affecting the device in hospital use can trigger both frameworks simultaneously. The manufacturer has obligations under MDR Articles 83 and 87 to 92. The hospital has obligations under NIS-2. If the two sides are not coordinated in advance, the reports will conflict.

EN IEC 81001-5-1:2022 as the common language. Both MDCG 2019-16 Rev.1 and the procurement practices emerging under NIS-2 point at EN IEC 81001-5-1:2022 as the state-of-the-art standard for health software security activities in the product life cycle. A manufacturer who can demonstrate credible alignment with 81001-5-1 is speaking the language both regulators want to hear.

A worked example

A Class IIa remote monitoring device is in use at a university hospital in Austria. A critical vulnerability is published for a widely used open source library that the device uses. The manufacturer has an SBOM and learns about the CVE within four hours of publication. Here is how the two regulatory frameworks interact over the next 72 hours.

Hour 4. Manufacturer detection. The manufacturer's IR plan flags the CVE. The triage rubric assesses patient safety impact. A remote attacker could disable monitoring alerts, which would fall under the MDR Article 2(65) serious incident definition if it occurred to a patient in active monitoring.

Hour 8. Customer notification. The manufacturer activates its incident communications plan. A notification goes to every hospital that operates the device. The notification gives a plain-language impact summary, compensating controls (for example, isolate the device from the general network until patched), and the expected patch timeline. The PRRC is in the loop and an MDR Article 87 evaluation is underway.

Hour 10. Hospital-side actions. The hospital receives the notification. Under NIS-2 and the national transposition, the hospital is an essential entity in the healthcare sector. The hospital concludes that the event could lead to operational disruption and patient safety impact and files an early warning to its national CSIRT within 24 hours of awareness.

Hour 48. Coordinated response. The manufacturer ships a patch. The hospital deploys it under change control. The manufacturer submits its MDR Article 87 report. The hospital submits its 72-hour NIS-2 incident notification. Because the two sides were in contact from hour 8, the reports are consistent rather than contradictory. At Day 14 a blameless joint post-incident review feeds the ISO 14971 risk file, the EN 62304 configuration records, the PMS records, and the hospital's NIS-2 risk management measures.

The takeaway: the two regulatory regimes are separate but they cover the same incident. Coordination is a commercial and safety advantage, not a legal nicety.

The Subtract to Ship playbook

A MedTech startup does not need to become a NIS-2 expert. It needs to be useful to its hospital customers who are NIS-2 experts. Here is how to get there without building a second compliance programme.

Step 1. Confirm your own scope. Check the national transposition of NIS-2 in each member state where you have commercial activity. In most cases a medical device manufacturer is not listed as an essential or important entity under healthcare, but some member states have added manufacturers of specific high-risk device types. If you fall in scope, the full NIS-2 obligation set applies to you. If not, the rest of the playbook is about being a good vendor to in-scope customers.

Step 2. Build the evidence pack. One pack, updated quarterly, that answers the top 20 procurement questions. It should include: SBOM, CVD policy and security contact, IR plan summary, EN IEC 81001-5-1:2022 alignment statement, MDR Annex I Section 17 coverage matrix, incident notification commitments to the customer, and a short statement of how you will support the customer's NIS-2 obligations contractually.

Step 3. Write a customer notification commitment. A one-page document that states how fast, through what channel, and with what content the manufacturer will notify customers of a security incident affecting the device. Hospitals under NIS-2 need this timeline in writing so they can meet their own 24-hour early warning clock. Without this commitment in the contract, the hospital has to assume the worst and the deal gets harder.

Step 4. Align the MDR vigilance clock and the NIS-2 clock. MDR Article 87 runs on a 15-day clock (with shorter clocks for serious public health threats and deaths). NIS-2 runs on 24-hour early warning and 72-hour incident notification clocks for in-scope entities. These clocks are not the same and they do not replace each other. Your IR plan should assume that both clocks apply to the same event from different sides.

Step 5. Do not promise what you cannot deliver. Tibor has seen startups promise "immediate notification" in customer contracts and then discover they had no detection capability to support it. A realistic commitment (for example, 8-hour first notification of confirmed incidents) is better than an aspirational one.

Step 6. Refer the customer to their own obligations. When a hospital hands you a 40-page questionnaire, answer it honestly. If a question is about the hospital's operational obligations under NIS-2 rather than your manufacturing obligations under MDR, say so clearly. This is not passing the buck. It is helping the customer understand where the line sits.

Reality Check

Use these questions to stress-test your NIS-2 readiness from a manufacturer's perspective.

  1. Have you checked whether the national NIS-2 transposition in your largest customer country lists medical device manufacturers in scope?
  2. Do you have a one-page customer notification commitment in writing, and does it match what your IR plan can actually deliver?
  3. If a critical CVE dropped on a Sunday, could you notify every affected hospital customer within 12 hours?
  4. Does your CVD policy cross-reference the customer's NIS-2 obligations, so that hospital buyers see that you have thought about it?
  5. Can you walk a hospital procurement team through how MDR Annex I Section 17 and EN IEC 81001-5-1:2022 map to their NIS-2 controls?
  6. Have you run at least one tabletop exercise that includes a hospital customer on the call?
  7. Do you have a single evidence pack you can send to a prospective customer on request, or does every procurement questionnaire trigger a fire drill?

Frequently Asked Questions

Is a medical device manufacturer directly regulated under NIS-2? Generally, no, not in the role of manufacturer. NIS-2 primarily regulates operators of essential and important services. Healthcare providers are explicitly in scope as essential entities. Some member state transpositions have extended the scope in ways that can touch manufacturers of certain device types. The only safe answer is to check the national law that applies to you.

Is MDR cybersecurity enough to satisfy NIS-2? No. MDR cybersecurity and NIS-2 cover different angles. MDR covers the product and its lifecycle. NIS-2 covers the operator's risk management and incident response. A manufacturer who is fully compliant with MDR Annex I Section 17 still needs to support customers whose obligations run under NIS-2.

What is the NIS-2 incident notification timeline? NIS-2 introduces a tiered notification obligation for in-scope entities: an early warning within 24 hours of awareness and a formal incident notification within 72 hours. A final report follows later. These clocks are separate from, and faster at the front end than, the MDR Article 87 reporting clock.

What do hospitals actually ask for in procurement? In Felix's experience coaching founders through these conversations, the top five requests are: SBOM, vulnerability disclosure contact and policy, incident notification commitment, evidence of security testing, and a contractual clause committing the manufacturer to support the customer's incident response.

Is EN IEC 81001-5-1:2022 mentioned in NIS-2? Not directly. EN IEC 81001-5-1:2022 is the MDCG 2019-16 Rev.1 reference for medical device cybersecurity. NIS-2 sets cybersecurity risk management requirements at a higher, operator-facing level and does not name product standards. In practice, alignment with EN IEC 81001-5-1 is how a manufacturer answers the product-quality questions inside a NIS-2-driven procurement questionnaire.

Does NIS-2 apply outside the EU? NIS-2 is an EU directive. A non-EU manufacturer selling to EU hospitals will see NIS-2 obligations arrive indirectly through customer procurement terms.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Sections 17.2 and 17.4, Article 83, Articles 87 to 92.
  2. Directive (EU) 2022/2555 (NIS-2 Directive) on measures for a high common level of cybersecurity across the Union.
  3. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for Medical Devices (December 2019, Rev.1 July 2020).
  4. 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.
  5. EN ISO 14971:2019+A11:2021, Medical devices, Application of risk management to medical devices.