Il Cyber Resilience Act: l'11 settembre 2026 è una scadenza vera

La maggior parte dei regolamenti europei vi dà una data di conformità e un periodo di grazia durante il quale tutti si organizzano con calma. Il Cyber Resilience Act fa qualcosa di diverso. Il suo primo obbligo stringente è un orologio di segnalazione di 24 ore, e parte l'11 settembre 2026.

Un orologio di 24 ore non si introduce gradualmente. O il processo esiste quel giorno, o mancate la scadenza.

Cos'è il CRA

Il Regolamento (UE) 2024/2847 fissa requisiti di cibersicurezza per i prodotti con elementi digitali immessi sul mercato dell'UE. Quell'espressione copre molto più di quanto si supponga inizialmente: qualsiasi prodotto software o hardware, e le sue soluzioni di elaborazione dati a distanza, il cui uso previsto o ragionevolmente prevedibile includa una connessione dati diretta o indiretta.

I dispositivi connessi rientrano. E anche la maggior parte del software commerciale, i sistemi operativi, i browser, le app mobili, il firmware e i componenti dentro altri prodotti.

Il Regolamento è stato pubblicato a novembre 2024 e si applica per fasi:

11 giugno 2026: obblighi per gli organismi di valutazione della conformità.
11 settembre 2026: obblighi di segnalazione per vulnerabilità attivamente sfruttate e incidenti gravi.
11 dicembre 2027: piena applicazione, inclusi requisiti essenziali di cibersicurezza, marcatura CE, documentazione tecnica e distinta base del software.

La data intermedia è quella su cui pianificare, perché arriva per prima e perché dipende da capacità che potreste non avere.

Cosa succede l'11 settembre 2026

Da quella data i fabbricanti devono segnalare:

Vulnerabilità attivamente sfruttate nei loro prodotti con elementi digitali, e

incidenti gravi che riguardano la sicurezza di tali prodotti.

La segnalazione passa dalla Piattaforma unica di segnalazione del CRA, gestita dall'ENISA, verso il CSIRT designato nello Stato membro dello stabilimento principale del fabbricante, che poi condivide con gli altri CSIRT interessati e con l'ENISA.

I tempi:

Entro 24 ore dalla conoscenza: un preallarme.
Entro 72 ore: una notifica completa, incluse le misure correttive o di mitigazione adottate.
Entro 14 giorni da quando una misura correttiva è disponibile: una relazione finale per una vulnerabilità attivamente sfruttata.
Entro un mese: una relazione finale per un incidente grave.

Ventiquattro ore dalla conoscenza, non dalla conferma né dal rimedio. Se una vulnerabilità in un componente del vostro prodotto viene sfruttata in rete di sabato, l'orologio corre di sabato.

Perché è più difficile di quanto sembri

L'obbligo di segnalazione in sé è un modulo. La difficoltà sta in tutto ciò che serve avere prima di poterlo compilare.

Dovete sapere cosa c'è nel vostro prodotto

Per segnalare che una vulnerabilità nel vostro prodotto è attivamente sfruttata, dovete sapere che il componente vulnerabile è nel vostro prodotto. Per un'applicazione moderna con centinaia di dipendenze transitive, non è qualcosa a cui un umano risponde a memoria.

Per questo i team stanno costruendo ora pipeline per la distinta base del software, con oltre un anno di anticipo sul requisito formale di SBOM di dicembre 2027. La SBOM non è l'obiettivo. L'obiettivo è poter rispondere a «siamo interessati?» in poche ore, e la SBOM è ciò che rende la domanda rispondibile.

L'aspetto scomodo è che questo vale anche per prodotti spediti anni fa. Se avete dispositivi supportati sul campo che eseguono firmware compilato nel 2022 da un albero di dipendenze che nessuno ha registrato, ricostruirlo è lavoro vero.

Dovete stare a guardare

La conoscenza fa partire l'orologio, e ci si aspetta che sia attiva anziché accidentale. Significa monitorare i feed di vulnerabilità, iscriversi agli avvisi dei propri componenti, seguire i cataloghi delle vulnerabilità sfruttate note e avere un canale su cui i ricercatori di sicurezza possano raggiungervi e ottenere risposta.

Dovete avere un percorso decisionale

Qualcuno deve poter decidere, a qualsiasi ora, se un incidente supera la soglia e se l'orologio è partito. Senza un ruolo nominato e un percorso di escalation, le prime ore se ne vanno a capire chi possa prendere la decisione.

Le dipendenze a fine vita diventano una passività

Se un componente del vostro prodotto non riceve più aggiornamenti di sicurezza, portate comunque l'obbligo di segnalazione quando viene sfruttato, e non avete alcuna correzione a monte da indicare. Verificare le dipendenze a fine vita è tra le cose più utili nella fase preparatoria, perché la risposta a volte impone una migrazione con i suoi tempi.

Cosa porta la piena applicazione a dicembre 2027

Gli obblighi di dicembre 2027 sono il programma più grande e vanno avviati molto prima.

Sicurezza fin dalla progettazione e per impostazione predefinita. I prodotti devono essere progettati, sviluppati e fabbricati per garantire un livello adeguato di cibersicurezza basato sul rischio. Nessuna password predefinita. Configurazione sicura all'uscita dalla scatola. Minimizzazione della superficie di attacco. Protezione dei dati in transito e a riposo.

