Cyber Resilience Act: perché la prima scadenza cade già a settembre 2026

Un'idea sbagliata si rivela tenace: che il Cyber Resilience Act riguardi i produttori solo dalla fine del 2027. Vale per una parte degli obblighi — ma non per il primo, ed è il più scomodo. Entra in vigore già l'11 settembre 2026. Mentre scrivo, manca meno di un trimestre.

Non considero il CRA burocrazia fine a sé stessa. Costringe un settore che per decenni ha trattato la sicurezza come un extra facoltativo a qualcosa che nei campi critici è scontato da tempo: dimostrare ciò che si fa. Eppure molti sottovalutano quanto presto parta l'orologio. Da qui questo articolo.

Cosa richiede il CRA — e da quando

Il Cyber Resilience Act (regolamento (UE) 2024/2847) è in vigore da dicembre 2024. Stabilisce quanto sicuri debbano essere i "prodotti con elementi digitali" contro gli attacchi — cioè tutto ciò che contiene software o si collega a una rete. Dal termostato intelligente al controllore industriale. Ci sono due date chiave, e non vanno confuse:

11 settembre 2026 — l'obbligo di notifica. Da questa data devo notificare ogni vulnerabilità attivamente sfruttata e ogni incidente di sicurezza grave entro 24 ore agli organismi competenti — l'agenzia UE ENISA e i team di risposta nazionali (CSIRT). Vale anche per i prodotti già da tempo sul mercato e ancora in supporto.

11 dicembre 2027 — tutto il resto. Da allora il prodotto deve essere progettato sicuro fin dall'origine, ricevere aggiornamenti di sicurezza per tutto il suo ciclo di vita, presentare una distinta base software completa, superare una valutazione di conformità e recare la marcatura CE.

Accostando le due date, emerge il vero problema: si può notificare solo ciò che si sa essere nel proprio prodotto. E questo porta dritti all'ostacolo sottovalutato.

Perché l'obbligo di notifica è il vero ostacolo

Notificare una vulnerabilità entro 24 ore sembra un dettaglio organizzativo. Non lo è. Per poter solo valutare se una falla appena resa pubblica tocca il mio prodotto, mi serve un elenco completo di tutti i componenti software integrati — la cosiddetta SBOM (software bill of materials), la distinta base del codice. Senza di essa, a ogni nuova segnalazione di vulnerabilità resto al buio, a indovinare se uno dei miei componenti è coinvolto.

In altre parole: la SBOM che ufficialmente diventa obbligatoria solo nel 2027, in pratica mi serve già a settembre 2026. Chi inizia solo allora a inventariare le proprie dipendenze ha già perso il primo caso reale. A ciò si aggiunge la pura logistica: chi nota una falla sfruttata, chi la valuta, chi la notifica — e quella catena funziona anche un sabato sera? Ventiquattro ore sono ventiquattro ore.

Affidabilità e resistenza agli attacchi convergono

È qui che diventa interessante per il mio lavoro principale. Da oltre tre decenni sviluppo software embedded critico, in gran parte secondo la ISO 26262 — la norma per la sicurezza funzionale dei veicoli. La sicurezza funzionale chiede: cosa succede se un componente si guasta? Il CRA aggiunge una seconda domanda: cosa succede se qualcuno attacca il dispositivo di proposito?

Queste due domande sono state a lungo mondi separati. Non lo sono più. Un esempio eloquente è l'intrusione a distanza in una Jeep Cherokee nel 2015: due ricercatori di sicurezza presero il controllo di freni e cambio tramite una falla nel sistema di infotainment — da remoto, sulla rete cellulare. 1,4 milioni di veicoli dovettero essere richiamati. Ogni dimostrazione di sicurezza del freno divenne priva di valore, perché il freno non cedette per caso ma su comando di un aggressore. Una falla nel software era diventata un problema di sicurezza in senso letterale.

