Sicurezza dei dispositivi medici: i 3 pilastri cyber per competere con i mercati globali

Il 3 febbraio 2026 la statunitense FDA (Food and Drug Administration) ha pubblicato l’aggiornamento della guida “Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions“, documento che segna un cambio di paradigma nella regolamentazione della sicurezza informatica dei dispositivi medici.

La revisione, che sostituisce la versione di giugno 2025, integra definitivamente i requisiti introdotti dalla Section 524B del Federal Food, Drug, and Cosmetic Act (FD&C Act), obbligatori dal 29 marzo 2023.

Per i produttori europei – e italiani in particolare – che guardano al mercato statunitense (che rappresenta circa il 40% del mercato globale dei dispositivi medici), comprendere le differenze tra l’approccio FDA e quello del Medical Device Regulation europeo non è più un’opzione: è una necessità competitiva.

Ma è anche un’opportunità per anticipare tendenze che, con ogni probabilità, il Cyber Resilience Act porterà presto anche in Europa.

Il perimetro della rivoluzione: cosa sono i cyber device

La Section 524B introduce il concetto di “cyber device”, definito come dispositivo che soddisfa cumulativamente tre condizioni: contiene software (incluso firmware o programmable logic), ha la capacità di connettersi a Internet, e presenta caratteristiche tecnologiche vulnerabili a minacce cyber.

L’interpretazione che la FDA dà di “capacità di connettersi a Internet” è estremamente ampia: include non solo connettività di rete tradizionale (Wi-Fi, Ethernet), ma anche Bluetooth, porte USB, porte seriali e qualsiasi altro mezzo che possa, anche indirettamente o non intenzionalmente, consentire una connessione.

La logica è semplice quanto implacabile: se un dispositivo può essere connesso, prima o poi sarà connesso, indipendentemente dalle intenzioni del produttore.
Questa definizione cattura una platea di dispositivi significativamente più ampia rispetto all’approccio europeo.

Il MDR, infatti, non prevede una categoria specifica di “cyber device”: la cyber security è trattata come requisito trasversale, modulato in base alla classificazione di rischio del dispositivo (Classe I, IIa, IIb, III). Un termometro digitale con porta USB, ad esempio, potrebbe non richiedere particolare attenzione cyber in Europa (se Classe I non-sterile), ma negli USA sarebbe soggetto ai requisiti completi della Section 524B.

I tre pilastri obbligatori per i cyber devices

La Section 524B impone ai produttori di cyber devices tre obblighi documentali precisi, da includere nelle submission premarket (510(k), PMA, De Novo, HDE).

I tre pilastri obbligatori per i cyber device sono:

• piano di gestione delle vulnerabilità post-market;ù
• processi di sviluppo sicuro;
• Software Bill of Materials (SBOM).

Primo pilastro: piano di gestione delle vulnerabilità post-market

L’obbligo previsto dalla Section 524B(b)(1) richiede un piano formale per “monitorare, identificare e gestire, in tempi ragionevoli, le vulnerabilità e gli exploit postmarket”. Il piano deve includere procedure di Coordinated Vulnerability Disclosure (CVD): processi strutturati per ricevere segnalazioni da ricercatori esterni, valutare le vulnerabilità, coordinare la disclosure e comunicare con gli stakeholder.

La FDA distingue inoltre due regimi di patching:

• Vulnerabilità note accettabili (524B(b)(2)(A)): aggiornamenti su ciclo regolare, giustificato dal produttore.
• Vulnerabilità critiche (524B(b)(2)(B)): patch “as soon as possible”, fuori dal ciclo ordinario, per vulnerabilità che potrebbero causare “rischi incontrollati”.

Questa distinzione introduce un criterio di urgenza assente nel MDR, che si limita a richiedere che il software sia “mantenuto in stato sicuro” (Annex I §17.4) senza specificare tempistiche.

Secondo pilastro: processi di sviluppo sicuro

La Section 524B(b)(2) impone ai produttori di “progettare, sviluppare e mantenere processi e procedure per fornire una ragionevole garanzia che il dispositivo e i sistemi correlati siano cybersicuri”.

La FDA raccomanda l’adozione di un Secure Product Development Framework (SPDF): un insieme di processi che riducono il numero e la gravità delle vulnerabilità lungo tutto il ciclo di vita del prodotto.

Lo SPDF dovrebbe integrare:

