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, the directive does not apply. 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). Healthcare providers appear in Annex I (sectors of high criticality); medical device and in vitro diagnostic manufacturers appear in Annex II Section 5(a) (other critical sectors, manufacturing subsector), defined by reference to Art. 2(1) MDR and Art. 2(2) IVDR.
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 are essential; medium-sized entities listed in Annex I and all entities listed in Annex II (regardless of size) are important. The two categories trigger different supervisory regimes (ex ante supervision under Art. 32 for essential entities, ex post enforcement under Art. 33 for important entities), but both are subject to the cybersecurity risk-management measures of Art. 21. 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) carve-outs that capture certain smaller entities by entity type, excluding many Swiss 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 faces no NIS2 compliance obligation as a matter of Swiss law.
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) requires essential and important entities to address supply chain security, including relationships with direct suppliers.2NIS2 (n 1), Art. 21(2)(d). Art. 21(3) further requires entities to assess "the overall quality of products and cybersecurity practices of their suppliers."3NIS2 (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 been uneven. 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.4European 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, and some have, gone further.
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?
The cybersecurity landscape for medical devices is not defined by NIS2 alone. Swiss manufacturers selling into the EU already navigate a complex matrix of overlapping requirements that intersect with, and in some cases predate, the NIS2 framework. For a US-based manufacturer reaching for the closest analogue, the contrast is structural: the FDA's premarket cybersecurity regime for "cyber devices" under section 524B of the Federal Food, Drug, and Cosmetic Act is a regulator-operated gate to market entry, whereas the pressure described here arrives laterally, through the customer's own supply-chain obligations rather than any authority's premarket review.
The MDR itself contains cybersecurity requirements, whose device-level implications are examined in Insight 18. Annex I, Sections 17.2 and 17.4 require that software-incorporating devices be developed in accordance with the state of the art for information security, including minimum IT network security measures.5Regulation (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.6Medical 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.7IEC 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). Formal EU harmonization is anticipated by May 2028, but Notified Bodies increasingly treat compliance as representing "state of the art" for MDR Annex I, Section 17.2 purposes. For connected devices that interact with hospital operational technology networks, IEC 62443 may apply in addition.8IEC 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 formal harmonization in 2028 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 mandatory harmonization incurs costs for a standard not yet legally required, 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.9Regulation (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.10European 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 recalibrate the interface with 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, with that interface examined in Insight 14. 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,11Commission 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.12NIS2 (n 1), Art. 34(4)–(5). Member State implementations may vary; some have adopted higher ceilings. Management bodies can be held personally liable and potentially suspended from management functions pending remediation. 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 contract will reflect that exposure. 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. NIS2 Recital 82 and Art. 21(1) emphasize risk-based, proportionate measures.13NIS2 (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. Swiss SMEs, excluded from direct NIS2 scope by size thresholds, may find themselves subject to flowdown requirements designed for large enterprises.
Several provisions merit scrutiny. Audit rights may expose proprietary security architecture when external auditors request network diagrams and access to security operations centers. Incident notification timeframes may exceed the supplier's detection capabilities. Unlimited liability for cybersecurity deficiencies transforms a supply contract into an existential exposure, and cybersecurity representations and warranties may survive contract termination indefinitely. Each provision represents a commitment that must be operationally deliverable, not merely contractually acceptable.
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.14Federal Act on Information Security (Bundesgesetz über die Informationssicherheit beim Bund, Informationssicherheitsgesetz, ISG) of 18 December 2020 (SR 128), as amended, Art. 74e.
The ISG defines critical infrastructure broadly across nine sectors and 27 subsectors, including healthcare facilities such as hospitals, nursing homes, and medical laboratories. Notably, the law also covers "manufacturers of hardware or software whose products are used by critical infrastructures."15ISG (n 14), Art. 74b.
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 does not reach every such manufacturer, only those whose hardware or software has remote-maintenance access, serves to control or monitor operational technical systems, or ensures 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. Whether a given device crosses the threshold is nonetheless fact-specific; the Cybersicherheitsverordnung (CSV; Cybersecurity Ordinance) adds size-based carve-outs for the smallest entities; 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 regime provides a six-month grace period before fines apply (effective 1 October 2025) and caps fines for intentional or grossly negligent violations at CHF 100,000.16Art. 74h ISG (n 14) (Strafbestimmungen, fine ceiling of CHF 100,000); 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 notifications under five distinct regimes: NIS2 to the national CSIRT 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.17Art. 23(4) NIS2 (n 1); Art. 33 Regulation (EU) 2016/679 (GDPR) [2016] OJ L119/1; Art. 74e ISG (n 14); 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, three regulatory bodies, and contractual counterparties, each with distinct expectations about content, timing, and remediation.
5. Why Do These Interdependencies Matter?
For Swiss medical device manufacturers selling connected devices into the EU market, the question is not whether to implement cybersecurity measures, but which framework to anchor those measures around, and whether the organization has examined the interdependencies between certification status, contractual commitments, technical architecture, insurance coverage, and governance structures that together determine cybersecurity posture.
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 architecture 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 in isolation from contractual review may reveal that representations have already been made, and potentially breached. Certification pursued without architectural assessment may expose 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 Exposure
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.18Art. 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 Coverage 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.
These questions require analysis tailored to specific products, markets, and commercial relationships. The regulatory frameworks establish parameters; the particular circumstances of each manufacturer determine which exposures are material and which dependencies are critical.
The German hospital's procurement questionnaire asked the wrong question. It asked about NIS2 compliance as if legal applicability were the issue. 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.