Cyber Resilience Act Reporting: The 24-Hour Early Warning Duty for US and Swiss Manufacturers

The EU reporting duty uses a concept familiar from US vulnerability management. CISA requires reliable evidence of active exploitation in the wild, an assigned CVE identifier and clear remediation action for inclusion in its Known Exploited Vulnerabilities catalog. Covered Federal Civilian Executive Branch agencies must address catalog vulnerabilities under CISA's remediation requirements.1Cybersecurity and Infrastructure Security Agency (CISA), “Reducing the Significant Risk of Known Exploited Vulnerabilities”, criteria 1–3 for the Known Exploited Vulnerabilities (KEV) catalog: an assigned CVE identifier, reliable evidence of active exploitation in the wild and clear remediation action. Criterion 2 expressly includes attempted exploitation, including honeypot activity. CISA, Binding Operational Directive 26-04, “Prioritizing Security Updates Based on Risk” (10 June 2026), Scope, Required Actions and Appendix A. It applies to covered Federal Civilian Executive Branch systems, with the stated statutory exclusions; contractor application depends on the governing procurement contract. It revokes BOD 19-02 and BOD 22-01, retains the KEV criteria and phases its requirements. Remediation may include patching, decommissioning or another action that eliminates the vulnerability. For medical devices, federal law requires the sponsor of a covered premarket application or submission for a cyber device to provide the FDA with a plan to monitor, identify and address postmarket cybersecurity vulnerabilities and exploits.221 U.S.C. § 360n-2, section 524B of the Federal Food, Drug, and Cosmetic Act (“Ensuring cybersecurity of devices”), added by Pub. L. 117-328, div. FF, title III, § 3305(a), 136 Stat. 5832 (29 December 2022); effective 90 days after enactment under § 3305(d) of Pub. L. 117-328. 21 U.S.C. § 360n-2(a) identifies the covered premarket applications and submissions; 21 U.S.C. § 360n-2(b)(1) requires a plan to monitor, identify and address postmarket vulnerabilities and exploits, as appropriate and in a reasonable time, including coordinated vulnerability disclosure and related procedures. 21 U.S.C. § 360n-2(b)(2) addresses processes, updates and patches; 21 U.S.C. § 360n-2(c) defines a cyber device and 21 U.S.C. § 360n-2(d) provides for exemptions. This comparison does not displace other FDA reporting duties. Neither of these provisions, by itself, creates a general manufacturer duty to report exploitation to a government response team within a day. Other US reporting obligations remain separate. The EU Cyber Resilience Act (CRA) imposes the manufacturer reporting duty discussed here. Since 11 September 2026, Art. 14 CRA has required manufacturers of in-scope products with digital elements made available on the EU market to give an early warning without undue delay and within 24 hours of awareness of an actively exploited vulnerability or a severe incident, to a national CSIRT and to ENISA at the same time, through a single reporting platform that ENISA brought into initial operation the same day.3Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) [2024] OJ L 2024/2847, Art. 2, Art. 3(42), Art. 14, Art. 69(3) and Art. 71(2) CRA (scope, triggers, clocks and phase-in); Art. 64(10) CRA corrected by [2025] OJ L 2025/90555 (2 July 2025).4European Union Agency for Cybersecurity (ENISA), 'The CRA Single Reporting Platform is launched' (Press release, 11 September 2026), announcing initial operating capability. The CRA uses closely comparable language to CISA's definition, but attaches its own reporting duty. For a US or Swiss manufacturer without an EU office, identifying the receiving CSIRT is part of that duty.

1. What Starts the 24-Hour Clock: Exploitation, Severity and Awareness

Two events trigger the duty, neither of which depends on a personal data breach; the same event can nevertheless engage both reporting regimes. The first is an actively exploited vulnerability, which Art. 3(42) CRA defines as a vulnerability “for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”. The second is a severe incident having an impact on the security of the product. Art. 14(5) CRA treats such an incident as severe where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code in the product or in a user's network and information systems.3 Recital 68 CRA gives as its example of a severe incident an attacker who introduces malicious code into the channel through which the manufacturer releases security updates to users, and takes vulnerabilities discovered without malicious intent in good-faith testing, investigation, correction or disclosure out of the mandatory track. Neither CRA trigger requires a personal-data breach or securities materiality. Those regimes ask different questions and may apply to the same event. CISA expressly includes attempted exploitation, including honeypot activity, in its catalog criteria. The CRA instead supplies its own statutory definition; a catalog classification does not replace that legal assessment.1

