Cyber Resilience Act per chi sviluppa software: segnalare entro 24 ore

Aggiornato a ottobre 2026. Molti considerano il cyber resilience act un tema del 2027, l'anno della marcatura CE per i prodotti con elementi digitali. In realtà una parte del regolamento è già applicabile: dall'11 settembre 2026 i fabbricanti devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi con tempi molto stretti. Qui vediamo chi è coinvolto, quali sono le scadenze e come organizzare un processo che funzioni anche di notte e nei festivi.

Cosa prevede il cyber resilience act oggi

Il Regolamento (UE) 2024/2847 si applica in pieno dall'11 dicembre 2027, ma prevede date anticipate:

• dall'11 giugno 2026 le norme sugli organismi di valutazione della conformità;
• dall'11 settembre 2026 gli obblighi di segnalazione dell'articolo 14.

L'obbligo di segnalazione vale anche per i prodotti già immessi sul mercato prima del 2027, non solo per quelli nuovi. È il punto che sorprende di più: un'applicazione venduta tre anni fa e ancora supportata rientra nel perimetro.

In Italia il Governo ha approvato in via preliminare, l'8 ottobre 2026, lo schema di decreto nazionale che affida all'ACN notifica e vigilanza (Agenda Digitale). Gli obblighi europei, però, non aspettano il decreto: sono già in vigore.

I tempi: 24 ore, 72 ore, poi la relazione finale

Le segnalazioni passano dalla piattaforma unica gestita da ENISA, operativa dall'11 settembre 2026; per l'Italia il CSIRT coordinatore indicato è il CSIRT Italia dell'ACN (Cybersecurity360). Il regolamento chiede anche di informare gli utilizzatori coinvolti, senza indebito ritardo.

Un chiarimento utile: non ogni CVE pubblicata fa scattare l'obbligo. Serve un'evidenza affidabile che qualcuno abbia sfruttato la vulnerabilità senza autorizzazione. Una prova di concetto pubblicata, da sola, non basta. Ma va valutata e la valutazione va documentata.

Chi è «fabbricante» nel cyber resilience act

Fabbricante è chi sviluppa o fa sviluppare un prodotto con elementi digitali e lo commercializza con il proprio nome o marchio. Il perimetro comprende software e hardware, ma ci sono esclusioni e regimi specifici (per esempio per alcuni settori già regolati e per il software libero non commerciale). Prima di costruire processi, la prima domanda è quindi giuridica: il mio prodotto rientra?

Esempio ipotetico: una software house vende un'applicazione per la gestione del magazzino a decine di clienti con licenza annuale. È un prodotto messo a disposizione sul mercato e il suo produttore è con ogni probabilità un fabbricante. Diverso è il caso di uno sviluppo realizzato su commessa per un solo cliente e non commercializzato: qui la qualificazione va verificata caso per caso con un legale.

Per chi acquista software, invece, il cyber resilience act diventa un argomento contrattuale: chiedere al fornitore come gestisce le segnalazioni è legittimo e, per i soggetti NIS2, coerente con la sicurezza della catena di fornitura.

Le sanzioni

Il regolamento prevede sanzioni amministrative elevate: le analisi di settore riportano massimali fino a 15 milioni di euro per le violazioni più gravi, tra cui quelle legate agli obblighi dei fabbricanti (Agenda Digitale). Il decreto italiano definirà procedure e autorità competenti. Al di là delle multe, una segnalazione mancata scoperta dopo un attacco ai clienti pesa sulla reputazione molto più della sanzione.

Il processo minimo per rispettare le 24 ore

Ventiquattro ore sono poche se la segnalazione dipende da una persona sola o da una casella email letta il lunedì. Il processo che consiglio di impostare ha sei elementi:

