Dall’11 settembre 2026 il Cyber Resilience Act (Regolamento UE 2024/2847) non è più soltanto una norma da studiare in vista del 2027: sono diventati applicabili gli obblighi di segnalazione previsti dall’articolo 14. Chi immette sul mercato europeo un prodotto con elementi digitali – un dispositivo connesso, un software commerciale, un’app o un componente – deve ora notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi entro tempi molto stretti, a partire da un primo allarme entro 24 ore.
Lo stesso giorno l’ENISA ha attivato la prima versione operativa della Single Reporting Platform, il portale unico attraverso cui passano le notifiche. Per molte PMI italiane che sviluppano software o prodotti IoT la domanda non è più “se”, ma “chi fa cosa quando succede”.
Cosa è entrato in vigore l’11 settembre 2026
Il Cyber Resilience Act (CRA) introduce requisiti di sicurezza per l’intero ciclo di vita dei prodotti con elementi digitali. La maggior parte di questi requisiti – progettazione sicura, gestione delle vulnerabilità, documentazione, marcatura CE – si applicherà dall’11 dicembre 2027. Gli obblighi di segnalazione sono stati invece anticipati di quindici mesi.
Secondo la pagina della Commissione europea dedicata al reporting, il fabbricante che viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave che incide sulla sicurezza del proprio prodotto deve inviare:
- un preallarme entro 24 ore da quando ne è venuto a conoscenza;
- una notifica più completa entro 72 ore;
- una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva, per le vulnerabilità sfruttate, oppure entro un mese dalla notifica a 72 ore, per gli incidenti gravi.
Le segnalazioni vengono ricevute dal CSIRT coordinatore dello Stato membro in cui il fabbricante ha lo stabilimento principale, cioè dove si prendono prevalentemente le decisioni sulla sicurezza dei prodotti. Per l’Italia l’interlocutore tecnico-operativo è il CSIRT Italia dell’Agenzia per la Cybersicurezza Nazionale, come ricordato anche da Aruba Magazine il 10 settembre 2026.
Chi è coinvolto: non solo i grandi produttori
Il CRA ragiona per prodotti, non per dimensione aziendale. Rientrano nel perimetro, in linea generale, i fabbricanti che commercializzano nell’Unione hardware o software con elementi digitali. Qualche esempio vicino alla realtà delle PMI:
- un’azienda che produce centraline, sensori o gateway connessi per edifici, impianti o progetti Smart City e IoT;
- una software house che vende un gestionale installabile o un’app con licenza;
- chi distribuisce a pagamento un plugin o un tema WordPress;
- un produttore di macchinari che integra firmware e connettività remota.
Anche le soluzioni di elaborazione dati da remoto possono rientrare quando sono necessarie al funzionamento del prodotto, come il cloud che fa funzionare un dispositivo connesso. Il software erogato puramente come servizio (SaaS) è invece disciplinato soprattutto dalla direttiva NIS2, se l’azienda ne è soggetta: è un confine da verificare caso per caso.
Un punto importante riguarda i prodotti già in commercio. Come sintetizzato da Hogan Lovells l’11 settembre 2026, gli obblighi di segnalazione valgono anche per i prodotti immessi sul mercato prima della piena applicazione del CRA. Le linee guida della Commissione, pubblicate il 27 luglio 2026 secondo Freshfields, chiariscono però che non occorre segnalare retroattivamente sfruttamenti di cui si era già a conoscenza prima dell’11 settembre.
Cosa cambia concretamente per un’azienda
La difficoltà vera non è compilare un modulo, ma accorgersi in tempo del problema e sapere chi decide. Ventiquattro ore passano in fretta, soprattutto se l’allarme arriva di venerdì sera da un cliente che segnala un comportamento anomalo.
1. Sapere quali prodotti sono in ambito
Serve un inventario dei prodotti e delle versioni ancora in circolazione, con i componenti di terze parti e le librerie open source utilizzate. Senza questa mappa è impossibile capire se un bollettino di sicurezza pubblicato su una libreria riguarda i propri clienti.
2. Definire cosa significa “attivamente sfruttata” e “grave”
Non tutte le vulnerabilità vanno notificate: l’obbligo riguarda quelle per cui esiste evidenza di sfruttamento e gli incidenti gravi. Conviene fissare in anticipo criteri interni e un responsabile che valuti ogni segnalazione, documentando anche le decisioni di non notificare.
3. Preparare il canale di notifica
L’accesso alla Single Reporting Platform, i dati aziendali, i riferimenti dei prodotti e un modello di preallarme vanno predisposti prima dell’emergenza. L’ENISA mette a disposizione FAQ, manuali, video tutorial e un help desk.
4. Informare gli utilizzatori
L’articolo 14 prevede anche che il fabbricante informi gli utilizzatori interessati – e, se opportuno, tutti – sulla vulnerabilità o sull’incidente e sulle misure per mitigarne l’impatto. Serve quindi un canale di comunicazione con i clienti che funzioni davvero: anagrafiche aggiornate, email di servizio, avvisi nel prodotto.
Il ruolo di automazioni e integrazioni
Qui l’organizzazione conta più della tecnologia, ma gli strumenti aiutano a ridurre i tempi morti. Alcuni esempi realistici:
- un collegamento tra ticketing di assistenza e monitoraggio che porta subito all’attenzione del responsabile le segnalazioni con parole chiave di sicurezza;
- un controllo automatico delle dipendenze che confronta le librerie usate con le vulnerabilità note pubblicate;
- un registro interno delle valutazioni, con data e ora di presa di conoscenza, utile a dimostrare il rispetto delle scadenze;
- modelli precompilati per preallarme, notifica e comunicazione ai clienti.
Sono attività tipiche di API e integrazioni tra sistemi già presenti in azienda, senza introdurre piattaforme nuove. Nei progetti di software su misura conviene prevedere fin dall’inizio log affidabili, gestione delle versioni e un processo di aggiornamento rapido.
Rischi, sanzioni e aspetti ancora incerti
L’articolo 64 del Regolamento prevede, per la violazione dei requisiti essenziali e degli obblighi degli articoli 13 e 14, sanzioni amministrative fino a 15 milioni di euro o fino al 2,5% del fatturato mondiale annuo, se superiore. Per microimprese e piccole imprese è previsto un alleggerimento: non si applicano sanzioni per il solo mancato rispetto del termine delle 24 ore del preallarme. Restano invece dovute la notifica a 72 ore e la relazione finale.
Alcuni aspetti richiedono ancora attenzione:
- la qualificazione di software sviluppato per un singolo cliente, di plugin distribuiti gratuitamente da aziende o di componenti integrati in prodotti altrui va valutata caso per caso;
- il confine tra CRA e NIS2 per chi offre sia prodotti sia servizi cloud non è sempre netto;
- la piattaforma ENISA è partita come “capacità operativa iniziale”: interfacce e procedure potranno evolvere.
Per i casi dubbi è opportuno confrontarsi con il proprio consulente legale o con i riferimenti dell’ACN.
Da dove partire nelle prossime settimane
Un piano minimo e realistico per una PMI che produce o vende software e dispositivi connessi:
- elencare i prodotti con elementi digitali ancora supportati e le relative versioni;
- nominare un responsabile e un sostituto per la valutazione delle segnalazioni;
- scrivere una procedura di una pagina con scadenze, criteri e contatti;
- registrarsi e prendere confidenza con la Single Reporting Platform;
- verificare come raggiungere rapidamente i clienti in caso di avviso di sicurezza;
- pianificare i requisiti del dicembre 2027, a partire dalla gestione delle vulnerabilità.
Chi sviluppa estensioni per siti e negozi online può trovare utile rileggere anche le considerazioni su quando conviene un plugin WordPress custom, perché ogni componente mantenuto nel tempo porta con sé responsabilità di aggiornamento.
Conclusione
L’11 settembre 2026 segna il passaggio del Cyber Resilience Act dalla teoria alla pratica. Per le PMI il primo obiettivo non è la conformità completa, attesa per il 2027, ma la capacità di reagire entro 24 e 72 ore con informazioni ordinate. Se vuoi capire come collegare assistenza, monitoraggio e software per rendere questo processo sostenibile, contattaci per un primo confronto.