L'Articolo 14 è quello che fa partire l'orologio

Non sai se il CRA si applica al tuo prodotto? Verifica la classe di rischio in quattro passaggi.

1. Che cosa richiede l'Art. 14

L'Art. 14 impone al fabbricante di un prodotto con elementi digitali il dovere di segnalare due tipi di eventi: ogni vulnerabilità attivamente sfruttata contenuta nel prodotto e ogni incidente grave che abbia un impatto sulla sicurezza di quel prodotto. Il dovere è rivolto al CSIRT designato come coordinatore e, in parallelo, ad ENISA, attraverso la piattaforma unica di segnalazione.

Il soggetto obbligato è il fabbricante, non il rivenditore e non l'utente finale: chi sviluppa o fabbrica il prodotto, oppure lo fa sviluppare o fabbricare e lo commercializza con il proprio nome o marchio, ha il dovere. Il perimetro è il prodotto immesso sul mercato, a prescindere da quando è stato venduto la prima volta. Un prodotto sul mercato da anni rientra pienamente nel perimetro.

2. I tre termini, su due catene parallele

Ogni evento da notificare passa per tre passaggi: un preallarme, la notifica a 72 ore — notifica delle vulnerabilità su una catena, notifica di incidente sull'altra — e una relazione finale. I primi due termini sono identici sulle due catene — 24 ore per il preallarme, 72 ore per quella notifica — ma la relazione finale ha due termini diversi a seconda di che cosa si sta segnalando. Confonderli è l'errore più frequente nelle procedure interne che ci vengono mostrate.

Catena uno, vulnerabilità attivamente sfruttate: preallarme entro 24 ore dalla conoscenza; notifica delle vulnerabilità entro 72 ore; relazione finale entro 14 giorni dalla disponibilità di una misura correttiva o di attenuazione. Il termine finale è agganciato alla disponibilità della correzione, non al calendario.

Catena due, incidenti gravi con impatto sulla sicurezza del prodotto: preallarme entro 24 ore, notifica di incidente entro 72 ore, e poi relazione finale entro un mese dalla notifica di incidente. Stessi primi due passaggi, ancoraggio diverso per l'ultimo. Poiché il calcolo del termine finale dipende da come l'evento è stato qualificato al primo passaggio, la qualificazione va registrata insieme all'articolo applicato.

3. Sfruttata non è lo stesso che segnalata

La catena delle vulnerabilità non parte da ogni vulnerabilità. Parte solo quando esistono prove attendibili che qualcuno abbia sfruttato la vulnerabilità in un sistema senza l'autorizzazione del proprietario. La divulgazione responsabile di un ricercatore, un articolo accademico, uno scanner che segnala una libreria vecchia: nulla di tutto questo, da solo, fa partire l'orologio delle 24 ore, perché nulla di tutto questo è prova di uno sfruttamento reale e non autorizzato.

La distinzione taglia in entrambe le direzioni. Segnalare troppo poco ti espone a una sanzione; segnalare tutto brucia credibilità presso il CSIRT e consuma tempo che servirà per i casi reali. La decisione che una data segnalazione non è, o non è ancora, una vulnerabilità attivamente sfruttata va presa in fretta e, soprattutto, va messa per iscritto: un «no» motivato è una difesa, un «no» implicito non lascia traccia quando un ispettore chiede perché non hai depositato.

4. L'orologio parte dalla conoscenza, non dal lunedì

Le 24 ore decorrono dal momento in cui l'azienda viene a conoscenza dell'evento. Non da quando il responsabile apre la mail, non dal lunedì mattina, non dalla riunione di allineamento. Se una segnalazione arriva all'indirizzo pubblico alle 23:40 di sabato, quello è l'istante che dovrai difendere davanti al CSIRT e, se si arriva a tanto, davanti all'autorità di vigilanza del mercato.