• Security risk management separato (ma interfacciato) dal safety risk management ISO 14971 3.
• Threat modeling obbligatorio per identificare vettori di attacco
• Security architecture views: quattro tipologie di rappresentazioni architetturali (Global System View, Multi-Patient Harm View, Updateability/Patchability View, Security Use Case Views).
• Cyber security testing: penetration testing obbligatorio con report dettagliati.

Qui emerge una differenza metodologica fondamentale rispetto all’ISO 14971, che adotta un approccio probabilistico (Probabilità × Gravità).

Il security risk management FDA è invece non-probabilistico: valuta l’exploitability assumendo un attaccante intenzionale con capacità crescenti nel tempo, non la probabilità di failure accidentale.

L’implementazione di un Secure Product Development Framework (SPDF), inoltre, influisce direttamente sulla sicurezza dei pazienti riducendo la probabilità che le vulnerabilità informatiche possano essere sfruttate per causare danni clinici.

Nel documento della FDA è espresso che l’SPDF agisce sulla sicurezza dei pazienti attraverso diversi meccanismi chiave:

• riduzione del numero e della gravità delle vulnerabilità;
• sicurezza fin dalla progettazione (Secure by Design);
• identificazione proattiva dei rischi clinici;
• gestione dei rischi per l’intero ciclo di vita.

Riduzione del numero e della gravità delle vulnerabilità

L’obiettivo primario di un SPDF è quello di ridurre sistematicamente la quantità e la criticità delle vulnerabilità nei prodotti medici lungo tutto il loro ciclo di vita (progettazione, sviluppo, rilascio, supporto e smaltimento). Poiché le minacce informatiche possono sfruttare queste debolezze per compromettere la funzionalità del dispositivo, ridurle significa diminuire drasticamente il rischio di danni ai pazienti.

Sicurezza fin dalla progettazione (Secure by Design)

L’utilizzo di un SPDF garantisce che la sicurezza sia “integrata” nel dispositivo fin dall’inizio e non aggiunta in un secondo momento.

Questo approccio:

• Previene la necessità di riprogettare il dispositivo quando vengono scoperte vulnerabilità critiche dopo la commercializzazione.
• Assicura che il dispositivo sia resiliente e affidabile, mantenendo le sue funzioni critiche anche in presenza di tentativi di compromissione.

Identificazione proattiva dei rischi clinici

I processi interni all’SPDF, come il Threat Modeling (modellazione delle minacce) e i test di cyber security, sono progettati per esporre come le minacce informatiche possano manifestarsi come pericoli clinici (per esempio, ritardi nelle diagnosi o nei trattamenti).

Questo permette ai produttori di:

• Valutare l’impatto di un attacco sulla sicurezza e sull’efficacia del dispositivo.
• Implementare controlli di sicurezza specifici per mitigare i rischi di danni diretti o indiretti ai pazienti.

Gestione dei rischi per l’intero ciclo di vita

L’SPDF non si limita alla fase di vendita, ma prevede la manutenzione della sicurezza per tutta la durata operativa del dispositivo.

Questo è fondamentale perché le minacce si evolvono; un SPDF efficace permette di identificare e correggere rapidamente nuove vulnerabilità tramite patch e aggiornamenti, garantendo che il dispositivo rimanga sicuro per il paziente anche anni dopo la sua installazione.

L’adozione di un SPDF trasforma la cybersecurity da un problema puramente tecnico a un elemento portante della sicurezza clinica parte della qualità del prodotto, assicurando che i dispositivi medici operino in modo sicuro all’interno dell’ecosistema sanitario interconnesso.

Terzo pilastro: Software Bill of Materials (SBOM)

La Section 524B(b)(3) rende obbligatoria la produzione di un SBOM, un inventario formale e dettagliato di tutti i componenti software e delle dipendenze di un dispositivo, che includa “componenti commerciali, open-source e off-the-shelf”.

Lo SBOM deve essere:

• Machine-readable (formati raccomandati: SPDX, CycloneDX).
• Conforme agli “elementi minimi” identificati dal NTIA (National Telecommunications and Information Administration) nell’ottobre 2021.
• Arricchito con informazioni su livello di supporto e end-of-support date per ciascun componente.
• Incluso nel labeling del dispositivo, quindi accessibile agli utilizzatori.

Quest’ultimo punto segna una discontinuità radicale con l’approccio europeo. Nel MDR, l’SBOM (pur se non esplicitamente chiamato così) fa parte della documentazione tecnica riservata, accessibile solo agli Organismi Notificati e alle autorità competenti.

La FDA impone invece la trasparenza verso gli utenti finali: ospedali e strutture sanitarie devono poter conoscere i componenti software dei dispositivi per integrarli nei propri framework di risk management (per esempio, NIST Cybersecurity Framework).

