A software developer fixes a bug. The authentication module has a known cryptographic weakness; the patch is well understood, developed, and tested within days. In conventional software, it deploys the following week.
But this software is a medical device. Under the EU MDR, the patch may constitute a significant change, potentially requiring impact assessment, notified body consultation, and controlled deployment through healthcare change management processes. A fix measured in days enters a regulatory process measured in months. The vulnerability remains exploitable in every clinical deployment for the duration. The manufacturer faces a tension that conventional software development does not contemplate: rapid remediation and regulatory compliance may be mutually exclusive.
1. Where Do SaMD Cybersecurity Obligations Originate?
Cybersecurity requirements for medical devices under the EU MDR flow from general safety and performance requirements rather than from explicit cybersecurity provisions. Annex I Section 17.1 requires that devices incorporating electronic programmable systems be designed to ensure repeatability, reliability, and performance in line with intended use. 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), verification and validation.1Regulation (EU) 2017/745 (MDR), Annex I, Sections 17.1, 17.2, and 17.4. Section 17.4 requires manufacturers to set out minimum requirements concerning hardware, IT network characteristics, and IT security measures including protection against unauthorized access. These provisions establish cybersecurity as integral to software device compliance.
The MDCG has issued guidance specifically addressing cybersecurity for medical devices, providing interpretive clarity on MDR expectations.2MDCG 2019-16 Rev.1, Guidance on Cybersecurity for Medical Devices (Medical Device Coordination Group 2020). The guidance emphasizes that manufacturers must consider cybersecurity throughout the device lifecycle, from design through post-market surveillance. Risk management under ISO 14971 must incorporate cybersecurity risks alongside traditional safety risks. The guidance references harmonized standards and international frameworks without mandating specific technical approaches, providing flexibility while creating uncertainty about minimum acceptable practices. ENISA has supplemented these efforts with procurement guidance for healthcare cybersecurity, addressing the institutional dimension that MDCG guidance does not cover.3ENISA, Procurement Guidelines for Cybersecurity in Hospitals (February 2020); ENISA, Cloud Security for Healthcare Services (January 2021).
Swiss requirements under the Medizinprodukteverordnung (MepV; SR 812.213) incorporate corresponding cybersecurity expectations through alignment with MDR essential requirements. Swissmedic has not issued separate cybersecurity guidance, but expects manufacturers to demonstrate cybersecurity risk management consistent with international best practices. A cybersecurity approach satisfying MDR expectations should, in principle, satisfy Swiss requirements, but whether technical documentation submitted to Swissmedic adequately addresses cybersecurity considerations is a question that regulatory alignment alone does not resolve.
2. Which Adjacent Frameworks Apply Beyond the MDR?
The Swiss Informationssicherheitsgesetz (ISG; SR 128) introduces mandatory cyber incident reporting obligations that intersect with SaMD cybersecurity. Art. 74a ff. ISG, effective since 1 April 2025, require operators of critical infrastructure (including healthcare providers) to report cyberattacks to the Bundesamt für Cybersicherheit (BACS) within 24 hours.4Art. 74a ff. Bundesgesetz über die Informationssicherheit beim Bund (ISG; SR 128) (Meldepflicht für Cyberangriffe auf kritische Infrastrukturen), in force since 1 April 2025. For SaMD manufacturers whose products are deployed in Swiss healthcare settings, a vulnerability exploited in clinical environments may trigger ISG reporting obligations for the healthcare operator, and contractual notification obligations back to the manufacturer. The 24-hour ISG timeline creates pressure that parallels but does not align with MDR vigilance reporting timelines, EUDAMED incident notification, or Art. 23 NIS2 reporting in the EU. Whether the manufacturer's incident response procedures account for these concurrent notification channels, each with different triggers, recipients, content requirements, and deadlines, is a coordination challenge that intensifies with every additional jurisdiction in which the product is deployed.
The data protection dimension compounds the notification burden. A cybersecurity incident affecting SaMD that processes patient data may simultaneously trigger reporting obligations under Art. 24 of the Swiss Datenschutzgesetz (DSG), requiring notification to the EDÖB "as soon as possible," and, for EU-deployed products processing EU personal data, under Art. 33 GDPR, which imposes a 72-hour notification deadline to the relevant supervisory authority.5Art. 24 Bundesgesetz über den Datenschutz (DSG; SR 235.1); Art. 33 Regulation (EU) 2016/679 (GDPR). A single SaMD cybersecurity incident affecting patient data in a cross-border deployment may thus require concurrent notification to BACS (ISG, 24 hours), the EDÖB (DSG, "as soon as possible"), an EU supervisory authority (GDPR, 72 hours), the EU competent authority through the Authorized Representative (MDR vigilance), and potentially a CSIRT and ENISA (NIS2, 24 hours for early warning). Each notification channel has distinct content requirements, confidentiality constraints, and follow-up obligations. The multi-channel notification architecture is not a theoretical concern; it is the operational reality facing any Swiss SaMD manufacturer with EU market access whose product handles health data.
The US regulatory dimension warrants attention for Swiss SaMD manufacturers targeting global markets. Section 524B of the Federal Food, Drug, and Cosmetic Act, enacted through the Consolidated Appropriations Act 2023, codifies FDA cybersecurity expectations as statutory requirements rather than guidance recommendations.621 U.S.C. § 360n-2 (Section 524B FD&C Act); FDA, Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (September 2023). Premarket submissions must include a software bill of materials (SBOM), a plan for addressing post-market cybersecurity vulnerabilities, and evidence that the device can receive security patches. While the FDA framework focuses on premarket submission requirements rather than the MDR's lifecycle approach, manufacturers seeking both EU and US market access face the challenge of maintaining parallel cybersecurity documentation that satisfies structurally different regulatory expectations.
The May 2021 lapse of the mutual recognition agreement between Switzerland and the EU affects cybersecurity compliance architecture for Swiss manufacturers. As third-country manufacturers under MDR, Swiss-based SaMD companies must work through EU Authorized Representatives for EU market access, and cybersecurity incident response must account for this structure. When vulnerabilities require coordinated disclosure or security updates trigger vigilance reporting, communication flows must reach both EU competent authorities (through the AR) and Swissmedic simultaneously. Whether incident response procedures account for this dual-channel structure, and whether they have been tested against the time pressure of active vulnerability scenarios, may not have been examined before the first cross-border incident forces the question.
The NIS2 Directive adds an institutional dimension to SaMD cybersecurity. Healthcare entities operating SaMD (hospitals, diagnostic laboratories, digital health platforms) may qualify as essential or important entities under Art. 3 NIS2, subject to cybersecurity risk management obligations under Art. 21 and incident notification requirements under Art. 23.7Directive (EU) 2022/2555 [2022] OJ L333/80, Art. 3 (essential and important entities), Art. 21 (cybersecurity risk-management measures), Art. 23 (reporting obligations). These obligations flow upstream to SaMD manufacturers through supply chain security requirements: Art. 21(2)(d) NIS2 requires entities to address supply chain security, including security-related aspects concerning relationships with direct suppliers or service providers. Healthcare customers increasingly translate these obligations into contractual flowdown provisions requiring manufacturers to demonstrate vulnerability management practices, incident notification capabilities, and coordinated disclosure procedures. The cybersecurity requirements examined in Insight 19 in the context of connected medical devices apply with particular force to SaMD, where the software itself, rather than an embedded component, constitutes the entire device surface area.
The EU Cyber Resilience Act imposes cybersecurity obligations on products with digital elements, but medical devices regulated under MDR are excluded from its scope under Art. 2(2)(a).8Regulation (EU) 2024/2847 (CRA), Art. 2(2)(a), excluding products covered by MDR (n 1). This exclusion reflects the view that MDR already imposes cybersecurity requirements on medical devices. However, software components used alongside medical devices (companion apps, cloud services, data analytics platforms) may fall within CRA scope if they qualify as "products with digital elements" under the CRA and are not themselves classified as medical devices under MDR/IVDR. Boundary cases such as wellness apps with clinical data feeds can present classification ambiguity. Moreover, the exclusion depends on MDR cybersecurity requirements keeping pace with CRA standards.
In December 2025, the European Commission proposed amendments to both MDR and IVDR that would add explicit cybersecurity provisions to the general safety and performance requirements in Annex I and introduce mandatory reporting of actively exploited vulnerabilities and severe incidents to CSIRTs and ENISA through new reporting obligations (proposed Art. 87a MDR and Art. 82a IVDR).9COM(2025) 1023 final (16 December 2025). Rather than lifting the CRA's medical device exclusion, the proposal preserves that carve-out and addresses the resulting cybersecurity gap from within the device legislation itself: it envisions that compliance with the MDR/IVDR cybersecurity requirements, including incident reporting via EUDAMED, would satisfy the corresponding CRA obligations under the lex specialis principle, avoiding duplication. The practical implication is that voluntary alignment with the CRA's SBOM, vulnerability-handling, and security-support-period expectations is the more defensible posture: a manufacturer that meets the broader standard before it becomes mandatory will absorb the proposed Annex I provisions with less disruption than one treating the existing MDR baseline as sufficient.
A security patch that addresses a critical vulnerability may simultaneously constitute a significant change requiring fresh conformity assessment, transforming a days-long fix into a months-long regulatory process.
3. Why Is IEC 81001-5-1 Becoming the Benchmark?
IEC 81001-5-1 provides a normative framework for security activities throughout the health software product lifecycle, from concept through decommissioning.10IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle. The standard establishes process requirements for security risk management, security requirements specification, secure architecture design, secure implementation, security verification and validation, security release, and post-market security activities. Although the standard is not harmonized under MDR, notified bodies increasingly reference IEC 81001-5-1 as representing the state of the art for medical device software cybersecurity.
Security risk management under IEC 81001-5-1 complements but does not replace safety risk management under ISO 14971. The standard requires manufacturers to identify security risks (threats, vulnerabilities, and potential attack vectors) and evaluate their potential impact on device safety, effectiveness, and data security. Security risks that could affect patient safety must be addressed through the safety risk management process; security risks affecting data confidentiality or system availability may require separate treatment. The interplay between security and safety risk management demands coordination that neither discipline's frameworks fully address.
The standard addresses software bill of materials as a foundation for vulnerability management. The standard requires accurate inventories of third-party components, open-source libraries, and dependencies incorporated in the software, increasingly expressed in a machine-readable format such as SPDX or CycloneDX. This SBOM enables systematic vulnerability monitoring: when security researchers discover vulnerabilities in common components, manufacturers with accurate SBOMs can quickly determine whether their products are affected. The practical challenge lies in maintaining SBOM accuracy across complex software supply chains where dependencies may change with each build.
Secure development practices under IEC 81001-5-1 include requirements for threat modeling during design, secure coding practices during implementation, and security testing during verification. The standard does not prescribe specific techniques (recognizing that appropriate practices vary with software architecture, risk profile, and organizational capability) but requires manufacturers to document and justify their approach. Notified bodies reviewing conformity assessment submissions may request evidence that secure development practices were followed, including threat models, secure coding guidelines, and security test results.
4. When Do Vulnerability Disclosures Create Regulatory Conflict?
Vulnerability management intersects with the post-market surveillance obligations examined in Insight 12, but the intersection is not straightforward. Security vulnerability monitoring operates on different timelines, through different channels, and with different urgency than traditional post-market safety surveillance. The question of how these overlapping obligations interact, and whether a manufacturer's PMS system adequately addresses cybersecurity-specific monitoring, adds a coordination challenge that regulatory frameworks have not resolved.
Vulnerability discovery occurs through multiple channels: internal security testing, external security research, third-party component advisories, and coordinated vulnerability disclosure programs. Active monitoring of vulnerability databases (CVE, NVD, and vendor-specific advisories) for known vulnerabilities affecting SBOM components represents baseline practice. Whether passive monitoring suffices, or whether engagement with security research communities provides materially better early warning, depends on the product's threat profile and deployment context, questions that implicate both technical assessment and regulatory risk appetite.
Coordinated vulnerability disclosure presents particular challenges for medical device manufacturers. Security researchers who discover vulnerabilities expect timely acknowledgment, collaborative remediation, and eventual public disclosure that credits their work. Aligning the disclosure process to the recognized standards for the practice, ISO/IEC 29147 on vulnerability disclosure and ISO/IEC 30111 on vulnerability handling, gives manufacturers a defensible framework that notified bodies and security researchers both accept. Medical device regulatory frameworks require change impact assessment, potentially notified body consultation, and controlled update deployment. These timelines may conflict: the prevailing industry convention (popularized by Google Project Zero) expects disclosure within 90 days, while regulatory processes may require longer. The tension between these timelines (security researchers expecting weeks, regulatory processes potentially requiring months) creates disclosure challenges that standard IT security practices do not address and that no regulatory framework has fully resolved.
Severity assessment compounds the difficulty. Technical severity and clinical impact do not align. A vulnerability rated critical by CVSS scoring may have limited clinical relevance if the affected component is not exposed in typical deployments, while a moderate vulnerability affecting diagnostic algorithms could endanger patients. The gap between standardized technical metrics and actual clinical risk demands context-specific analysis that neither scoring system alone provides.
5. When Do Security Patches Require Notified Body Review?
Security updates and patches for SaMD must navigate the intersection of software engineering best practices and medical device regulatory requirements. Rapid deployment of security patches is standard practice in IT security; controlled change management with impact assessment is standard practice in medical device regulation. Reconciling these approaches requires change control procedures that enable timely security response within regulatory constraints.
Determining when security updates require notified body involvement depends on whether changes are "significant" under MDR. For devices with legacy MDD/AIMDD certificates operating under transitional provisions, MDCG 2020-3 provides a framework for assessing change significance.11MDCG 2020-3, Guidance on Significant Changes Regarding the Transitional Provision Under Art. 120 of MDR (applies to legacy devices under transitional provisions). For fully MDR-certified devices, the applicable framework is the manufacturer's change control procedures under its quality management system (Art. 10(9)–(10) MDR), the conformity assessment annex under which the device was certified, and the notified body's procedures for assessing whether changes require updated conformity assessment. In either case, changes affecting device safety or performance may be significant and require conformity assessment update; changes addressing cybersecurity vulnerabilities without affecting clinical functionality may be non-significant.
But cybersecurity changes often affect both: a patch that modifies authentication logic addresses a security vulnerability but may also affect system behavior in ways that could impact clinical use. Each security update requires classification against significance criteria, a determination whose outcome depends on the specific change, the device's conformity assessment pathway, and the notified body's expectations, which may not align with the manufacturer's own assessment.
Two contrasting cases illustrate where the line tends to fall. A patch that updates a vulnerable third-party library, a logging dependency or a transport-layer component, while leaving the device's clinical functionality, user interface, and intended purpose untouched, will ordinarily be non-significant and deployable through routine change control. A patch that hardens authentication by altering session handling or access-control logic sits closer to the threshold, because it can change how clinicians interact with the device or how it behaves at the point of care, and may therefore require conformity assessment. The difficulty is that a single advisory often demands both kinds of change at once, so each must be classified on its own facts rather than inferred from the security label. Pre-agreeing the significance criteria with the notified body, before an active vulnerability forces the question, is the practical safeguard.
Update deployment in healthcare environments presents practical challenges beyond regulatory classification. Healthcare organizations operate under constraints that may delay security updates: change control windows, system validation requirements, interoperability concerns, and clinical workflow impacts all affect update timing. Manufacturers cannot simply release patches and expect immediate deployment; they must work with healthcare customers to communicate urgency, provide deployment guidance, and accommodate operational constraints while maintaining pressure for timely remediation.
End-of-support planning deserves attention throughout the product lifecycle. Security support requires ongoing investment: vulnerability monitoring, patch development, testing, and deployment support consume resources indefinitely. The question of how long security support persists, and what obligations continue after declared end-of-support, intersects with regulatory lifecycle obligations in ways that standard software licensing models do not address. The Cyber Resilience Act introduces specific requirements for security support period disclosure,12CRA (n 8), Art. 13(8) and Art. 13(19); Annex I, Part II. formalizing expectations whose interaction with MDR post-market obligations remains undefined.
6. What Are the Strategic Consequences?
Security is cheaper built in than bolted on. That much is uncontroversial. But the practical question (how deeply to invest in secure architecture before market entry, versus addressing security iteratively through post-market updates) depends on the product's risk classification, the notified body's expectations, and the manufacturer's tolerance for the regulatory consequences of security-driven changes after certification. Secure design principles referenced in IEC 62443-4-113IEC 62443-4-1:2018, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements. (defense in depth, least privilege, secure defaults) are most effectively implemented at the architecture stage. Deferring security consideration until conformity assessment creates a tension between market timing and security posture that may not have a clean resolution.
Supply chain security presents a different order of difficulty. Third-party components and open-source libraries introduce risks that the manufacturer cannot fully control but remains responsible for. A single product may incorporate hundreds of dependencies, each with its own vulnerability profile, maintenance cadence, and end-of-life trajectory. The security posture of each dependency affects the security posture of the device,14NIST, 'CVE-2021-44228 Detail' (National Vulnerability Database, 10 December 2021). Log4Shell demonstrated how a single component vulnerability could affect thousands of products, including medical device software. but the depth of due diligence that is practically achievable, and the contractual provisions that component suppliers will accept, vary enormously across the software supply chain. Whether existing arrangements adequately address vulnerability notification obligations is a question many manufacturers have not asked.
Contractual cybersecurity obligations in SaMD supply chains deserve specific attention. Manufacturers distributing SaMD through healthcare IT integrators, cloud hosting providers, or platform operators face cybersecurity responsibilities that require explicit contractual allocation, yet standard software licensing terms rarely contemplate medical device-specific requirements. The intersection of supply chain cybersecurity with MDR post-market obligations, NIS2 flowdown requirements, and data protection notification duties creates contractual questions whose answers depend on the specific supply chain configuration, the product's risk profile, and the regulatory expectations applicable in each deployment jurisdiction. The difficulty intensifies when critical suppliers discontinue components or cease security support: whether existing contractual arrangements adequately address these contingencies, and whether they remain aligned with the manufacturer's ongoing regulatory obligations, are questions that retrospective negotiation under time pressure cannot resolve.
The revised Product Liability Directive (EU) 2024/2853 introduces a cybersecurity dimension to product liability that SaMD manufacturers must factor into strategic planning.15Directive (EU) 2024/2853 [2024] OJ L 2024/2853, Art. 7(2)(f) (product safety requirements including safety-relevant cybersecurity requirements), Art. 9 (disclosure of evidence). Under the revised PLD, a product may be deemed defective if it fails to provide cybersecurity updates that a person is entitled to expect, transforming the failure to patch known vulnerabilities from a regulatory compliance issue into a product liability exposure. The directive's disclosure-of-evidence provisions (Art. 9) may compel manufacturers to reveal vulnerability assessment records and patch decision timelines in litigation, creating a direct link between cybersecurity governance quality and litigation risk. This liability dimension reinforces the business case for security-by-design: the cost of proactive vulnerability management is measurable, while the cost of defending cybersecurity-based product liability claims is not.
Incident response exposes the gap between preparation and reality. When a security incident affects a medical device (vulnerability disclosure, active exploitation, data breach), the manufacturer responds under time pressure with potentially serious consequences for patient safety and regulatory standing.16MDCG 2023-3 Rev.1, Questions and Answers on Vigilance Terms and Concepts provides guidance on incident reporting for cybersecurity events affecting medical devices. The question is not whether an incident response plan exists. It is whether that plan has been tested against realistic scenarios involving simultaneous regulatory notification in multiple jurisdictions, coordinated disclosure with security researchers on incompatible timelines, and healthcare customers whose operational constraints prevent immediate remediation.
A further layer applies where the SaMD incorporates artificial intelligence. Software that qualifies as a high-risk AI system under the EU AI Act must satisfy the accuracy, robustness, and cybersecurity obligations of Art. 15, which require resilience against attempts to alter its use, behavior, or performance by exploiting system vulnerabilities.17Regulation (EU) 2024/1689 (AI Act), Art. 15 (accuracy, robustness and cybersecurity of high-risk AI systems). For an AI-enabled diagnostic or decision-support tool, these obligations operate alongside the MDR cybersecurity requirements examined here, and the two regimes must be reconciled rather than satisfied in isolation, a convergence examined in Insight 14 and Insight 24.
The regulatory landscape continues to evolve. Standards like IEC 81001-5-1 may gain harmonization status. The Commission's December 2025 proposal to amend MDR and IVDR, adding explicit cybersecurity provisions to Annex I and routing vulnerability and incident reporting to CSIRTs and ENISA while preserving the CRA's medical device exclusion, is under legislative consideration. Competent authorities may increase enforcement attention on cybersecurity deficiencies. Each of these developments would alter the compliance calculus, and a security program designed to satisfy today's baseline requirements may not survive tomorrow's expectations. The question is not whether cybersecurity requirements will intensify. It is whether the manufacturer's existing architecture, processes, and contractual arrangements are structured to absorb that intensification, or whether they will require fundamental revision under time pressure. That assessment depends on facts and circumstances that no general analysis can resolve.