Cybersecurity for SaMD: Meeting MDR and Beyond

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 a dedicated cybersecurity chapter. Annex I Section 17.1 MDR requires that devices incorporating electronic programmable systems be designed to ensure repeatability, reliability, and performance in line with intended use. Annex I Section 17.2 MDR 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. Annex I Section 17.4 MDR 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 on cybersecurity for medical devices, explaining how it reads the MDR's requirements.2MDCG 2019-16 Rev.1, Guidance on Cybersecurity for Medical Devices (Medical Device Coordination Group, July 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, so manufacturers may choose their methods but cannot tell what minimum a notified body will accept. ENISA has supplemented these efforts with procurement guidance for healthcare cybersecurity, addressing hospitals and other healthcare institutions, which the 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 the MDR's general safety and performance 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 hospitals on the cantonal hospital lists and licensed medical laboratories) to report cyberattacks to the Bundesamt für Cybersicherheit (BACS) within 24 hours.4Art. 74a ff. Bundesgesetz über die Informationssicherheit (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 manufacturer may also be under the duty in its own right. Art. 74b(1)(u) ISG applies it to manufacturers of hardware or software whose products are used by critical infrastructures, where the hardware or software has remote-maintenance access or is used to control and monitor operational systems and processes or to ensure public safety; such a manufacturer reports cyberattacks on its own IT resources (Art. 74a(1) ISG). 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.

Data protection law adds further notification duties. 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 (MDR vigilance), and potentially a CSIRT (Art. 23 NIS2, 24 hours for early warning). Each notification channel has distinct content requirements, confidentiality constraints, and follow-up obligations. For a Swiss SaMD manufacturer with EU market access whose product handles health data, these parallel channels are part of ordinary incident handling, even where some of the duties fall on its healthcare customers.

US Cybersecurity Requirements

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 for a cyber device must include a software bill of materials (SBOM), a plan for addressing post-market cybersecurity vulnerabilities, and processes that provide reasonable assurance of cybersecurity and make security updates and patches available. 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.

Swiss Manufacturers Without Mutual Recognition

The May 2021 lapse of mutual recognition between Switzerland and the EU for medical devices affects how Swiss manufacturers organize cybersecurity compliance. 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 (in coordination with 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.

NIS2 and Healthcare Customers

The NIS2 Directive reaches SaMD cybersecurity through the healthcare institutions that operate it. 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 NIS2 and incident notification requirements under Art. 23 NIS2.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. Cybersecurity requirements for connected medical devices bear most heavily on SaMD, where the software is the whole device rather than an embedded component.

The Cyber Resilience Act and Medical Devices

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) CRA.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 MDR and Annex I IVDR 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: manufacturers would report actively exploited vulnerabilities and severe incidents, as the CRA defines them, to the CSIRTs and ENISA through EUDAMED within 30 days of becoming aware of them, and vigilance reports that also qualify would be made available to those bodies at the same time. Whether voluntary alignment with the CRA's SBOM, vulnerability-handling, and security-support-period expectations would make the proposed Annex I provisions easier to absorb is a question the proposal leaves open.

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 overlaps with the obligations set out in the analysis of post-market surveillance for SaMD, but the overlap 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 such database 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. ISO/IEC 29147 on vulnerability disclosure and ISO/IEC 30111 on vulnerability handling are the recognized standards for the practice. 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 disclosure within about 90 days, regulatory processes potentially requiring longer) creates disclosure challenges that standard IT security practices do not address and that no regulatory framework has fully resolved.

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. Judging the clinical risk therefore takes an analysis of the specific context, which no technical score supplies on its own.

5. When Do Security Patches Require Notified Body Review?

Security updates and patches for SaMD must meet both software engineering best practice 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 Rev.1, Guidance on Significant Changes Regarding the Transitional Provision Under Article 120 of the MDR with Regard to Devices Covered by Certificates According to MDD or AIMDD (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) 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. A single advisory often calls for both kinds of change at once, and each must then be classified on its own facts rather than by its security label.

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. Strategic Considerations for SaMD Manufacturers

Security is cheaper built in than bolted on. That much is uncontroversial. But how much to build security into the design before market entry, rather than adding it piece by piece 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 best implemented at the design 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. When suppliers the device depends on discontinue components or end security support, renegotiating after the event and under time pressure cannot settle whether existing contracts cover it or still match the manufacturer's ongoing regulatory obligations.

The revised Product Liability Directive (EU) 2024/2853 brings cybersecurity into product liability, and SaMD manufacturers must plan for it.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, so a failure to patch known vulnerabilities can lead to product liability as well as a compliance problem. The directive's disclosure-of-evidence provisions (Art. 9 PLD) 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. The prospect of such claims strengthens 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.2, Questions and Answers on Vigilance Terms and Concepts as Outlined in the Regulation (EU) 2017/745 and Regulation (EU) 2017/746, which lists a cyberattack related to life-supporting or life-saving devices among its examples of a serious public health threat. An incident response plan helps only if it 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.

SaMD that incorporates artificial intelligence and qualifies as a high-risk AI system under the EU AI Act must also satisfy the accuracy, robustness, and cybersecurity obligations of Art. 15 AI Act, 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 apply alongside the MDR cybersecurity requirements discussed here, and the two regimes must be reconciled rather than satisfied in isolation; the analysis of AI-enabled medical devices under the MDR and the AI Act covers how they meet.

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. Cybersecurity requirements will tighten. Whether the manufacturer's existing systems, processes, and contractual arrangements can absorb that, or will need fundamental revision under time pressure, depends on facts and circumstances that no general analysis can resolve.