1. Canale di ricezione unico. Un indirizzo o un modulo pubblicato per la segnalazione di vulnerabilità, monitorato con turni e reperibilità.
2. Inventario dei prodotti e delle versioni supportate. Senza sapere chi usa quale versione è impossibile capire l'impatto.
3. Distinta dei componenti software (SBOM). Molte vulnerabilità sfruttate arrivano da librerie di terze parti: la distinta permette di capire in minuti se si è esposti.
4. Criteri di valutazione scritti. Quando una vulnerabilità è «attivamente sfruttata»? Chi decide? Una pagina con criteri ed esempi evita discussioni nel momento sbagliato.
5. Ruoli chiari. Chi riceve, chi valuta, chi decide di notificare, chi compila e chi invia sulla piattaforma ENISA, con sostituti nominati.
6. Modelli pronti. Preallarme, notifica, relazione finale e comunicazione ai clienti già impostati, da completare e non da scrivere da zero.

Un'esercitazione a tavolino di un'ora, con un caso inventato, mostra subito dove il processo si inceppa.

Cyber resilience act e NIS2: come si incastrano

Le due norme parlano a soggetti diversi ma si toccano spesso. La NIS2 riguarda l'organizzazione che eroga servizi critici e la obbliga a notificare gli incidenti significativi; il cyber resilience act riguarda il prodotto e chi lo fabbrica. Un'azienda può essere entrambe le cose: soggetto NIS2 e produttore di software. In quel caso conviene un unico processo di gestione degli eventi, con due rami di notifica. Per la parte NIS2 trovi il piano operativo nell'articolo sulla notifica degli incidenti nelle prime 24 ore.

Un esempio di cronologia

Per rendere concreti i tempi, ecco una cronologia ipotetica. Un lunedì alle 18 un cliente segnala che un'installazione del tuo software è stata compromessa sfruttando un difetto nel modulo di autenticazione.

• Lunedì sera. Il canale di segnalazione riceve il messaggio; il reperibile apre un caso e avvisa il responsabile della sicurezza del prodotto.
• Martedì mattina. L'analisi conferma che il difetto esiste in tre versioni supportate e che c'è un'evidenza affidabile di sfruttamento. Il responsabile decide che il caso va notificato.
• Martedì entro le 18. Parte il preallarme sulla piattaforma unica: sono passate meno di 24 ore da quando l'azienda ne è venuta a conoscenza.
• Giovedì entro le 18. Parte la notifica con le informazioni disponibili: prodotto, versioni, natura della vulnerabilità, misure correttive o di mitigazione già indicate ai clienti.
• Nei giorni successivi. Viene rilasciata una correzione; entro 14 giorni dalla sua disponibilità si invia la relazione finale.

La parte difficile non è compilare i moduli: è prendere la decisione di notificare in poche ore, con informazioni incomplete. Per questo i criteri e i ruoli vanno decisi prima.

Cosa chiedere ai propri fornitori di componenti

Chi sviluppa software usa librerie, componenti e servizi di terzi. Il regolamento chiede al fabbricante di gestire anche queste dipendenze. Nella pratica conviene:

• tenere aggiornata la distinta dei componenti e le loro versioni;
• seguire gli avvisi di sicurezza dei componenti più critici;
• inserire nei contratti con i fornitori di componenti commerciali tempi di comunicazione delle vulnerabilità compatibili con le proprie 24 ore;
• prevedere come sostituire rapidamente un componente non più supportato.

Un fornitore che scopre una vulnerabilità e la comunica dopo una settimana rende impossibile rispettare i tempi a valle. È un tema da contratto, non da buona volontà.

Errori da evitare

• Aspettare la certezza assoluta. Il preallarme serve proprio a segnalare presto, con le informazioni disponibili; i dettagli arrivano con la notifica e la relazione finale.
• Affidarsi a una sola persona. Ferie, malattie e weekend sono la norma, non l'eccezione: ogni ruolo del processo ha bisogno di un sostituto.
• Dimenticare i clienti. L'obbligo di informare gli utilizzatori coinvolti è parte del processo, con messaggi chiari su rischio e misure da adottare.

Cosa fare adesso

Se sviluppi e vendi software, verifica entro questo mese tre cose: se i tuoi prodotti rientrano nel perimetro, se esiste un canale di segnalazione monitorato e chi è autorizzato a inviare il preallarme. Sono decisioni da prendere a freddo, non durante un incidente. Se vuoi impostare governance e processo in modo proporzionato, nella pagina sulla consulenza NIS2 trovi come lavoro su sicurezza dei prodotti e dei fornitori.