Il quadro europeo: MDR, NIS2 e le competenze frammentate

Sul fronte europeo, la cyber security dei dispositivi medici è regolata da un mosaico normativo che intreccia:

Medical Device Regulation (MDR 2017/745): impone requisiti generali di sicurezza (Annex I §17: “software must 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”). Il MDCG (Medical Device Coordination Group) ha pubblicato nel 2019 una guidance sulla cybersecurity (MDCG 2019-16), ma rimane un documento principle-based, che demanda agli standard armonizzati (IEC 62304, IEC 62443, IEC 81001-5-1) la specificazione dei requisiti.

Direttiva NIS2 (recepita in Italia con D.Lgs. 138/2024): si applica ai produttori di dispositivi medici se soggetti “essenziali” o “importanti” (generalmente, oltre 50 dipendenti e 10 milioni di euro di fatturato o rilevanza settoriale).

La NIS2 impone misure di cyber security organizzativa – risk management,
incident reporting entro 24/72 ore, sicurezza della supply chain – ma non interviene direttamente sulla cyber security del prodotto, che rimane dominio del MDR.

Il GDPR impone data protection by design e notifica dei data breach entro 72 ore, ma il focus è sulla protezione dei dati personali, non sulla sicurezza funzionale del dispositivo.

Questa frammentazione si riflette anche nella distribuzione delle competenze regolatorie:

• Organismi Notificati: valutano la conformità MDR, inclusa (implicitamente) la cybersecurity del prodotto.
• Ministero della Salute: vigila sul post-market e gestisce il sistema di vigilanza nazionale.
• ACN (Agenzia per la Cybersicurezza Nazionale): coordina gli obblighi NIS2, ma solo per la cyber security organizzativa, non del prodotto.
• AIFA: ha competenza limitata ai dispositivi cd. combination (farmaco-device), senza ruolo diretto sulla cyber security.

Nessuno di questi attori, però, ha un mandato esplicito e prescrittivo sulla cybersecurity dei dispositivi paragonabile a quello della FDA.

I gap strutturali: in 4 fronti in cui l’Europa è indietro

Il confronto tra i due sistemi rivela differenze sostanziali su quattro fronti:

• SBOM e trasparenza;
• coordinated vulnerability disclosure;
• testing prescrittivo.

SBOM e trasparenza

Sul fronte della trasparenza documentale, i due sistemi esprimono filosofie radicalmente diverse. Negli Stati Uniti, lo SBOM è un documento obbligatorio, deve essere prodotto in formato machine-readable e reso accessibile agli utilizzatori attraverso il labeling del dispositivo.

In Europa, invece, lo SBOM – pur essendo implicitamente richiesto dalla documentazione tecnica prevista dal MDR – non ha formato prescritto ed è trattato come documento riservato, accessibile esclusivamente agli Organismi Notificati e alle autorità competenti, non agli utenti finali.

Le conseguenze operative di questa differenza sono tutt’altro che formali.

Un ospedale statunitense può integrare lo SBOM di un dispositivo nei propri sistemi di vulnerability management, scansionarlo automaticamente contro banche dati pubbliche come il NIST National Vulnerability Database e ricevere alert in tempo reale nel momento in cui uno dei componenti software del dispositivo risulta affetto da una vulnerabilità nota.

Può quindi prendere decisioni informate – isolare il dispositivo dalla rete, richiedere una patch al produttore, attivare misure compensative – prima ancora che il produttore stesso abbia comunicato ufficialmente il problema.

In Europa, questa capacità di reazione autonoma è oggi sostanzialmente assente: gli utilizzatori dipendono interamente dalla proattività del produttore nella comunicazione delle vulnerabilità, senza alcuno strumento per una verifica indipendente.

Coordinated vulnerability disclosure

Sul fronte della gestione coordinata delle vulnerabilità, il divario tra i due sistemi è altrettanto marcato.

Negli Stati Uniti, i produttori di cyber devices sono tenuti a definire un piano formale di Coordinated Vulnerability Disclosure già in fase di submission premarket, con procedure dettagliate che disciplinano anche le modalità di ricezione delle segnalazioni provenienti da ricercatori esterni.

Il processo è quindi codificato, pubblico e vincolante prima ancora che il dispositivo arrivi sul mercato.

In Europa, il MDR si affida al sistema di vigilanza tradizionale – basato sulle Field Safety Notices e sulle notifiche alle autorità competenti – e, per i produttori soggetti alla NIS2, all’obbligo di incident reporting entro ventiquattro e settantadue ore.

