Da un mese, se un fornitore di software scopre che una vulnerabilità di un suo prodotto viene sfruttata, ha 24 ore per dirlo all'ENISA. Non è più una buona pratica. Dall'11 settembre 2026 è un obbligo del Cyber Resilience Act, il Regolamento (UE) 2024/2847, e vale anche per chi non si sente un "vendor": chi scrive lo SCADA di una linea o il software di un laboratorio per un singolo stabilimento.
A luglio abbiamo messo in fila le tre norme sulla cybersecurity industriale, CRA, Regolamento Macchine e NIS2. Qui restiamo sul CRA e lo guardiamo dal lato di chi il software lo fornisce.
Chi riguarda
Il CRA si applica ai "prodotti con elementi digitali" messi a disposizione sul mercato europeo. La formula è ampia di proposito e va dall'hardware con firmware alle applicazioni. Molti fornitori industriali scoprono tardi che il software sviluppato per un cliente, e consegnato nell'ambito di un'attività commerciale, ci rientra. Il gestionale di supervisione scritto per una sola azienda non resta fuori perché ha un solo utente.
Due date, non una
L'11 settembre 2026, già passato, sono partiti gli obblighi di segnalazione. Riguardano le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza del prodotto. Si segnala attraverso la piattaforma unica che l'ENISA ha messo in linea, con una sequenza precisa: un preallarme entro 24 ore da quando se ne viene a conoscenza, una notifica entro 72 ore, un rapporto finale entro 14 giorni da quando è disponibile la correzione (un mese, per gli incidenti gravi).
I tempi della segnalazione obbligatoria prevista dal Cyber Resilience Act per le vulnerabilità sfruttate e gli incidenti gravi.
L'11 dicembre 2027 arriva il resto: requisiti essenziali di sicurezza, valutazione della conformità, marcatura CE, documentazione tecnica, periodo di supporto dichiarato. È la data di cui si parla di più. Per la segnalazione, però, ci siamo già dentro.
Il punto che si sottovaluta
Gli obblighi di segnalazione non riguardano solo i prodotti nuovi. Valgono anche per quelli messi sul mercato prima del 2027, cioè per il software che gira da anni negli impianti, e continuano dopo la fine del periodo di supporto.
Per un integratore significa una cosa molto concreta: bisogna sapere che cosa si è installato, dove e con quali componenti. Una libreria vulnerabile dentro un'applicazione consegnata nel 2021 diventa un problema di oggi, se qualcuno la sfrutta. La parte che costa di più, secondo noi, non è il canale di segnalazione. È ricostruire l'elenco dei componenti del software già consegnato.
In pratica, per un fornitore industriale
Le cose da avere sono poche, ma vanno fatte prima di averne bisogno:
- un canale pubblico per ricevere le segnalazioni, con una politica di divulgazione coordinata che dica cosa succede dopo;
- una procedura interna che stabilisca chi valuta una segnalazione, chi decide se fa scattare l'obbligo di notifica e in quanto tempo;
- la distinta dei componenti software (SBOM) di ogni prodotto, tenuta aggiornata;
- aggiornamenti di sicurezza separati da quelli funzionali, perché il cliente deve poterli installare senza ritrovarsi una versione nuova del programma;
- un periodo di supporto dichiarato e motivato.
Sul periodo di supporto, una nota. Il CRA fissa un minimo di cinque anni, ma chiede che sia allineato alla vita prevista del prodotto. In un laboratorio o su una linea il software resta in servizio molto più a lungo di un PC d'ufficio, dieci o quindici anni non sono rari. Lì cinque anni rischiano di essere pochi, e conviene dirlo al cliente prima della firma, non dopo.
Il doppio binario per chi fa software di macchina
Chi fornisce PLC e SCADA ha un'altra scadenza. Dal 20 gennaio 2027 si applica il Regolamento Macchine (UE) 2023/1230, con requisiti di cybersecurity propri sui sistemi di comando. Le due norme guardano lo stesso software da lati diversi: il CRA il prodotto digitale, il Regolamento Macchine la sicurezza della macchina in cui finisce. Conviene leggerle insieme, perché buona parte della documentazione tecnica si sovrappone.
Che cosa abbiamo fatto noi
Abbiamo pubblicato una politica di divulgazione coordinata delle vulnerabilità, con un canale dedicato, security@contech.xyz, e tempi di riscontro dichiarati: conferma di ricezione entro 3 giorni lavorativi, prima valutazione entro 10. Sul sito c'è anche il file security.txt secondo lo standard RFC 9116, così chi cerca il contatto lo trova dove se lo aspetta.
Dietro c'è una procedura interna di presa in carico, con chi decide e in quanto tempo. E stiamo rivedendo prodotto per prodotto l'ambito di applicazione e il percorso verso dicembre 2027: quali software rientrano, in quale categoria, che cosa manca.
Non diciamo di essere pronti per il 2027, perché i requisiti essenziali si applicano da lì e il lavoro è in corso. Diciamo che il canale c'è e che a ogni segnalazione risponde una persona.
Le fonti, per chi vuole andare a vedere: la pagina della Commissione europea sugli obblighi di segnalazione del CRA e l'annuncio dell'ENISA sul lancio della piattaforma unica di segnalazione.
La nostra politica di divulgazione delle vulnerabilità e il canale di segnalazione sono pubblicati qui.
Per i clienti: su richiesta condividiamo la nostra analisi di ambito di applicazione prodotto per prodotto.
Argomenti trattati
