Prove di cybersicurezza dei dispositivi medici

Sytance · Aggiornato 6 ottobre 2026

Le prove di cibersicurezza dei dispositivi medici verificano se i requisiti di sicurezza e i controlli del rischio funzionino nella configurazione prevista del dispositivo. I risultati devono indicare le condizioni di prova e il comportamento osservato, così che i revisori possano valutare cosa dimostrino le prove sul prodotto.

Scopo delle prove

L’ambito delle prove deriva dalle minacce e dai requisiti di sicurezza del dispositivo. Se solo un account di servizio autorizzato può modificare la configurazione, provare l’interfaccia diretta sia con account consentiti sia con account vietati e verificare se le impostazioni memorizzate cambiano.

Evidenze pre-market

Il fascicolo pre-market utilizza le prove per supportare la verifica e la convalida della progettazione, l’efficacia dei controlli di sicurezza e l’adeguatezza dei controlli del rischio.

Evidenze post-market

Il processo post-market utilizza le prove per valutare nuove vulnerabilità, verificare le correzioni, individuare regressioni e mantenere la fiducia nelle versioni distribuite.

Ambito delle prove pre-market

L’attuale guida FDA pre-market individua diversi tipi di prove e analisi di cibersicurezza che possono essere inclusi in una presentazione. Questa dovrebbe spiegare perché le prove selezionate siano adeguate ai rischi, all’architettura e ai controlli del dispositivo.

Prove dei requisiti di sicurezza

Prove di mitigazione delle minacce

Prove di vulnerabilità

Penetration test

Una sola scansione non basta

Una scansione delle vulnerabilità segnala i rilievi compresi nella propria copertura. Può individuare una debolezza nota in un servizio di rete, mentre serve una prova separata per verificare se il dispositivo rifiuti un comando non autorizzato o si ripristini dopo un aggiornamento non riuscito. Valutare l’impatto sui pazienti sulla base dell’architettura del dispositivo e dell’analisi dei rischi.

Una scansione delle vulnerabilità può individuare problemi noti, ma può non rilevare difetti progettuali e ipotesi di fiducia non sicure.
L’analisi statica può individuare debolezze nel codice, ma non dimostra la configurazione distribuita né il comportamento dei controlli in fase di esecuzione.
Il fuzz testing può rivelare la gestione degli input malformati, ma non sostituisce la revisione dell’architettura o i penetration test.
I penetration test possono mostrare percorsi di sfruttamento, ma restano limitati dall’ambito, dal tempo, dall’accesso del tester e dalla metodologia.

I rilievi alimentano la gestione dei rischi

I rilievi delle prove dovrebbero essere valutati per l’impatto sulla sicurezza e collegati al processo di gestione dei rischi di cibersicurezza. La FDA spiega che un’anomalia di sicurezza può richiedere una mitigazione perché la sua sfruttabilità può causare un tipo di danno diverso da quello di un normale difetto software.

Valutazione dei rilievi

I rapporti dovrebbero descrivere il rilievo, il componente o l’interfaccia interessati, la sfruttabilità, le versioni coinvolte, lo stato dei controlli e le possibili conseguenze per i pazienti.

Correzione rinviata

Se una correzione viene rinviata, il fascicolo dovrebbe spiegare la motivazione basata sul rischio, il rilascio previsto, i dispositivi interessati già in uso e le modalità con cui l’aggiornamento li raggiungerà.

Prove post-market

La FDA raccomanda prove di sicurezza durante lo sviluppo e dopo il rilascio a intervalli commisurati al rischio. Una modifica al meccanismo di aggiornamento, ad esempio, può richiedere nuove prove di integrità e ripristino. La divulgazione di una vulnerabilità di un componente può richiedere un’indagine e prove di regressione della correzione.

Nella documentazione UE, i risultati della verifica supportano la valutazione dei rischi e possono individuare modifiche necessarie al dispositivo o alle relative istruzioni. MDCG 2019-16 spiega come queste attività proseguano dopo il rilascio. IEC 81001-5-1 fornisce un processo del ciclo di vita per mantenerle.