Nessuno di questi strumenti, tuttavia, equivale a un processo strutturato di coordinated vulnerability disclosure: il MDR non richiede che il produttore definisca canali dedicati per la ricezione di segnalazioni esterne, né che pubblichi procedure chiare su come i ricercatori debbano comunicare le vulnerabilità scoperte e in quali tempi possano aspettarsi una risposta.

Testing prescrittivo

Sul fronte della verifica tecnica della sicurezza, la distanza tra i due sistemi è forse quella più immediatamente percepibile nella pratica quotidiana dei produttori.

La FDA impone il penetration testing come requisito esplicito, richiedendo che i relativi report documentino in modo analitico l’indipendenza dei tester rispetto al team di sviluppo, il perimetro dell’attività svolta, la durata, le metodologie impiegate e la totalità dei risultati emersi, incluse le vulnerabilità non rimediate con la relativa giustificazione.

Non si tratta dunque di una generica attività di verifica, ma di un processo codificato nei suoi elementi costitutivi, la cui adeguatezza è valutabile dalla FDA su basi oggettive e uniformi.

In Europa, il riferimento rimane la norma IEC 62304 per lo sviluppo del software medicale, che prevede attività di verifica e validazione senza tuttavia prescrivere il penetration testing come requisito specifico né definirne le caratteristiche minime in termini di indipendenza, profondità o metodologia.

Gestione del fine vita software

L’ultimo gap strutturale riguarda la gestione del ciclo di vita del software e la sua comunicazione agli utilizzatori.

Negli Stati Uniti, i produttori sono tenuti a indicare nel labeling del dispositivo le date di fine supporto dei componenti software inclusi nel prodotto, consentendo agli utilizzatori di sapere con anticipo quando un determinato componente non riceverà più aggiornamenti di sicurezza.

In Europa non esiste un obbligo equivalente, e la questione rimane affidata alla discrezionalità del produttore.

Le implicazioni di questa asimmetria diventano concrete nel momento in cui un componente software raggiunge il proprio end-of-support: da quel momento, le vulnerabilità che vengono scoperte non possono più essere rimediate attraverso patch ufficiali del fornitore, e il dispositivo che lo incorpora diventa progressivamente più esposto nel tempo.

Un utilizzatore europeo – tipicamente una struttura sanitaria – che non abbia ricevuto comunicazione preventiva su questa scadenza si trova a gestire un
rischio che non sapeva di correre, scoprendolo spesso solo quando la vulnerabilità è già nota e attivamente sfruttata.

Negli Stati Uniti, la stessa struttura sanitaria avrebbe invece potuto pianificare per tempo le proprie contromisure – sostituzione del dispositivo, segmentazione di rete, attivazione di compensating controls – disponendo di un’informazione che il sistema regolatorio impone al produttore di fornire.

La trasparenza sul ciclo di vita del software non è quindi un dettaglio tecnico di interesse secondario: è una componente essenziale della capacità di un utilizzatore di gestire consapevolmente il rischio cyber nel tempo.

Le implicazioni per i produttori italiani

Per un produttore italiano che voglia operare su entrambi i mercati, e che se soggetto alla NIS2 si trova già a gestire una compliance cyber security di natura organizzativa, il problema che si pone è quello di un doppio binario regolatorio:

• da un lato i requisiti del MDR e del D.Lgs. 138/2024;
• dall’altro le prescrizioni della Section 524B FDA, che si sovrappongono parzialmente ma non coincidono, richiedendo documentazione, processi e verifiche in larga parte distinti.

La compliance FDA comporta investimenti aggiuntivi che, per quanto variabili in funzione della complessità del dispositivo, sono quantificabili in ordini di grandezza precisi.

La componente una tantum – che comprende l’implementazione del tooling per la generazione dello SBOM, la predisposizione della documentazione di security architecture, lo svolgimento del penetration testing e il supporto della consulenza regolatoria specializzata nel mercato statunitense – si colloca in una forbice tra i 165.000 e i 320.000 euro per dispositivo.

A questa si aggiunge una componente ricorrente, stimabile tra gli 80.000 e i 135.000 euro annui, che copre la manutenzione continuativa dello SBOM,
l’operatività del processo di coordinated vulnerability disclosure, il testing periodico e l’aggiornamento della documentazione regolatoria al mutare del quadro normativo o delle caratteristiche del dispositivo.

