Dall’11 settembre 2026 il fabbricante di un prodotto con elementi digitali deve segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi: un preallarme entro 24 ore da quando ne viene a conoscenza, una notifica completa entro 72 ore, poi un rapporto finale. La segnalazione si fa sulla piattaforma unica di ENISA, e vale anche per il software già in vendita.
Gli obblighi di segnalazione sono una delle parti del Cyber Resilience Act, il Regolamento (UE) 2024/2847, che si applicano prima del resto del testo. Il regolamento vale per intero dall’11 dicembre 2027.
Quali sono gli obblighi di segnalazione del Cyber Resilience Act?
Il fabbricante deve segnalare due cose: le vulnerabilità attivamente sfruttate e gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto. Per entrambe la pagina della Commissione sugli obblighi di segnalazione fissa tre scadenze:
- un preallarme entro 24 ore da quando il fabbricante ne viene a conoscenza;
- una notifica completa entro 72 ore;
- un rapporto finale, che per una vulnerabilità sfruttata va mandato entro 14 giorni da quando è disponibile una misura correttiva, e per un incidente grave entro un mese dalla notifica delle 72 ore.
Le 24 ore partono dal momento in cui si viene a sapere del problema. Per chi ha un prodotto sul mercato, vuol dire sapere già oggi chi riceve l’allarme, anche di sabato, e chi è in grado di inviare il preallarme.
Come funziona la piattaforma di segnalazione di ENISA?
Si segnala una volta sola, sulla CRA Single Reporting Platform, che ENISA ha sviluppato e gestisce. La notifica arriva al CSIRT designato come coordinatore, che la inoltra ai CSIRT degli altri Stati membri in cui il prodotto è disponibile, e nello stesso momento è resa disponibile a ENISA.
La piattaforma è attiva dall’11 settembre 2026 nella sua prima capacità operativa. ENISA scrive che ne amplierà le funzioni nei prossimi mesi, e ha aperto un help desk per le domande che le guide pubblicate non coprono.
Chi è il fabbricante che deve segnalare?
È chi sviluppa o fabbrica prodotti con elementi digitali, oppure li fa progettare, sviluppare o fabbricare da altri, e li mette in commercio con il proprio nome o marchio. A pagamento, con altre forme di monetizzazione o gratis. La definizione è quella della sintesi del testo pubblicata dai servizi della Commissione, che precisa di non rappresentarne la posizione ufficiale.
Conta la seconda metà della frase. Un’impresa che fa sviluppare un’app o un portale da una software house e lo vende ai propri clienti con il proprio marchio sembra rientrare nella descrizione, anche se non ha scritto una riga di codice. È una nostra lettura della sintesi, e per il proprio contratto va verificata.
La stessa sintesi dice che il fabbricante stabilisce un periodo di assistenza, durante il quale garantisce la gestione delle vulnerabilità, e che la data in cui finisce, mese e anno, va indicata in modo chiaro al momento dell’acquisto.
Gli obblighi valgono anche per il software già venduto?
Quelli di segnalazione sì. Le FAQ sul Cyber Resilience Act dei servizi della Commissione (1.4 e 5.3), un documento che dichiara di non avere valore interpretativo vincolante, lo spiegano con l’articolo 69 del regolamento.
La regola generale, all’articolo 69(2) secondo le FAQ, è che un prodotto immesso sul mercato prima dell’11 dicembre 2027 deve rispettare i requisiti del regolamento solo se da quella data subisce una modifica sostanziale. Gli obblighi di segnalazione dell’articolo 14 fanno eccezione, con l’articolo 69(3): dall’11 settembre 2026 valgono per tutti i prodotti con elementi digitali che rientrano nel regolamento, anche quelli immessi sul mercato prima.
Le date da tenere a mente sono tre. Il regolamento è in vigore dal 10 dicembre 2024, la segnalazione è obbligatoria dall’11 settembre 2026, e dall’11 dicembre 2027 il regolamento si applica per intero.
Per un prodotto già venduto che rientra nel regolamento, quindi, oggi vale l’obbligo di segnalazione. I requisiti lo riguarderanno solo se dall’11 dicembre 2027 verrà modificato in modo sostanziale.
Il software su misura è escluso dal CRA?
No. Le FAQ della Commissione (4.2.5) parlano dei prodotti «tailor-made», adattati a uno scopo particolare per un particolare utente commerciale, e fra gli esempi c’è il software sviluppato su misura per le esigenze di un’azienda specifica. Per questi prodotti il fabbricante può discostarsi da due requisiti essenziali:
- la configurazione sicura di default (Allegato I, parte I, punto 2(b));
- la fornitura gratuita degli aggiornamenti di sicurezza (Allegato I, parte II, punto 8).
Può farlo solo se fabbricante e utente hanno concordato esplicitamente condizioni contrattuali diverse. Le FAQ si aspettano poi che il fabbricante metta nella documentazione tecnica la prova che il prodotto è davvero su misura. La segnalazione delle vulnerabilità non compare fra i due requisiti.
C’è anche un esempio in negativo: una piattaforma CRM venduta a più aziende non è tailor-made, anche se il fornitore permette qualche piccola personalizzazione.
Il CRA vale per il software usato in azienda e per il SaaS?
Per l’uso proprio le FAQ (1.5) dicono che un prodotto fabbricato per uso proprio non è immesso sul mercato, e il Cyber Resilience Act non lo copre. L’esempio che fanno sono gli strumenti di sviluppo e di configurazione che un fabbricante sviluppa per sé. Per un software che un’azienda fa sviluppare da un fornitore e usa al suo interno, le FAQ non danno una risposta: la domanda va fatta a un legale, con il contratto sotto mano.
Per il cloud la risposta è meno netta. Le FAQ (1.2) dicono che un servizio Software-as-a-Service autonomo, progettato e sviluppato fuori dalla responsabilità del fabbricante di un prodotto con elementi digitali, non è di per sé un prodotto con elementi digitali. Rientra però nel regolamento se corrisponde alla definizione di «remote data processing», l’elaborazione dei dati a distanza dell’articolo 3(2). La Commissione ha annunciato una guida separata su questo concetto. Finché non c’è, per un’app che lavora con un proprio backend in cloud noi tratteremmo il backend come parte del prodotto: è una nostra prudenza.
Che cosa scrivere nel contratto con il fornitore?
Chi è il fabbricante, chi fa la segnalazione e in quante ore il fornitore avvisa. Sono le prime righe che metteremmo per iscritto se si vende un prodotto sviluppato da altri, perché le 24 ore si rispettano solo se chi scopre il problema e chi lo segnala si sono già messi d’accordo. È la nostra lettura di software house, non un testo della Commissione. L’elenco completo:
- chi è il fabbricante, e quindi chi presenta la segnalazione sulla piattaforma di ENISA;
- i tempi interni fra fornitore e committente: in quante ore il fornitore avvisa, attraverso quale canale, e chi decide se la vulnerabilità è attivamente sfruttata;
- l’elenco dei componenti di terze parti (la SBOM, la distinta del software) e chi lo tiene aggiornato, perché una vulnerabilità può stare in una libreria che nessuno dei due ha scritto;
- la durata del periodo di assistenza e i tempi di risposta della manutenzione in quel periodo;
- per un prodotto su misura, una clausola esplicita sulle eventuali deroghe e la prova da conservare nella documentazione tecnica.
Per il proprio caso, chi è fabbricante e che cosa scrivere, la risposta la dà un legale che conosce il prodotto e il contratto.
Due fatti di dotenv, per chi valuta un fornitore. Siamo certificati UNI CEI EN ISO/IEC 27001:2024 per la progettazione, lo sviluppo e l’assistenza di soluzioni software e applicativi: il certificato è nella pagina delle certificazioni. È una norma sulla gestione della sicurezza delle informazioni, e non certifica che un prodotto sia conforme al Cyber Resilience Act. E il codice sorgente è di chi ha pagato il lavoro, e resta suo anche se un giorno sceglie un altro fornitore.
Cosa fare adesso per il Cyber Resilience Act?
Un elenco: quali prodotti l’azienda mette in commercio con il proprio nome, chi li ha sviluppati, quali sono ancora in uso e da chi. Con quell’elenco si capisce per quali prodotti la domanda sul fabbricante si pone, e con quale fornitore va scritto un accordo sui tempi. Per un passo più leggero, le guide di ENISA sulla piattaforma e la sezione 5 delle FAQ della Commissione sono dedicate agli obblighi di segnalazione.
Se il prodotto è un’app o un portale da far costruire, sulla pagina dello sviluppo di web app descriviamo le fasi con cui ne sviluppiamo una, fino alla distribuzione e agli aggiornamenti periodici con le correzioni dei bug, e tre progetti fatti. Da lì si può chiedere una prima chiamata.