Il Cyber Resilience Act (CRA) è il Regolamento (UE) 2024/2847. Introduce requisiti orizzontali di cybersecurity per prodotti con elementi digitali immessi sul mercato UE. Per fabbricanti software e hardware, la sicurezza prodotto diventa un obbligo di compliance lungo il ciclo di vita.
Fonti: Regolamento (UE) 2024/2847, sintesi Commissione europea sul CRA, pagina Commissione europea sul CRA, materiali ENISA sul CRA.
Punti chiave
- Il CRA è entrato in vigore il 10 dicembre 2024.
- Gli obblighi principali si applicano dall’11 dicembre 2027.
- Gli obblighi di reporting dell’articolo 14 si applicano prima, dall’11 settembre 2026.
- Il CRA copre prodotti hardware e software con elementi digitali messi a disposizione sul mercato UE, salvo esclusioni definite.
- I fabbricanti devono gestire sicurezza in fase di progettazione, vulnerabilità, valutazione di conformità, documentazione tecnica e marcatura CE.
- La non conformità ai requisiti essenziali e agli articoli 13 e 14 può portare a sanzioni fino a 15 milioni di euro o 2,5% del fatturato mondiale.
Ambito di questo articolo
Questo articolo spiega gli obblighi CRA per fabbricanti, importatori, distributori e team software. Non sostituisce un’analisi legale o un piano di valutazione di conformità specifico per prodotto.
Cos’è il Cyber Resilience Act
Il CRA è una normativa di product security. Si applica in modo trasversale ai prodotti con elementi digitali, inclusi software, hardware e soluzioni di remote data processing necessarie per una funzione del prodotto. La Commissione lo descrive come framework orizzontale per hardware e software sicuri nel mercato UE.
Quando si applica: calendario
| Data | Milestone | Conseguenza operativa |
|---|---|---|
| 10 dicembre 2024 | Entrata in vigore | Inizia il periodo di preparazione. |
| 11 giugno 2026 | Applicazione Capitolo IV | Si applicano le regole sugli organismi notificati. |
| 11 settembre 2026 | Applicazione articolo 14 | Partono gli obblighi di reporting su vulnerabilità sfruttate e incidenti severi. |
| 11 dicembre 2027 | Applicazione principale | Si applicano gli obblighi core CRA. |
Chi è soggetto al CRA
Il CRA riguarda operatori economici come fabbricanti, rappresentanti autorizzati, importatori e distributori. Gli obblighi più intensi ricadono sul fabbricante, perché controlla progettazione, sviluppo, documentazione, gestione vulnerabilità e conformità.
Il software open source richiede analisi specifica. Il regolamento distingue attività non commerciali, attività commerciali e ruolo di open-source software steward. Non si deve presumere che ogni repository sia fuori ambito.
Le categorie di prodotti
| Categoria | Lettura pratica | Impatto compliance |
|---|---|---|
| Prodotti standard | Prodotti non elencati come importanti o critici. | Obblighi fabbricante e valutazione di conformità. |
| Importanti classe I | Prodotti in Allegato III con rilevanza cybersecurity. | Aspettative di conformità più strutturate. |
| Importanti classe II | Prodotti a rischio superiore in Allegato III. | Onere di valutazione più forte. |
| Critici | Prodotti in Allegato IV. | Possibile rilevanza certificazione e garanzie più alte. |
Obblighi principali per i fabbricanti
- Progettare, sviluppare e produrre secondo requisiti essenziali di cybersecurity.
- Documentare risk assessment cyber e controlli tecnici.
- Gestire vulnerabilità durante il periodo di supporto.
- Fornire informazioni e istruzioni di sicurezza agli utenti.
- Eseguire la valutazione di conformità appropriata.
- Applicare la marcatura CE quando i requisiti sono soddisfatti.
Notifica vulnerabilità e incidenti
L’articolo 14 introduce obblighi di reporting per vulnerabilità attivamente sfruttate e incidenti severi che impattano la sicurezza del prodotto. La sintesi della Commissione indica applicazione dall’11 settembre 2026. I team prodotto dovrebbero preparare intake, triage, evidenze e disclosure prima di quella data.
Coordinamento con NIS 2 e altre normative UE
La NIS 2 riguarda soggetti e misure di gestione del rischio. Il CRA riguarda prodotti con elementi digitali. Un vendor software può essere impattato da entrambi: NIS 2 come soggetto e CRA come fabbricante. Per contesto, vedi NIS 2, revisione del Cybersecurity Act UE, Cyber Solidarity Act e finanziamenti per readiness CRA.
Checklist operativa
- Inventariare prodotti e componenti digitali sul mercato UE.
- Classificare categoria prodotto e ruolo di operatore economico.
- Mappare controlli secure-by-design al ciclo di vita prodotto.
- Definire intake, triage, remediation e disclosure vulnerabilità.
- Preparare documentazione tecnica e repository evidenze.
- Valutare percorso di conformità e piano marcatura CE.
- Coordinare reporting CRA con processi NIS 2, DORA o settoriali.
Ciclo di sviluppo sicuro nel CRA
I fabbricanti dovrebbero tradurre gli obblighi CRA nel ciclo di vita prodotto. Il ciclo pratico include classificazione, threat modeling, review di design, controllo dipendenze, test sicurezza, approvazione release, aggiornamenti di sicurezza e comunicazione fine supporto. Ogni passaggio deve lasciare evidenza.
| Fase ciclo di vita | Evidenza da conservare |
|---|---|
| Classificazione prodotto | Analisi ambito, decisione categoria, ruolo operatore. |
| Design sicuro | Threat model, review architettura, requisiti sicurezza. |
| Build e dipendenze | SBOM, review dipendenze, record firma. |
| Testing | Risultati test sicurezza, note remediation vulnerabilità. |
| Release | Evidenze conformità, istruzioni sicurezza, documentazione CE. |
| Post-market | Intake vulnerabilità, patch, evidenze notifica. |
Checkpoint per importatori e distributori
Importatori e distributori non dovrebbero considerare il CRA un problema solo del fabbricante. Servono evidenze che i prodotti siano identificati, accompagnati dalla documentazione richiesta e gestiti senza compromettere la conformità. Il procurement dovrebbe richiedere documentazione product security prima della distribuzione.
Workflow di gestione vulnerabilità
- Ricevere segnalazioni tramite un canale presidiato.
- Valutare exploitability, versioni impattate e impatto sicurezza prodotto.
- Assegnare owner remediation e data target.
- Preparare comunicazione utenti e istruzioni aggiornamento.
- Valutare se scattano obblighi di reporting articolo 14.
- Conservare log decisionali ed evidenze tecniche.
Implicazioni sanzioni e governance
Il massimale sanzionatorio CRA per requisiti essenziali e articoli 13 e 14 è sufficiente a rendere la sicurezza prodotto un rischio da governance. La compliance deve quindi entrare nella product governance, non restare solo nei team engineering.
Pianificazione del periodo di supporto
La gestione vulnerabilità CRA non è un’attività una tantum di release. I fabbricanti devono pianificare per quanto tempo aggiornamenti di sicurezza, intake vulnerabilità e comunicazioni utenti saranno supportati. Il testo regolatorio va verificato per categoria prodotto, ma il punto operativo è chiaro: il periodo di supporto deve essere definito, comunicato e finanziato.
Pacchetto documentazione tecnica
- Descrizione prodotto e uso previsto.
- Risk assessment cyber e decisioni di design.
- Mapping requisiti essenziali.
- SBOM o inventario componenti dove applicabile.
- Test e note remediation vulnerabilità.
- Evidenze di valutazione conformità.
- Istruzioni sicurezza utenti e informazioni sul supporto.
Modello operativo del team prodotto
La readiness CRA richiede collaborazione tra product, engineering, sicurezza, legale e supporto. Engineering possiede implementazione sicura. Security possiede threat modeling e validazione. Legale e compliance possiedono interpretazione conformità. Support gestisce comunicazioni e intake vulnerabilità. Product management governa lifecycle e impegni di supporto.
Rischio legacy e modifica sostanziale
I prodotti già sul mercato prima della data principale richiedono analisi quando subiscono modifiche sostanziali. I team prodotto dovrebbero definire cosa conta come cambio rilevante per la sicurezza, chi lo approva e quando aggiornare documentazione tecnica. Questo deve entrare nella release governance.
I fabbricanti che costruiscono o aggiornano il programma CRA spesso traggono vantaggio dal supporto di un CISO esterno per fare da ponte tra ingegneria di prodotto, cybersecurity e legale. Il servizio Virtual CISO di Aegister copre governance della sicurezza prodotto, disegno della gestione vulnerabilità, prontezza per la valutazione di conformità e coordinamento con gli obblighi NIS 2 quando entrambi i regimi si applicano.
FAQ
Quando si applica il CRA?
Il CRA è entrato in vigore il 10 dicembre 2024. L’articolo 14 si applica dall’11 settembre 2026. Gli obblighi principali si applicano dall’11 dicembre 2027.
Il CRA si applica al software?
Sì, quando il software è un prodotto con elementi digitali messo a disposizione sul mercato UE, secondo ambito ed esclusioni del regolamento.
La marcatura CE basta?
No. La marcatura CE è l’esito visibile della conformità. Contano evidenze, risk assessment, gestione vulnerabilità e documentazione.