Si tratta di cifre significative, ma che vanno lette nel contesto di un mercato – quello statunitense – che rappresenta la quota più rilevante dei ricavi globali del settore e che, per molti produttori, costituisce il principale driver di crescita internazionale.

Analisi costi-benefici: oltre il ritorno sull’investimento nel mercato Usa

I requisiti FDA rappresentano de facto lo stato dell’arte globale in cybersecurity dei dispositivi medici.

Adottarli proattivamente significa, in sintesi:

• Ridurre il rischio di breach: le vulnerabilità note (catalogate nel CISA Known Exploited Vulnerabilities) devono essere eliminate dal design secondo FDA; in Europa, possono essere mitigate con compensating controls, ma rimangono presenti.
• Prepararsi al Cyber Resilience Act: la proposta CRA, attualmente in fase di
  finalizzazione, converge verso il modello FDA (SBOM obbligatorio, vulnerability disclosure 24h, security-by-design).
• Migliorare la posizione assicurativa: le compagnie assicurative cyber premiano sempre più le organizzazioni con cyber security posture certificabile.

Cyber Resilience Act: non più un’ipotesi, ma una realtà di convergenza normativa

Il Cyber Resilience Act (Regolamento (UE) 2024/2847) è stato pubblicato in Gazzetta Ufficiale l’11 dicembre 2024 ed è entrato in vigore il 10 gennaio 2025.

Non si tratta più di una proposta in discussione, ma di un testo definitivo con tempistiche di applicazione già stabilite, la cui applicazione e portata appare ancora poco compresa dai player coinvolti.

La timeline è chiara:

• 11 settembre 2026: diventa obbligatoria la segnalazione delle vulnerabilità attivamente sfruttate (Art. 14);
• 11 dicembre 2027: applicazione completa dei requisiti sostanziali del regolamento.

Il CRA introduce requisiti che convergono significativamente con l’approccio FDA:

• il CRA introduce requisiti che convergono significativamente con l’approccio FDA;
• vulnerability disclosure con tempistiche stringenti;
• security-by-design obbligatorio.

Il CRA introduce requisiti che convergono significativamente con l’approccio FDA

L’Art. 13 del CRA richiede che i produttori forniscano una Software Bill of Materials (SBOM) “in formato elettronico comunemente utilizzato e machine-readable”.

Lo SBOM deve essere reso disponibile alle autorità e, in molti casi, anche agli utilizzatori. Questa è una convergenza quasi totale con il requisito FDA Section 524B(b)(3).

Vulnerability disclosure con tempistiche stringenti

L’Art. 14 impone ai produttori di notificare all’ENISA (e di riflesso alle autorità nazionali) le vulnerabilità attivamente sfruttate entro 24 ore dalla loro scoperta.

Questa timeline è persino più stringente della NIS2 e allineata con l’approccio FDA per “critical vulnerabilities causing uncontrolled risks”.

Security-by-design obbligatorio

Gli Artt. 10-11 del CRA stabiliscono requisiti essenziali di cyber security che devono essere integrati sin dalla fase di progettazione, in linea con il concetto di Secure Product Development Framework promosso dalla FDA.

La questione aperta: dispositivi medici, dentro o fuori

Il CRA prevede all’Art. 2, paragrafo 3, che i prodotti soggetti a normativa settoriale con requisiti cyber security “almeno equivalenti” possano essere esentati dall’applicazione del CRA per quegli aspetti già coperti dalla normativa specifica.
Qui si apre un interrogativo cruciale: il MDR può essere considerato “almeno equivalente” al CRA in materia di cyber security?

La risposta, allo stato attuale, è negativa per almeno tre ragioni:

• SBOM: il MDR non richiede SBOM pubblico, machine-readable, continuamente aggiornato.
• Vulnerability disclosure: il sistema di vigilanza MDR (Field Safety Notices) non prevede le tempistiche stringenti del CRA (24h per vulnerabilità attivamente sfruttate).
• Security-by-design prescrittivo: la guidance MDCG 2019-16 è principle-based, non prescrive framework specifici come il CRA.

È quindi altamente probabile che i dispositivi medici siano da intendere soggetti a un doppio regime:

• MDR per sicurezza funzionale, prestazioni cliniche, biocompatibilità.
• CRA per cybersecurity (SBOM, vulnerability management, secure development).

La Commissione Europea dovrà chiarire questo punto tramite atti delegati o implementing acts entro il 2026, considerando che l’industria non può permettersi di attendere.

Settembre 2026: la prima scadenza critica

Tra meno di otto mesi (settembre 2026) scatterà l’obbligo di notifica delle vulnerabilità attivamente sfruttate.