What follows is a sequence rather than a single report. For an actively exploited vulnerability, Art. 14(2) CRA requires an early warning without undue delay and in any event within 24 hours of becoming aware, naming where known the Member States in which the product has been made available. Unless the relevant information has already been provided, a vulnerability notification is due without undue delay and in any event within 72 hours of the same awareness, with general information on the product, the nature of the exploit and of the vulnerability, the corrective or mitigating measures taken and those users can take, and an indication of how sensitive the manufacturer considers the information to be. A final report is due no later than 14 days after a corrective or mitigating measure is available, unless the relevant information has already been provided. Art. 14(4) CRA runs the same awareness-based, without-undue-delay 24-hour and 72-hour stages for a severe incident, with an early warning that states whether unlawful or malicious acts are suspected, but ends in a final report within one month after submission of the incident notification, unless the relevant information has already been provided. The coordinating CSIRT may ask for an intermediate report where necessary under Art. 14(6) CRA. Art. 14(8) CRA separately requires timely information to impacted users, and where appropriate all users; if the manufacturer fails to inform them in a timely manner, a recipient CSIRT may do so where proportionate and necessary to prevent or mitigate the impact. From 11 December 2027, Art. 64(2) CRA places infringements of Art. 14 CRA in the top penalty tier: up to EUR 15 million or, for an undertaking, 2.5% of its total worldwide annual turnover in the preceding financial year, whichever is higher. That CRA penalty regime is not yet applicable on 1 October 2026.3

The Installed Base, the Unsupported Product and the Component

The duty is not confined to products placed on the market under the new regime. Art. 69(3) CRA applies Art. 14 CRA to every in-scope product placed on the market before 11 December 2027, the date from which the Regulation as a whole applies, so a router, a firmware image or a software package sold in 2019 is reportable if, from 11 September 2026, the manufacturer becomes aware that it is being exploited.3 The draft guidance whose content the Commission approved in July 2026 explains the support-period consequence. Because the reporting duty is not tied to the support period, it continues after a product is no longer supported, even though the vulnerability-handling requirements of Annex I, Part II CRA do not.5European Commission, 'Approval of the content of the draft Communication from the Commission: Commission guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act)' C(2026) 5252 final (27 July 2026), cover (content approval, with formal adoption to follow); Annex, Section 9.1, paras 209 to 221 (reporting interpretation). The same guidance limits the retroactive reach: a manufacturer need not report a vulnerability whose exploitation it already knew of before 11 September 2026, but a vulnerability it knew of before that date and first learns is being exploited afterwards is reportable. The Commission's FAQ adds that a manufacturer may be unable to investigate a vulnerability in an old product, because the tooling, the build environment or the staff who knew the code may be gone, and that the duty to notify stands regardless.6European Commission, 'FAQs on the Cyber Resilience Act' (Version 1.4, 4 September 2026), entries 5.1 to 5.4 (awareness, exploitation, legacy products and integrated components); Commission-services explanations, not an authoritative statement extending legal duties.

Everything turns on awareness, and the Regulation does not define it. The guidance reads it as the moment when, after an initial assessment of a suspicious event, the manufacturer has “a reasonable degree of certainty” that a vulnerability in its product is being actively exploited or that a severe incident has compromised the product's security, and it says it aligned that reading with the implementing rules under NIS2 and with the European Data Protection Board's approach to personal data breach notification. It also insists that the initial assessment be carried out promptly.5 The FAQ lists the channels through which awareness can arrive, from a customer's report and a researcher's publication to the manufacturer's own telemetry, honeypots and monitoring of dark web forums, while stating that the CRA does not require the manufacturer to operate any of them.6 The formula leaves the hard cases where they were. Whether one credible report from one customer is reliable evidence, whether an exploit seen in a third party's honeypot is exploitation of this manufacturer's product, and when a group whose security operations center sits in the United States became aware for the purposes of a European clock are questions the guidance frames without deciding. These are interpretive explanations rather than additional statutory conditions. The Commission's 27 July 2026 cover document approves the content of draft guidance and says formal adoption and application will follow when all language versions are available; the September FAQ describes the guidance as adopted. The July text is used here for its stated interpretation, without treating either publication as an amendment to the CRA.