Questo sposta il problema dall'area tecnica a quella organizzativa. Ne discendono tre cose: un canale di ricezione unico e presidiato, che qualcuno guardi davvero; una regola di qualificazione scritta che dica chi decide se l'orologio è partito e su quali criteri; e una catena di reperibilità con soglie orarie e sostituti nominati. Le aziende che abbiamo visto in difficoltà non avevano un problema di competenza — avevano un problema di reperibilità.

5. Due adempimenti che quasi tutti dimenticano

Il primo è l'avviso agli utenti. Dopo aver notificato alle autorità, e senza indebito ritardo, il fabbricante informa gli utenti del prodotto sull'incidente o sulla vulnerabilità e, dove opportuno, sulle misure correttive o di attenuazione che possono adottare. Va conservata copia di quanto diffuso, con la data: l'avviso agli utenti è un obbligo a sé, non una cortesia.

Il secondo è la segnalazione a monte. Se la vulnerabilità si trova in un componente di terzi — anche open source — il fabbricante deve segnalarla alla persona o all'entità che mantiene il componente e cooperare con essa. Questo dovere, fissato dall'Art. 13(6), è materialmente impossibile senza una distinta base del software aggiornata: senza un SBOM non si sa né quali dei propri prodotti incorporano il componente né a chi scrivere.

6. Sanzioni: quanto, e che cosa le attenua

Le violazioni degli obblighi previsti dagli Articoli 13 e 14 — che comprendono i doveri di segnalazione che abbiamo descritto — sono soggette a sanzioni amministrative fino a 15 milioni di euro oppure, se l'autore è un'impresa, fino al 2,5% del fatturato mondiale annuo totale dell'esercizio precedente, se superiore. È la fascia più alta dello schema sanzionatorio del regolamento, e si applica ai doveri di segnalazione, non solo alla non conformità del prodotto.

L'importo non è automatico. Nel fissare la sanzione l'autorità pondera la natura e la gravità della violazione, la sua durata, il carattere doloso o colposo, e il grado di cooperazione con le autorità. In pratica è qui che la due diligence documentata paga: una decisione di qualificazione scritta, un registro di ricezione con marca temporale e la prova di una cooperazione tempestiva cambiano l'esito dello stesso evento sottostante.

7. Cosa fare prima dell'11 settembre 2026

Tre cose operative, in ordine di urgenza. Un canale pubblico di ricezione delle segnalazioni, abbinato a una politica di divulgazione coordinata delle vulnerabilità pubblicata dove i ricercatori la cercano — un file security.txt sul tuo dominio. Una regola di qualificazione scritta che dica chi decide se l'orologio è partito e su quali criteri. Una catena di reperibilità con soglie orarie e sostituti nominati, così che il caso del sabato sera abbia un responsabile.

Poi due prerequisiti amministrativi che seguono tempi non tuoi: le credenziali EU Login necessarie per raggiungere la piattaforma di segnalazione, e la designazione del tuo referente presso il CSIRT nazionale — in Italia, il CSIRT Italia dell'ACN. Chiederle il giorno dell'emergenza significa arrivare tardi per un motivo che non ha nulla di tecnico. Individua in anticipo le persone che potranno operare come rappresentante designato (Assigned Representative) sulla piattaforma, e completa la registrazione e l'associazione alla piattaforma unica di segnalazione seguendo le indicazioni ENISA vigenti al momento della notifica — il procedimento può evolvere, quindi non darlo per fisso. CRAnotify prepara il deposito ma non automatizza l'invio finale sulla SRP: non esiste un'API SRP automatica, e il deposito resta un atto del fabbricante, compiuto con le proprie credenziali. Il passo-passo è nella pagina dedicata.

Il resto — l'anagrafica dei prodotti, la distinta base del software, le integrazioni — si costruisce nei mesi successivi. Ma senza queste cinque cose pronte, la prima segnalazione reale ti troverà scoperto, e quella prima segnalazione può arrivare il giorno dopo l'11 settembre 2026.

Questo articolo descrive la nostra lettura del testo normativo e non costituisce parere legale.