Il CRA è un problema del 2026, non del 2027

Chiedete a un team di prodotto quando il Cyber Resilience Act (CRA) li colpirà e la maggior parte risponderà dicembre 2027. È questa la data in cui si applicano i requisiti essenziali, la valutazione della conformità e la marcatura CE, ed è la data a cui ogni presentazione di roadmap si allinea. È anche la data sbagliata da cui partire per la pianificazione.

Il CRA è entrato in vigore il 10 dicembre 2024 e l'articolo 71 stabilisce un calendario sfalsato, non una singola scadenza. Le disposizioni relative alla notifica degli organismi di valutazione della conformità (Capitolo IV, articoli da 35 a 51) si applicano a partire dall'11 giugno 2026. Gli obblighi di reporting dell'articolo 14 si applicano dall'11 settembre 2026. Solo il corpo principale del regolamento, i requisiti essenziali dell'Allegato I e il percorso di conformità per ottenere la marcatura CE, entreranno in vigore l'11 dicembre 2027 (Regolamento (UE) 2024/2847, articolo 71; Commissione europea, "Il Cyber Resilience Act: sintesi del testo legislativo", digital-strategy.ec.europa.eu). Quindi, il primo obbligo concreto per un produttore già in ambito di applicazione scatta circa quindici mesi prima della data a cui tutti stanno pianificando.

Questo non è un appello a iniziare presto. È una constatazione sull'ordine. Il team che organizza il lavoro sul CRA partendo all'indietro dalla marcatura CE del 2027 ha posizionato l'obbligo di reporting per ultimo, quando sia il calendario che le dipendenze operative lo pongono per primo.

Cosa entra effettivamente in vigore nel 2026

L'articolo 14 non è un obbligo burocratico da aggiungere alla fine. A partire dall'11 settembre 2026, un produttore di un prodotto con elementi digitali deve notificare qualsiasi vulnerabilità attivamente sfruttata in quel prodotto, nonché qualsiasi incidente grave che ne comprometta la sicurezza, al CSIRT designato come coordinatore per lo Stato membro rilevante e a ENISA, tramite una singola piattaforma di reporting. Il tempo a disposizione è inesorabile: una segnalazione preliminare entro 24 ore dal momento in cui si viene a conoscenza dell'evento, una notifica più completa entro 72 ore e un rapporto finale entro 14 giorni dal momento in cui è disponibile una misura correttiva per la vulnerabilità, o entro un mese per un incidente grave (Regolamento (UE) 2024/2847, articolo 14).

Leggete attentamente la condizione scatenante. Una "vulnerabilità attivamente sfruttata" è una vulnerabilità per cui esistono prove attendibili che un attore abbia eseguito un codice malevolo su un sistema senza il permesso del proprietario del sistema (Regolamento (UE) 2024/2847, articolo 3). Non si tratta di un'ipotesi che si può gestire con calma. È un evento reale, datato, che avvia un timer di 24 ore nel momento in cui ne venite a conoscenza, e questo obbligo entra in vigore oltre un anno prima dei requisiti essenziali che vi avrebbero reso capaci di rilevarlo.

Il dovere di conoscenza arriva prima del dovere di gestione

Ecco l'inversione che la pianificazione ancorata al 2027 trascura. Un dovere di segnalazione entro 24 ore dal momento in cui si viene a conoscenza di un evento è, in pratica, un dovere di essere in grado di venire a conoscenza. Non potete inviare una segnalazione preliminare su una vulnerabilità attivamente sfruttata nel vostro prodotto se non avete un canale attraverso cui l'exploit vi raggiunge, un inventario che vi dica quali versioni distribuite contengono il componente interessato e una regola di triage che decida se un incidente è "grave" prima che scada la finestra di 72 ore.

Ognuna di queste capacità è descritta nell'Allegato I, Parte II dello stesso regolamento: mantenere una software bill of materials che copra almeno le dipendenze di primo livello in un formato leggibile dalla macchina, operare una politica di disclosure coordinata delle vulnerabilità con un punto di contatto per le segnalazioni e rimediare alle vulnerabilità senza indugio tramite aggiornamenti di sicurezza (Regolamento (UE) 2024/2847, Allegato I, Parte II). Questi requisiti sono legalmente dovuti l'11 dicembre 2027. Ma l'obbligo di reporting che vi vincola legalmente dall'11 settembre 2026 è difficile da soddisfare in modo affidabile senza di essi. La legge vi permette di posticipare il processo di gestione al 2027; non vi permette di posticipare le conseguenze una volta che la consapevolezza dell'evento si verifica.

Quindi, l'effetto pratico dell'articolo 14, per chiunque sia effettivamente in ambito di applicazione, è anticipare la necessità di parti del modello operativo dell'Allegato I Parte II di quindici mesi. Non perché i requisiti essenziali si applichino in anticipo, ma perché l'obbligo di reporting è difficile da soddisfare in modo affidabile senza la struttura operativa che quei requisiti descrivono.

L'obiezione, e perché non regge

