A Swiss manufacturer of connected insulin pumps receives a procurement questionnaire from a German hospital group. The questionnaire asks for evidence of NIS2 compliance. The manufacturer's regulatory team reviews the NIS2 Directive and concludes, correctly, that as a Swiss entity it is not subject to the directive. They respond accordingly.
The manufacturer's legal analysis was technically accurate. It was also commercially irrelevant. Three months later, the contract went to a competitor who understood that the question was never about legal applicability.
1. Does NIS2 Apply to Swiss Manufacturers?
Directive (EU) 2022/2555, commonly known as NIS2, entered into force on 16 January 2023, with Member States required to transpose it into national law by 17 October 2024.1Directive (EU) 2022/2555 [2022] OJ L333/80 (NIS2), Art. 41 (transposition deadline), Art. 45 (entry into force). The directive significantly expands the scope of its predecessor, Directive (EU) 2016/1148 (NIS1).2Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union [2016] OJ L194/1 (NIS1). Healthcare providers appear in Annex I NIS2 (sectors of high criticality); medical device and in vitro diagnostic manufacturers appear in Annex II, point 5(a) NIS2 (other critical sectors, manufacturing), defined by reference to Art. 2(1) MDR and Art. 2(2) IVDR. One category of manufacturer sits higher: entities manufacturing medical devices considered critical during a public health emergency, within the meaning of Art. 22 of Regulation (EU) 2022/123,3Regulation (EU) 2022/123 of the European Parliament and of the Council of 25 January 2022 on a reinforced role for the European Medicines Agency in crisis preparedness and management for medicinal products and medical devices [2022] OJ L20/1, Art. 22. appear in Annex I NIS2 alongside healthcare providers.
Whether a given entity is classified as "essential" or "important" turns on size, not on Annex membership alone. Under Art. 3 NIS2, large entities listed in Annex I NIS2 are, as a rule, essential; medium-sized entities listed in Annex I and in-scope entities listed in Annex II NIS2 (whether medium-sized or large) are important. The two categories trigger different supervisory regimes (ex ante supervision under Art. 32 NIS2 for essential entities, ex post enforcement under Art. 33 NIS2 for important entities), but both are subject to the cybersecurity risk-management measures of Art. 21 NIS2. Not every company that produces medical devices falls within scope; contract manufacturers, component suppliers, and software developers may or may not qualify depending on their precise activities. Size thresholds further limit the directive to medium and large enterprises (50+ employees or EUR 10 million+ turnover), subject to Art. 2(2) NIS2 carve-outs that capture certain smaller entities by entity type, excluding many SMEs from direct applicability.
Switzerland is not an EU Member State. The NIS2 Directive has no direct legal effect in Swiss territory. A Swiss medical device manufacturer operating exclusively within Switzerland has no NIS2 compliance obligation.
But very few Swiss medical device manufacturers operate exclusively within Switzerland. The majority of production is destined for EU markets, making indirect applicability a sector-wide reality.
The NIS2 Directive imposes explicit supply chain security obligations on in-scope entities. Art. 21(2)(d) NIS2 requires essential and important entities to address supply chain security, including security-related aspects of the relationships between each entity and its direct suppliers or service providers.4NIS2 (n 1), Art. 21(2)(d). Art. 21(3) NIS2 further requires entities, when considering which supply chain measures are appropriate, to take into account the vulnerabilities specific to each direct supplier and service provider and "the overall quality of products and cybersecurity practices of their suppliers and service providers."5NIS2 (n 1), Art. 21(3).
This creates what might be termed an "indirect applicability cascade." The German hospital is subject to NIS2. The German hospital must ensure its suppliers meet appropriate cybersecurity standards. The Swiss manufacturer supplies the German hospital. The Swiss manufacturer must therefore demonstrate cybersecurity compliance, not because NIS2 applies to it, but because NIS2 applies to its customer.
A complication: NIS2 is a directive requiring Member State transposition, not a directly applicable regulation. Transposition has lagged unevenly: Germany missed the 17 October 2024 deadline and brought its implementing law into force only on 6 December 2025, while several Member States had still not transposed by year-end, and national implementations differ in their specific supply chain provisions, reporting thresholds, and enforcement mechanisms.6European Cyber Security Organisation (ECSO), NIS2 Directive Transposition Tracker (tracking national transposition status across all EU Member States). A Swiss manufacturer selling to customers across multiple EU jurisdictions faces not one set of indirect requirements but several, each shaped by national implementing choices. The directive sets minimum standards; Member States may go further, and some have.
The question of whether NIS2 applies directly to a Swiss manufacturer is less important than whether NIS2 applies to anyone the manufacturer wants to sell to.
2. Which Cybersecurity Framework Governs?
NIS2 is only one of several cybersecurity regimes in the medical device sector. Swiss manufacturers selling into the EU are already subject to other requirements that overlap with NIS2 and in some cases predate it. For a US-based manufacturer, the closest analogue is the FDA's premarket cybersecurity regime for "cyber devices" under section 524B of the Federal Food, Drug, and Cosmetic Act, but that regime is a gate to market entry operated by the regulator, whereas the pressure described here comes through the customer's own supply-chain obligations rather than any authority's premarket review.
The MDR itself contains cybersecurity requirements; the analysis of cybersecurity for medical device software covers what they mean for the individual device. Annex I, Sections 17.2 and 17.4 MDR require that software-incorporating devices be developed in accordance with the state of the art for information security, including minimum IT network security measures.7Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices [2017] OJ L117/1 (MDR), Annex I, Sections 17.2, 17.4. MDCG 2019-16 elaborates on these requirements, establishing expectations for secure design, threat modeling, vulnerability management, and post-market cybersecurity monitoring.8Medical Device Coordination Group, Guidance on Cybersecurity for Medical Devices (MDCG 2019-16 Rev.1, July 2020). These are existing obligations, not future requirements. Whether Swiss manufacturers with CE-marked devices have fully implemented them is a question that procurement due diligence increasingly probes.
IEC 81001-5-1, published in 2021, establishes requirements for secure software development and security risk management adapted to healthcare.9IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle (International Electrotechnical Commission, 2021). The Commission has asked the European standardization bodies to adopt it as a harmonized standard under the MDR by 27 May 2028; no reference to it has been published in the Official Journal. Until then, a manufacturer can still use it to show the state of the art that Annex I, Section 17.2 MDR requires, which MDCG 2019-16 expects manufacturers to demonstrate on the basis of applicable standards and guidance. For connected devices that interact with hospital operational technology networks, IEC 62443 may apply in addition.10IEC 62443, Industrial communication networks – Network and system security (series), International Electrotechnical Commission. Where a device straddles the boundary between health IT and industrial control, a distinction that connected devices increasingly blur, both standards may inform the assessment.
The timing creates a dilemma without a clean resolution. A manufacturer that waits for the standard's harmonization may face questions about why devices certified earlier did not reflect cybersecurity practices already recognized internationally. A manufacturer that adopts IEC 81001-5-1 before harmonization incurs costs for a standard that does not yet confer a presumption of conformity, while the final harmonized version may differ from the 2021 text.
The CRA (Regulation (EU) 2024/2847), with main obligations applying from December 2027, adds horizontal cybersecurity requirements for products with digital elements, but excludes products already regulated under sector-specific legislation, including the MDR.11Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements [2024] OJ L 2024/2847 (CRA), Art. 2(2). However, accessories that do not themselves qualify as medical devices, software components outside the SaMD definition, and general-purpose digital modules in device ecosystems may still fall within CRA scope.
In December 2025, the European Commission proposed amendments to both MDR and IVDR that would explicitly add cybersecurity to the general safety and performance requirements and introduce mandatory vulnerability reporting to CSIRTs and ENISA.12European Commission, Proposal for a Regulation amending Regulations (EU) 2017/745 and (EU) 2017/746, COM(2025) 1023 final (16 December 2025). At the time of writing, this proposal is under consideration by the European Parliament and Council; final adoption and entry into force remain subject to the legislative process. The same proposal would change how the device rules relate to the AI Act for medical AI, disapplying most of the AI Act's horizontal high-risk obligations for AI-based devices to avoid duplicative conformity assessment and leaving device-specific requirements to be set under the MDR and IVDR; the analysis of AI-enabled medical devices describes that relationship as it stood before the proposal. Meanwhile, the Commission is developing implementing acts under Art. 21(5) NIS2 establishing harmonized technical requirements for cybersecurity risk management; the first such instrument covers digital infrastructure entities,13Commission Implementing Regulation (EU) 2024/2690 [2024] OJ L 2024/2690, adopted under NIS2 (n 1), Art. 21(5). and extension to healthcare supply chains is widely anticipated, though no draft has been announced.
The regulatory framework is not settled. Each evolution adds requirements that affect Swiss manufacturers' market access even when those requirements have no direct legislative applicability in Swiss territory. The question becomes how these requirements reach manufacturers in practice.
3. How Do Requirements Reach Swiss Suppliers?
The practical impact of NIS2 on Swiss manufacturers manifests primarily through contractual flowdown provisions. In-scope EU entities face substantial penalties for non-compliance: essential entities up to EUR 10 million or 2% of global annual turnover (whichever is higher), important entities up to EUR 7 million or 1.4% of turnover.14NIS2 (n 1), Art. 34(4)–(5). Member State implementations may vary; some have adopted higher ceilings. Management bodies can be held personally liable for infringements under Art. 20(1) NIS2. For essential entities, and only where other enforcement measures have proved ineffective, supervisory authorities may additionally request a temporary prohibition on individuals at chief executive or legal representative level exercising managerial functions, pending remediation (Art. 32(5) NIS2). These stakes create powerful incentives to push compliance obligations downstream through supply contracts.
Standard procurement questionnaires routinely probe certifications (typically ISO/IEC 27001), penetration-testing cadence, incident-response documentation, vulnerability remediation timelines, and secure software development lifecycle practices, with the relative weight given to each item varying by customer and Member State.
Hospital procurement officers may lack the technical expertise to evaluate the substantive adequacy of cybersecurity measures, but they can verify the presence or absence of certifications and documentation. The absence of an ISO 27001 certificate, or an inability to produce penetration test reports from the prior twelve months, provides a defensible basis for vendor disqualification. Whether this proxy approach actually improves supply chain security is a separate question; what matters for market access is that the proxy has become the gatekeeping mechanism.
Where the EU customer is subject to NIS2, the supply contract will impose matching requirements on the supplier. Typical flowdown provisions require suppliers to maintain equivalent security standards, notify the customer of security incidents within specified timeframes (often 24–48 hours, mirroring NIS2 reporting obligations), permit security audits, provide evidence of penetration testing, maintain documented vulnerability management processes, and accept liability for security breaches attributable to supplier systems. The cumulative effect transforms supplier qualification from a commercial negotiation into a regulatory compliance exercise conducted at one remove.
A tension exists between these undifferentiated flowdown requirements and the directive's own proportionality principle. Recital 82 and Art. 21(1) NIS2 emphasize risk-based, proportionate measures.15NIS2 (n 1), Recital 82, Art. 21(1). Yet procurement questionnaires rarely calibrate requirements to the specific risk a particular supplier poses; they impose uniform expectations regardless of whether the supplier provides mission-critical monitoring software or non-networked calibration equipment. Small Swiss suppliers, which would fall below the size thresholds even if NIS2 applied to them, may find themselves subject to flowdown requirements designed for large enterprises.
Several provisions merit scrutiny. Audit rights may disclose the supplier's proprietary security design when external auditors request network diagrams and access to security operations centers. Incident notification deadlines may be shorter than the time the supplier needs to detect an incident. Unlimited liability for cybersecurity deficiencies can put the supplier's existence at stake, and cybersecurity representations and warranties may survive contract termination indefinitely. Each provision is a commitment the supplier must be able to carry out in practice.
Contractual flowdowns from EU customers constitute one source of obligation. Swiss domestic law presents another.
4. What Does Swiss Law Require Independently?
Switzerland has developed its own cybersecurity regulatory framework, which both overlaps with and diverges from the EU approach. As of 1 April 2025, the amended Informationssicherheitsgesetz (ISG; Federal Act on Information Security) requires operators of critical infrastructure to report cyberattacks to the Federal Office for Cybersecurity (BACS) within 24 hours of discovery.16Federal Act on Information Security (Bundesgesetz über die Informationssicherheit, Informationssicherheitsgesetz, ISG) of 18 December 2020 (SR 128), as amended, Art. 74e.
Art. 74b ISG lists the reporting-obligated authorities and organizations in a broad catalog spanning energy, finance, transport, and healthcare, including hospitals on the cantonal hospital lists and licensed medical laboratories. Notably, the law also covers "manufacturers of hardware or software whose products are used by critical infrastructures."17ISG (n 16), Art. 74b; Art. 12 CSV (SR 128.51).
This raises an open interpretive question: does a medical device manufacturer qualify as a manufacturer of hardware or software whose products are used by critical infrastructure? Art. 74b ISG does not reach every such manufacturer, only those whose hardware or software has remote-maintenance access, is used to control and monitor operational systems and processes, or serves to ensure public safety. A connected insulin pump deployed in a Swiss hospital, carrying the remote-maintenance pathway such devices typically have, fits that description more readily than a non-networked instrument. A manufacturer's size does not exempt it from the duty to report: the exemptions in the Cybersicherheitsverordnung (CSV; Cybersecurity Ordinance), among them the one for small organizations in Art. 12(2) CSV, apply to other categories of Art. 74b(1) ISG, and none applies to the manufacturers listed in Art. 74b(1)(u) ISG. Whether a given device crosses the threshold nonetheless depends on its facts, and no BACS guidance addresses medical device manufacturers by name. The threshold question of manufacturer inclusion therefore remains genuinely uncertain at the level that matters: the individual device.
The ISG framework parallels NIS2 in structure if not in scope. Both require incident reporting within 24 hours. Both impose management responsibility for cybersecurity compliance. Both contemplate sanctions for non-compliance, though the Swiss sanctions regime is narrower: its provisions took effect only on 1 October 2025, six months after the reporting obligation itself, and the fine of up to CHF 100,000 attaches not to the missed report as such but to the intentional disregard of a legally binding BACS order issued after a report has been missed.18Art. 74g–74h ISG (n 16) (fine of up to CHF 100,000 for intentional non-compliance with a legally binding BACS order issued after a missed report); transitional provisions of the cybersecurity amendments to the ISG (reporting obligation in force 1 April 2025; sanctions provisions in force 1 October 2025).
Swiss manufacturers may therefore face dual reporting obligations: to BACS under Swiss law, and to EU customers under contractual flowdown provisions reflecting NIS2 requirements. The notification windows may align (both 24 hours) but the recipients, formats, and follow-up obligations differ. An incident response procedure that addresses only one regime leaves the other unaddressed.
Data Protection Notification Obligations
Cybersecurity incidents involving connected medical devices almost invariably involve personal health data, triggering parallel data protection notification obligations. A manufacturer facing a cybersecurity incident on a connected device deployed in an EU hospital may need to coordinate with notifications under five distinct regimes, not all of them its own: the hospital's NIS2 early warning to the CSIRT or competent authority within 24 hours; Art. 33 GDPR to the supervisory authority within 72 hours; ISG to BACS within 24 hours; Art. 24 DSG to the EDÖB as soon as possible for high-risk data protection breaches; and contractual notification to the customer within 24–48 hours.19Art. 23(4) NIS2 (n 1); Art. 33 Regulation (EU) 2016/679 (GDPR) [2016] OJ L119/1; Art. 74e ISG (n 16); Art. 24 Bundesgesetz über den Datenschutz (DSG) of 25 September 2020 (SR 235.1). Each regime specifies different recipients, different formats, different thresholds for what constitutes a reportable incident, and different follow-up obligations. The five-way notification complexity transforms what might appear as a single incident response challenge into a coordination exercise spanning two jurisdictions, four regulatory recipients, and contractual counterparties, each with distinct expectations about content, timing, and remediation.
5. Why Do These Interdependencies Matter for Swiss Medical Device Manufacturers?
Swiss medical device manufacturers selling connected devices into the EU market have to decide which framework to base their cybersecurity measures on, and whether they have examined how certification status, contractual commitments, technical design, insurance coverage, and governance structures depend on one another.
Certification and Contractual Interdependencies
The relationship between these elements is not sequential. A manufacturer considering ISO/IEC 27001:2022 certification must examine its existing contractual commitments to EU customers; some may already presuppose such certification. The product's design must support the controls the standard requires. Cyber liability insurance coverage may depend on certification as a prerequisite. Each consideration shapes the others. Certification pursued without contractual review may leave the manufacturer to discover later that it has already made representations, and potentially breached them. Certification pursued without a review of the product's design may reveal technical limitations that the management system cannot paper over.
Similar interdependencies surround software development lifecycle practices. Whether a manufacturer's processes align with IEC 81001-5-1 matters not only for anticipated MDR harmonization but also for customer due diligence expectations as of late 2025, for the defensibility of "state of the art" claims in conformity documentation, and for the consistency between what sales materials promise and what engineering actually delivers. The gap between documented processes and implemented practices, common in organizations that have grown faster than their quality systems, becomes a liability when customers begin requesting evidence.
Product Liability for Cybersecurity Defects
The revised Product Liability Directive (EU) 2024/2853, applicable from December 2026, introduces burden-of-proof reversal where a product did not comply with mandatory safety requirements.20Art. 7, 9, 10 Directive (EU) 2024/2853 [2024] OJ L 2024/2853 (PLD). Its broad "product" definition encompasses software. A cybersecurity deficiency that enables unauthorized device manipulation (an unlocked network interface, unpatched firmware, default credentials) could constitute a "defect" under this framework. Non-compliance with cybersecurity standards may simultaneously establish both regulatory breach and product defectiveness.
Insurance and Governance Gaps
Cyber liability policies increasingly specify coverage prerequisites (certifications, incident response procedures, penetration testing) that a manufacturer may not satisfy when an incident creates urgency. Both NIS2 and the Swiss ISG emphasize management body accountability, and customers conducting vendor due diligence inquire about executive-level cybersecurity responsibility and decision-making authority. The allocation of internal responsibility determines whether cybersecurity commitments made in commercial negotiations can actually be delivered.
Which of these risks are material for a given manufacturer, and which of its dependencies are essential, depends on its own circumstances.
The German hospital's procurement questionnaire was phrased in terms of NIS2 compliance, which invited an answer about legal applicability. The real issue was whether the manufacturer could demonstrate cybersecurity practices that warranted procurement confidence. That question does not depend on where the manufacturer is incorporated.