Per i produttori di dispositivi medici, questo significa:

• Avere un sistema di monitoraggio attivo che scansioni continuamente: a) CISA Known Exploited Vulnerabilities (KEV) Catalog; b) ENISA Vulnerability Database 9; c) CVE/NVD databases; d) Security advisories dei fornitori di componenti third-party.
• Avere un SBOM aggiornato e interrogabile per identificare immediatamente se una vulnerabilità divulgata pubblicamente impatta i propri dispositivi. Senza SBOM machine-readable, questo processo richiede giorni o settimane; con SBOM, può essere automatizzato in ore.
• Avere processi decisionali pre-definiti per classificare una vulnerabilità come “attivamente sfruttata” e attivare la notifica entro 24 ore. Questo richiede coordinamento tra team tecnici, legali e regulatory affairs.

Chi non si è ancora dotato di questi strumenti ha circa sei mesi per implementarli. Il rischio di non compliance non è teorico: il CRA prevede sanzioni fino a 15 milioni di euro o al 2,5% del fatturato globale annuo (Art. 63).

L’effetto convergenza: FDA + CRA come nuovo standard globale

L’adozione del Cyber Resilience Act crea una situazione normativa inedita: per la prima volta, Stati Uniti ed Europa convergono su requisiti cybersecurity prescrittivi per i prodotti, riducendo a pochi elementi residui le differenze tra i due sistemi.

L’obbligo di produrre uno SBOM in formato machine-readable è oggi presente in entrambi i quadri normativi, così come il requisito di security-by-design – declinato come Secure Product Development Framework dalla FDA e disciplinato dagli Artt. 10 e 11 del CRA in Europa – che persegue in entrambi i casi il medesimo obiettivo, pur attraverso approcci tecnici parzialmente diversi.

Anche la vulnerability disclosure è ora obbligatoria su entrambe le sponde
dell’Atlantico, con la differenza che il CRA impone una tempistica più stringente – ventiquattro ore per la notifica delle vulnerabilità attivamente sfruttate – rispetto al regime FDA, che richiede intervento il più tempestivamente possibile, senza fissare una scadenza oraria precisa.

L’unica area in cui permane una asimmetria significativa riguarda la comunicazione delle date di fine supporto dei componenti software: la FDA la impone esplicitamente come elemento del labeling, mentre il CRA la tratta in modo implicito nell’Art. 11, senza la stessa cogenza prescrittiva.

Si tratta tuttavia di una differenza destinata verosimilmente a ridursi con l’adozione degli atti delegati e delle specifiche tecniche che la Commissione Europea dovrà emanare in attuazione del Regolamento.

Il quadro complessivo che emerge è quello di una sostanziale armonizzazione globale degli standard di cyber security per i prodotti: un produttore che abbia raggiunto la piena conformità FDA si trova oggi in una posizione di vantaggio significativo rispetto alla compliance CRA, potendo riutilizzare larga parte della documentazione e dei processi già sviluppati per il mercato statunitense.

Questa convergenza ha un’implicazione strategica fondamentale: un dispositivo FDA-compliant è sostanzialmente CRA-ready, e viceversa.

I produttori che hanno già intrapreso il percorso di compliance FDA si trovano con un vantaggio competitivo significativo per il mercato europeo post-2027.

Qualche raccomandazione operative

Per i produttori italiani di dispositivi medici, la roadmap di compliance si articola attorno a tre orizzonti temporali che devono essere gestiti in parallelo, ciascuno con le proprie priorità operative.

La prima scadenza critica è settembre 2026, quando entra in vigore l’obbligo di notifica delle vulnerabilità attivamente sfruttate previsto dall’Art. 14 del CRA.

Entro quella data, i produttori devono aver implementato un sistema di generazione automatizzata dello SBOM in formato machine-readable – SPDX o CycloneDX sono i formati di riferimento – integrato con un sistema di vulnerability monitoring capace di generare alert in tempo reale sulle banche dati KEV e CVE.

Ma la componente tecnologica da sola non è sufficiente: serve un processo
decisionale pre-definito che consenta di classificare una vulnerabilità come “attivamente sfruttata” e di attivare la notifica all’ENISA entro le ventiquattro ore previste dal Regolamento.

Questo richiede che i team tecnici e legali siano già formati e allineati sulle rispettive responsabilità, prima che arrivi la prima notifica vera.

La seconda scadenza è dicembre 2027, quando il CRA diventa pienamente applicabile.