Un professionista attento solleverà un'obiezione, e vale la pena prenderla sul serio. L'articolo 14 è circoscritto. Si applica solo alle vulnerabilità attivamente sfruttate e agli incidenti gravi, non alla routine di segnalazioni di basso livello. Un prodotto ben gestito potrebbe trascorrere molto tempo senza un evento segnalabile. Perché non implementare un processo di reporting semplificato da settembre 2026, mantenere lo sviluppo della gestione delle vulnerabilità sulla tabella di marcia del 2027 e accettare il piccolo rischio di un evento anticipato?

Tre motivi per cui la versione semplificata è una trappola.

Innanzitutto, la prospettiva dell'evento raro capovolge il rischio. L'obbligo non è gravoso perché si verifica spesso. È pericoloso perché si verifica in modo imprevedibile e avvia un timer di 24 ore che non potete permettervi di perdere per costruire capacità. La settimana in cui avete una vulnerabilità attivamente sfruttata è proprio la settimana in cui non potete permettervi di assemblare una software bill of materials per capire quali clienti sono interessati.

In secondo luogo, la forma della responsabilità è diversa da una lacuna di conformità, ed è peggiore. Una postura incompleta secondo l'Allegato I emerge durante la valutazione, in una stanza, con una possibilità di rimediare. Una notifica mancata entro 24 ore è un fallimento distinto, datato e dimostrabile esternamente. Crea un record che in seguito potrebbe essere rilevante in discussioni di supervisione o di applicazione della legge, e il tracciato di reporting che costruite da settembre 2026 fa parte di quel record. Un processo semplificato non è una versione ridotta della conformità; è una traccia documentata dei momenti in cui non eravate pronti.

In terzo luogo, un processo di reporting senza un processo di gestione alle spalle è una messinscena. Essere in grado di inviare un modulo a ENISA entro 24 ore è inutile se non potete rispondere alle domande effettive del modulo: quali versioni sono interessate, qual è la misura correttiva e quando viene distribuita. L'obbligo di reporting e i requisiti di gestione sono un unico sistema osservato in due momenti diversi. Non potete acquistare la metà osservabile e saltare quella operativa.

Pianificate all'indietro partendo da settembre 2026

La correzione pratica non è "fate tutto ora". È identificare il sottoinsieme minimo dei requisiti essenziali del 2027 che l'articolo 14 rende critici nel 2026 e programmare quel sottoinsieme rispetto alla data di settembre piuttosto che a quella di dicembre 2027.

Questo minimo per la prontezza della segnalazione è più piccolo dell'intero programma dell'Allegato I ed è abbastanza specifico da pianificare:

• Una software bill of materials aggiornata per ogni prodotto distribuito, almeno per le dipendenze di primo livello, in modo che nel giorno di una vulnerabilità sfruttata possiate definire l'impatto in ore, non in settimane.
• Un canale di ricezione monitorato e una politica di disclosure coordinata delle vulnerabilità, in modo che gli exploit e le segnalazioni di terze parti vi raggiungano effettivamente e avviino il timer a cui siete responsabili.
• Una regola scritta di triage per la gravità e gli incidenti che possa classificare un evento come segnalabile entro la finestra di 72 ore senza convocare un comitato.
• Un proprietario designato e un percorso di invio testato verso il CSIRT coordinatore e ENISA, verificato sulla piattaforma di reporting prima di doverlo utilizzare in condizioni operative reali.

Niente di tutto ciò richiede gli standard armonizzati o il percorso di conformità che sono ancora in fase di finalizzazione per il 2027. Tutto ciò può essere costruito ora e rappresenta un acconto sugli obblighi del 2027 piuttosto che un lavoro da buttare. I produttori di prodotti importanti nell'Allegato III Classe II hanno un secondo motivo per non aspettare: il loro percorso di conformità richiede generalmente un organismo notificato, e questi organismi possono essere designati solo una volta che la macchina del Capitolo IV entra in vigore l'11 giugno 2026. La capacità di valutazione è finita e le code si formano alle scadenze, non prima.

La regola da tenere a mente

Quando un regolamento si applica in fasi, la data principale è solitamente l'ultima, e l'ultima data è la meno utile per la pianificazione. Leggete invece il calendario sfalsato e chiedetevi quale obbligo dipende dagli altri. Per il CRA, l'obbligo di reporting dell'articolo 14 arriva per primo nel calendario e per primo nel grafo delle dipendenze: non potete segnalare ciò che non potete rilevare, e non potete rilevare senza la struttura di gestione che i requisiti del 2027 descrivono. Pianificate il lavoro all'indietro partendo dall'11 settembre 2026, non in avanti verso l'11 dicembre 2027, e l'ordine emergerà da sé.

Se il vostro compito immediato è capire quali dei vostri prodotti sono raggiunti dal CRA e cosa l'obbligo di reporting di settembre 2026 richiede effettivamente per ciascuno di essi, questa attività di definizione dell'ambito e di incrocio dei riferimenti è il tipo di lavoro per cui ISMS Copilot è stato progettato per velocizzare il processo. Per molti team, il lavoro per la marcatura CE è una scadenza del 2027; la prontezza secondo l'articolo 14 è una scadenza del 2026. Pianificate per la prima scadenza prima.

Questa è un'analisi pratica della conformità, non un parere legale. Confermate l'ambito di applicazione del vostro prodotto e gli obblighi che vi competono consultando direttamente il regolamento e, ove necessario, la vostra autorità competente o un consulente legale.