Dall'11 settembre 2026 un fabbricante di prodotti con elementi digitali che scopre una vulnerabilità attivamente sfruttata ha ventiquattro ore per un primo avviso a ENISA e al CSIRT nazionale, e settantadue per la notifica completa. L'obbligo vale anche per i prodotti già venduti. Il punto difficile non è la velocità della segnalazione: è che in ventiquattro ore devi sapere se quel componente vulnerabile è dentro il tuo prodotto. E questa è una domanda di inventario, non di sicurezza.
01Cosa scatta esattamente l'11 settembre 2026?
Il Cyber Resilience Act — Regolamento (UE) 2024/2847 — è entrato in vigore il 10 dicembre 2024 e si applica in via generale dall'11 dicembre 2027. Ma il regolamento ha un calendario a scaglioni scritto nell'articolo 71: «This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026». L'articolo 14 è quello degli obblighi di segnalazione, ed è il primo pezzo di CRA che diventa esigibile.
Gli eventi da segnalare sono due. Una vulnerabilità attivamente sfruttata è quella «per la quale esistono prove attendibili che un attore malevolo l'abbia sfruttata in un sistema senza il permesso del proprietario» (art. 3, punto 42). Un incidente grave è quello che pregiudica — o può pregiudicare — la capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni importanti, o che porta all'esecuzione di codice malevolo nel prodotto o nei sistemi di un utente (art. 14, par. 5).
Le finestre temporali, per entrambi i casi, sono queste:
- 24 ore — early warning: «senza indebito ritardo e in ogni caso entro ventiquattro ore» da quando il fabbricante ne viene a conoscenza. Basta dire che il fatto esiste e in quali Stati membri il prodotto è disponibile.
- 72 ore — notifica vera e propria: natura del problema, valutazione, misure correttive o mitigazioni adottate o disponibili.
- 14 giorni — relazione finale per le vulnerabilità attivamente sfruttate, «entro quattordici giorni da quando una misura correttiva o mitigante è disponibile».
- 1 mese — relazione finale per gli incidenti gravi, calcolata dalla presentazione della notifica a 72 ore, non dalla disponibilità della patch: una differenza che conta quando si scrive la procedura.
La segnalazione va simultaneamente al CSIRT designato come coordinatore e a ENISA, attraverso un canale unico: la Single Reporting Platform prevista dall'articolo 16, che ENISA opera e mantiene e che diventa operativa proprio l'11 settembre 2026 (ENISA, Single Reporting Platform). Si segnala una volta sola: è la piattaforma a distribuire l'informazione ai CSIRT degli altri Stati membri in cui il prodotto è disponibile.
02Vale anche per i prodotti già sul mercato?
Sì, ed è la parte che sorprende di più. La regola generale del CRA sulla transizione (art. 69, par. 2) dice che i prodotti immessi sul mercato prima dell'11 dicembre 2027 sono soggetti al regolamento solo se, da quella data, subiscono una modifica sostanziale. Sembra una via d'uscita comoda. Ma il paragrafo successivo la chiude: «In deroga al paragrafo 2, gli obblighi di cui all'articolo 14 si applicano a tutti i prodotti con elementi digitali che rientrano nell'ambito di applicazione del presente regolamento e che sono stati immessi sul mercato prima dell'11 dicembre 2027» (art. 69, par. 3).
Tradotto in termini operativi: la macchina della conformità — requisiti essenziali, documentazione tecnica, marcatura CE — riguarda i prodotti nuovi e parte nel dicembre 2027. L'obbligo di segnalare, invece, parte prima e riguarda tutto il parco installato. Compresa quella versione rilasciata quattro anni fa che nessuno tocca più ma che un cliente ha ancora in produzione.
03Chi è «fabbricante», e cosa rischia?
Il regolamento definisce fabbricante «la persona fisica o giuridica che sviluppa o fabbrica prodotti con elementi digitali, o che li fa progettare, sviluppare o fabbricare, e li commercializza con il proprio nome o marchio» (art. 3, punto 13). La conseguenza è netta: non conta chi ha scritto il codice, conta chi mette il nome sulla scatola. Se distribuisci a tuo marchio un prodotto che qualcun altro ha sviluppato per te, l'obbligo di segnalazione è tuo.
Il perimetro merceologico è ampio — «prodotto software o hardware e le sue soluzioni di trattamento dati a distanza, compresi i componenti immessi sul mercato separatamente» (art. 3, punto 1) — ma non è illimitato. Il considerando 12 chiarisce che i servizi cloud progettati e sviluppati al di fuori della responsabilità di un fabbricante di prodotti con elementi digitali non rientrano nel CRA: il SaaS puro sta piuttosto nel perimetro NIS2. Ma la funzionalità cloud senza la quale il prodotto non funziona è parte del prodotto.
Sul rischio economico il testo è esplicito: l'inosservanza dei requisiti essenziali dell'allegato I e degli obblighi degli articoli 13 e 14 è punita con sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, se superiore (art. 64, par. 2). C'è però una valvola: il paragrafo 10 dello stesso articolo esclude dalle sanzioni amministrative microimprese e piccole imprese, limitatamente al mancato rispetto del termine delle ventiquattro ore. Va letta per quello che è: l'obbligo resta, la notifica a 72 ore e la relazione finale restano sanzionabili. Non è un rinvio, è un margine di respiro sul primo avviso.
04Perché ventiquattro ore sono un problema di inventario
La scena è sempre la stessa. Esce una CVE su una libreria molto diffusa, con evidenza di sfruttamento in corso. La domanda da risolvere non è «come la ripariamo» — quella viene dopo — ma «è dentro un nostro prodotto? in quale versione? presso quali clienti? in quali Paesi UE?». Se la risposta dipende da tre persone che aprono i repository e leggono i file di dipendenze a memoria, non arriva in ventiquattro ore. E se non arriva, non è che segnali male: non hai i dati per segnalare.
La dimensione del problema non è un'impressione. Il rapporto OSSRA 2026 di Black Duck, costruito su 947 codebase commerciali analizzate in 17 settori, misura una media di 581 vulnerabilità open source per codebase, più che raddoppiate rispetto all'anno precedente (+107%), con l'87% delle codebase che ne contiene almeno una e il numero medio di componenti open source cresciuto del 30% in dodici mesi (Black Duck, OSSRA 2026). Il software commerciale, oggi, è in larghissima parte assemblato: la parte scritta in casa è la minoranza.
E la preparazione non tiene il passo: nella rilevazione ENISA sulle PMI europee (194 organizzazioni, 31 Paesi, febbraio-marzo 2026) l'area con i punteggi più bassi è proprio la gestione degli incidenti e del ciclo di vita del prodotto (ENISA, 13 luglio 2026) — esattamente la capacità che l'11 settembre 2026 diventa obbligatoria.
05Cosa dice davvero il CRA sulla SBOM (e cosa non dice)
Qui serve precisione, perché intorno a questa scadenza sta circolando parecchia confusione commerciale. La SBOM — software bill of materials, la distinta base del software: l'elenco leggibile a macchina dei componenti che compongono un prodotto — non è un obbligo che scatta l'11 settembre 2026. Sta nell'allegato I, parte II, punto 1, tra i requisiti di gestione delle vulnerabilità, e chiede ai fabbricanti di «identificare e documentare le vulnerabilità e i componenti contenuti nei prodotti con elementi digitali, anche redigendo una distinta base del software in un formato di uso comune e leggibile da una macchina, che copra almeno le dipendenze di primo livello».
Tre cose vanno dette con onestà, perché il testo dice esattamente queste e non di più:
- La data è l'11 dicembre 2027, non settembre 2026: l'allegato I fa parte dei requisiti essenziali, che si applicano con l'applicazione generale del regolamento e, per l'articolo 69, ai prodotti immessi sul mercato da quella data o sostanzialmente modificati dopo.
- Il minimo di legge sono le dipendenze di primo livello. Il testo dice «almeno»: non impone l'albero transitivo completo. Chi promette che il CRA obbliga alla SBOM ricorsiva sta vendendo, non citando.
- La SBOM non va pubblicata. Il regolamento non ne impone la divulgazione: va tenuta nella documentazione tecnica e messa a disposizione delle autorità di vigilanza del mercato su richiesta (considerando 77).
Quindi: a settembre 2026 nessuno ti sanziona perché non hai una SBOM. Ti sanziona, semmai, perché non hai segnalato in tempo. Ed è qui che il cerchio si chiude: la SBOM non è ciò che la legge ti chiede a settembre, è ciò che rende sopravvivibile quello che la legge ti chiede a settembre. Costruirla adesso risolve due scadenze con un lavoro solo — la finestra delle ventiquattro ore oggi, l'allegato I nel dicembre 2027.
06E il codice scritto dall'AI?
È il punto che cambia la natura del problema, e che quasi nessuno collega al CRA. Lo stesso rapporto OSSRA registra che circa l'85% delle organizzazioni usa assistenti di codifica basati su AI — e che il 76% di quelle che li vietano ammette che gli sviluppatori li usano comunque — con il numero medio di file per codebase cresciuto del 74% in un anno.
Il rischio più discusso è la dipendenza allucinata: uno studio presentato a USENIX Security 2025 ha generato 576.000 campioni di codice con 16 modelli e ha trovato pacchetti inesistenti nel 5,2% dei casi sui modelli commerciali e nel 21,7% su quelli open source, per un totale di 205.474 nomi di pacchetto unici mai esistiti (Spracklen et al., USENIX Security 2025). Un nome inventato che qualcuno registra davvero diventa un canale d'ingresso pulito: è il fenomeno che chiamano slopsquatting.
Ma la dipendenza allucinata è il caso patologico, ed è anche il più facile da intercettare: un pacchetto che non esiste rompe la build. Il caso normale è più silenzioso e, per il CRA, più importante: l'AI importa pacchetti che esistono e funzionano, e che nessuno ha scelto consapevolmente. Nessuno li ha valutati per manutenzione, licenza, provenienza, storia delle vulnerabilità. Nessuno ha deciso di assumersene la responsabilità: sono semplicemente comparsi nel file delle dipendenze insieme a una funzione che serviva.
Se il criterio di accettazione di quel codice è «funziona», il criterio funziona benissimo — finché non devi dichiarare a un'autorità cosa c'è dentro il tuo prodotto, entro ventiquattro ore, con il tuo nome sulla scatola.
Non è un argomento contro l'AI nello sviluppo: la produttività è reale. È un argomento sul cancello. Se la generazione accelera di dieci volte e il cancello resta «passano i test», l'inventario si sfalda dieci volte più in fretta. Il cancello giusto è banale da descrivere e richiede disciplina da tenere: ogni build produce la sua distinta base, ogni dipendenza nuova compare in un diff che una persona guarda, ogni componente ha un proprietario. Chi genera codice con l'AI ha più bisogno di una SBOM, non meno.
07Cosa mettere a contratto, e cosa fare adesso
C'è un'asimmetria strutturale nel CRA che le PMI incontrano subito: l'obbligo sta su chi immette il prodotto sul mercato a proprio nome, ma la conoscenza dei componenti sta spesso sul fornitore software. Il regolamento chiede al fabbricante di esercitare la dovuta diligenza quando integra componenti di terzi, «affinché tali componenti non compromettano la sicurezza del prodotto» (art. 13, par. 5) — ma la dovuta diligenza, in pratica, si esercita con il contratto. Sono tre clausole, e vanno scritte prima che serva usarle:
- Tempi di notifica del fornitore più stretti dei tuoi. Se hai ventiquattro ore da quando vieni a conoscenza, il fornitore deve avvisarti in una frazione di quel tempo, con canale e destinatario nominati — non un indirizzo generico di assistenza.
- Consegna della SBOM a ogni release, in formato di uso comune e leggibile a macchina, aggiornata quando cambia una dipendenza. È l'unico modo perché l'inventario resti vivo invece di essere una fotografia scaduta.
- Cooperazione durante la finestra di segnalazione, con reperibilità definita e responsabilità esplicite se il ritardo nasce a monte. Aggiungi la durata del periodo di supporto e degli aggiornamenti di sicurezza: è una variabile contrattuale, non un dato di fatto.
Sul piano interno l'ordine che funziona è questo. Primo, il perimetro: quali prodotti immetti a tuo nome e in quali Paesi UE sono disponibili — la lista dei Paesi è un'informazione che l'early warning chiede espressamente, ed è quella che di solito manca. Secondo, l'inventario dei componenti generato automaticamente dentro la pipeline di build: una SBOM fatta a mano è già vecchia il giorno dopo. Terzo, una procedura di segnalazione con nomi e numeri di telefono, che risponda a una domanda sola — chi decide, alle tre di notte di un sabato, che quel fatto va notificato — provata almeno una volta a freddo. Quarto, i contratti. In quest'ordine: il quarto senza il primo non serve a niente.
Il monitoraggio tecnico continuo — correlare ogni giorno le nuove CVE con l'inventario — è un'altra capacità, e in casa nostra vive nella famiglia Fenrir. Ma viene dopo: senza inventario non c'è niente da correlare. Il lavoro che P3 fa su questa scadenza è quello a monte, ed è il lavoro noioso: perimetro, distinta base, procedura, clausole. È lo stesso metodo con cui affrontiamo NIS2 e DORA — prima la fotografia, poi le decisioni — e la stessa logica di controllo che chiamiamo sovranità operativa: sapere cosa c'è nei tuoi sistemi è il presupposto di ogni altra scelta, incluso il software sovrano e la valutazione di un fornitore cloud. Se il punto di partenza è la fotografia di rete, dati e fornitori, quello è un audit on-prem di sette giorni.