Gestione delle vulnerabilità. Un processo documentato che copra identificazione, correzione, test, distribuzione e divulgazione. Gli aggiornamenti di sicurezza devono essere forniti senza ritardo e gratuitamente, per un periodo di supporto che rifletta la vita attesa del prodotto, con cinque anni come riferimento comune.

Distinta base del software. In formato leggibile da macchina, che copra almeno le dipendenze di primo livello e sia mantenuta aggiornata.

Documentazione tecnica e valutazione della conformità. La maggior parte dei prodotti si autovaluta. Le categorie importanti e critiche, che includono per esempio gestori di password, VPN, sistemi operativi e sistemi di controllo industriale, richiedono il coinvolgimento di un terzo.

Marcatura CE. L'equivalente digitale del marchio fisico, che dichiara la conformità.

Politica di divulgazione coordinata delle vulnerabilità. Pubblicata, con un punto di contatto funzionante.

Chi rientra davvero

Alcuni casi limite ricorrono di continuo.

Il software libero e open source sviluppato al di fuori di un'attività commerciale è in gran parte fuori ambito. Il Regolamento introduce la figura del gestore di software open source con obblighi più leggeri. Ma se commercializzate open source, o lo spedite dentro un prodotto che vendete, gli obblighi di prodotto sono vostri.

Il software come servizio resta in genere fuori dal CRA e ricade piuttosto sotto NIS2, anche se le soluzioni di elaborazione dati a distanza integranti un prodotto con elementi digitali vengono trascinate dentro. Se il vostro dispositivo dipende dal vostro backend cloud per funzionare, quel backend viaggia con il prodotto.

Importatori e distributori hanno anch'essi obblighi. Se immettete sul mercato UE un prodotto di terzi con il vostro nome o marchio, siete trattati come fabbricanti.

I prodotti già regolamentati altrove, come dispositivi medici, veicoli e apparecchiature aeronautiche, sono trattati nei rispettivi quadri.

Le questioni di ambito non sono affatto banali ed è un punto in cui un'ora con i vostri legali fa risparmiare mesi di ingegneria mal orientata.

Cosa faremmo nel tempo che resta

Se rientrate e iniziate ora, questo è l'ordine che funziona:

Primo, costruire l'inventario dei prodotti. Cosa avete davvero sul mercato UE? Incluse versioni vecchie ancora sul campo, varianti in marchio bianco e prodotti che distribuite per conto di altri. Quella lista è di solito più lunga di quanto chiunque si aspetti.

Secondo, integrare la generazione di SBOM nella CI. Generare una SBOM a ogni build, in CycloneDX o SPDX, conservarla insieme all'artefatto di rilascio e mantenerla interrogabile. Il punto è poter chiedere «quali dei nostri rilasci spediti contengono questa libreria?» e ottenere risposta in minuti.

Terzo, collegare il monitoraggio delle vulnerabilità. Alimentare con i dati SBOM uno scanner che sorvegli avvisi e cataloghi di vulnerabilità sfruttate note, e instradare gli allarmi su un canale che qualcuno legga.

Quarto, scrivere il runbook degli incidenti. Chi dichiara, chi valuta, chi segnala, chi comunica. Persone nominate, sostituti e contatti fuori orario. Poi provarlo una volta con un avviso finto. È nella prova che scoprite che chi ha le credenziali della piattaforma di segnalazione è in ferie.

Quinto, pubblicare una politica di divulgazione delle vulnerabilità. Un file security.txt, un indirizzo presidiato e un tempo di risposta dichiarato. È un pomeriggio di lavoro ed è la differenza tra sapere di un problema da un ricercatore o da un giornalista.

Sesto, avviare il lavoro per dicembre 2027. Impostazioni predefinite sicure, meccanismi di aggiornamento, decisioni sul periodo di supporto e documentazione sono questioni di architettura, non burocrazia. I prodotti che progettate nel 2026 saranno ancora sul mercato nel 2028.

La sovrapposizione che nessuno sfrutta

C'è una duplicazione significativa tra il CRA e altri regimi, e la maggior parte delle aziende li tratta separatamente, il che è uno spreco.

Una SBOM costruita per il CRA risponde a gran parte delle domande sulla catena di fornitura di NIS2. Il runbook degli incidenti si sovrappone al preallarme di 24 ore di NIS2 e alla notifica di violazione a 72 ore del GDPR. I processi di gestione delle vulnerabilità alimentano direttamente i questionari di sicurezza dei clienti e gli acquisti aziendali.

Costruite tutto questo una volta come capacità di piattaforma. L'alternativa sono tre team che costruiscono tre versioni dello stesso inventario di asset.

Dove trovare aiuto

Costruiamo e manteniamo software per aziende che vendono nell'UE, il che significa sempre più costruire la visibilità sulla catena di fornitura e l'infrastruttura di aggiornamento che il CRA presuppone. Se state capendo se rientrate, o avete la data di settembre in calendario e nessun monitoraggio attivo, scrivete a office@c9group.dev.

Il nostro servizio di manutenzione dei sistemi legacy è spesso il punto di partenza, perché i prodotti con la peggiore visibilità sulle dipendenze sono di solito i più vecchi. Il quadro normativo più ampio è nella nostra guida alla conformità digitale UE 2026.

Siamo ingegneri più che avvocati. Le decisioni su ambito e classificazione spettano ai vostri legali, e noi costruiamo sulla risposta che danno.