Weekly Medical Device Cybersecurity Briefing

This week’s main event was operational rather than legislative: the EU Cyber Resilience Act’s Single Reporting Platform went live on 11 September, starting the clock on 24-hour/72-hour/final-report vulnerability and incident notifications for any manufacturer selling connected products into the EU, including third-party software components embedded in otherwise-excluded medical devices. Separately, quantum-computing vendor IonQ published a self-funded resource estimate claiming a 20,000-qubit machine could break a 256-bit elliptic-curve signature in under 26 days, a forward-looking signal for firmware-signing and device-identity infrastructure that continues last week’s PQC thread but should be read as one company’s own estimate rather than an independently verified result. On deadlines, nothing closed this week, but the FDA’s generative-AI discussion-paper comment period (due 19 October) has been added to the tracking table, and the 11 September CRA reporting milestone has rolled off now that it has passed.

1. EU Cyber Resilience Act’s Single Reporting Platform Goes Live, Starting the Reporting Clock

On 11 September 2026, ENISA deployed the initial operating capability of the Cyber Resilience Act’s Single Reporting Platform (SRP), the mandatory channel through which manufacturers subject to the CRA’s reporting requirements must notify authorities of actively exploited vulnerabilities and severe incidents affecting products with digital elements sold in the EU. The platform’s go-live coincides with the date the CRA’s reporting obligations become legally binding, 15 months before the Act’s broader requirements become fully applicable on 11 December 2027.

How the reporting mechanism works

A manufacturer that becomes aware of an actively exploited vulnerability (reliable evidence of malicious, unauthorized exploitation, as distinct from good-faith security research) or a severe incident (one that compromises the availability, authenticity, integrity, or confidentiality of the product’s data or functions, or introduces malicious code) must submit an early warning within 24 hours, a fuller technical notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure becomes available for an actively exploited vulnerability, or within one month after submission of the 72-hour notification for a severe incident. Each notification goes to a single national CSIRT, designated as the coordinator for the manufacturer, generally in the Member State where the manufacturer has its main establishment in the EU, which then disseminates the information to other relevant national CSIRTs and to ENISA, so a manufacturer selling across multiple member states files once rather than per-country. The obligation is not retrospective: a manufacturer that already knew about an exploited vulnerability before 11 September has no new duty to report it, but if it learns after 11 September that the vulnerability is being actively exploited, the reporting obligation applies regardless of how old the underlying vulnerability is. Reporting duties also flow through the supply chain: if a product contains an actively exploited vulnerability originating in an integrated third-party component and that vulnerability is actively exploited in the manufacturer’s product, the manufacturer must report it, independent of any separate obligation the component’s own maker may have if that component was itself placed on the EU market. Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.

Manufacturer relevance

MDR/IVDR-regulated medical devices remain outside the CRA’s own product-level requirements, so a device manufacturer does not report device vulnerabilities to the SRP in its capacity as a device maker. The exclusion is product-specific: connected accessories, companion apps, standalone software tools, gateways, and other products associated with a medical device need to be assessed separately to determine whether they are themselves covered by MDR/IVDR or fall within the CRA. Products or components covered under CRA now carry a live 24-hour reporting clock. Because the duty triggers on the manufacturer’s own awareness of active exploitation rather than on when the vulnerability was introduced, the practical readiness question is detection and escalation speed: does the organization have a process that can recognize an active exploitation event in a covered component affecting its product and route it to whoever owns EU regulatory reporting within 24 hours, before the clock, not the vulnerability’s age, becomes the compliance problem. Manufacturers with any product line that touches CRA-covered components should confirm now which entity (including the relevant EU-established manufacturer or, where applicable, its authorised representative) is responsible for identifying the correct national CSIRT and filing, since the SRP’s routing logic depends on knowing that in advance rather than working it out during an active incident. Importantly, Article 14 reporting applies to in-scope products already placed on the EU market; manufacturers do not have to wait until the CRA’s broader December 2027 requirements become applicable.

Sources: The CRA Single Reporting Platform is launched - ENISA, 11 September 2026; Single Reporting Platform (SRP) - ENISA; Preparing for the EU Cyber Resilience Act: Key Reporting Obligations From 11 September 2026 - Goodwin, 11 September 2026

2. IonQ Publishes Vendor Resource Estimate for Breaking 256-Bit Elliptic-Curve Signatures

On 8 September 2026, quantum-computing company IonQ (NYSE: IONQ) published what it describes as the first fully compiled, end-to-end fault-tolerant resource estimate for running Shor’s algorithm against secp256k1, a 256-bit elliptic curve used for ECDSA signatures (notably in Bitcoin, which is why IonQ chose it as a widely scrutinized benchmark). The paper’s headline claim is that a 20,000-physical-qubit trapped-ion machine, built on IonQ’s “Walking Cat” architecture, could solve the underlying discrete-logarithm problem in an estimated 25.7 days per attempt (19,397 physical qubits, 1,457 logical qubits, roughly 39 million Toffoli gates). No real system, wallet, or device was attacked; this is an architectural and resource-estimation study, and IonQ says the result aligns with its own publicly stated hardware roadmap for the 2028 timeframe.

What this is, and isn’t

This is a company research paper published on IonQ’s own site to support its commercial quantum-security and hardware roadmap narrative, not an independently peer-reviewed or third-party-replicated result, and no NIST, CISA, or other regulator or standards body had issued commentary on this specific paper as of this writing. IonQ states it followed responsible-disclosure practice by briefing U.S. government and industry partners in advance, but that is a claim from the company, not independent confirmation. The finding also targets signature and authentication schemes (code signing, certificate hierarchies, device identity, firmware-update authentication) rather than data confidentiality: unlike a “harvest now, decrypt later” attack on encrypted traffic, a forged signature is only exploitable going forward, not retroactively against data already captured. secp256k1 itself is not the curve typically used in medical device PKI (NIST’s P-256 and P-384 are far more common), but the underlying mathematical problem, the elliptic-curve discrete logarithm, is generic to any 256-bit curve, so the estimate is a directional signal about EC-signature-dependent infrastructure generally rather than a curve-specific one.

Manufacturer relevance

This adds a data point, not a new obligation, to the crypto-agility and PQC-migration work flagged in last week’s G7/CISA call to action. IonQ’s own framing (and NIST’s existing guidance) treats signature migration as the last, hardest step in post-quantum transition, precisely because firmware-signing keys and secure-boot root-of-trust hierarchies are difficult to rotate once deployed in fielded devices. NIST’s already-standardized ML-DSA and SLH-DSA signature algorithms are unaffected by this class of quantum attack, so the mitigation path does not change. What manufacturers should take from this is calibration, not urgency: if a cryptographic-asset inventory (per last week’s G7 recommendation) has not yet identified where EC signatures anchor firmware authenticity and device identity, this is another reminder to do so, but the estimate should be treated as one vendor’s self-published projection until independent cryptographers or a standards body weigh in on the underlying methodology.

Sources: IonQ Publishes World’s First Fully Compiled, End-to-End Blueprint for Breaking 256-Bit Elliptic-Curve Signatures - IonQ, 8 September 2026; IonQ Estimates 20,000-Qubit Machine Could Break Bitcoin’s secp256k1 in 26 Days - The Quantum Insider, 8 September 2026