US developers of AI-enabled devices arrive in Europe with a cybersecurity file already built. That file rests on section 524B of the FD&C Act for cyber devices, on the FDA's premarket cybersecurity guidance in its February 2026 revision and, for the model itself, on the threat vocabulary of the FDA's January 2025 draft guidance on AI-enabled device software functions, with its data poisoning, model inversion and model evasion.1FD&C Act § 524B; FDA cybersecurity guidance (3 February 2026); FDA draft AI guidance (7 January 2025). The instinct that travels with that file is that Europe asks the same question in a different dialect. It does not. The EU asks it twice, in two instruments that protect different objects with different tools. Switzerland, which sits outside the EU regulatory perimeter, asks it a third time and attaches a reporting clock of its own. A file that satisfies one of those questions can fail the other two without a single fact about the device changing.
1. The Two Compliance Perimeters and Where They Fail to Meet
The MDR's cybersecurity duty is short, and it is not addressed to the model. Section 17.2 of Annex I MDR requires that software be developed and manufactured in accordance with the state of the art, taking into account the principles of development life cycle, risk management, including information security, verification and validation. Section 17.4 of Annex I MDR requires the manufacturer to set out minimum requirements concerning hardware, IT networks characteristics and IT security measures, including protection against unauthorized access, necessary to run the software as intended. Section 23.4(ab) of Annex I MDR carries those minimum requirements into the instructions for use.2Regulation (EU) 2017/745 (MDR), Annex I, sections 17.1 to 17.4 and 23.4(ab); Art. 8; Art. 113. The object of protection is the device and its performance, and the perimeter is the device in its IT environment. The manufacturer's task is to specify what that environment must look like and to build a product that does not depend on it. MDCG 2019-16 Rev.1, the Medical Device Coordination Group's cybersecurity guidance of July 2020, follows that shape. Its elements are defense in depth, a security risk process running alongside safety risk management, and a joint responsibility, the guidance's own preferred term, shared among manufacturer, integrator, operator and user, with the operator expected to keep the environment secure and to install the patches the manufacturer prescribes.3MDCG 2019-16 Rev.1 (July 2020), section 2.6 on joint responsibility. It is a document about networks, access and updates. It was written four years before the AI Act existed, for a device whose logic is fixed at release.
What the MDR does not supply is a yardstick. Art. 8 MDR gives a presumption of conformity to devices that follow harmonized standards cited in the Official Journal. The standard the market treats as the reference for health-software security, EN IEC 81001-5-1:2022, sits in the Commission's standardization request to CEN and CENELEC with a deadline for adoption of 27 May 2028. As of publication its reference had not been published under the MDR. The ten amending decisions to the MDR harmonized-standards list through June 2026 cover gloves, sterilization, biological evaluation, risk management, implants and connectors, and none adds the security life-cycle standard.4Standardisation request M/575; Implementing Decision (EU) 2021/1182 and its amendments, none citing EN IEC 81001-5-1:2022. A manufacturer that follows the standard earns no presumption. A notified body that expects it is applying the state of the art rather than a cited standard, which is a different argument when a certificate is refused.
The AI Act's cybersecurity duty is addressed to something the MDR does not see. For an AI system that is a medical device, or a safety component of one, whose device requires notified-body assessment, Art. 6(1) and Annex I AI Act make the system high-risk. Art. 15(1) AI Act then requires that it achieve an appropriate level of accuracy, robustness and cybersecurity and that it perform consistently in those respects throughout its lifecycle. Art. 15(5) AI Act spells out what that means. The system must be resilient against attempts by unauthorized third parties to alter its use, outputs or performance by exploiting system vulnerabilities, with technical solutions that include, where appropriate, measures to prevent, detect, respond to, resolve and control for attacks that manipulate the training data set (data poisoning) or pre-trained components used in training (model poisoning), inputs designed to cause the model to make a mistake (adversarial examples or model evasion), confidentiality attacks or model flaws.5Regulation (EU) 2024/1689 (AI Act), Art. 6(1), Art. 9(2), Art. 13(3), Art. 15, Annex IV. The perimeter has moved. A poisoned training set alters a device's output without anyone gaining unauthorized access to the device. To the network and the access-control layer the MDR file describes, an adversarial input is an ordinary input. The attack surface the AI Act names is the model and the pipeline that produced it. The interests it protects under Art. 9(2)(a) AI Act are health, safety and fundamental rights, and no MDR risk file was ever asked to weigh the last of these.
The two perimeters could have been joined by a third instrument, and for medical devices they are not. Under Art. 12(1) of the Cyber Resilience Act (CRA), a high-risk AI system that meets the CRA's essential cybersecurity requirements, for the product and for the manufacturer's processes, and says so in its CRA declaration of conformity, is deemed to comply with the cybersecurity requirements of Art. 15 AI Act. The provision is a bridge, built so that product manufacturers would not have to derive the AI Act's security standard from first principles. Art. 2(2)(a) CRA then excludes from the CRA every product to which the MDR applies.6Regulation (EU) 2024/2847 (CRA), Art. 2(2)(a) and Art. 12(1). The joint FAQ of the MDCG and the European Artificial Intelligence Board, issued in June 2025, records the consequence in a single note. Medical devices are out of the CRA's scope.7AIB 2025-1 / MDCG 2025-6 (19 June 2025), Q22; not legally binding. For an AI-enabled medical device, the only EU instrument that translates Art. 15 AI Act into product-level cybersecurity requirements is closed, and the MDR text says nothing about poisoned data or evasion. The gap between the two regimes sits exactly where the model does.
The regime that names the attacks on a learning model is the one whose product-level cybersecurity bridge is closed to medical devices, while the regime that governs the device says nothing about the model.
The joint FAQ does what guidance can. It reads Art. 15 AI Act into the device file and expects manufacturers of high-risk medical AI to secure AI-specific assets such as training data sets and the trained model, to prevent data and model poisoning, and to treat cybersecurity as part of the risk management system and the quality management system, and therefore as subject to conformity assessment.7 That reading is not binding, as the document itself says, and it does not create the standard it presupposes. Whether a penetration test and a patch policy count as evidence of resilience against model evasion is left to the manufacturer's own risk assessment, which is to say it is left open.
2. Where the AI Act's Security Duty Bites Harder Than the MDR's
The FDA's cyber-device concept is gated on connectivity. Section 524B(c) of the FD&C Act reaches a device that includes software, has the ability to connect to the internet and carries characteristics that could be vulnerable to cybersecurity threats.1 Art. 15(5) AI Act has no such gate. It attaches to the high-risk AI system as such. A diagnostic model that never leaves an isolated workstation must still be resilient against manipulation of its training data, because the attack the provision names happens before the device is switched on. The FDA's January 2025 draft lists data poisoning, model inversion, model evasion and performance drift among the threats a submission should address. The AI Act writes a comparable list into the statute, then qualifies it twice, with "where appropriate" and with a requirement that the technical solutions be appropriate to the circumstances and the risks.5 The qualifiers do not soften the duty. They relocate the judgment about what the duty requires from the text to whoever assesses conformity.
The duty also runs longer than the MDR's. Art. 15(1) AI Act asks for consistent performance throughout the lifecycle. Art. 15(4) AI Act requires a system that continues to learn after being placed on the market to be built so as to eliminate or reduce as far as possible the risk of possibly biased outputs feeding back into future operations. Art. 9(2)(c) AI Act folds post-market monitoring data back into the risk process, and Annex IV AI Act requires the technical documentation to describe the cybersecurity measures put in place, next to the validation and testing procedures and the metrics used to measure accuracy and robustness.5 Art. 13(3)(b)(iii) AI Act then requires the instructions to deployers to state any known or foreseeable circumstance, under intended use or reasonably foreseeable misuse, that may lead to risks to health, safety or fundamental rights. Where section 23.4(ab) of Annex I MDR asks for minimum IT requirements, the AI Act's instructions ask what could be done to the model and how the deployer would notice.
None of this comes with a harmonized standard. The Commission's standardization request of 23 June 2025 asked CEN and CENELEC to deliver harmonized standards on cybersecurity specifications for AI systems, among the other deliverables it requested, by 31 August 2025. As of publication no harmonized standard supporting Art. 15 AI Act had been cited in the Official Journal. The Commission's own account expected the first deliverables from the standardization bodies in the course of 2026, with citation to follow a substantive review.8Commission Implementing Decision C(2025) 3871 (23 June 2025); no harmonized standard cited as of publication. Art. 17(1)(e) AI Act anticipates the gap. Where harmonized standards are not applied in full or do not cover a requirement, the quality management system must record the means used to ensure compliance. For cybersecurity that means every provider of a high-risk medical AI must construct its own account of what resilience against model evasion looks like and defend it before a body that has no cited standard to measure it against either. Common specifications under Art. 41 AI Act remain a fallback where standards are late. Whether that route is taken for cybersecurity, and when, was open at publication.
The consequences are structured differently as well. The MDR leaves penalties to the Member States under Art. 113 MDR, so an MDR cybersecurity failure is punished, if at all, under national law and through the certificate. The AI Act carries its own scale. Under Art. 99(4)(a) AI Act, a provider that breaches its obligations under Art. 16 AI Act, the first of which is compliance with the requirements that include Art. 15 AI Act, faces administrative fines of up to EUR 15 million or 3 % of total worldwide annual turnover, whichever is higher. Art. 99(4)(b) AI Act applies the same scale to the authorized representative. Art. 44(3) AI Act separately obliges a notified body that finds a system no longer meets the requirements to suspend, withdraw or restrict the certificate, taking account of proportionality, unless corrective action is taken within the deadline the body sets.9AI Act (n 5), Art. 99(4), Art. 16(a), Art. 17(1)(e), Art. 44(3); MDR (n 2), Art. 113. A vulnerability discovered after placement on the market therefore has an AI Act price and an MDR price, and the AI Act's is computed on group turnover.
The timing, and possibly the scope, were rewritten in the weeks before publication. The Digital Omnibus on AI, proposed on 19 November 2025, was adopted by the Council on 29 June 2026 and signed on 8 July 2026. At publication the Official Journal had yet to carry it. As adopted, it moves the application date for Annex I high-risk systems, the route a regulated medical device travels, from 2 August 2027 to 2 August 2028. It also inserts a new Art. 2(13) AI Act, under which the requirements of Art. 9 to Art. 15 and Art. 17 to Art. 25 AI Act may be limited for Art. 6(1) AI Act systems where and to the extent that the Annex I product legislation provides an equivalent or higher level of protection. The specifying delegated acts are due by 2 August 2027.10Digital Omnibus on AI, COM(2025) 836, adopted 29 June 2026: Art. 113, Art. 2(13), Art. 111(2) and Art. 6(1a) to (1c) AI Act as amended. Whether a delegated act will treat sections 17.2 and 17.4 of Annex I MDR as equivalent to Art. 15(5) AI Act is the open question that sits under everything above. The MDR text does not mention the attacks Art. 15(5) AI Act names, and the joint FAQ reads the AI Act's list into the MDR file rather than the other way round. The delegated act had not been drafted at publication, however, and a compliance program built for 2028 may be building to a requirement that a 2027 delegated act narrows, or leaves entirely in place.
3. Switzerland's Position: MepV, ISG and the Absent AI Act
Switzerland is not an EU Member State, and neither the MDR nor the AI Act has direct effect there. The Swiss device regime, the MepV, incorporates the EU text rather than restating it. Art. 6(2) MepV requires every device to meet the general safety and performance requirements of Annex I of the EU-MDR, so sections 17.2, 17.4 and 23.4(ab) bind a manufacturer for the Swiss market word for word. Art. 6(4) MepV attaches a presumption of conformity to the technical standards Swissmedic designates.11Medizinprodukteverordnung (MepV) (SR 812.213), Art. 6, Art. 25(4), Art. 51, Art. 66. Swissmedic's information sheet on medical device software, in its April 2026 version, points manufacturers to MDCG 2019-16 for cybersecurity and says nothing about artificial intelligence.12Swissmedic, 'Merkblatt Medizinprodukte-Software' (Version 3.0, 21. April 2026). On the device layer, then, Switzerland is the MDR without the AI Act, and for a US reader the second half of that sentence matters more. A Swiss market entry tests nothing that Art. 15 AI Act will test in the EU.
There is no Swiss AI Act, and none is scheduled. On 12 February 2025 the Federal Council chose sector-specific amendments over a horizontal statute, committed to ratifying the Council of Europe's framework convention on artificial intelligence, which Switzerland signed on 27 March 2025, and ordered a consultation draft by the end of 2026. Nothing in that decision touches the MepV, and healthcare is named only as a sector in which regulatory work continues, a course examined in Insight 61.13Federal Council decision of 12 February 2025; Council of Europe AI convention, signed for Switzerland 27 March 2025. What does reach a Swiss AI-enabled device is the DSG, which the EDÖB declared directly applicable to AI-supported processing in November 2023. Health data are besonders schützenswerte Personendaten under Art. 5 lit. c DSG, and Art. 8 DSG requires data security appropriate to the risk. Art. 24 DSG requires a breach that is likely to result in a high risk for the data subject to be reported to the EDÖB as quickly as possible.14Datenschutzgesetz (DSG) (SR 235.1), Art. 5 lit. c, Art. 8, Art. 24; EDÖB statement of 9 November 2023. A poisoning attack on a model trained on Swiss patient data is, on the Swiss side, a data-security event before it is a device event.
The Swiss layer that has no EU or US counterpart in this form is the ISG. Since 1 April 2025, Art. 74b(1) ISG has listed the authorities and organizations that must report cyberattacks to the BACS, and two of its letters reach an AI-enabled device from both ends. Letter f covers hospitals on the cantonal hospital lists under the KVG. Letter u covers manufacturers of hardware or software whose products are used by critical infrastructures, where the product has a remote-maintenance access or serves the control and monitoring of operational systems and processes or the safeguarding of public safety, with no requirement that the manufacturer have a seat in Switzerland. Art. 74b(3) ISG applies the duty to attacks with effects in Switzerland even where the affected IT systems are abroad. The report is due within 24 hours of discovery under Art. 74e(1) ISG. The triggers in Art. 74d ISG include an attack that led to manipulation or leakage of information or that remained undetected over a longer period, and the size exemptions in Art. 12 CSV contain none for letter u manufacturers. Since 1 October 2025, willful non-compliance with a final BACS order that carries the penal warning is punishable under Art. 74h ISG with a fine of up to CHF 100,000.15Informationssicherheitsgesetz (ISG) (SR 128), Art. 74b, 74d, 74e, 74h; Cybersicherheitsverordnung (CSV) (SR 128.51), Art. 12, Art. 14. The reach of letter u toward a US group with no Swiss entity is examined in Insight 58. The point here is narrower. A connected AI device in a Swiss hospital puts the manufacturer, not only the hospital, on a 24-hour clock that neither the MDR's vigilance system nor the AI Act's serious-incident regime runs.
The clocks then multiply. The same exploited vulnerability may be a schwerwiegendes Vorkommnis occurring in Switzerland, to be reported to Swissmedic under Art. 66 MepV, a duty the Swiss authorized representative carries under Art. 66(2bis) MepV where one is required. It may be a serious incident under Art. 87 MDR for the EU market, and it may call for an Art. 24 DSG notification, which the CSV itself uses as one of the circumstances that make an attack reportable to the BACS. On the AI Act side it may be nothing at all unless the incident infringes obligations under Union law intended to protect fundamental rights, because Art. 73(10) AI Act limits serious-incident reporting for MDR devices to that single category.16AI Act (n 5), Art. 2(1)(a), Art. 22, Art. 73(10); MDR (n 2), Art. 11, Art. 87. Four authorities, four definitions of the event and four moments from which time runs, none coordinated with the others.
Third-country status compounds it. A Swiss manufacturer has been a third-country manufacturer under the MDR since the medical-devices chapter of the Swiss-EU mutual recognition agreement stopped delivering mutual recognition on 26 May 2021. It needs an authorized representative under Art. 11 MDR, who is liable for defective devices on the same basis as, and jointly and severally with, the manufacturer under Art. 11(5) MDR. Under the AI Act the same manufacturer is a provider established in a third country and must, under Art. 22 AI Act, appoint by written mandate an authorized representative established in the Union. That representative's tasks include verifying that the EU declaration of conformity and the technical documentation have been drawn up and that an appropriate conformity assessment procedure has been carried out, and keeping the documentation at the disposal of the authorities for ten years.16 The result is two mandates, with different tasks and different liability, that may or may not sit with the same entity. The protocols to the mutual recognition agreement signed on 2 March 2026 do not, on their own terms, restore the devices chapter, a matter Insight 53 takes up.17Swiss-EU MRA (SR 0.946.526.81), Annex 1, ch 4; protocols signed 2 March 2026; Botschaft of 13 March 2026. In the opposite direction the border is porous. Art. 25(4) MepV treats certificates from EU-designated notified bodies as equivalent to Swiss ones where the procedure applied and the body's qualification can credibly be shown to match the Swiss requirements. In practice the EU body's verdict on the AI Act layer is therefore also the verdict Switzerland receives, from a body Swissmedic did not designate.11
4. Conformity Assessment Under Two Regimes at Once
Art. 43(3) AI Act folds the AI Act's requirements into the MDR conformity assessment. The provider follows the MDR procedure, the requirements of Section 2 of Chapter III AI Act apply and form part of that assessment, and an MDR notified body may control them provided its compliance with the AI Act's notified-body criteria in Art. 31(4), (5), (10) and (11) AI Act was assessed in the notification procedure.18AI Act (n 5), Art. 43(3) and (4), Art. 3(23), Art. 8(2), Art. 25(3) and (4); MDR (n 2), Annex II 6.1(b), Annex IX 4.10. The general shape of that single assessment, and the capacity question behind it, are examined in Insight 51. For cybersecurity the narrower point is what evidence the one assessor will read. An MDR technical file carries software verification and validation under section 6.1(b) of Annex II MDR, a description of the design and development process and evidence of validation in the finished device. An AI Act file carries, under Annex IV AI Act, the cybersecurity measures put in place, the validation and testing data and their characteristics, and the metrics used to measure robustness. Art. 8(2) AI Act lets the provider integrate the second into the first. Integration is a choice about where the evidence sits, not about what evidence exists. A file that documents penetration testing of the device's interfaces without documenting how the training pipeline was protected against poisoning is complete under one regime and silent under the other.
The assessor's competence is the second variable. The joint FAQ expects cybersecurity to be part of the risk management system and the quality management system and therefore subject to conformity assessment.7 The body assessing an adversarial-robustness argument, however, is a medical-device body whose AI Act competence, if assessed at all, was assessed inside the MDR notification procedure. For a Swiss manufacturer the choice of that body is also the choice of the body whose certificate Switzerland accepts under Art. 25(4) MepV. Whether a body designated for the device type, competent in the technology and assessed for the AI Act layer will exist when it is needed is a question the regulation does not answer and the standardization calendar makes harder.
Change control is where the two regimes disagree most visibly. Under Art. 43(4) AI Act a substantial modification requires a new conformity assessment, unless, for a system that continues to learn after being placed on the market, the change was pre-determined at the initial assessment and described in the technical documentation under point 2(f) of Annex IV AI Act. Art. 3(23) AI Act defines the term autonomously, as a change not foreseen or planned in the initial conformity assessment that affects compliance with the Section 2 requirements or modifies the intended purpose. The joint FAQ confirms that the concept is autonomous and not aligned with the MDR's own test, under which section 4.10 of Annex IX MDR requires the notified body's approval for changes that could affect safety and performance or the conditions prescribed for use.18 A model retrained to close a poisoning vulnerability affects compliance with Art. 15 AI Act by construction. Whether it also affects safety and performance under the MDR is a separate question with a separate answer. The MDR side of that dilemma, the security patch that becomes a significant change, is examined in Insight 18. The AI Act adds a second test to the same patch.
The timing rule adds a third. Art. 111(2) AI Act, as amended by the Digital Omnibus on AI, applies the regulation to high-risk systems placed on the market before the Chapter III application date, 2 August 2028 for the device route, only if they are subject to significant changes in their designs from that date. The joint FAQ's Question 31 still reasons from the 2 August 2027 date the AI Act carried when the FAQ was written, so the guidance and the amending act point at different years.19Digital Omnibus on AI (n 10), Art. 111(2) AI Act as amended; AIB 2025-1 / MDCG 2025-6 (n 7), Q29 to Q31. Whether a retrained model, a new feature-extraction layer or a security update is a significant change in design decides whether a device certified in 2027 enters the AI Act at all. The regulation does not define the phrase.
Finally, the model rarely belongs entirely to the manufacturer. Art. 25(3) AI Act makes the product manufacturer the provider where the safety-component AI system is placed on the market together with the product under the manufacturer's name. Art. 25(4) AI Act requires a written agreement with any third party supplying an AI system, tools, services, components or processes, free and open-source tools aside (a carve-out that does not reach general-purpose AI models). The agreement must specify the information, capabilities, technical access and other assistance, based on the generally acknowledged state of the art, that the provider needs for compliance.18 A licensed foundation model, a contract-developed classifier and a pre-trained component bought from a US parent all fall within that provision. The assistance the provider needs for Art. 15(5) AI Act, evidence about training data and pre-trained components that could have been poisoned, is precisely what a licensor is least willing to hand over.
5. Strategic Considerations
The questions that decide exposure here are not the ones a cybersecurity program is built to answer. Whether the device's AI is a safety component or is the device, and whether the notified body's involvement satisfies Art. 6(1) AI Act, determines whether Art. 15 AI Act applies at all. The Digital Omnibus on AI narrows the safety-component definition, excluding systems used solely for non-safety-related assistance, optimization or quality control unless their failure would endanger health and safety, and that narrowing moves the line for devices that were confidently on one side of it.10 Which entity in the group is the provider, the Swiss subsidiary that places the device on the market or the US parent that trained the model, determines who must hold the Art. 25(4) AI Act agreement and whose turnover the fine is computed on. And whether the group has a Swiss seat, or merely a device with a remote-maintenance link into a Swiss hospital, determines whether a 24-hour BACS clock runs beside the Swissmedic, EDÖB and EU vigilance clocks.
Behind those sit questions that depend on facts only the company holds. What the notified body was told at the initial assessment about pre-determined changes decides whether a security retraining is a substantial modification or an anticipated one. That record was written by a regulatory team that may never have been asked about adversarial robustness. What the model license says about training-data provenance decides whether the Art. 15(5) AI Act evidence can be assembled at all. What the incident-response plan treats as discovery decides which of four clocks starts first, and whether a report to one authority shows, by its timing, that a report to another was late.
For a US-listed parent the feedback loop is concrete. A certificate suspended under Art. 44(3) AI Act or an administrative fine computed on group turnover is a candidate for risk-factor disclosure and for a Board's review of its D&O coverage. A BACS order against a Swiss subsidiary is the kind of foreign administrative action that standard US policies sub-limit. None of that appears in a section 524B file.
Whether a given device sits on the right side of each of these lines depends on the intended purpose as written, the notified body's designation, the contracts around the model and the group's Swiss footprint. Those are questions of fact and of drafting, and they require analysis tailored to the device, the entities involved and the commercial context.