Entro quella data, i processi di security-by-design devono essere documentati in conformità agli Artt. 10 e 11 del Regolamento, la vulnerability disclosure policy deve essere pubblica e operativa, il labeling deve essere aggiornato con lo SBOM accessibile agli utilizzatori, e il produttore deve aver condotto un security assessment formale secondo i requisiti essenziali dell’Annex I CRA.

Si tratta di un lavoro sostanziale che, se avviato solo nel 2027, non potrà essere completato in tempo.

Accanto a queste due scadenze puntuali esiste infine una dimensione di compliance continua, che non ha una data di completamento ma deve diventare parte integrante del ciclo di sviluppo e manutenzione del prodotto.

Il security risk management deve essere condotto come processo separato rispetto al safety risk management previsto da ISO 14971, pur mantenendo i necessari punti di interfaccia tra i due. Il penetration testing deve avere cadenza regolare, almeno annuale.

Lo SBOM deve essere aggiornato ad ogni release del software, idealmente attraverso integrazione automatizzata nella pipeline CI/CD. I componenti software devono essere monitorati rispetto alle loro date di fine supporto, con un preavviso operativo di almeno dodici-diciotto mesi per pianificare la sostituzione o le misure di mitigazione alternative.

Il ruolo cruciale degli organismi notificati

Con l’entrata in vigore del Cyber Resilience Act, gli Organismi Notificati si trovano a dover affrontare una sfida che va ben oltre il semplice aggiornamento delle proprie procedure interne.

Fino ad oggi, la valutazione della cybersecurity dei dispositivi medici si è svolta prevalentemente attraverso il prisma delle norme armonizzate – IEC 62304 per lo sviluppo del software, IEC 62443 per la sicurezza dei sistemi industriali – che fornivano un quadro di riferimento tecnico consolidato, ancorché non sempre adeguato alla specificità delle minacce cyber.

Con il CRA, il riferimento normativo cogente si amplia e si fa più prescrittivo: gli ON sono ora chiamati a valutare la conformità dei dispositivi rispetto a requisiti che vanno oltre la tradizionale verifica documentale e richiedono competenze tecniche specialistiche che molti di essi non hanno ancora sviluppato in modo sistematico.

Le aree di maggiore criticità sono quelle che caratterizzano precisamente l’approccio FDA e che il CRA ora importa nel sistema europeo:

• la capacità di valutare un threat model strutturato, verificando che il produttore abbia identificato in modo esaustivo i vettori di attacco rilevanti per il dispositivo e il sistema in cui opera;
• la competenza per giudicare l’adeguatezza di un penetration testing, distinguendo tra un’attività superficiale e una genuinamente approfondita; la capacità di verificare la completezza e la correttezza di uno SBOM machine-readable, controllando che rifletta effettivamente tutti i componenti software del dispositivo;
• e infine la comprensione del vulnerability management lifecycle, per valutare se i processi del produttore siano realmente in grado di identificare, classificare e rimediare le vulnerabilità in tempi compatibili con le scadenze imposte dal Regolamento.

Su queste competenze, il livello di preparazione degli ON europei è oggi disomogeneo, e questa disomogeneità rischia di tradursi, ancora una volta, in una variabilità degli assessment che il CRA intendeva invece uniformare.

Organismi di certificazione per la conformità al CRA

È ragionevole attendersi che nei prossimi mesi emergeranno organismi di certificazione accreditati specificamente per la conformità al CRA, come previsto dall’Art. 47 del Regolamento, che potranno affiancare gli Organismi Notificati nelle valutazioni cyber security, colmando almeno in parte il deficit di competenze specialistiche descritto.

Questo scenario apre tuttavia una questione di coordinamento ancora irrisolta: come si articolerà il rapporto tra la certificazione CRA e la valutazione MDR quando entrambe insistono sullo stesso dispositivo, e quale delle due prevarrà in caso di valutazioni divergenti.

In questo contesto di incertezza, i produttori farebbero bene ad adottare un approccio proattivo piuttosto che attendere che il quadro si consolidi.

Il primo passo è aprire un dialogo diretto con il proprio Organismo Notificato per comprendere come intenda integrare i requisiti CRA nelle valutazioni MDR già in corso, evitando di scoprire a submission avviata che le aspettative dell’ON divergono dalla documentazione predisposta.

Prima di arrivare alla submission formale, può essere opportuno sottoporre il dispositivo a un assessment preliminare condotto da enti specializzati in cyber security, capaci di identificare i gap rispetto ai requisiti CRA con il livello di profondità tecnica che un ON generalista potrebbe non garantire.