È esattamente qui che oggi nascono le lacune costose: nei produttori che hanno sotto controllo l'affidabilità ma non hanno mai esaminato sistematicamente il lato attacco. Chi pensa la ISO 26262 senza un'analisi di sicurezza che l'accompagni non chiude più la sua catena argomentativa.

Cosa cambia concretamente nel firmware

Il CRA viene volentieri liquidato come tema da giuristi. Lo ritengo un errore. Dietro i requisiti ci sono compiti molto concreti per il firmware — il software di controllo che risiede in modo fisso nel dispositivo. Quattro punti mi paiono centrali:

Il software deve risiedere cifrato nel dispositivo. Chi può leggere il codice in chiaro dalla flash ha lasciato una porta aperta. I microcontrollori moderni offrono protezione — blocco sicuro della lettura, avvio firmato, aree di memoria legate a una chiave. L'essenziale è gestirli in modo pulito anche in produzione, invece di perdere le chiavi per strada.

Gli aggiornamenti devono essere a prova di manomissione. Un dispositivo deve poter ricevere aggiornamenti di sicurezza per tutto il suo ciclo di vita — e in modo tale che nessuno possa introdurre software estraneo. Un prodotto senza un percorso di aggiornamento firmato e verificato, dal 2027 semplicemente non è più commercializzabile.

Ogni componente deve essere noto e sorvegliato. Ogni libreria acquistata, ogni mattone del sistema operativo in tempo reale, ogni stack crittografico va nella distinta base e deve essere monitorato per vulnerabilità note. Vi rientra il riconoscere componenti obsoleti che il fornitore originario non mantiene più — prima che lo faccia un'autorità.

Il codice pulito ripaga. Nei progetti critici sviluppo secondo regole di codifica rigorose, come MISRA-C. Molte di queste regole eliminano proprio i comportamenti indefiniti da cui poi si costruiscono gli exploit. Chi lavora così fin dall'inizio ha già svolto una parte dei compiti del CRA — ma dovrebbe anche poterlo dimostrare.

Anche il piccolo produttore è "produttore"

Un equivoco diffuso vuole che riguardi solo i grandi gruppi. Sbagliato. Il CRA si applica a chiunque immetta sul mercato UE un prodotto con elementi digitali — dalla media impresa allo sviluppatore singolo specializzato. Anche chi importa o rivende dispositivi porta i propri obblighi. E le sanzioni non sono uno spauracchio: arrivano fino a 15 milioni di euro o al 2,5 per cento del fatturato annuo mondiale.

Chi finora pensava che la sicurezza fosse un'opzione per "versioni successive del prodotto" non ha più questa scelta.

Cosa consiglio ora ai produttori

I prossimi mesi decidono se settembre 2026 troverà un procedimento ordinato o un'improvvisazione frenetica. Il mio consiglio è poco spettacolare, ma funziona: iniziare. Una ricognizione di quali prodotti sono coinvolti e ancora supportati. Una prima distinta base software per prodotto. Un percorso di notifica definito che regga davvero, sul piano organizzativo, il termine delle 24 ore. E, in parallelo, irrobustire il firmware — come architettura ponderata, non come toppa applicata dopo.

Un posizionamento onesto per chiudere: chi cerca un timbro che certifichi che va già tutto bene è nel posto sbagliato con me. Chi vuole sapere dove sono davvero i suoi prodotti a settembre 2026, e cosa fare nel firmware entro allora, è nel posto giusto.

Conclusione

Il CRA non è un problema lontano per dopodomani. La prima scadenza vincolante cade a settembre 2026, e presuppone che io sappia già oggi cosa c'è nei miei prodotti. Chi inizia presto distribuisce il lavoro ed evita costose correzioni dell'ultimo minuto poco prima della scadenza.

La leva maggiore raramente sta nella sola tecnica. Sta nel gioco pulito tra distinta base, processo di notifica e hardening del dispositivo — e nel pensare finalmente affidabilità e resistenza agli attacchi come un unico concetto condiviso, non come due cassetti separati. È esattamente il ponte su cui preferisco lavorare.