Components multiply the reports. Where an actively exploited vulnerability originates in a third-party component, both the guidance and the FAQ say that the manufacturer of the finished product must notify it, and the FAQ adds that the component's own manufacturer must notify it too where the component was itself placed on the market.56 Under that interpretation, a vulnerability in an integrated component that cannot be exploited, or has not been exploited, in the finished product is not subject to mandatory actively-exploited-vulnerability reporting by the integrator. The distinct upstream-reporting and remediation duty in Art. 13(6) CRA belongs to the general regime applying from 11 December 2027, subject to the transition in Art. 69(2) CRA; it is not an additional duty already applicable in October 2026. Other applicable law and contractual duties remain separate. One widely used library exploited in the wild can therefore produce a notification from every manufacturer in whose product it has been exploited, each of which must decide on its own evidence whether the vulnerable code is reachable and whether exploitation has reached its own product. The later general framework also provides support for smaller manufacturers. Art. 17(6) CRA provides for coordinating-CSIRT helpdesks, particularly for microenterprises and small and medium-sized enterprises. When the CRA penalty regime applies from 11 December 2027, Art. 64(10)(a) CRA, as corrected in July 2025, excludes the specified fines for microenterprises and small enterprises that miss the 24-hour early-warning deadline. That narrow exception does not remove the reporting duty or extend to failures concerning the 72-hour notification or final report.3

The Cyber Resilience Act uses language comparable to CISA's vulnerability catalog, but imposes its own early-warning duty on manufacturers of products within its scope. An absence of EU offices does not remove that duty or settle which CSIRT receives the warning.

2. Which CSIRT Receives the Report When the Manufacturer Has No EU Establishment

The notification does not go to ENISA alone. Art. 14(7) CRA directs it to the electronic notification end-point of the CSIRT designated as coordinator of one Member State and ordinarily makes it simultaneously accessible to ENISA. The particularly exceptional limitation on initial access is discussed below. That coordinator is the CSIRT each Member State designates for coordinated vulnerability disclosure under Art. 12(1) NIS2, so the CRA routes manufacturers to an institution whose NIS2 role is to broker disclosures between those who report vulnerabilities and the vendors concerned.37Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union, amending Regulation (EU) No 910/2014 and Directive (EU) 2018/1972, and repealing Directive (EU) 2016/1148 (NIS 2 Directive) [2022] OJ L333/80, Art. 12(1), Art. 23(3) and (4), and Art. 26(1) to (3) NIS2 (coordinator, incident reporting and jurisdiction). For a manufacturer with a main establishment in the Union, the CRA places that establishment in the Member State where decisions related to the cybersecurity of its products are predominantly taken and, if that Member State cannot be determined, where it has the establishment with the highest number of employees in the Union.

A US or Swiss manufacturer with no main establishment in the Union follows a four-step order instead, and it is an order of distribution facts rather than of corporate structure. The notification goes to the coordinator of the Member State where the authorized representative acting for the highest number of the manufacturer's products is established; failing that, where the importer placing the highest number of its products on the market is established; failing that, where the distributor making the highest number available is established; and failing all three, where the highest number of users of its products are located. The order applies “based on the information available to the manufacturer”, and only for the last step does the text let a manufacturer keep sending later notifications to the CSIRT it first reported to.3

Each step carries a question the text leaves open. The first rung uses an authorized representative if one has been designated; Art. 14(7) CRA does not require appointment solely to obtain a reporting endpoint. The general representative framework in Art. 18(1) CRA, applying from 11 December 2027, likewise provides for optional appointment. The identity of the coordinator can therefore depend on distribution choices made for other reasons. The Regulation does not say whether the highest number of products counts product types or units sold, or over what period. A US software company that sells by direct download to EU customers may have no representative, importer or distributor at all, and lands on the Member State with the most users, a figure its sales data may or may not hold. Under the later general framework, Art. 18(2) CRA excludes the manufacturer's core obligations under Art. 13(1) to (11) CRA from the representative's mandate without listing Art. 14 CRA. That distinction should not be treated as proof of a particular platform filing function in October 2026. Any arrangements for submitting a report on the manufacturer's behalf must preserve the manufacturer's own reporting responsibility.3

