Il Cyber Resilience Act, Regolamento (UE) 2024/2847, obbliga i fabbricanti di prodotti con elementi digitali a notificare le vulnerabilità sfruttate attivamente e gli incidenti gravi dall'11 settembre 2026, con preallarme entro 24 ore, notifica completa entro 72 ore e relazione finale entro 14 giorni. Gli altri obblighi si applicano dall'11 dicembre 2027.
Da qualche mese i clienti industriali ci fanno sempre la stessa domanda: se il nostro macchinario ha un software a bordo, e quel software ha un buco, chi deve dirlo e a chi. Fino a poco tempo fa la risposta era un'alzata di spalle e una patch silenziosa. Dall'11 settembre 2026 esiste una procedura, le sue scadenze si contano in ore, e non rispettarla è sanzionabile.
Il Cyber Resilience Act, Regolamento (UE) 2024/2847, porta la marcatura CE nel mondo della cybersecurity: i prodotti con elementi digitali che non sono sicuri non possono stare sul mercato europeo. È in vigore da dicembre 2024, ma gli obblighi arrivano a scaglioni, e il primo è a poche settimane da qui.
Le due date che contano
11 settembre 2026. Partono gli obblighi di segnalazione. Il fabbricante deve notificare le vulnerabilità sfruttate attivamente e gli incidenti gravi che impattano la sicurezza di un prodotto con elementi digitali. Le segnalazioni passano da un'unica piattaforma europea, la Single Reporting Platform, che le smista verso ENISA e il CSIRT competente.
11 dicembre 2027. Si applica tutto il resto: requisiti essenziali di sicurezza, documentazione tecnica, gestione delle vulnerabilità per l'intero periodo di supporto, valutazione di conformità e marcatura CE.
C'è un dettaglio che spiazza. Gli obblighi di notifica coprono anche i prodotti già immessi sul mercato prima dell'applicazione piena del regolamento. Un dispositivo che hai venduto nel 2023 e che ancora supporti rientra da settembre.
Ti riguarda anche se non fai hardware
Il perimetro sono i prodotti con elementi digitali: hardware connesso, ma anche software immesso sul mercato come prodotto. Sistemi operativi, router, sensori industriali, applicazioni, librerie commerciali. Restano fuori i servizi cloud puri, tranne quando una componente di elaborazione remota è parte integrante del prodotto, e i settori con regole proprie come dispositivi medici, automotive e aviazione civile. L'open source sviluppato fuori da un'attività commerciale è escluso, con una figura intermedia, l'open source steward, per le fondazioni che distribuiscono componenti su cui l'industria si appoggia.
Sul software su misura la risposta onesta è che dipende da come lo metti a disposizione. Un modulo che rivendi a più clienti è un prodotto. Un gestionale sviluppato per un solo committente e mai commercializzato è un caso da guardare in faccia con un legale, non da liquidare in un articolo. In entrambi gli scenari, però, il lavoro tecnico che serve è lo stesso.
Notificare in 24 ore: cosa devi avere pronto
Le finestre sono strette: preallarme entro 24 ore da quando vieni a conoscenza di una vulnerabilità sfruttata attivamente, notifica completa entro 72 ore, relazione finale entro 14 giorni da quando è disponibile una misura correttiva. Per gli incidenti gravi la relazione finale slitta a un mese. Il cronometro parte dalla conoscenza del fatto, che in pratica vuol dire da quando la mail arriva nella casella che hai pubblicato.
Ventiquattro ore sono poche se la segnalazione arriva un venerdì sera e la persona che sa dove guardare è in ferie. Serve un canale dove le segnalazioni atterrano davvero, cioè un indirizzo di sicurezza che qualcuno legge, un reperibile, e un modello di notifica con le parti fisse già compilate. Chi ha fatto questo lavoro per la NIS2 ha già metà del percorso, perché le finestre da 24 e 72 ore sono le stesse.
SBOM: sapere cosa c'è dentro
Il CRA chiede al fabbricante di identificare e documentare i componenti del prodotto, redigendo una SBOM, la distinta dei componenti software, in un formato leggibile dalle macchine e diffuso, che copra almeno le dipendenze di primo livello. Non va spedita agli utenti finali: vive nella documentazione tecnica, e le autorità di sorveglianza possono chiederla.
In concreto significa generare la SBOM in pipeline a ogni build, con CycloneDX o SPDX e strumenti che sono gratuiti, archiviarla insieme all'artefatto e collegarla a un feed di vulnerabilità note. Il guadagno vero non è la conformità. È che quando esce la prossima Log4Shell sai in dieci minuti quali dei tuoi prodotti contengono quella libreria, invece di scoprirlo dopo tre giorni di grep.
Le sanzioni, per capirsi
La violazione dei requisiti essenziali di sicurezza e degli obblighi di segnalazione arriva fino a 15 milioni di euro o al 2,5 per cento del fatturato mondiale annuo, il maggiore dei due. Per gli altri obblighi il tetto è 10 milioni o il 2 per cento. Informazioni scorrette o incomplete fornite alle autorità costano fino a 5 milioni o l'1 per cento.
Cosa conviene fare adesso
Cinque settimane non bastano a rifare la sicurezza di prodotto, ma bastano per la parte di notifica, che è l'unica obbligatoria a settembre. Devi sapere quali prodotti sono nel perimetro, chi è il referente, come faresti a scoprire di essere sotto attacco e chi scrive la notifica. Il resto, SBOM in pipeline, aggiornamenti sicuri, periodo di supporto dichiarato, si costruisce nei quindici mesi che portano a dicembre 2027.
Quel percorso è più semplice con chi scrive il software nella stanza. Fa parte di come gestiamo i progetti software su misura, e se hai dubbi sul fatto che un tuo prodotto rientri o no, raccontaci cosa fa.
