Il Cyber Resilience Act viene spesso raccontato come un appuntamento del 2027. È vero che la parte principale del regolamento diventerà applicabile l’11 dicembre 2027. Ma fermarsi a quella data può creare una falsa sensazione di distanza.
Dall’11 settembre 2026 diventano applicabili gli obblighi di segnalazione previsti dall’articolo 14. Per produttori di software e dispositivi connessi non è un anticipo burocratico: significa saper riconoscere un evento, qualificare il prodotto coinvolto, raccogliere le informazioni e attivare il flusso verso le autorità entro tempi molto brevi.
Che cosa parte davvero l’11 settembre
Il CRA richiede ai produttori di notificare due categorie precise: le vulnerabilità contenute nel prodotto che risultano attivamente sfruttate e gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto stesso. Non stiamo quindi parlando dell’obbligo di comunicare qualsiasi bug o qualunque problema informatico.
La procedura passa dalla Single Reporting Platform predisposta da ENISA. Dal momento in cui il produttore viene a conoscenza dell’evento, il primo avviso deve arrivare entro 24 ore e la notifica principale entro 72 ore. Per una vulnerabilità attivamente sfruttata segue un rapporto finale entro 14 giorni dalla disponibilità della misura correttiva o di mitigazione; per un incidente grave, entro un mese dalla notifica principale.
I termini non dicono che in 24 ore debba essere conclusa l’analisi. Dicono però che l’organizzazione deve essere in grado di capire abbastanza presto che cosa sta accadendo e avviare una comunicazione attendibile, aggiornandola mentre l’indagine prosegue.
Chi deve prestare attenzione
Il perimetro comprende prodotti hardware e software con una connessione dati diretta o indiretta, messi a disposizione sul mercato dell’Unione. La figura centrale è il produttore: chi sviluppa, fa sviluppare o fabbrica il prodotto e lo commercializza con il proprio nome o marchio, anche gratuitamente.
Questo passaggio conta soprattutto per le PMI tecnologiche. Un’impresa che vende un’applicazione, un apparato connesso, un componente software o un servizio remoto indispensabile al funzionamento del prodotto potrebbe trovarsi nel perimetro anche se non si descrive abitualmente come “produttore”. Importatori e distributori hanno a loro volta obblighi specifici di verifica, informazione e cooperazione.
Al contrario, acquistare e utilizzare un gestionale o un dispositivo non trasforma automaticamente un’azienda nel suo produttore. Ruolo, contratto, marchio, modalità di commercializzazione e modifiche apportate al prodotto vanno esaminati caso per caso.
La guida europea rende il CRA più concreto
La Commissione europea ha pubblicato a luglio una guida non vincolante pensata per trasformare il testo normativo in decisioni operative. Il documento contiene 67 esempi, casi d’uso e schemi e dedica particolare attenzione a microimprese e PMI.
I chiarimenti affrontano alcuni dei punti che generano più dubbi: quando un prodotto rientra nel CRA, come considerare l’elaborazione remota dei dati e il software open source, che cosa può essere una modifica sostanziale, come definire il periodo di supporto e come affrontare valutazione del rischio e segnalazioni.
La guida non sostituisce il regolamento e non risolve automaticamente ogni caso di confine. Offre però una base molto più utile per costruire inventario, responsabilità e procedure prima che arrivi un evento reale.
Perché il reporting riguarda anche prodotti già sul mercato
C’è un dettaglio facile da perdere. Le disposizioni generali del CRA si applicheranno ai prodotti immessi sul mercato prima dell’11 dicembre 2027 principalmente quando, da quella data, subiscono una modifica sostanziale. Gli obblighi di segnalazione hanno invece un perimetro temporale più ampio: riguardano anche prodotti con elementi digitali già resi disponibili sul mercato europeo.
Un produttore non può quindi limitarsi a preparare la documentazione dei prossimi prodotti. Deve sapere quali versioni sono ancora in uso, quali componenti contengono, chi riceve una segnalazione di vulnerabilità e quali clienti potrebbero essere interessati.
Quattro domande da portare in riunione oggi
La conformità comincia da domande molto operative:
- Quali prodotti e versioni abbiamo immesso sul mercato europeo e sotto quale ruolo?
- Chi decide se una vulnerabilità è attivamente sfruttata o se un incidente è grave?
- Possiamo raccogliere entro poche ore dati tecnici, impatto, versioni coinvolte e misure adottate?
- Chi è autorizzato a inviare la notifica e chi coordina sviluppo, sicurezza, legale e comunicazione?
Se le risposte sono sparse tra persone, ticket e fogli non aggiornati, il problema non è soltanto normativo. È la stessa frammentazione che rallenta correzione, assistenza ai clienti e risposta a un incidente.
Dal prodotto sicuro al produttore pronto
Il CRA chiede sicurezza lungo l’intero ciclo di vita: valutazione del rischio, sviluppo, gestione dei componenti, aggiornamenti, periodo di supporto e trattamento delle vulnerabilità. La segnalazione è soltanto il punto in cui questa capacità diventa visibile anche all’esterno.
Per arrivare preparati non serve creare una macchina burocratica. Serve collegare ciò che spesso esiste già ma lavora separatamente: inventario dei prodotti, processo di vulnerability disclosure, monitoraggio delle minacce, incident response, tracciamento delle dipendenze e responsabilità decisionali.
L’11 settembre non chiude il percorso verso il 2027. Lo rende operativo.
Nota: questo articolo offre un inquadramento informativo e operativo e non sostituisce una valutazione legale sul caso specifico.