The harder question for a group is whether it has a main establishment in the Union at all. The CRA does not define an establishment, and neither the Commission's guidance nor its FAQ addresses the position of a manufacturer outside the Union under Art. 14(7) CRA.56 A Swiss parent that markets products under its own name and runs product security from Basel, with a distribution subsidiary in Germany and a plant in Poland, can be read as a manufacturer with EU establishments whose cybersecurity decisions are not taken in any Member State, so that its main establishment follows the head count, or as a manufacturer with no EU establishment whose German subsidiary is its importer. The two readings can point to different CSIRTs. NIS2 answers a neighboring question differently: for the digital providers that Art. 26(1)(b) NIS2 lists, Art. 26(2) NIS2 moves from where decisions on cybersecurity risk-management measures are predominantly taken, to where cybersecurity operations are carried out, and only then to head count, and it says expressly that the second step applies where those decisions are not taken in the Union. The CRA omits both the middle step and that sentence. For a listed NIS2 digital provider that is not established in the Union at all, Art. 26(3) NIS2 instead requires an EU representative and attaches jurisdiction to that representative's Member State.7 A group that is a NIS2 digital provider and a CRA manufacturer at once may find its two regulators located by two different tests.

The platform's dissemination design is set out in Art. 16 CRA. The initial coordinator is to pass the notification without delay to the coordinators of the Member States the manufacturer has identified as markets for the product; Art. 16(3) CRA provides for the notified information necessary for market surveillance to reach the relevant national authorities. ENISA's 11 September launch announcement describes initial operation of the coordinator-to-coordinator route, rather than certifying every function of the later general framework. Delegated Regulation (EU) 2026/881 specifies the conditions for delaying dissemination to other CSIRTs. Its information-related grounds require that the cybersecurity risks of dissemination outweigh the benefits and cannot be mitigated by handling or sharing restrictions. At least one further condition must apply: an effective mitigation measure is expected within 72 hours; the information is sufficient to create an exploitation technique; sufficient partial information can be shared for risk mitigation; or the coordinator is acting as a trusted intermediary in coordinated vulnerability disclosure. The first ground requires dissemination if mitigation is not made available within that 72-hour period. The partial-information and exploit-enabling grounds require dissemination once effective mitigation is available; the coordinated-disclosure ground also requires the parties' consent. Separate grounds address an affected recipient CSIRT's confidentiality capability and a compromise of the platform notified by ENISA. Any delay is the initial coordinator's decision, limited to the time strictly necessary, and does not extend the manufacturer's reporting deadline.8Commission Delegated Regulation (EU) 2026/881 of 11 December 2025 supplementing Regulation (EU) 2024/2847 of the European Parliament and of the Council by specifying the terms and conditions for applying the cybersecurity-related grounds in relation to delaying the dissemination of notifications [2026] OJ L 2026/881, recital 2 and Art. 3 to 5 of Delegated Regulation (EU) 2026/881 (grounds and limits for delayed dissemination).

Ordinary delayed dissemination to other CSIRTs does not restrict ENISA's access. A different, particularly exceptional route in Art. 16(2) CRA concerns the 72-hour vulnerability notification under Art. 14(2)(b) CRA. It applies where the manufacturer indicates one of three circumstances: exploitation known only in the initial coordinator's Member State; immediate further dissemination likely to reveal information contrary to that Member State's essential interests; or an imminent high cybersecurity risk from further dissemination. Only the fact of notification, general product and exploit information and the fact that security grounds were invoked are then made available simultaneously to ENISA until the full notification is disseminated. This is not a general confidentiality opt-out. The manufacturer's sensitivity indication under Art. 14(2)(b) CRA also informs an ordinary delay request; Art. 16(2) CRA refers to that sensitivity while cross-referring to the 24-hour provision in Art. 14(2)(a) CRA. That mismatch is present in the statutory text.38

From 11 December 2027, the general framework in Art. 17(2) CRA permits the coordinating CSIRT, after consulting the manufacturer, to inform the public or require the manufacturer to do so where public awareness is necessary to prevent or mitigate a severe incident, to handle an ongoing incident, or where disclosure is otherwise in the public interest. Art. 17(4) CRA provides that the mere act of notification does not increase the notifier's liability. That later Union-law protection should not be presented as an October 2026 immunity, or as protection against liability for the underlying conduct. Its effect in a US product-liability or securities action is a separate question.3

