Come dimostrano i fabbricanti la cybersecurity dei loro dispositivi medici in modo solido per l'intero ciclo di vita del prodotto?
Affianchiamo i fabbricanti di dispositivi medici connessi e basati su software nella costruzione di una dimostrazione di cybersecurity end-to-end: dal Threat Modeling e dal Secure Development Lifecycle alla software bill of materials (SBOM) fino al monitoraggio delle vulnerabilità post-commercializzazione. La cybersecurity nell'ambito del Regolamento (UE) 2017/745 (MDR) non è una disciplina separata, ma parte dei requisiti generali di sicurezza e prestazione. Il vero collo di bottiglia è che la stessa analisi delle minacce deve alimentare la gestione del rischio, la documentazione tecnica e il sistema post-market, invece di esistere come documento isolato.
- MedTech
- IVD
Panoramica
Quali requisiti di cybersecurity pongono MDR e FDA ai fabbricanti?
Cybersecurity per l'intero ciclo di vita · MDR (UE 2017/745), MDCG 2019-16, IEC 81001-5-1, IEC 62304
Ultimo aggiornamento: 2026-06-13
I dispositivi medici connessi e basati su software sono al contempo superficie di attacco e prodotto regolamentato. I requisiti si distribuiscono su diversi corpus normativi che richiedono la stessa dimostrazione da angolazioni diverse. I punti in cui la dimostrazione si blocca più frequentemente:
- La MDR (UE 2017/745) non tratta la sicurezza informatica separatamente: l'Allegato I richiede per i sistemi elettronici programmabili uno sviluppo secondo lo stato dell'arte, inclusa la protezione contro gli accessi non autorizzati. La cybersecurity è quindi parte dei requisiti generali di sicurezza e prestazione, non un documento aggiuntivo.
- Le linee guida MDCG 2019-16 specificano come questi GSPR vengono dimostrati all'Organismo Notificato: analisi delle minacce, requisiti di security, verifica e un piano per la fase post-commercializzazione devono essere inclusi nella documentazione tecnica.
- Cybersecurity e gestione del rischio secondo ISO 14971 devono essere integrate: i rischi di security che possono causare danni ai pazienti confluiscono nell'analisi del rischio relativa al prodotto. AAMI TIR57 descrive il collegamento tra la gestione del rischio di security e quella di safety.
- Per il mercato statunitense il FD&C Act Section 524B richiede per i Cyber Device tra l'altro un piano per la gestione delle vulnerabilità post-commercializzazione e una software bill of materials (SBOM). Una Premarket Submission priva di questi elementi viene respinta dalla FDA come incompleta (Refuse to Accept) dal ottobre 2023.
- Il Secure Development Lifecycle secondo IEC 81001-5-1 e il ciclo di vita del software secondo IEC 62304 devono essere integrati affinché le attività di security si aggancino alla documentazione software già richiesta invece di procedere in parallelo.
Servizi
Come la supportiamo
Threat Modeling e analisi del rischio di security
Analisi sistematica delle minacce al prodotto e alle sue interfacce, documentata come Threat Model tracciabile che confluisce nella gestione del rischio secondo ISO 14971 e nelle prove GSPR della MDR, costituendo la base per ogni ulteriore dimostrazione di cybersecurity.
Secure Development Lifecycle
Sviluppo di un ciclo di vita della security secondo IEC 81001-5-1, integrato con il ciclo di vita del software secondo IEC 62304, con requisiti di security definiti, misure di design e prove di verifica per la documentazione tecnica.
Scopri di più →Gestione SBOM
Creazione e manutenzione di una software bill of materials che registra tutti i componenti incluse le librerie open source e di terze parti, come base per il monitoraggio delle vulnerabilità e come elemento obbligatorio della FDA submission secondo Section 524B.
Cybersecurity post-market
Sviluppo di un processo per il monitoraggio delle nuove vulnerabilità, la valutazione del loro impatto sul proprio prodotto e la risoluzione coordinata, con raccordo alla Post-Market Surveillance e al sistema di segnalazione secondo la MDR.
Scopri di più →Documentazione tecnica cybersecurity
Consolidamento di Threat Model, requisiti di security, prove di verifica e piano post-market in un dossier cybersecurity verificabile secondo MDCG 2019-16 come parte della documentazione tecnica.
Gap analysis e preparazione all'audit
Analisi di conformita della documentazione di security esistente rispetto a MDR GSPR, MDCG 2019-16 e requisiti FDA, con elenco di misure prioritizzato prima dell'audit dell'Organismo Notificato o della sottomissione FDA.
Come collaboriamo
Cosa conta davvero
La cybersecurity nei dispositivi medici raramente fallisce per una singola misura, ma per la sequenza e la mancata integrazione. Il punto di partenza è il Threat Model: chi non rileva sistematicamente le minacce e i vettori di attacco fin dall'inizio, deriva in seguito i requisiti di security dall'intuizione invece che da un'analisi tracciabile. Dal Threat Model derivano due filoni: i rischi di security nella gestione del rischio secondo ISO 14971, attraverso il collegamento che AAMI TIR57 descrive, e i requisiti di security nel processo di sviluppo. Entrambi devono provenire dalla stessa fonte, altrimenti si generano le contraddizioni tra il fascicolo di cybersecurity e l'analisi del rischio che nell'audit dell'Organismo Notificato emergono per prime.
Il secondo collo di bottiglia si trova dopo la commercializzazione. La SBOM non è un documento di sottomissione, ma un registro vivente: solo il costante raffronto con le vulnerabilità di nuova scoperta la trasforma nella prova che il FD&C Act Section 524B e MDCG 2019-16 richiedono. Per questo pianifichiamo il processo post-market già quando nasce la documentazione tecnica, e lo raccordiamo alla Post-Market Surveillance e al sistema di segnalazione secondo la MDR (UE 2017/745). In questo modo la cybersecurity passa da capitolo aggiuntivo a un filone che alimenta le stesse prove che il prodotto deve comunque fornire.
Il nostro approccio
Il nostro approccio
Fase
Risultato
Scoping e gap analysis
Ricognizione di architettura, interfacce e documentazione esistente; elenco di lacune prioritizzato rispetto a MDR GSPR, MDCG 2019-16 e requisiti FDA.
Threat Modeling
Threat Model documentato con minacce identificate, vettori di attacco e requisiti di security derivati.
Valutazione del rischio di security
Rischi di security valutati e trasferiti nella gestione del rischio secondo ISO 14971, collegamento tra security e safety stabilito secondo AAMI TIR57.
SBOM e misure di security
Software bill of materials aggiornata, misure di design e verifica implementate lungo IEC 81001-5-1 e IEC 62304.
Dossier cybersecurity
Documentazione cybersecurity verificabile secondo MDCG 2019-16 come parte della documentazione tecnica, preparata per l'Organismo Notificato o la FDA.
Esercizio post-market
Processo stabilito per il monitoraggio delle vulnerabilità e la risoluzione coordinata, raccordato alla Post-Market Surveillance e al sistema di segnalazione.
Errori tipici
Perché i progetti spesso falliscono
La cybersecurity viene gestita come documento autonomo separato dalla gestione del rischio.
I rischi di security che possono causare danni ai pazienti devono secondo AAMI TIR57 confluire nell'analisi del rischio relativa al prodotto secondo ISO 14971. Un fascicolo separato genera contraddizioni che emergono nell'audit dell'Organismo Notificato.
La SBOM viene creata una volta per la sottomissione e poi non aggiornata.
Una software bill of materials ha valore solo se viene continuamente verificata rispetto alle nuove vulnerabilità; una SBOM obsoleta non soddisfa né lo scopo del FD&C Act Section 524B né il monitoraggio post-market secondo MDCG 2019-16.
La parte post-market della cybersecurity viene pianificata solo dopo la commercializzazione.
MDCG 2019-16 e Section 524B richiedono già prima della sottomissione un piano per la gestione delle vulnerabilità post-commercializzazione. Chi lo presenta in ritardo rischia richieste di integrazioni invece di un percorso di approvazione lineare.
I componenti open source e di terze parti non vengono registrati sistematicamente.
Proprio questi componenti sono una fonte frequente di vulnerabilità note; senza una SBOM completa non è possibile dimostrare, in seguito a un avviso di sicurezza, se il proprio prodotto è interessato.
Il ciclo di vita della security procede in parallelo al ciclo di vita del software secondo IEC 62304 invece di essere integrato con esso.
Se i requisiti di security non vengono collegati ai requisiti software e ai test già richiesti, si generano documentazione doppia e lacune nella verifica.
FAQ
Domande frequenti
Fonti
- Regolamento (UE) 2017/745 (MDR), testo primario, Allegato I (GSPR, sistemi elettronici programmabili)
- Regolamento (UE) 2017/746 (IVDR), testo primario, requisiti generali di sicurezza e prestazione
- MDCG 2019-16, Guidance on Cybersecurity for medical devices
- IEC 81001-5-1, IEC 62304, IEC 62443, ISO 14971, AAMI TIR57
- FD&C Act Section 524B (Ensuring Cybersecurity of Devices)
- https://theentourage.de/clinical-medical-affairs/cybersecurity-embedded-systems/ (contenuto pagina esistente, revisionato)
Life Science Journal
Aggiornamenti regolatori, direttamente nella Sua casella di posta.
Nuovi requisiti, decisioni delle autorità e indicazioni pratiche. Una volta al mese, cancellazione possibile in qualsiasi momento.
Case Study
Come si presenta nella pratica
Normative e standard considerati
- Regolamento (UE) 2017/745 (MDR)
- MDR Allegato I (Requisiti generali di sicurezza e prestazione, GSPR)
- Regolamento (UE) 2017/746 (IVDR)
- MDCG 2019-16 (Guidance on Cybersecurity for medical devices)
- IEC 81001-5-1 (Security nel ciclo di vita del software sanitario)
- IEC 62304 (Ciclo di vita del software per dispositivi medici)
- IEC 62443 (Security per sistemi di automazione e controllo industriale)
- ISO 14971 (Gestione del rischio)
- AAMI TIR57 (Principles for medical device security - risk management)
- FD&C Act Section 524B (Cyber Devices, USA)
Argomenti correlati
Gestione del rischio →
Trasferire i rischi di security nell'analisi del rischio secondo ISO 14971
Design Controls →
Radicare i requisiti di security nel processo di sviluppo
Post-Market Surveillance →
Raccordare il monitoraggio delle vulnerabilità a PMS e sistema di segnalazione
MDR Consulting →
Cybersecurity come parte delle prove GSPR secondo Regolamento (UE) 2017/745
Un progetto concreto in merito?
Ci descriva brevemente la sua situazione di partenza. Ci facciamo vivi con una prima valutazione, di norma entro un giorno lavorativo.
Preferisce il contatto diretto? +49 89 4161170-0
info@theentourage.de
- Risposta di norma entro un giorno lavorativo
- 4 sedi: DE · CH · IT · US
- 100% Life Sciences