Cyberattacchi e blackout digitali: se LIS, cloud e FSE non rispondono, la diagnostica di prossimità può proteggere la continuità — oppure moltiplicare gli errori
Il 22 luglio 2026 ENISA ha pubblicato nuove linee di indirizzo per inserire la cybersicurezza nell’intero ciclo di acquisto sanitario, includendo dispositivi medici e IVD. Il vero banco di prova, però, arriva dopo l’acquisto: che cosa accade a identità, controlli, risultati critici e tracciabilità quando un POCT resta acceso ma la rete non è più disponibile?
Alle 8:12 il controllo di qualità è accettabile. L’analizzatore è pronto. Il campione viene processato e il risultato compare sul display.
Alle 8:13 il middleware restituisce un’altra informazione: server non raggiungibile.
Il valore esiste, ma non raggiunge la cartella. Il paziente è davanti all’operatore, ma l’anagrafica centrale non risponde. Il medico non vede il dato. Il Fascicolo sanitario elettronico è fuori dal percorso. L’assistenza remota del fornitore non può collegarsi.
Che cosa si fa?
Si consegna il risultato su carta? Si continua a eseguire test? Chi controlla che il profilo selezionato sia corretto? Come viene comunicato un valore critico? Quando la rete tornerà disponibile, chi impedirà che lo stesso esame venga caricato due volte o attribuito all’episodio sbagliato?
Il dispositivo non è guasto. Ed è proprio questo a rendere la situazione insidiosa.
Un POCT può continuare a misurare durante un incidente digitale. Ma produrre un numero non significa mantenere in funzione il processo diagnostico.
La notizia: la cybersicurezza entra nel capitolato sanitario
Il 22 luglio 2026 ENISA ha annunciato i primi passi operativi del piano europeo per la cybersicurezza di ospedali e prestatori sanitari. L’Agenzia dell’Unione europea per la cybersicurezza e la Commissione hanno sottoscritto un accordo triennale da sei milioni di euro per sostenere preparazione, rilevazione, risposta e governance.
Nello stesso giorno ENISA ha pubblicato le nuove Procurement Guidelines for the Cybersecurity of Hospitals and Healthcare Providers.
Il documento è una guida, non una legge e non sostituisce gli obblighi nazionali o regolatori applicabili. Il suo segnale politico e organizzativo è però netto: la cybersicurezza non dovrebbe essere valutata dopo l’installazione, quando emerge una vulnerabilità. Deve entrare nella pianificazione, nella selezione del fornitore, nel contratto, nella manutenzione e nella dismissione.
Tra le tecnologie espressamente considerate compaiono:
- dispositivi medici e IVD;
- sistemi informativi clinici e di laboratorio;
- cartelle elettroniche;
- servizi cloud;
- sistemi di identificazione;
- telemedicina e assistenza remota;
- infrastrutture di rete e fornitori di servizi gestiti.
È la descrizione reale di una rete POCT. L’analizzatore è soltanto uno dei nodi.
Non serve necessariamente un criminale
Quando si parla di cybersicurezza sanitaria, l’immaginario corre subito al ransomware, al riscatto e alla sottrazione di dati. Sono minacce reali. ENISA rileva da anni una forte esposizione del settore sanitario e indica il ransomware tra gli attacchi più ricorrenti.
Ma dal punto di vista clinico l’effetto da governare è più ampio: l’indisponibilità o l’inaffidabilità del sistema. Può essere provocata da un attacco, da un aggiornamento errato, da una configurazione difettosa, dalla perdita della connettività, da un certificato scaduto o dal guasto di un fornitore esterno.
Uno studio pubblicato nel 2025 su JAMA Network Open ha analizzato l’interruzione mondiale provocata il 19 luglio 2024 da un aggiornamento software difettoso. Tra 2.232 ospedali statunitensi osservabili, 759 — il 34% — mostrarono una perdita di risposta dei servizi di rete. Dei 1.098 servizi distinti risultati indisponibili, il 21,8% era rivolto direttamente ai pazienti e il 15,4% aveva una funzione operativa.
Lo studio non dimostra che ogni servizio clinico interno fosse fermo e riguarda organizzazioni statunitensi con caratteristiche specifiche. Mostra però che un singolo evento nella catena tecnologica può propagarsi rapidamente a strutture differenti, anche senza un attaccante.
La domanda corretta non è quindi soltanto «siamo protetti dagli hacker?». È: sappiamo curare e produrre risultati affidabili quando una parte della tecnologia non è disponibile?
Quando il laboratorio torna alla carta
Un caso di studio pubblicato nel 2025 ha ricostruito l’attività di un laboratorio universitario durante un attacco informatico. La sospensione immediata del LIS e dell’automazione impose il passaggio a richieste cartacee e trascrizioni manuali con doppia verifica.
I servizi critici furono mantenuti, ma i volumi degli esami di routine diminuirono nettamente nella prima settimana. Una funzionalità limitata del LIS fu ripristinata su rete locale entro il terzo giorno; gran parte dei servizi tornò operativa entro il decimo. Per un ritorno sostanziale alla normalità servirono circa due mesi.
Un secondo studio del 2026 su un laboratorio di patologia chimica sudafricano ha raccolto il punto di vista di 58 clinici dopo un attacco ransomware: l’84% riferiva un aumento dello stress e il 78% ritardi diagnostici. I volumi risultavano ridotti del 26,8% per la creatinina e del 34,1% per la vitamina B12.
Sono evidenze provenienti da singoli contesti e, nel secondo caso, in parte basate sulla percezione dei professionisti. Non permettono di calcolare il rischio di una farmacia o di una Casa della comunità italiana.
Documentano però un fenomeno concreto: quando il sistema digitale cade, il lavoro non torna semplicemente a «come si faceva prima». Tornano insieme carta, telefonate, doppie registrazioni, informazioni incomplete, code, ritardi e riconciliazioni successive.
Il paradosso del POCT
La diagnostica di prossimità può essere una risorsa straordinaria durante un’interruzione.
Un dispositivo localmente autonomo può continuare a produrre glicemia, emogas, elettroliti, emoglobina, INR o altri parametri essenziali vicino al paziente, senza attendere il trasporto del campione e la piena disponibilità dell’automazione centrale.
Ma lo stesso decentramento può amplificare il disordine se ogni sede improvvisa una propria soluzione.
Il POCT offline rischia di perdere:
- verifica anagrafica sul sistema centrale;
- autorizzazione e competenza aggiornata dell’operatore;
- ricezione della richiesta e della finalità clinica;
- sincronizzazione dell’ora;
- conferma centralizzata dello stato dei controlli di qualità;
- trasmissione di risultato, unità, flag e intervalli;
- notifica automatica dei valori critici;
- visibilità sul lotto e sulla versione software;
- controllo della flotta da parte del coordinatore;
- collegamento con LIS, cartella clinica e FSE.
Un analizzatore può quindi essere disponibile mentre l’ecosistema che rende utilizzabile il suo risultato è degradato.
La vera resilienza non coincide con la capacità della macchina di accendersi senza internet. Consiste nel mantenere identità, integrità, significato e presa in carico del dato durante tutta l’interruzione e nel ritorno alla normalità.
Tre condizioni che non devono essere confuse
Modalità online: dispositivo, identificazione, controlli, middleware, documentazione e destinatari operano secondo il flusso validato.
Modalità degradata: alcune funzioni non sono disponibili, ma esiste un percorso alternativo autorizzato, tracciabile e testato. Il servizio può continuare entro limiti dichiarati.
Modalità isolata o non sicura: non è possibile dimostrare identità, controllo analitico, autorizzazione dell’operatore, integrità del dato o comunicazione del risultato. In questa condizione continuare tutti i test non è resilienza: può essere esposizione del paziente a un rischio non governato.
La distinzione deve essere stabilita prima dell’incidente. Altrimenti sarà la pressione del momento a decidere quali garanzie sacrificare.
Che cosa chiedono IVDR e norme di cybersicurezza
L’allegato I del Regolamento (UE) 2017/746 richiede, per i dispositivi che incorporano software o costituiscono software, che il fabbricante definisca i requisiti minimi relativi all’hardware, alle caratteristiche delle reti informatiche e alle misure di sicurezza necessarie, compresa la protezione contro accessi non autorizzati.
La Commissione raccoglie inoltre tra i riferimenti applicativi la MDCG 2019-16 rev.1 sulla cybersicurezza dei dispositivi medici. Le linee MDCG non sono giuridicamente vincolanti, ma esprimono un orientamento europeo su sicurezza per progettazione, gestione del rischio, aggiornamenti e responsabilità lungo il ciclo di vita.
Il punto da non confondere è questo: la conformità IVDR del dispositivo riguarda anche i rischi informatici pertinenti al prodotto, ma non può progettare da sola la continuità operativa dell’organizzazione che collega quel dispositivo a identità, reti, cloud e percorsi clinici.
Sul piano organizzativo, il decreto legislativo 4 settembre 2024, n. 138 ha recepito in Italia la direttiva NIS2. Il settore sanitario compare tra quelli altamente critici; anche la fabbricazione di dispositivi medici e IVD è considerata nel quadro previsto dal decreto.
Questo non significa che ogni farmacia, laboratorio, distributore o piccolo fabbricante sia automaticamente soggetto a tutti gli obblighi NIS2. Contano tipologia, dimensioni, criteri applicabili e identificazione nel sistema nazionale. Sarebbe scorretto trasformare il nome della direttiva in un’etichetta universale.
Il principio, però, supera il perimetro formale: gestione del rischio, continuità, sicurezza della catena di fornitura e risposta agli incidenti sono requisiti di buona governance anche per le organizzazioni non direttamente qualificate come soggetti NIS.
Anche l’articolo 32 del GDPR richiama riservatezza, integrità, disponibilità e resilienza dei sistemi, oltre alla capacità di ripristinare tempestivamente accesso e disponibilità dei dati dopo un incidente.
La disponibilità non è quindi un lusso informatico. Nel settore sanitario può diventare una condizione della sicurezza delle cure.
La novità ENISA: comprare anche il giorno del guasto
Le linee ENISA di luglio 2026 suggeriscono di valutare la cybersicurezza nelle fasi di pianificazione, selezione e gestione del contratto.
Tra le misure indicate figurano:
- inventario aggiornato di sistemi e fornitori critici;
- gestione delle vulnerabilità e degli aggiornamenti;
- segmentazione delle reti dei dispositivi;
- accesso remoto del fornitore preventivamente autorizzato, limitato nel tempo, protetto con MFA e registrato;
- aggiornamenti distribuiti attraverso canali cifrati e firmati;
- obblighi contrattuali di comunicazione degli incidenti e delle vulnerabilità;
- tempi definiti per correzioni e supporto;
- piani di continuità che comprendano disponibilità dei dispositivi, sistemi di riserva o alternative manuali;
- prove documentate del failover e revisione del piano dopo le esercitazioni;
- gestione sicura del fine vita e cancellazione dei dati dai dispositivi dismessi.
ENISA propone persino che i fornitori partecipino, quando pertinente, alle esercitazioni di continuità. È un passaggio culturale importante: non basta che l’azienda prometta assistenza. Deve essere chiaro come collaborerà quando il cliente non può più utilizzare i canali ordinari.
Le domande che dovrebbero entrare nel contratto POCT
Prima di acquistare un sistema connesso, una struttura dovrebbe ottenere risposte verificabili almeno su questi punti:
- Il dispositivo può operare senza rete? Per quanto tempo e con quali funzioni disattivate?
- Quanti risultati può conservare localmente e come ne protegge integrità e riservatezza?
- Quali identificativi minimi sono obbligatori durante l’offline?
- Che cosa accade alle credenziali e alle autorizzazioni dell’operatore se il server non risponde?
- Lo stato dei controlli di qualità viene conservato e applicato localmente?
- Come vengono gestiti data, ora e fuso orario durante la perdita di sincronizzazione?
- Alla riconnessione, come sono riconosciuti duplicati, conflitti e record temporanei?
- È possibile esportare i dati in un formato utilizzabile senza dipendere dal cloud del fornitore?
- Chi viene avvisato quando emerge una vulnerabilità e in quale tempo?
- Chi autorizza, verifica e documenta patch e aggiornamenti?
- Come avviene l’assistenza remota e quali registri lascia?
- Qual è la data di fine supporto di sistema operativo, dispositivo e middleware?
Una risposta commerciale come «funziona anche offline» non è sufficiente. Occorre una dimostrazione nello scenario reale, con il dispositivo configurato, la rete isolata e il successivo riallineamento dei dati.
Una procedura per il risultato nato durante il buio digitale
Il piano di continuità di una rete POCT dovrebbe seguire il singolo risultato dall’inizio alla fine.
Dichiarazione dell’incidente. Deve esistere un’autorità che dichiara l’inizio della modalità degradata, assegna un codice all’evento e comunica quali sistemi sono affidabili, quali sono indisponibili e quali test possono continuare.
Selezione delle prestazioni. Durante un’interruzione prolungata può essere necessario sospendere attività differibili e riservare risorse, consumabili e personale alle prestazioni con effettivo impatto clinico immediato.
Identificazione alternativa. Devono essere definiti identificatori obbligatori, gestione di omonimi e record temporanei, etichette di emergenza e regole per pazienti incapaci di rispondere. Un numero provvisorio deve poter essere riconciliato senza cancellare la storia.
Qualità analitica locale. Il dispositivo deve rendere disponibili stato dei controlli, lotto, scadenza, manutenzione e flag anche senza server centrale. Se questi elementi non sono verificabili, il protocollo deve dire quando fermarsi.
Documento riconoscibile. Il risultato prodotto durante il downtime dovrebbe essere chiaramente identificato come tale, riportare dispositivo, operatore, data e ora, modalità di identificazione e necessità di successiva riconciliazione. Non deve sembrare un referto ordinario se non ha seguito il percorso ordinario.
Comunicazione clinica. I valori critici richiedono recapiti alternativi, conferma di ricezione e tracciamento manuale o su un canale indipendente. La caduta del middleware non sospende l’urgenza biologica.
Registro parallelo. Ogni test eseguito offline deve entrare in un elenco unico, numerato e protetto, che consenta di sapere quanti risultati attendono il recupero e quali sono già stati comunicati.
Ritorno online. La riconciliazione deve confrontare identità, valore, unità, orario, episodio, eventuale risultato già ripetuto e decisioni intervenute. Il caricamento massivo non dovrebbe avvenire senza controlli sui duplicati e senza distinguere il tempo della misura dal tempo della trasmissione.
Chiusura dell’evento. Occorre verificare che tutti i risultati siano stati recuperati o annullati, che i destinatari abbiano ricevuto eventuali correzioni e che quasi-eventi, ritardi e deviazioni siano analizzati.
L’esercitazione che vale più del backup
Possedere un backup non dimostra di saperlo ripristinare. Possedere una procedura non dimostra che gli operatori sappiano applicarla sotto pressione.
Una rete territoriale dovrebbe simulare almeno una volta:
- perdita contemporanea di internet e anagrafica;
- dispositivo funzionante ma middleware isolato;
- credenziali non verificabili;
- risultato critico durante l’interruzione;
- due pazienti omonimi;
- ritorno della rete con risultati duplicati;
- indisponibilità del fornitore principale;
- aggiornamento fallito su una sola sede della rete.
L’esercitazione deve misurare tempi, errori, telefonate senza risposta, risultati non riconciliati e decisioni di sospensione. Se tutto si conclude con «abbiamo stampato e poi sistemato», la prova non ha ancora verificato il processo diagnostico.
Il ponte tra industria, formazione e territorio
L’industria deve progettare sicurezza e continuità insieme: accessi remoti limitati, aggiornamenti firmati, registri esportabili, funzionamento locale documentato, riconciliazione verificabile e supporto anche durante l’isolamento.
Il laboratorio e il biologo possono definire quali prestazioni mantenere, quali controlli richiedere, come gestire comparabilità, trascrizione e recupero dei risultati.
Farmacisti, infermieri e operatori territoriali devono conoscere la differenza tra una semplice icona rossa e la dichiarazione formale di modalità degradata. Devono sapere quando continuare e quando il dato non è più difendibile.
Medici e responsabili clinici devono disporre di canali alternativi per richieste, risultati urgenti e decisioni.
Responsabili IT, privacy e direzione devono trasformare il cyber-incidente in un problema condiviso di continuità assistenziale, non lasciarlo confinato nella sala server.
Il POCT è un ecosistema proprio perché il suo valore dipende dalle relazioni tra questi soggetti. Durante un’interruzione, quelle relazioni diventano più importanti della connettività.
Il risultato più difficile da validare
Nel 2026 acquistare un POCT senza valutare vulnerabilità, accessi remoti, aggiornamenti, fine supporto e comportamento offline significa acquistare soltanto la sua giornata migliore.
La sicurezza del paziente si misura invece nella giornata peggiore: quando il cloud non risponde, il LIS è isolato, il tecnico non può collegarsi e l’operatore deve decidere se quel numero possa ancora essere consegnato e utilizzato.
Un sistema resiliente non è quello che non si ferma mai. È quello che riconosce in quale stato si trova, conserva le garanzie essenziali, limita ciò che non può governare e sa ricostruire ogni passaggio dopo il ripristino.
Il POCT può restare acceso nel buio digitale.
La domanda è se resteranno accese anche identità, qualità e responsabilità.
Se domani la vostra rete venisse isolata per ventiquattro ore, sapreste indicare quali test continuare, come documentarli e chi è autorizzato a riportarli nel percorso clinico quando il sistema tornerà disponibile?