3. How NIS2 and Medical Device Reporting Duties Differ From the CRA

The CRA regulates products; NIS2 regulates the entities that run services, and a manufacturer can be both. Annex II to NIS2 lists manufacturers of medical devices and in vitro diagnostic devices, subject to its exception for specified critical devices in Annex I NIS2, and undertakings manufacturing computer, electronic and optical products. The ordinary size rule covers medium-sized and larger entities, while Art. 2(2) and (3) NIS2 also reach specified entities regardless of size. For manufacturing entities, jurisdiction ordinarily follows establishment under Art. 26(1) NIS2, and the applicable national transposition must be checked.7 An in-scope EU subsidiary that manufactures connected hardware can therefore owe its national CSIRT or competent authority an early warning without undue delay and within 24 hours of becoming aware of a significant incident, and an incident notification without undue delay and within 72 hours of that awareness. Art. 23(4) NIS2 generally requires the final report within one month after submission of the incident notification; if the incident is still ongoing then, a progress report is due instead, followed by a final report within one month of handling the incident. Its parent, if manufacturer of an in-scope product, may separately owe the CRA sequence to a coordinator in another Member State. The triggers differ as well. Art. 23(3) NIS2 asks whether an incident has caused or is capable of causing severe operational disruption of the entity's services or financial loss, or considerable damage to others; the CRA also reaches specified potential effects on a product's ability to protect data and functions, or the introduction or execution of malicious code. The compromised update channel of recital 68 CRA can meet both regimes’ tests, depending on the facts.

The Commission has proposed to connect the two. Its Digital Omnibus proposal of November 2025 would add an Art. 23a NIS2 obliging ENISA to build a single-entry point for incident reporting, which may build on the CRA platform, and an Art. 23(12) NIS2 under which a manufacturer's severe-incident notification under Art. 14(3) CRA would count as NIS2 reporting where it contains the information NIS2 requires.9European Commission, Proposal for a Regulation of the European Parliament and of the Council amending Regulations (EU) 2016/679, (EU) 2018/1724, (EU) 2018/1725, (EU) 2023/2854 and Directives 2002/58/EC, (EU) 2022/2555 and (EU) 2022/2557 as regards the simplification of the digital legislative framework, and repealing Regulations (EU) 2018/1807, (EU) 2019/1150, (EU) 2022/868, and Directive (EU) 2019/1024 (Digital Omnibus) COM(2025) 837 final (19 November 2025), Art. 6, points 1 and 2 of the Digital Omnibus proposal (proposed Art. 23a and Art. 23(12) NIS2); a proposal at the article horizon. The proposed cross-credit would cover severe incidents, not a vulnerability notification as such. As of 1 October 2026, it remained a proposal rather than an operative reporting shortcut. The proposed single-entry point would also require piloting and a Commission notice before notifications under each added act were enabled. Manufacturers should therefore assess each current duty and its filing arrangements separately; overlapping facts may still have to reach different authorities in different Member States.

Medical Devices: CRA Exclusion and Separate Vigilance Triggers

