Il Cyber Resilience Act per i prodotti connessi: cosa devono fare adesso i produttori

Se costruisci un prodotto con un chip, una radio o un meccanismo di aggiornamento software e lo vendi nell’Unione europea, il Cyber Resilience Act non è più un problema futuro.

Il Regolamento (UE) 2024/2847 è entrato in vigore a dicembre 2024. Dall’11 settembre 2026 i produttori devono segnalare le vulnerabilità sfruttate attivamente e gli incidenti gravi. Dall’11 dicembre 2027 si applica la maggior parte degli altri obblighi, compresi i requisiti di sicurezza che un prodotto deve rispettare per avere la marcatura CE.

Non sono un avvocato e questa non è una consulenza legale. Ma lavoro da anni su prodotti di sicurezza embedded, e vedo lo stesso schema in molti team: il regolamento viene letto come un documento di conformità, mentre gran parte di ciò che chiede è una capacità ingegneristica.

Cosa è cambiato a settembre 2026

Il primo obbligo diventato esecutivo è la segnalazione. Quando un produttore viene a sapere di una vulnerabilità sfruttata attivamente in un suo prodotto, o di un incidente grave che ne riguarda la sicurezza, deve inviare un preallarme entro 24 ore, attraverso la piattaforma unica di segnalazione gestita dall’ENISA.

Contano due dettagli.

• L’obbligo vale per i prodotti già sul mercato, non solo per quelli nuovi.
• Ventiquattro ore non bastano per cominciare a cercare informazioni. Bastano solo per usare informazioni che hai già.

Quindi la vera domanda non è «conosciamo la regola?». È «riusciamo a dire, in poche ore, quali dei nostri prodotti contengono il componente colpito, quali versioni sono sul campo e chi è responsabile della correzione?».

Cosa si applica da dicembre 2027

Da dicembre 2027 i requisiti essenziali del CRA si applicano per intero. In pratica, i prodotti con elementi digitali devono essere progettati e mantenuti tenendo conto della sicurezza per tutto il periodo di supporto. Tra le altre cose, questo significa:

• nessuna vulnerabilità sfruttabile nota al momento dell’immissione sul mercato;
• configurazioni sicure per impostazione predefinita;
• la possibilità di distribuire aggiornamenti di sicurezza, separati da quelli funzionali quando possibile;
• protezione della riservatezza e dell’integrità dei dati, anche con crittografia allo stato dell’arte;
• un processo di gestione delle vulnerabilità e una distinta dei componenti software (SBOM);
• un periodo di supporto definito e comunicato agli utenti.

Le violazioni possono costare care: per i requisiti essenziali le sanzioni arrivano a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, se superiore.

La parte sottovalutata: sapere cosa c’è dentro il prodotto

Ogni obbligo qui sopra dipende da una cosa sola: un’immagine precisa e aggiornata di cosa compone il tuo prodotto.

Non solo un elenco di componenti software. Un’immagine di come sono collegati tra loro.

• Quale firmware gira su quale revisione hardware?
• Quali chiavi firmano quali aggiornamenti?
• Quali certificati stabiliscono l’identità di un dispositivo?
• Quali librerie di terze parti gestiscono la crittografia, e in quali versioni?

Molte organizzazioni hanno queste informazioni. Solo che sono sparse tra team di ingegneria, sistemi di produzione, fornitori e vecchia documentazione. Funziona fino al giorno in cui hai 24 ore per agire.

La crittografia fa parte dello «stato dell’arte»

Il CRA non nomina algoritmi specifici. Chiede una protezione che rifletta lo stato dell’arte.

Quell’espressione ha una scadenza. Il NIST ha pubblicato i primi standard di crittografia post-quantistica ad agosto 2024. La roadmap coordinata dell’Unione europea chiede agli Stati membri di avviare la transizione entro la fine del 2026 e di proteggere i casi d’uso ad alto rischio entro il 2030. Un prodotto connesso immesso sul mercato nel 2028, con dieci o quindici anni di supporto, vivrà ben dentro quella transizione.

Non significa che ogni prodotto debba uscire domani con algoritmi post-quantistici. Significa che devi sapere dov’è la tua crittografia e come la cambieresti. Ne ho scritto di più in Perché sto costruendo Shorium.

Da dove partirei

Se oggi fossi responsabile di un portafoglio di prodotti connessi, farei quattro cose, in quest’ordine.

1. Mappare i prodotti coinvolti. Quali hanno elementi digitali, quali sono sul mercato e quale periodo di supporto puoi davvero garantire.
2. Costruire l’inventario che servirà in una crisi. Componenti, versioni, chiavi, certificati e fornitori, collegati ai prodotti e alle versioni sul campo. La SBOM è l’inizio, non la fine.
3. Provare la segnalazione in 24 ore. Prendi una vulnerabilità reale dell’anno scorso e misura quanto ci vuole per rispondere: prodotti colpiti, versioni colpite, responsabile, mitigazione.
4. Verificare la catena di aggiornamento. Riesci a distribuire un aggiornamento di sicurezza firmato a ogni prodotto che supporti ancora? Cosa succede se una chiave di firma o un algoritmo devono cambiare?

Nessuno di questi passi richiede uno strumento nuovo dal primo giorno. Richiedono qualcuno che si prenda la responsabilità della domanda.

L’opportunità dentro l’obbligo

È facile leggere il CRA come un costo. Credo sia anche una spinta.

I team che vedono chiaramente i propri prodotti, e li sanno cambiare in sicurezza, fanno prodotti migliori. Il regolamento fissa solo la data in cui quella capacità smette di essere facoltativa.

Se vuoi confrontarti su come la tua organizzazione lo sta affrontando, scrivimi.