Gli obblighi di notifica del Cyber Resilience Act trasformano la gestione delle vulnerabilità in un problema non soltanto tecnico, ma organizzativo: per rispettare le scadenze occorre sapere già quali componenti sono presenti nei prodotti, dove sono installati e chi deve prendere le decisioni.
Indice degli argomenti
Dove si mostra la vera natura del Cyber Resilience Act
L’orologio è già partito. Dall’11 settembre 2026 il produttore che venga a conoscenza di una vulnerabilità attivamente sfruttata in un prodotto con elementi digitali ha ventiquattro ore per il primo allarme, settantadue per la notifica completa e quattordici giorni per la relazione finale una volta disponibile la misura correttiva. Il canale è la piattaforma unica di segnalazione gestita da ENISA; il destinatario, in Italia, il CSIRT Italia incardinato presso l’Agenzia per la Cybersicurezza Nazionale.
Ventiquattro ore sembrano poche. Diventano pochissime se si prova a scomporre ciò che, in quelle ore, un’azienda deve materialmente fare: stabilire se la vulnerabilità tocca un prodotto ancora sul mercato, quali versioni sono coinvolte, quanti esemplari sono installati e presso chi, chi ha fornito il componente, quali clienti vanno avvisati e chi, dentro l’organizzazione, ha il potere di decidere.
Nessuna di queste risposte si costruisce in ventiquattro ore. O c’era prima, o non c’è.
È qui che il Cyber Resilience Act mostra la sua vera natura: prima ancora che una norma di sicurezza, è una norma di organizzazione.
Quattro casi per capire il perimetro
Il regolamento si applica a chiunque immetta sul mercato europeo un prodotto con elementi digitali, cioè quasi tutto ciò che contiene software o si connette a qualcosa. Tuttavia, per spiegare meglio è analizzare quattro casi concreti.
Il costruttore di macchine. Un’impresa produce linee di confezionamento con diagnostica da remoto. Il PLC monta un modulo di comunicazione di terze parti e su quel modulo viene pubblicata una vulnerabilità già sfruttata in rete. La domanda non è se il CRA si applichi, perché si applica: è se l’azienda sappia, entro sera, su quali matricole quel firmware è installato, in quali stabilimenti e in quali Paesi. Un portafoglio costruito in vent’anni contiene generazioni diverse di macchine, configurazioni personalizzate sul singolo cliente e impianti ancora in servizio dei quali si è persa la mappa. Il CRA obbliga a ricostruirla.
La videocamera e la serratura. Videocamere di sorveglianza domestica, serrature intelligenti, sistemi di allarme e assistenti vocali per la casa non sono prodotti qualsiasi: l’Allegato III li colloca tra i prodotti importanti di classe I, con una procedura di conformità più esigente quando non si applichi integralmente una norma armonizzata. E c’è un secondo passaggio, spesso trascurato: la vulnerabilità può non essere nella telecamera, ma nel servizio cloud che la rende raggiungibile dallo smartphone. Quel servizio, se necessario al funzionamento del prodotto, del prodotto fa parte. Non è un’appendice contrattuale del fornitore.
La libreria. Dicembre 2021, Log4Shell. La domanda che paralizzò migliaia di aziende non fu come si correggesse la vulnerabilità, ma dove fosse installata. Allora la risposta arrivò in giorni o in settimane, e nessuno ne rispondeva. Oggi quella stessa domanda ha un termine e un destinatario. È il motivo per cui la distinta dei componenti software, la SBOM prevista dall’Allegato I, non è un adempimento documentale ma lo strumento che rende sostenibile la scadenza.
Dispositivi medici. Un produttore di dispositivi medici e un costruttore di veicoli omologati sono esclusi dal CRA, perché intervengono il regolamento sui dispositivi medici e quello sulla sicurezza generale dei veicoli. Ma l’esclusione copre il prodotto regolato, non l’azienda. Il braccialetto per il monitoraggio del benessere che non è dispositivo medico rientra nell’Allegato III; il dongle diagnostico venduto nel post-vendita, la dashcam e la stazione di ricarica domestica non sono coperti dall’omologazione del veicolo. Nella stessa impresa possono così convivere linee di prodotto dentro e fuori il perimetro, con regimi di segnalazione diversi. È il primo esercizio da fare, ed è un esercizio giuridico prima che tecnico.
Il momento della conoscenza
L’articolo 14 è semplice nei tempi e impegnativo nella pratica, perché tutto dipende da quando l’organizzazione possa dirsi “a conoscenza”.
Una segnalazione può arrivare al customer care, a uno sviluppatore, a un distributore, a un ricercatore indipendente che scrive a un indirizzo generico. Da lì deve raggiungere chi è in grado di qualificarla. Se il percorso richiede tre giorni e cinque funzioni aziendali, il problema esiste già prima della scadenza regolamentare.
Serve dunque una procedura vera: un punto di ingresso, criteri di escalation, un responsabile e qualcuno che abbia il mandato di decidere anche con informazioni incomplete. Il GDPR ha insegnato la stessa lezione con i data breach. Cambia l’oggetto: al centro non c’è il dato, c’è il prodotto.
La filiera è il punto delicato
Un prodotto digitale raramente nasce tutto nella stessa azienda: firmware, sistema operativo, componenti hardware, servizi cloud, software open source. Quando uno di questi soggetti scopre una vulnerabilità, il tempo comincia a correre anche per chi incorpora il suo componente.
Se il produttore deve reagire in ventiquattro ore, un fornitore che comunica dopo tre giorni rende quel termine ingestibile. Le clausole di sicurezza smettono quindi di essere formule di stile: chi comunica, entro quanto, a quale referente, con quali informazioni, con quale supporto nella fase di rimedio e con quali conseguenze in caso di silenzio. È un lavoro contrattuale da iniziare ora, perché i contratti di fornitura si rinegoziano alla scadenza, non nel giorno dell’incidente.
Dove incontra NIS2
CRA e NIS2 guardano a oggetti diversi: la direttiva alla resilienza dell’organizzazione e dei servizi, il regolamento alla sicurezza dei prodotti. Ma finiscono sulle stesse scrivanie, security, IT, legal, procurement e vertici, e condividono gli stessi processi: rilevazione, qualificazione, escalation, notifica, comunicazione ai terzi.
Costruire una procedura separata per ogni regolamento produce l’effetto opposto a quello voluto: più passaggi, più interlocutori, decisioni più lente. La strada ragionevole è partire dal processo, chi riceve, chi valuta, chi decide, chi avvisa, e agganciarvi poi gli obblighi delle singole normative.
Una prova che si può fare domani
La maggior parte delle disposizioni sarà pienamente applicabile dall’11 dicembre 2027, con sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale. Ma il livello di preparazione è misurabile oggi, con una simulazione di mezza giornata.
Si sceglie un componente realmente utilizzato e si ipotizza che sia oggetto di una vulnerabilità attivamente sfruttata. Quanto serve per sapere dove è installato? Chi viene coinvolto? Il fornitore risponde, e in quanto tempo? Chi decide se segnalare? Le informazioni necessarie esistono, o vanno ricostruite?
Se la risposta richiede giorni, la simulazione ha già individuato il punto debole. E l’ha individuato in tempo, che è sicuramente uno degli aspetti più positivi in una normativa estremamente complessa.
Partecipa alla community