La prima scadenza del Cyber Resilience Act (CRA) che riguarda i team di prodotto è l'11 settembre 2026, quando iniziano ad applicarsi gli obblighi di notifica. Gli obblighi principali seguono l'11 dicembre 2027. La notifica dipende da processi e persone, che richiedono tempo per essere costruiti: per questo viene prima di tutto il resto.
Cosa si applica e quando
Il CRA è il Regolamento (UE) 2024/2847. Secondo la pagina della Commissione europea dedicata al CRA, il regolamento stabilisce requisiti di cybersicurezza obbligatori per i fabbricanti, lungo l'intero arco di pianificazione, progettazione, sviluppo e manutenzione dei prodotti con elementi digitali. Richiede inoltre ai fabbricanti di gestire le vulnerabilità per tutto il ciclo di vita del prodotto.
| Data | Cosa accade |
|---|---|
| 10 dicembre 2024 | Il CRA è entrato in vigore |
| 11 settembre 2026 | Si applicano gli obblighi di notifica |
| 11 dicembre 2027 | Si applicano gli obblighi principali |
I prodotti conformi recheranno la marcatura CE e il rispetto delle regole è garantito dalle autorità nazionali di vigilanza del mercato. Alcuni prodotti di particolare rilevanza per la cybersicurezza potrebbero richiedere una valutazione di terza parte da parte di un organismo notificato prima della vendita sul mercato dell'UE. Stabilite per tempo da quale lato di questo confine si colloca il vostro prodotto, perché ciò cambia le vostre tempistiche.
Il 27 luglio 2026 la Commissione ha inoltre pubblicato una guida pratica per i fabbricanti. La legga prima di vincolarsi a un'impostazione per uno qualsiasi dei processi descritti di seguito.
Evidenze di sviluppo sicuro
Autorità e clienti chiederanno che cosa avete fatto: conviene quindi produrre le evidenze come sottoprodotto del lavoro quotidiano, anziché ricostruirle in seguito. Una struttura riconosciuta aiuta.
Il NIST Secure Software Development Framework, SP 800-218, è un insieme essenziale di pratiche di alto livello da innestare sull'SDLC che già adottate. I suoi obiettivi dichiarati sono ridurre le vulnerabilità nel software rilasciato, limitare l'impatto di quelle che restano e intervenire sulle cause radice perché non si ripresentino. Offre inoltre un vocabolario comune da usare con clienti e fornitori. È un documento statunitense e non una checklist del CRA, quindi va considerato come un'impalcatura.
Evidenze da conservare per ogni release:
- il threat model o la design review che ha riguardato la modifica
- gli esiti di code review e test, compresi i test di sicurezza
- gli elenchi delle dipendenze con le versioni e la decisione presa sulle vulnerabilità note al loro interno
- l'approvazione del rilascio, con nome e data
Il materiale Secure by Design di CISA aggiunge due indicazioni pratiche. La responsabilità deve stare a livello esecutivo e i default contano: MFA, logging e SSO dovrebbero essere disponibili fin da subito, senza costi aggiuntivi. Se il vostro prodotto li vende come componenti aggiuntivi a pagamento, mettete in conto che la scelta venga messa in discussione. CISA pubblica inoltre indicazioni sulle roadmap verso linguaggi memory safe, utili se il vostro codice è in C o C++.
Gestione delle vulnerabilità e notifica
Dall'11 settembre 2026 i fabbricanti devono notificare le vulnerabilità attivamente sfruttate, insieme agli altri elementi indicati nella pagina della Commissione dedicata alla notifica. Consulti quella pagina per l'ambito esatto e per il canale da utilizzare. Non si affidi a una sintesi, compresa questa.
Ciò che serve internamente, indipendentemente dai dettagli definitivi:
- Un unico punto di raccolta. Un contatto di sicurezza presidiato, indicato sul sito del prodotto e nella documentazione, con un responsabile designato e un sostituto.
- Una routine di triage. Qualcuno stabilisce entro un tempo definito se una segnalazione è valida, se la vulnerabilità è sfruttata e quali prodotti e versioni coinvolge. Un punteggio di severità coerente rende tutto più rapido; il nostro calcolatore CVSS è utile per concordare i punteggi all'interno del team.
- Un percorso decisionale per la notifica. Metta per iscritto chi decide che una vulnerabilità sfruttata fa scattare una notifica e chi la invia. Lo provi almeno una volta con un caso fittizio, anche fuori dall'orario di lavoro se è quando potrebbe davvero accadere.
- Una traccia di ogni decisione. Comprese le segnalazioni che avete ritenuto fuori ambito, con la motivazione.
La notifica non può funzionare se non si sa che cosa contiene il proprio prodotto. Mantenga un inventario aggiornato dei componenti per ogni versione rilasciata, perché l'esposizione a una nuova vulnerabilità non si valuta a memoria.
Processi di aggiornamento
La Commissione indica la mancanza di aggiornamenti di sicurezza tempestivi tra i problemi che il CRA intende affrontare. I prodotti devono essere progettati, aggiornati e mantenuti in modo da proteggere gli utenti. In pratica significa testare il percorso di aggiornamento con la stessa serietà delle funzionalità.
Verifichi quanto segue per ogni linea di prodotto:
- È possibile rilasciare una correzione di sicurezza separatamente da una release di funzionalità.
- I clienti possono venire a sapere che esiste un aggiornamento e installarlo non richiede una chiamata al supporto.
- Le versioni vecchie hanno una data di fine supporto dichiarata, che i clienti possono vedere prima dell'acquisto.
- Per l'hardware, avete testato l'aggiornamento di un dispositivo rimasto offline per un anno e il ripristino di uno che si interrompe a metà.
La lacuna più comune non è la tecnologia, ma la responsabilità. Molti team riescono a costruire una patch in un giorno e poi impiegano tre settimane per scoprire chi ha l'autorità di rilasciarla.
Documentazione tecnica
Le fonti che ho utilizzato non elencano i contenuti richiesti per il fascicolo tecnico, che vanno quindi ricavati dal testo normativo e dalle indicazioni della Commissione. Il punto pratico è che la documentazione va costruita in modo continuo a partire dalle evidenze descritte sopra, non scritta nell'ultimo trimestre prima della scadenza.
Assegni a ogni prodotto una cartella di documentazione, o una sezione del repository, con un responsabile. Vi raccolga la progettazione e la valutazione dei rischi, l'inventario dei componenti, gli esiti dei test, la procedura di gestione delle vulnerabilità e la politica di aggiornamento. La versioni insieme al prodotto. Quando un auditor o un'autorità chiede un fascicolo, deve poterlo esportare, non commissionare.
Se rientrate anche nell'ambito della direttiva NIS2, che secondo la Commissione il CRA integra, riutilizzi le stesse procedure per incidenti e vulnerabilità invece di mantenerne due serie.
Da dove iniziare
- Legga la guida della Commissione del 27 luglio 2026 e la pagina sulla notifica, e metta per iscritto quali prodotti rientrano nell'ambito di applicazione e se qualcuno potrebbe richiedere un organismo notificato.
- Designi un responsabile per la raccolta delle segnalazioni di vulnerabilità e per la notifica delle vulnerabilità sfruttate, pubblichi un contatto di sicurezza ed esegua una simulazione in questo trimestre.
- Produca un inventario dei componenti per ogni release supportata e faccia della sua generazione una parte della build.
- Confronti l'SDLC attuale con le pratiche SSDF, registri le lacune e inizi a conservare per ogni release le evidenze di review, test e approvazione.
- Testi il percorso di aggiornamento end to end e pubblichi le date di fine supporto per ciascun prodotto.
- Crei la cartella di documentazione per prodotto e la popoli con ciò che già avete. Se desidera un parere esterno sulle lacune, il nostro servizio di consulenza e il nostro servizio di sviluppo software sicuro riguardano esattamente questo.
