La maggior parte dei calendari di conformità indica il Cyber Resilience Act come un obbligo a partire dal dicembre 2027. È a partire da quella data che entrerà in vigore il contenuto del regolamento: sicurezza fin dalla progettazione, documentazione tecnica, valutazione della conformità e marcatura CE.
Tuttavia, gli obblighi di segnalazione entrano in vigore molto prima. A partire dall’11 settembre 2026, i produttori di prodotti con componenti digitali dovranno segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi entro termini prestabiliti, e tali obblighi si estendono ai prodotti già immessi sul mercato dell’UE. Un prodotto spedito per la prima volta nel 2018 e ancora oggi in vendita rientra nell’ambito di applicazione sin dal primo giorno.
Per i produttori, ciò comporta un termine di segnalazione di 24 ore. Per la popolazione ben più ampia di organizzazioni che acquistano e gestiscono la tecnologia anziché immetterla sul mercato, il CRA introduce un aspetto meno visibile e per il quale sono notevolmente meno preparate: un nuovo flusso di notifiche di sicurezza provenienti da terze parti, secondo i loro tempi piuttosto che i propri.
A due settimane dalla scadenza, pochissime organizzazioni hanno stabilito chi sarà incaricato di riceverle.
Non è prevista alcuna presentazione nella data stessa. Non c’è alcuna dichiarazione da presentare né alcun modulo da compilare. L’11 settembre è il momento in cui entrano in vigore gli obblighi determinati dagli eventi, il che rende più difficile pianificarli rispetto a una scadenza convenzionale. Il fattore scatenante è un incidente, e gli incidenti non seguono i calendari.
Per i produttori il quadro normativo è chiaro. Una volta che un’organizzazione viene a conoscenza del fatto che una vulnerabilità in uno dei suoi prodotti viene sfruttata attivamente, ha 24 ore per emettere un allarme preventivo, 72 ore per fornire una notifica più completa e un periodo definito successivamente per presentare una relazione finale. Le sanzioni per la mancata ottemperanza agli obblighi fondamentali previsti dal regolamento a carico dei produttori arrivano a 15 milioni di euro o al 2,5% del fatturato annuo globale, a seconda di quale sia l’importo più elevato.
Se un’organizzazione rientri in tale categoria viene affrontato di seguito. L’osservazione più ampia, che finora ha attirato poca attenzione, è che l’effetto operativo più immediato del CRA sarà avvertito dalle organizzazioni che non sono direttamente soggette alla sua regolamentazione.
Vale la pena soffermarsi sulla sequenza di ciò che entrerà in vigore a settembre.
La piattaforma di segnalazione gestita dall’ENISA dovrebbe diventare operativa entro tale data, piuttosto che prima. Gli standard armonizzati che definiranno i criteri di conformità per i produttori sono ancora in fase di consultazione pubblica. Inoltre, l’obbligo di mantenere una politica coordinata di divulgazione delle vulnerabilità – il meccanismo attraverso il quale i produttori vengono a sapere più comunemente che i loro prodotti sono oggetto di attacchi – non diventerà generalmente applicabile fino a dicembre 2027.
L’obbligo di segnalazione precede quindi l’obbligo di istituire il canale attraverso il quale proviene la maggior parte delle segnalazioni.
Non si tratta di una svista. Ciò riflette un cambiamento deliberato nella sequenza con cui viene strutturata la regolamentazione digitale dell’UE: gli obblighi vengono introdotti gradualmente ed entrano in vigore prima dell’infrastruttura di supporto, sulla base del ragionamento che attendere la completa disponibilità degli strumenti ritarderebbe di anni la riduzione dei rischi. La direttiva NIS2 ha seguito questo modello. La legge sull’IA lo ha seguito. Il CRA lo sta seguendo ora.
Per le funzioni di GRC, l’implicazione è strutturale piuttosto che tattica. I programmi di conformità devono operare sempre più spesso nell’intervallo che intercorre tra l’entrata in vigore di un obbligo e la maturazione dell’ecosistema che lo circonda. Pianificare partendo dal presupposto che la normativa arrivi già completamente definita significa pianificare sulla base di un modello che non è più applicabile.
Ciò richiede una valutazione breve e ponderata, poiché le eccezioni comportano costi elevati.
Poche organizzazioni si definiscono «produttori». La normativa non si basa sull’autodefinizione. Essa considera ciò che viene immesso sul mercato dell’UE e sotto quale nome o marchio. L’hardware a marchio proprio, il firmware integrato, i dispositivi connessi rivenduti con il logo dell’azienda e il software incorporato in un prodotto fisico possono tutti far rientrare un’organizzazione nell’ambito di applicazione. Gli importatori e i distributori che rimarchiano un prodotto o lo modificano in modo sostanziale si assumono di conseguenza gli obblighi del produttore.
La domanda rilevante non è quindi se un’organizzazione sviluppi software, bensì: cosa immette l’organizzazione sul mercato dell’UE, a nome di chi, e cosa contiene quel prodotto?
Consigliamo di documentare la risposta questa settimana. Per la maggior parte delle organizzazioni si tratta di un’operazione di breve durata. Per una minoranza, invece, rappresenta la differenza tra un programma gestito e uno non pianificato.
Oltre ai propri doveri nei confronti delle autorità, il CRA richiede che un produttore che venga a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave informi gli utenti interessati e, se del caso, tutti gli utenti, indicando anche le misure di mitigazione che tali utenti possono adottare. Qualora un produttore non lo faccia entro un periodo ragionevole, il CSIRT nazionale di coordinamento può comunicare direttamente le informazioni.
Considerato dal punto di vista del destinatario, ciò crea un flusso in entrata del tutto nuovo. A partire dall’11 settembre, le organizzazioni inizieranno a ricevere notifiche di sicurezza relative ai prodotti presenti nel proprio ambiente, emesse dal produttore di tali prodotti, che spesso non è la parte con cui intrattengono il rapporto commerciale.
Ne derivano tre conseguenze.
La responsabilità non è definita. Queste notifiche arrivano in genere a un account manager, all’interno del reparto acquisti, oppure in una casella di posta condivisa controllata durante l’orario di lavoro. Secondo la nostra esperienza, gli avvisi di vulnerabilità dei fornitori vengono raramente indirizzati, per impostazione predefinita, al processo di triage degli incidenti. Vengono invece inoltrati in modo informale da chiunque ne riconosca l’importanza.
La notifica avvia una valutazione, non una segnalazione. Questa distinzione viene spesso fraintesa e vale la pena precisarla. Un avviso del produttore non costituisce di per sé un incidente segnalabile. Il fatto che diventi tale ai sensi della NIS2 o del DORA dipende dal fatto che i servizi dell’organizzazione stessa siano sostanzialmente interessati, cosa che raramente risulta evidente entro la prima ora. Questo è proprio il motivo per cui è importante strutturare la prima ora. Qualora la soglia venga successivamente superata, l’organizzazione dovrà dimostrare il momento in cui ne è venuta a conoscenza.
Attualmente i contratti non affrontano questo aspetto. Pochi accordi con i fornitori specificano il canale di notifica, il formato, il destinatario designato o i tempi previsti. In questo ambito, il CRA offre al settore degli appalti ciò che prima mancava. Per un decennio, la garanzia di sicurezza dei fornitori si è basata in gran parte su questionari con forza contrattuale limitata. Il regolamento stabilisce ora una linea di base rispetto alla quale è possibile negoziare impegni specifici: accesso a una distinta dei materiali software (SBOM), una politica di divulgazione pubblicata, un periodo di supporto definito e modalità di notifica concordate. Va notato che la CRA obbliga i produttori a redigere una SBOM, ma non li obbliga a fornirla ai propri clienti. A tale distinzione servono i rinnovi contrattuali, e la maggior parte di essi scade ben prima del dicembre 2027.
Ogni termine previsto da questo regime decorre dal momento in cui si viene a conoscenza della situazione.
La Commissione europea ha affrontato questo aspetto a livello di produttore, pubblicando nel luglio 2026 delle linee guida che spiegano quando si ritiene che un produttore ne sia venuto a conoscenza. Ciò che nessuna linea guida esterna può determinare è chi, all’interno di una determinata organizzazione, sia in grado di venirne a conoscenza per conto di essa.
In pratica, la segnalazione arriva tramite un tecnico dell’assistenza alle 19:00, un ricercatore che scrive a un indirizzo e-mail generico o il team di sicurezza di un cliente che contatta un account manager in ferie.
Il parallelo con il GDPR è istruttivo. Le violazioni sono state segnalate con settimane di ritardo, non per occultamento, ma a causa di un errore di classificazione. Il supporto tecnico ha registrato il problema come un difetto. Il reparto IT lo ha trattato come un errore di configurazione. Nessuno aveva concordato cosa costituisse un evento segnalabile, la valutazione non è mai stata avviata e l’ufficio legale ne è venuto a conoscenza solo quando un cliente ha sollevato una domanda.
Tre elementi dovrebbero essere documentati prima dell’11 settembre: i criteri che determinano una valutazione immediata, le persone autorizzate a segnalare il problema ai livelli superiori e a prendere una decisione al di fuori dell’orario di lavoro, e il registro in cui viene registrato quel momento.
Due settimane non sono sufficienti per istituire un programma CRA completo. Sono sufficienti per definire le componenti che devono essere operative per prime.
Per le organizzazioni che immettono prodotti sul mercato dell’UE:
Per tutte le altre organizzazioni:
L’ultimo punto è l’unico che dimostra se gli altri funzionano.
Un’organizzazione può impiegare ogni strumento a disposizione e comunque perdere il momento cruciale.
Un allarme preventivo non può essere presentato sulla base di un certificato. Un prodotto non può essere classificato in base a una politica. E una valutazione 24 ore su 24 non può essere condotta secondo un processo che esiste solo come documento che nessuno ha mai provato.
Le organizzazioni che gestiranno bene il mese di settembre saranno quelle in cui una persona designata, contattata alle 19:00 di sabato, capisce di essere autorizzata ad agire.
Qualunque sia la tecnologia, tutto inizia con la giusta dose di governance.
Due settimane non bastano per costruire un programma CRA, ma sono sufficienti per rispondere alle due domande sollevate in questo articolo: se il regolamento si applica alla vostra organizzazione e chi riceve la notifica quando arriva.
I nostri servizi CRA coprono la definizione dell’ambito di applicabilità, la preparazione alla rendicontazione ai sensi dell’articolo 14, l’inoltro delle notifiche ai fornitori e l’integrazione degli obblighi CRA nei programmi NIS2 e DORA già in corso.
Invitiamo le organizzazioni ad affrontare questo tema prima dell’11 settembre. Dopo tale data, la situazione sarà diversa.