Medical devices sit outside the CRA altogether. Art. 2(2)(a) and (b) CRA exclude products with digital elements to which the EU Medical Device Regulation (MDR) or the In Vitro Diagnostic Regulation (IVDR) applies, and recital 25 CRA gives the reason: both regulations already address cybersecurity through their own essential requirements and conformity assessment.310Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC [2017] OJ L117/1 (MDR), consolidated version of 19 July 2026. Art. 2(64) to (68), Art. 87(1) to (8), and Annex I, sections 17.2 and 17.4 MDR (potential outcomes, immediate reporting, outer limits and advance corrective-action reporting).11Regulation (EU) 2017/746 of the European Parliament and of the Council of 5 April 2017 on in vitro diagnostic medical devices and repealing Directive 98/79/EC and Commission Decision 2010/227/EU [2017] OJ L117/176 (IVDR), consolidated version of 10 January 2025. Art. 2(67) to (71) and Art. 82(1) to (8) IVDR (potential outcomes, immediate reporting, outer limits, uncertainty and advance corrective-action reporting). On the design side the MDR does address it. Annex I, Sections 17.2 and 17.4 MDR require device software to be developed in accordance with the state of the art, taking into account information security, and manufacturers to set minimum IT security measures, including protection against unauthorized access. The reporting side is where the exclusion bites. Vigilance under Art. 87 MDR, and under its counterpart in Art. 82 IVDR, is triggered by a serious incident, which Art. 2(65) MDR defines by reference to death, a serious deterioration of health or a serious public health threat that an incident led to, might have led to or might lead to, or by a field safety corrective action, which Art. 2(68) MDR confines to action taken to prevent or reduce the risk of a serious incident. Reports go to competent authorities. Under Art. 87(3) to (5) MDR and Art. 82(3) to (5) IVDR, the ordinary serious-incident report is due immediately once a causal relationship is established or reasonably possible, and no later than 15 days after awareness. Death or unanticipated serious deterioration requires reporting immediately once causation is established or suspected, with a 10-day outer limit; a serious public health threat requires immediate reporting, within two days of awareness. Uncertainty about reportability does not suspend those deadlines. Field safety corrective actions follow a different rule: they must be reported without undue delay before action is taken, except where urgency requires immediate action.1011

Active exploitation alone does not trigger device vigilance if it neither constitutes a potentially reportable serious incident nor occasions a reportable field safety corrective action. Lack of actual injury is not enough: qualifying potential outcomes count, and uncertainty about a potentially reportable incident does not excuse timely reporting. The CRA does not fill this gap because the device is excluded. The Commission has named the gap itself. Recital 44 of its December 2025 proposal to simplify the device regulations calls it “an important cybersecurity gap” and proposes a new Art. 87a MDR and Art. 82a IVDR, under which device manufacturers would report actively exploited vulnerabilities and severe incidents, both defined by reference to the CRA, to the coordinating CSIRTs of the Member States where the device has been made available, and to ENISA, through Eudamed within 30 days of awareness, without replacing existing vigilance duties. The proposal would defer these new cyber-reporting provisions until three years after entry into force.12European Commission, Proposal for a Regulation of the European Parliament and of the Council amending Regulations (EU) 2017/745 and (EU) 2017/746 as regards simplifying and reducing the burden of the rules on medical devices and in vitro diagnostic medical devices, and amending Regulation (EU) 2022/123 as regards the support of the European Medicines Agency for the expert panels on medical devices and Regulation (EU) 2024/1689 as regards the list of Union harmonisation legislation referred to in its Annex I, COM(2025) 1023 final (16 December 2025), procedure 2025/0404(COD). Recital 44, Art. 1, points (68)(b) and (69), Art. 2, points (54)(b) and (55), and Art. 5(3)(c) COM(2025) 1023 final (proposed additive cyber-reporting duties and three-year deferred application; not operative on 1 October 2026). As of publication that proposal was still in the European Parliament's public health committee. A US device company that reads the CRA's 24-hour clock as a cybersecurity baseline for its whole portfolio is reading a regime that does not reach its devices, and a company that reads the proposed 30-day device clock as the answer is reading a regime that does not yet exist.

The line between the two regimes is drawn by device qualification, not by sector, and it cuts through health-technology portfolios. A health-monitoring wearable to which neither the MDR nor the IVDR applies is an important product under Annex III, class I, point 19 CRA and has been subject to the 24-hour clock since 11 September 2026 if it falls within the CRA’s scope and the reporting trigger is met, while a regulated device from the same manufacturer answers to device vigilance instead.3 A clinician portal, a companion app that does not itself qualify as a device, or an integration engine sold by a device manufacturer may fall on the CRA side of the line while the device it connects to does not. Section 9.3 of the July draft CRA guidance addresses vehicle type-approval and certificates issued under other harmonization legislation; it does not resolve this medical-device qualification question.5 Where a product's qualification is contested or changes, so does the authority that must hear about its exploitation, and the answer on the day the exploitation is found may differ from the answer on the day the qualification is settled.

4. A Swiss Manufacturer on Both Sides of the Border

Switzerland is not an EU Member State, and the CRA does not mention it. A Swiss manufacturer whose products reach the EU market is a manufacturer like any other, and if it has no main establishment in the Union it reports through the same four-step order as a US one. Art. 34 CRA contemplates mutual recognition agreements with third countries on conformity assessment; that mechanism concerns how a product is assessed and does not touch the reporting duty, which runs from the manufacturer to a CSIRT in the Union wherever the product was assessed.3 A Swiss group whose products were placed on the EU market before 11 December 2027 has been inside Art. 14 CRA for every in-scope product since 11 September 2026.