È altresì importante chiedere esplicitamente a proprio ON quali standard interpretativi intenda adottare nell’applicazione del CRA: la scelta tra riferimenti tecnici diversi – come l’ETSI EN 303 645 per la sicurezza dei dispositivi IoT o le norme della famiglia IEC 62443 – non è neutrale e può avere implicazioni significative su quali evidenze documentali saranno ritenute sufficienti a dimostrare la conformità.

Cyber security per i dispositivi medici: una finestra di opportunità che si chiude

Il Cyber Resilience Act trasforma radicalmente il panorama regolatorio europeo. Entro settembre 2026 – tra meno di sette mesi – scatta il primo obbligo concreto (notifica vulnerabilità).

Entro dicembre 2027 tra diciotto mesi – la conformità deve essere completa.
Per i produttori italiani ed europei, questo non è più tempo di pianificazione strategica: è tempo di esecuzione operativa.

Chi ha già avviato percorsi di compliance FDA si trova in una posizione privilegiata, potendo riutilizzare gran parte della documentazione e dei processi.

Chi invece ha rimandato, pensando al CRA come a un problema del 2027, si trova ora con un gap di diciotto mesi da colmare su più fronti contemporaneamente.
La cybersecurity dei dispositivi medici non è più un tema di nicchia o un “nice to have” per chi esporta negli USA. È diventata un requisito cogente pan-europeo, con sanzioni significative per chi non si adegua e, soprattutto, con impatti reali sulla sicurezza dei pazienti.

L’industria italiana dei dispositivi medici – forte di eccellenze riconosciute a livello globale – ha l’opportunità di trasformare questo cambio normativo in un vantaggio competitivo, anticipando gli standard globali e posizionandosi come leader nella security-by-design.

Ma la finestra di opportunità si chiude rapidamente.

La domanda non è più “se” adeguarsi, né “quando”: è “quanto velocemente”. E la risposta dovrebbe essere una sola: immediatamente.

Bibliografia

[1] L’autore: fellow dell’ISLC (information Society Law Center dell’Università degli Studi di Milano) specializzato in corporate liability, cybersecurity e compliance normativa, con focus su NIS2, AI Act, MDR e Cyber Resilience Act, è Legal Specialist presso CCLEX (Studio Legale Associato Colombo Caramori) e Head Of Legal presso Rights Chain Ltd -London.
[2] Nel sistema regolatorio statunitense, i produttori di dispositivi medici devono ottenere l’autorizzazione della FDA prima di immettere un prodotto sul mercato attraverso specifiche procedure di submission premarket. Il 510(k) è la procedura più comune, applicabile ai dispositivi che possono dimostrare sostanziale equivalenza a un dispositivo già legalmente commercializzato (il cosiddetto “predicate device”); non richiede la dimostrazione diretta di sicurezza ed efficacia, ma che il nuovo dispositivo non sollevi nuove questioni di sicurezza rispetto al predicate.

Il PMA (Premarket Approval) è invece la procedura più stringente, riservata ai dispositivi di Classe III – quelli che supportano o sostengono la vita, o che presentano un rischio potenziale di danno grave – e richiede la dimostrazione positiva di sicurezza ed efficacia attraverso evidenze cliniche. Il De Novo è una procedura introdotta per dispositivi innovativi a rischio basso o moderato che non hanno un predicate device idoneo per il percorso 510(k): consente di stabilire una nuova classificazione regolatoria per tipologie di
dispositivi non precedentemente disciplinate.

L’HDE (Humanitarian Device Exemption) è infine un regime speciale pensato
per dispositivi destinati alla diagnosi o al trattamento di patologie rare che colpiscono meno di ottomila pazienti l’anno negli Stati Uniti, per i quali i requisiti di dimostrazione di efficacia sono attenuati in considerazione della limitata popolazione disponibile per gli studi clinici. Tutte queste procedure, pur differendo per requisiti e soglie di evidenza, costituiscono i principali percorsi attraverso cui la FDA esercita il controllo premarket sui dispositivi medici immessi sul mercato statunitense.

[3] La norma UNI CEI EN ISO 14971:2022 (ultima versione armonizzata) definisce i requisiti, i principi e il processo per la gestione dei rischi associati ai dispositivi medici. Guida i produttori a identificare i pericoli, stimare, valutare, controllare e monitorare i rischi durante tutto il ciclo di vita (progettazione, produzione, post-produzione). È lo standard internazionale di
riferimento per la sicurezza dei pazienti e la conformità al Regolamento UE 2017/745 (MDR).