Cyber Resilience Act: la sicurezza non finisce alla fine della tua CLI 🌐

C’è una vecchia abitudine che il settore tech ha impiegato decenni a consolidare: la sicurezza è una feature opzionale, si aggiorna dopo. Il Cyber Resilience Act è il no secco dell’Unione europea a quell’abitudine. Non perché la norma sia particolarmente severa — lo è, ma non è quello il punto. Il punto è che per la prima volta la sicurezza è un requisito giuridico del prodotto, non un add-on.

Vuoi il quadro completo? Cosa è un prodotto con elementi digitali, chi è obbligato, i requisiti dell’Allegato I, le segnalazioni e le sanzioni sono nella guida pratica: Cyber Resilience Act — Guida pratica.

Il secondo autore di ogni bug di sicurezza 🐛

Il Regolamento (UE) 2024/2847 nasce da un’osservazione lapalissiana ma scomoda: quasi tutti gli incidenti gravi negli ultimi anni (espressione cortese per “quelli che finiscono in prima pagina”) sono partiti dalla stessa vulnerabilità: un componente conosciuto, una patch disponibile, e un prodotto che nessuno aggiornava.

Il CRA rovescia il punto di vista. Non cerca di indurire Arduino, il tuo modem o il tuo microcontrollore. Chiede che chi immette un prodotto sul mercato sappia cosa contiene, garantisca la gestione delle vulnerabilità per tutta la vita del prodotto, e lo dica chiaramente.

Una lettura sbagliata di questo regolamento è vederlo come il “successore” di NIS 2. Non lo è: le due norme corrono in parallelo e si leggono insieme. NIS 2 guarda all’organizzazione — governance, misure, responsabilità di chi gestisce i sistemi. Il CRA guarda al prodotto — cosa contiene, come viene aggiornato, chi risponde del suo ciclo di vita. Un software, un dispositivo, un componente: se è connesso a qualcosa, ha un ciclo di vita di sicurezza di cui qualcuno è responsabile. Sono due facce dello stesso rischio.

“Prodotto con elementi digitali” è più ampio di quanto immagini 📦

La definizione (Art. 3) è la parte che la maggior parte delle aziende sottovaluta. Non conta solo il router o l’oggetto IoT. Conte qualsiasi prodotto software o hardware, inclusi i componenti immessi sul mercato separatamente, la cui finalità prevedibile include una connessione — logica o fisica, diretta o indiretta — a un dispositivo o a una rete.

Tradotto: un SDK, una libreria commerciale, un’app, un firmware, un dispositivo embedded. Se “parla” con qualcosa, ti riguarda. E il fabbricante non è solo chi produce hardware: è chi commercializza sotto il proprio nome, anche gratis.

Non è un vizio di forma: è la chiusura di un buco. Finora, se il tuo router era insicuro, la colpa era del produttore del chip; se il chip era insicuro, della libreria di rete; se la libreria, dell’open source. Il CRA spiega che la catena della sicurezza ha un punto di inizio: il fabbricante, e ogni componente conta.

Il cuore: Allegato I e la “doppia anima” 📋

La norma è costruita su due parti del tutto diverse:

• Parte I — sicurezza del prodotto: progettazione che minimizzi le vulnerabilità, configurazione sicura per default (niente password di default!), aggiornamenti, minimizzazione dei dati, log, resilienza. In sintesi: scegliere la sicurezza prima, non dopo.
• Parte II — gestione delle vulnerabilità: punto di contatto unico, politica di divulgazione coordinata, prove periodiche, divulgazione pubblica, aggiornamenti gratuiti durante il periodo di assistenza, e soprattutto la SBOM — la distinta base del software, l’elenco machine-readable delle dipendenze.

La Parte II è il salto culturale vero. “Sapere cosa c’è dentro il proprio prodotto” sembra ovvio, ma quasi nessun produttore di software può dirlo al di là del nome delle librerie di primo livello. Il CRA trasforma questa consapevolezza in requisito persistente: ricorda che un aggiornamento di sicurezza per una versione vecchia deve restare disponibile 10 anni? Non è un refuso.

I tre pilastri che toccano chi produce 🏗️

1. Il periodo di assistenza. Il fabbricante deve definire un periodo di assistenza di almeno 5 anni (o la durata prevista del prodotto, se inferiore), durante il quale la gestione delle vulnerabilità è garantita. Se il prodotto è destinato a stare in campo a lungo — router, sistemi operativi, schede madri — il periodo deve essere maggiore di 5 anni. Non è una scelta commerciale generosa: è un obbligo legale con impatto sul modello di business.

2. La segnalazione di vulnerabilità e incidenti (Art. 14). Da settembre 2026, se scopri una vulnerabilità attivamente sfruttata o un incidente grave sul tuo prodotto, hai 24 ore per il preallarme, 72 ore per la notifica, 14 giorni (o 1 mese) per la relazione finale — verso CSIRT ed ENISA su una piattaforma comune. Un team che non ha un runbook di incident response si trova a doverlo inventare sotto stress. Non è il momento migliore.

3. La conformità graduata. Autovalutazione per i prodotti generali e di Classe I (password manager, browser, VPN, Sistemi operativi, router); valutazione da parte di organismo notificato per la Classe II (firewall, IDS/IPS, hypervisor, runtime container); certificazione EUCC obbligatoria per i critici (moduli HSM, smart card, gateway contatori). Chi fa firewall scopre che la “semplice” checklist non basta più.

Il costo non è solo la multa 💸

Le sanzioni da €15 milioni/2,5% sono la parte che finisce nei titoli, ma non il conto più salato.

Il costo vero è quadriennale: catalogare i prodotti, redigere l’analisi dei rischi, costruire la SBOM, definire il periodo di assistenza, mettere in piedi il processo di divulgazione coordinata. Tutto prima che arrivi l’auditor. E c’è il lato commerciale: chi produce per settori regolati o per PA vedrà i clienti chiedere la Dichiarazione di conformità UE e la marcatura CE come requisito di acquisto. Chi non ce l’ha non avrà nemmeno il primo colloquio.

C’è però un’esenzione che vale la pena di citare per chi fa open source: per il gestore di software open source (il soggetto che ne sostiene commercialmente lo sviluppo) le sanzioni sono escluse. Non è un salvacondotto generale — la dovuta diligenza richiesta quando integri componenti di terzi, inclusi quelli open source, è esplicita — ma è un riconoscimento del ruolo che il contributo volontario gioca nella sicurezza.

Conclusione: la sicurezza è diventata parte della consegna 🚚

Il CRA non vieta nulla. Non ha liste di pratiche proibite né “cose brutte” da identificare. Chiede qualcosa di più difficile da fare che vietare: essere in grado di spiegare, con documentazione, cosa hai costruito e come lo mantieni al sicuro.

Per chi scrive codice è un passaggio di maturità: la sicurezza smette di essere il capitolo che qualcuno scrive alla fine del manuale e diventa parte del prodotto, con nome, cognome e scadenza. Come per AI Act e NIS 2, la vera domanda non è “cosa rischiamo se non lo facciamo”, ma “quanto ci costa scoprirlo tardi”.

Vuoi i dettagli operativi — chi rientra, i requisiti dell’Allegato I, come segnalare, quando e le sanzioni? Sono nella guida pratica: Cyber Resilience Act — Guida pratica.