Inside Switzerland, the ISG does not establish a horizontal manufacturer notification duty equivalent to Art. 14 CRA. It combines a vulnerability-response mechanism with reporting by specified critical-infrastructure organizations. Under Art. 73b(3) of the Informationssicherheitsgesetz (ISG), the Bundesamt für Cybersicherheit (BACS), on learning of a vulnerability, informs the manufacturer of the affected hardware or software, sets it a reasonable deadline to remedy it, and points out that non-compliance can be sanctioned under public procurement law and that the BACS may then publish information on the vulnerability naming the product, which Art. 73c(2) ISG allows once the deadline has passed without a fix.13Bundesgesetz über die Informationssicherheit (Informationssicherheitsgesetz, ISG) vom 18. Dezember 2020 (SR 128), version of 1 October 2025. Art. 5(d) to (g), Art. 73b, Art. 73c and Art. 74a to Art. 74e ISG (own-IT attacks, covered entities, Swiss effects and 24 hours from discovery). Verordnung über die Cybersicherheit (Cybersicherheitsverordnung, CSV) vom 7. März 2025 (SR 128.51), version of 1 April 2025. Art. 12 and Art. 14 to Art. 16 CSV (exceptions and reporting details). Outside any duty, Art. 73b(1) ISG has the BACS receive reports on cyber incidents and cyber threats, which may be made anonymously. The mandatory channel is the critical-infrastructure duty examined in the earlier article on Swiss cyberattack reporting. Since 1 April 2025, Art. 74a to Art. 74e ISG have required listed organizations, subject to the statutory and ordinance exceptions, to report a qualifying attack on their IT to the BACS within 24 hours of discovery. The attack must have effects in Switzerland; attacks affecting only unrelated activities are excluded. Art. 74b(1)(u) ISG reaches manufacturers of hardware or software used by critical infrastructures where the product has remote-maintenance access or is used to control and monitor operational systems and processes or to ensure public safety.13

The two regimes can meet in a single event. Exploitation of a Swiss manufacturer’s product in a customer’s control system may trigger its CRA duty for an in-scope product. The ISG duty is different: Art. 74a(1) ISG concerns attacks on the covered organization’s own IT, subject to the Swiss-effects rule and reporting conditions. Merely learning of exploitation in a customer’s systems does not automatically create the manufacturer’s ISG notification duty; the customer may owe its own report. Where the manufacturer operates or remotely manages the affected infrastructure, the allocation needs to be assessed on those facts. A vulnerability alone is a cyber threat under Art. 5(f) and (g) ISG, not the reportable cyberattack required by Art. 74d ISG.13

The Swiss position is set to change, though not quickly. On 20 August 2025 the Federal Council instructed the VBS to prepare by autumn 2026 a consultation draft on the cyber resilience of digital products, answering Motion 24.3810 of the Council of States' security policy committee, with security requirements for development and placing on the market, market surveillance and a basis for banning the import and distribution of insecure devices, and with the CRA expressly in view.14Bundesrat, ‘Der Bundesrat will die Cyberresilienz von digitalen Produkten stärken’ (Medienmitteilung, 20 August 2025). Legislative-development mandate and original autumn 2026 timetable; not enacted product obligations. On 25 September 2026 it changed the vehicle and the timetable. It merged that project with two others, on the protection of particularly important digital data (Motion 23.3002) and on the role of hosting and cloud providers (Motion 25.3011), into a standalone federal act on cybersecurity, the Cybersicherheitsgesetz (CSG), and asked the VBS for a consultation draft by June 2027.15Bundesrat, ‘Bundesrat will neues Cybersicherheitsgesetz schaffen’ (Medienmitteilung, 25 September 2026). June 2027 consultation-draft mandate, intended CRA alignment and planned transfer of critical-infrastructure reporting; announcement, not enacted law. The act is to set binding requirements for manufacturers, importers and dealers of software and hardware products, with a basis for market surveillance and a sales ban on insecure products, oriented on the CRA, together with specific cybersecurity duties to protect important digital data and for hosting and cloud providers, such as duties to cooperate and to defend against cyber threats. The critical-infrastructure reporting duty is to move from the ISG into the new act, and the ISG is to keep governing the information security of the federal authorities.

What that means for a Swiss manufacturer is mostly a matter of dates and open drafting. The consultation draft is due, on the Federal Council's own timetable, after the EU reporting duty has run for about nine months and some six months before the CRA applies in full on 11 December 2027; an enacted statute lies further out. The Federal Council describes a harmonized Swiss law as one that creates no additional compliance burden for companies already bound by the CRA, but a press release is not a text.15 Whether a Swiss duty will accept a notification filed on ENISA's platform, require a parallel report to the BACS, start its clock at awareness or at discovery, or borrow the ISG's gates are all open questions. A Swiss manufacturer of medical-device software covered by the MDR remains outside the CRA, but that exclusion does not remove Swiss product-vigilance duties. For devices made available in Switzerland, Art. 66(1) and (2) MepV already require reports to Swissmedic of serious incidents occurring in Switzerland and field safety corrective actions taken in Switzerland, with the MDR reporting rules incorporated. Any applicable ISG duty to the BACS is separate.16Medizinprodukteverordnung (MepV) vom 1. Juli 2020 (SR 812.213), version of 1 July 2026. Art. 66(1), (2) and (2bis) MepV (Swiss device vigilance, incorporated MDR reporting rules and authorized-representative responsibility).

5. Strategic Considerations for Manufacturers Reporting From Outside the Union

The questions that decide exposure under Art. 14 CRA are rarely the ones the text answers. Awareness is where they begin. For a group whose product security runs from a US security operations center, whose customer escalations arrive through an EU distributor and whose legal function sits in Basel or New York, which of those points marks the moment the 24 hours begin, and would the group's incident records show that moment to a CSIRT asking months later? The guidance ties awareness to a reasonable degree of certainty after a prompt initial assessment. Whether a given triage process was prompt, and whether it reached certainty earlier than its tickets suggest, can be answered only from the group's own records, and those records may be read against the date of the first public report of exploitation.

Routing raises questions of its own. Whether the group has a main establishment in the Union, whether its EU subsidiaries are establishments or importers, which authorized representative, importer or distributor handles the highest number of its products, and what that number measures, decide which Member State's CSIRT receives the first report and, through it, which market surveillance authority hears first. Where the answers change with a new distributor or a restructuring, does the routing change with them, and who inside the group would notice?

Then there is the seam between regimes. For a connected product, the same event may call for a CRA early warning to one CSIRT, a NIS2 early warning from an EU subsidiary to another, a vigilance report if a device is involved, a 24-hour report to the BACS if the group is itself subject to the ISG duty and the attack meets one of its gates, notices to customers under their contracts and, for a parent subject to Form 8-K, a materiality analysis under Item 1.05, which generally requires filing within four business days after the materiality determination. A foreign private issuer reporting on Form 6-K follows that form's different disclosure conditions.17Securities and Exchange Commission, “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure”, Release Nos. 33-11216 and 34-97989 (26 July 2023), 88 FR 51896 (4 August 2023), section II.E (pp. 85–88) and the Form 8-K amendments (pp. 182–185). General Instruction B.1 and Item 1.05 of Form 8-K generally require filing within four business days after the registrant determines that a cybersecurity incident is material; that determination must be made without unreasonable delay after discovery, and Item 1.05(c)–(d) provides specified delay mechanisms. Form 6-K, General Instructions A–B, applies a different regime to foreign private issuers: material information meeting its foreign-law, stock-exchange or security-holder disclosure conditions must be furnished promptly. A US listing alone does not determine the applicable form. Each has its own trigger and addressee, and a statement made in one may be read against a statement made in another. The product-security assessment and the securities materiality decision answer different questions. Their supporting facts may overlap, but their conclusions need not match.

The dates create further constraints. The reporting duty has applied since 11 September 2026; the substantive requirements apply from 11 December 2027; the proposed NIS2 link and the proposed device-reporting duty were, as of publication, still before the European Parliament's committees; the July guidance cover distinguishes content approval from later formal adoption; and the Swiss consultation draft is due by June 2027. A reporting process designed around one of these states will be tested against another before any of them settles.