Cosa devi sapere subito sul Cyber Resilience Act
La Commissione europea ha appena pubblicato le linee guida ufficiali per l’applicazione del Cyber Resilience Act (Regolamento UE 2024/2847), un documento di 230 paragrafi con decine di esempi pratici che chiarisce aspetti fondamentali della normativa. Se la tua azienda produce software, hardware connesso o opera nell’economia digitale europea, questa guida è essenziale per capire come adeguarsi.
La situazione in sintesi: il CRA è entrato in vigore il 10 dicembre 2024 e si applicherà pienamente dal 11 dicembre 2027. Non è una normativa futura: è già operativa. Le aziende che ignorano questi contenuti rischiano di navigare a vista in un contesto normativo che determina come progettare, sviluppare e mantenere i prodotti digitali per il mercato europeo.
L’azione immediata: leggi questa guida per comprendere se il tuo prodotto rientra nel perimetro del CRA e quali obblighi dovrai rispettare. Le scadenze sono precise e non lasciano spazio a rinvii dell’ultimo minuto.
Il Cyber Resilience Act in due parole
Il Cyber Resilience Act è la prima normativa europea orizzontale dedicata ai requisiti di cybersecurity dei prodotti con elementi digitali. Si applica trasversalmente a qualsiasi prodotto—hardware o software—che abbia una connessione dati diretta o indiretta a un dispositivo o a una rete, e che sia immesso sul mercato UE nel corso di un’attività commerciale.
L’obiettivo è duplice:
- Garantire che i prodotti digitali raggiungano il mercato con un livello adeguato di sicurezza informatica
- Assicurare che quel livello sia mantenuto per tutta la durata del ciclo di vita del prodotto attraverso obblighi di gestione delle vulnerabilità, notifica degli incidenti e aggiornamenti di sicurezza
A differenza del GDPR—che proteggono un diritto fondamentale della persona—il CRA opera su una logica di sicurezza del prodotto stesso. È più vicino alla direttiva sulla responsabilità del prodotto o al regolamento macchine che al diritto della protezione dei dati personali.
Chi rientra nel perimetro: non solo hardware
La percezione diffusa è che il CRA riguardi principalmente dispositivi IoT, router e smartwatch. Non è così. Il perimetro comprende:
- App e programmi software standalone
- Hardware con software integrato (IoT)
- Hardware standalone come circuiti integrati e schede madri
- Qualsiasi combinazione di hardware e software forniti separatamente ma progettati per operare insieme
Il criterio discriminante è la capacità del prodotto di scambiare informazioni digitali: deve esistere una connessione dati, diretta o indiretta, logica o fisica, a un dispositivo o a una rete.
La Commissione traccia un confine preciso: non ogni segnale elettrico è una “connessione dati”. Commutare un output tra 0 e 1 non è di per sé una connessione dati se quegli stati non rappresentano un’informazione. Serve che i segnali siano deliberatamente codificati come informazione da una sorgente e decodificati come tale dalla destinazione.
Esempi pratici:
- Un termostato basilare che apre o chiude un circuito: fuori perimetro
- Lo stesso termostato che comunica con un’app via Wi-Fi: dentro il perimetro
- Una valvola industriale comandata da un relè fisico: probabilmente fuori
- La stessa valvola controllata via protocollo di rete: quasi certamente dentro
Software standalone: quando si considera immesso sul mercato
Uno dei chiarimenti più attesi riguarda il software standalone. A differenza dei prodotti fisici, il software distribuito via canali digitali non ha stock, produzione fisica o logistica. Quando considerarlo “immesso sul mercato”?
La Commissione offre una risposta netta: il software standalone si considera immesso sul mercato nel momento in cui il produttore lo rende per la prima volta disponibile per distribuzione o uso sul mercato UE, nel corso di un’attività commerciale. Da quel momento, il produttore ha immesso sul mercato un numero virtualmente infinito di copie dello stesso prodotto simultaneamente.
Implicazione concreta: due clienti che acquistano la versione 1.0.0 dello stesso software in date diverse (per es. 1° e 15 gennaio 2028) hanno entrambi un prodotto immesso sul mercato in data 1° gennaio 2028. È la data del primo rilascio che conta.
Diverso il caso degli aggiornamenti successivi: se la versione 1.0.1 non costituisce una modifica sostanziale rispetto alla 1.0.0, la data di immissione sul mercato non cambia. Solo le iterazioni che integrano una modifica sostanziale vengono considerate un nuovo prodotto, con una nuova data di immissione e un nuovo obbligo di valutazione della conformità.
Questo principio vale esclusivamente per software standalone distribuito via canali digitali. Se il software è fornito su supporto fisico (per es. chiavetta USB) o è abbinato a hardware, allora si applicano regole diverse.
Open source: non è automaticamente fuori dal CRA
Questo è probabilmente il punto dove si concentreranno molte incomprensioni nell’ecosistema tecnologico. La percezione diffusa—e ancora errata—è che il software libero e open source sia per definizione escluso dal Cyber Resilience Act. Non è così.
La Commissione distingue con precisione: il CRA si applica ai prodotti immessi sul mercato nel corso di un’attività commerciale. Un FOSS (Free and Open Source Software) non è considerato immesso sul mercato quando il suo sviluppatore lo pubblica su un repository pubblico senza monetizzarlo in alcun modo. Ma attenzione: la monetizzazione può assumere forme non immediatamente evidenti.
Secondo la guida, un FOSS è da considerarsi “immesso sul mercato” quando il soggetto che lo pubblica:
- Addebita un prezzo per il suo utilizzo (anche solo per alcune funzionalità)
- Lo distribuisce attraverso una piattaforma tramite cui monetizza altri prodotti o servizi (per es. un marketplace gratuito che genera ricavi sulle transazioni)
- Condiziona l’accesso alla raccolta di dati personali per finalità diverse dalla sicurezza, compatibilità o interoperabilità del software
- Offre accesso a versioni specifiche con benefici aggiuntivi (assistenza tecnica, ottimizzazione delle prestazioni ecc.) su base remunerativa—anche quando una versione equivalente è disponibile gratuitamente
Il tema delle donazioni: il semplice fatto di includere un link a una piattaforma di raccolta donazioni non configura di per sé un’attività commerciale, anche se le donazioni ricevute superano i costi effettivi. Le donazioni per loro natura fluttuano nel tempo e non implicano, necessariamente, un’intenzione di fare profitto.
Tuttavia, le donazioni possono assimilarsi al pagamento di un prezzo—e quindi far scattare il CRA—quando l’accesso al software, alle funzionalità essenziali o agli aggiornamenti è condizionato in pratica al versamento di una donazione, oppure quando la struttura delle donazioni tradisce un’intenzione sistematica di generare profitto.
Esempio chiarificatore: una repository pubblica, liberamente accessibile con un link “Donate se lo trovate utile” resta quasi certamente fuori dal CRA. Lo stesso software che fornisce le release compilate e le patch di sicurezza solo a chi ha donato è quasi certamente dentro.
Steward vs. produttore: due ruoli, due regimi di obblighi
Il Cyber Resilience Act introduce una figura normativamente inedita: l’open-source software steward, cioè una persona giuridica che sistematicamente fornisce supporto continuato allo sviluppo di FOSS destinato ad attività commerciali, garantendone la vitalità, senza però immetterlo sul mercato nel senso del CRA.
La distinzione tra steward e produttore genera obblighi radicalmente diversi.
Il produttore deve adempiere in toto agli obblighi del CRA: valutazione dei rischi, documentazione tecnica, dichiarazione di conformità, marcatura CE, gestione delle vulnerabilità, notifica degli incidenti ecc.
Lo steward soggiace a obblighi più leggeri, definiti dall’articolo 24 CRA:
- Adottare e documentare una politica di cybersecurity per la gestione coordinata delle vulnerabilità dei prodotti FOSS di cui garantisce il supporto
- Cooperare con le autorità di sorveglianza del mercato ove richiesto
- In funzione del tipo di supporto concretamente fornito, notificare all’ENISA e ai CSIRT gli incidenti gravi che impattano la sicurezza dei prodotti, segnalare le vulnerabilità attivamente sfruttate di cui vengono a conoscenza, informando gli utenti impattati
La Commissione chiarisce che la stessa persona giuridica può essere simultaneamente produttore per un determinato FOSS (quello che monetizza) e steward per un altro (quello che mantiene pubblicamente senza monetizzarlo). L’esempio più comune è proprio quello dell’azienda che pubblica una versione community gratuita e una versione Enterprise a pagamento dello stesso software: è produttore per la versione a pagamento e steward per la versione gratuita.
Gli obblighi dello steward variano in base al tipo di supporto fornito:
- Supporto non tecnico (branding, governance della community ecc.): non tenuto a notificare vulnerabilità attivamente sfruttate all’ENISA
- Infrastruttura IT (hosting del codice sorgente, sistemi di version control ecc.): tenuto a notificare gli incidenti gravi
- Risorse ingegneristiche (sviluppatori): deve notificare anche le vulnerabilità attivamente sfruttate di cui viene a conoscenza
Modifica sostanziale: il confine critico
La modifica sostanziale è uno dei concetti più rilevanti—e più sottovalutati—dell’intero Cyber Resilience Act. Se una modifica a un prodotto già immesso sul mercato è qualificata come “sostanziale”, allora quel prodotto modificato è trattato come un nuovo prodotto, soggetto a una nuova valutazione della conformità.
L’articolo 3.30 CRA definisce “sostanziale” la modifica che:
- Incide sulla conformità del prodotto ai requisiti essenziali di cybersecurity, oppure
- Modifica la finalità d’uso per cui il prodotto era stato valutato
La Commissione fornisce una griglia di criteri pratici. Una modifica software è (probabilmente) sostanziale quando:
- Introduce nuovi vettori di minaccia: interfacce aggiuntive, canali di comunicazione, ambienti di esecuzione, dipendenze esterne attraverso cui le minacce potrebbero materializzarsi
- Abilita nuovi scenari di attacco: nuove modalità in cui potrebbe verificarsi accesso non autorizzato, manipolazione, interferenza o uso improprio
- Aumenta la probabilità di scenari già identificati (abbassando le competenze richieste per sfruttarli, aumentando l’esposizione ad attori non fidati, indebolendo le salvaguardie esistenti)
- Aumenta l’impatto potenziale degli scenari esistenti (ampliando i dati o le funzioni coinvolte, aggravando le conseguenze operative)
Viceversa, un aggiornamento di sicurezza che non introduce nuove funzionalità, finalità d’uso e non aggiunge nuovi rischi non è, in linea generale, una modifica sostanziale—anche se limita o modifica alcune funzionalità per mitigare vulnerabilità note.
Esempio dalla guida: una dashboard di monitoraggio industriale che in un aggiornamento acquisisce la capacità di controllare attivamente le macchine (e non solo di visualizzarne i dati) rappresenta una modifica sostanziale perché la finalità d’uso si trasforma radicalmente.
L’indice che deve farla da padrone è l’effetto sul profilo di rischio di cybersecurity del prodotto—non la scala o complessità del cambiamento. Piccole modifiche possono essere sostanziali, impegnativi aggiornamenti di sicurezza possono non esserlo.
Periodo di supporto: cinque anni è il minimo, non il default
Il Cyber Resilience Act richiede ai produttori di determinare un periodo di supporto durante il quale gestire efficacemente le vulnerabilità del prodotto. È diffusa la convinzione che “cinque anni” sia il periodo standard, ma non è così.
La Commissione è esplicita: cinque anni è il minimo, non il periodo di default. Il produttore è tenuto a determinare il periodo di supporto appropriato sulla base di una serie di criteri (indicati all’articolo 13.8 CRA), tra cui la natura del prodotto o il suo ciclo di vita atteso.
I prodotti ragionevolmente destinati a essere in uso per più di cinque anni devono avere periodi di supporto corrispondentemente più estesi. Un prodotto industriale con ciclo di vita ventennale non può legittimamente dichiarare cinque anni di supporto.
Per il software iterativo—dove versioni sostanzialmente modificate vengono rilasciate con frequenza—il quadro è più articolato: ogni versione sostanzialmente modificata immessa sul mercato deve avere il proprio periodo di supporto dichiarato.
Tuttavia, il CRA consente ai produttori (articolo 13.10 CRA) di interrompere la gestione delle vulnerabilità per le versioni precedenti, a condizione che gli utenti possano aggiornarsi gratuitamente alla versione più recente senza sostenere costi aggiuntivi.
La Commissione chiarisce cosa si intende per “costi aggiuntivi”: non include il ragionevole sforzo operativo (test, aggiustamenti di configurazione ecc.), riferendosi a oneri straordinari come l’acquisto di nuovo hardware o cambiamenti fondamentali all’infrastruttura.
Prodotti importanti e critici: la core functionality
Il CRA classifica i prodotti con elementi digitali in tre categorie: “default”, “importanti” (classe I e II) e “critici”. La classificazione determina il regime di valutazione della conformità applicabile—con significative implicazioni in termini di procedura e costi.
I prodotti “default” possono sempre ricorrere all’auto-valutazione (modulo A allegato al CRA). I prodotti importanti di classe II e i prodotti critici richiedono obbligatoriamente il coinvolgimento di un organismo notificato di terza parte, un certificatore indipendente.
Il criterio di classificazione è la “core functionality”: le caratteristiche e capacità tecniche principali del prodotto, senza le quali non potrebbe soddisfare la sua finalità d’uso.
Un prodotto ha la funzionalità di un sistema operativo se gestisce l’esecuzione di componenti software. Lo stesso prodotto che integra un sistema operativo (come uno smartphone) non ha, per questo, la core functionality di un sistema operativo perché ha una finalità d’uso difforme (come comunicare, accedere a informazioni ecc.).
La Commissione mette in guardia da due errori opposti: sovrastimare la core functionality (per “scendere” di categoria) o sottostimarla (per “salire” e affrontare obblighi più stringenti). Entrambe le manipolazioni sono vietate e sanzionabili.
Un prodotto con funzionalità superiori a quelle della categoria importante o critica di riferimento non ricade necessariamente in quella categoria. Un software SOAR (Security Orchestration, Automation and Response), per dare un esempio, è in grado di svolgere le funzioni di un SIEM (raccogliere dati da più fonti, analizzarli, correlarli). Però la sua core functionality va ben oltre: include anche incident response e automazione. Non può quindi essere classificato semplicemente come SIEM.
Remote Data Processing Solutions: il cloud che non ti aspetti
Forse il capitolo più tecnico e allo stesso tempo più impattante per l’economia digitale riguarda le Remote Data Processing Solutions (RDPS). Il CRA include nel concetto di “prodotto” anche le soluzioni di elaborazione remota dei dati che ne fanno parte.
La logica è comprensibile: un prodotto deve essere adeguatamente protetto nella sua interezza, indipendentemente da dove vengono elaborati i dati—localmente sul dispositivo dell’utente o da remoto da parte del produttore.
Tre sono le condizioni cumulative che definiscono una RDPS:
- L’elaborazione avviene “a distanza” (tipicamente fuori dall’ambiente dell’utente, incluso il cloud, anche il private cloud on-premises del produttore)
- L’assenza di tale elaborazione impedirebbe al prodotto di svolgere una delle sue funzioni
- Il software è progettato e sviluppato dal produttore, o sotto la sua responsabilità
Il terzo criterio è forse quello davvero decisivo per distinguere tra RDPS e componenti di terze parti. La Commissione chiarisce il confine rispetto ai modelli cloud più comuni:
- IaaS: il software che il produttore sviluppa e distribuisce sull’infrastruttura IaaS di terzi è RDPS (se soddisfa gli altri criteri), l’infrastruttura sottostante non lo è
- PaaS: l’applicazione sviluppata dal produttore e distribuita sull’ambiente PaaS di terzi è RDPS, l’ambiente PaaS in sé non lo è
- SaaS: un’applicazione completamente sviluppata e offerta da un fornitore terzo non è considerata RDPS—non è progettata dal produttore né sotto la sua responsabilità
Caso pratico: un termostato smart che riceve comandi dall’app e sincronizza le preferenze dell’utente tramite software di elaborazione remota sviluppato sotto la responsabilità del produttore. Trattasi di RDPS perché la sua assenza impedirebbe al prodotto di funzionare. L’infrastruttura IaaS di terzi su cui gira, invece, no. Deve comunque essere coperta dalla valutazione del rischio e il produttore è tenuto a esercitare la dovuta diligenza nei confronti del fornitore.
Obblighi di segnalazione: quando scatta la consapevolezza
Il CRA impone ai produttori di notificare simultaneamente al CSIRT coordinatore e all’ENISA le vulnerabilità attivamente sfruttate e gli incidenti gravi che impattano la sicurezza del prodotto.
La tempistica di notifica è serrata:
- Early warning entro 24 ore
- Notifica completa entro 72 ore
- Report finale entro 14 giorni (per vulnerabilità sfruttate) o un mese (per incidenti gravi)
Il nodo interpretativo affrontato dalla Commissione nella guida è: da quando decorre questo termine? La risposta è: dalla “consapevolezza” acquisita dal produttore.
La Commissione allinea la propria interpretazione a quella già consolidata nel contesto del GDPR e del Regolamento delegato NIS 2: il produttore è da considerarsi “consapevole” quando, dopo una valutazione iniziale, ha un ragionevole grado di certezza che una vulnerabilità nel suo prodotto sia attivamente sfruttata, o che un incidente grave abbia compromesso la sicurezza del prodotto.
Ciò implica che la ricezione di una segnalazione esterna (da un ricercatore di sicurezza, da un cliente, da un’autorità) non fa scattare immediatamente il termine: serve un’analisi preliminare. L’enfasi è sulla prontezza: quella valutazione iniziale deve essere condotta immediatamente, specialmente se la vulnerabilità potrebbe rappresentare un rischio significativo.
Interplay con altre normative: macchine, veicoli e RED
Un aspetto importante e spesso trascurato riguarda i rapporti tra il CRA e altre normative di armonizzazione UE. La guida chiarisce vari casi, a partire dal Regolamento Macchine (Regolamento UE 2023/1230, pienamente applicabile dal 20 gennaio 2027).
I certificati rilasciati ai sensi del Regolamento Macchine per i requisiti di cybersecurity relativi alla protezione dei sistemi di controllo—in particolare gli aspetti di protezione contro la corruzione e di sicurezza e affidabilità dei sistemi di controllo—restano validi per quei rischi specifici. Per tutto il resto il CRA si applica integralmente.
Il messaggio della guida è chiaro: i certificati esistenti consentono di riutilizzare le evidenze già prodotte per i rischi già coperti, evitando duplicazioni inutili. Però attenzione: non esentano dal condurre una valutazione completa ai sensi del CRA per i rischi residui non coperti dalla certificazione Machinery—come la gestione delle vulnerabilità, la minimizzazione dei dati, la riduzione della superficie di attacco o altri aspetti di sicurezza specifici del prodotto.
Per molte imprese industriali già in possesso di certificazioni Machinery questo può tradursi in un percorso di conformità al CRA significativamente più breve di quanto temuto—a condizione di mappare con precisione la copertura effettiva dei certificati esistenti, senza sopravvalutarla.
Le scadenze chiave che non ammettono rinvii
Il percorso di adeguamento ha scadenze precise:
- 10 dicembre 2024: Il regolamento è ufficialmente entrato in vigore
- 11 settembre 2026: Diventano obbligatorie le segnalazioni di incidenti e vulnerabilità
- 11 dicembre 2027: Piena applicazione del CRA. Da questa data, nessun prodotto non conforme potrà essere venduto nel mercato unico europeo
Technical Deep Dive
Valutazione dei rischi di cibersicurezza: il framework procedurale
L’articolo 10 del CRA stabilisce che i fabbricanti effettuino una valutazione dei rischi di cibersicurezza associati a un prodotto con elementi digitali e tengano conto dei risultati di tale valutazione durante le fasi di pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione del prodotto, allo scopo di ridurre al minimo i rischi di cibersicurezza, prevenire gli incidenti e ridurne al minimo il loro impatto.
La guida della Commissione non prescrive una metodologia specifica, ma richiede che la valutazione sia:
- Sistematica: applicata coerentemente a tutti i prodotti della medesima linea
- Documentata: con evidenza delle analisi condotte, dei rischi identificati, delle misure di mitigazione adottate
- Aggiornata: nel ciclo di vita del prodotto, specialmente in risposta a nuove minacce o vulnerabilità note
- Proporzionata: il livello di dettaglio deve essere coerente con la categoria di rischio del prodotto (default, importante, critico)
I fabbricanti possono adottare metodologie consolidate (STRIDE, PASTA, CVSS, OWASP ecc.), ma devono dimostrare che l’approccio prescelto copra efficacemente i rischi specifici del loro prodotto.
Gestione delle vulnerabilità: il ciclo di vita
L’articolo 13 CRA impone ai fabbricanti di istituire e mantenere una procedura di gestione delle vulnerabilità che copra:
- Identificazione: ricerca sistematica di vulnerabilità attraverso testing, code review, bug bounty ecc.
- Analisi: valutazione della severità, dell’impatto, della probabilità di sfruttamento
- Correzione: sviluppo e testing di patch, rilascio tempestivo
- Comunicazione: informazione agli utenti finali, ai distribuitori, alle autorità ove richiesto
- Monitoraggio: verifica dell’efficacia della patch, identificazione di possibili regressioni
La procedura deve operare per l’intero periodo di supporto dichiarato dal fabbricante (minimo 5 anni, salvo diverse circostanze).
Marcatura CE e documentazione tecnica
I prodotti conformi al CRA devono recare la marcatura CE. La documentazione tecnica deve includere:
- Descrizione del prodotto e della sua architettura
- Risultati della valutazione dei rischi di cibersicurezza
- Descrizione delle misure di sicurezza implementate
- Istruzioni per l’uso sicuro del prodotto
- Dichiarazione di conformità
- Per i prodotti importanti di classe II e critici: rapporto di conformità redatto da un organismo notificato
Incident response e coordinamento con le autorità
L’articolo 20 CRA richiede che i fabbricanti stabiliscano procedure di risposta agli incidenti che includano:
- Identificazione e contenimento dell’incidente
- Analisi dell’impatto e della causa radice
- Sviluppo e implementazione di contromisure
- Comunicazione agli stakeholder interessati
- Documentazione dell’intero processo
Per gli incidenti gravi che impattano la sicurezza del prodotto, la notifica deve avvenire:
- Al CSIRT coordinatore nazionale (in Italia, il CSIRT italiano presso il Dipartimento della Sicurezza della Repubblica)
- All’ENISA (Agenzia europea per la cybersicurezza)
- Agli utenti finali impattati (quando ragionevolmente identificabili)
Conformità per i produttori di software open source
I produttori di FOSS che decidono di commercializzare il loro software (e quindi ricadono nel perimetro del CRA) devono adottare un approccio pragmatico alla documentazione tecnica, considerando che il codice sorgente è pubblicamente disponibile.
La documentazione può:
- Fare riferimento a repository pubblici dove è disponibile il codice sorgente
- Includere link a issue tracker, pull request, changelog pubblicamente accessibili
- Descrivere la procedura di gestione delle vulnerabilità (per es. security.txt, bug bounty program, canali di segnalazione dedicati)
- Documentare il periodo di supporto per ogni versione rilasciata
Tuttavia, la semplicità della documentazione non esonera dal rispetto degli obblighi sostanziali: la valutazione dei rischi deve comunque essere condotta, documentata (anche internamente se non divulgata) e le vulnerabilità devono comunque essere gestite secondo la procedura dichiarata.
Interoperabilità con NIS 2 e DORA
Le aziende soggette a NIS 2 (operatori di servizi essenziali e fornitori di servizi digitali critici) e a DORA (entità finanziarie) devono coordinare gli obblighi del CRA con quelli preesistenti.
La guida della Commissione riconosce che esiste sovrapposizione ma non equivalenza:
- NIS 2 si focalizza sulla sicurezza dei servizi e delle infrastrutture critiche
- DORA si focalizza sulla resilienza operativa digitale del settore finanziario
- CRA si focalizza sulla sicurezza intrinseca dei prodotti
Un’azienda che sviluppa un prodotto software per il settore finanziario e lo vende nel mercato UE è soggetta a tutti e tre i regolamenti, con obblighi che si integrano piuttosto che si sovrappongono. La Commissione ha annunciato che emetterà una guidance specifica su questo coordinamento, attualmente ancora attesa.
Sanzioni e enforcement
Il CRA non specifica sanzioni nel testo normativo, ma rimanda al regolamento sulla sorveglianza del mercato (Regolamento UE 2023/2454). Le autorità nazionali di sorveglianza del mercato possono:
- Ordinare il ritiro dal mercato di prodotti non conformi
- Comminare ammende amministrative fino al 5% del fatturato annuale globale dell’azienda (o 20 milioni di euro, se superiore)
- Sospendere temporaneamente la commercializzazione di prodotti specifici
- Avviare procedimenti penali per violazioni gravi (per es. false dichiarazioni di conformità)
L’enforcement sarà progressivo: nel periodo 2024-2027 le autorità si concentreranno su sensibilizzazione e supporto alle aziende; dopo il 2027, l’applicazione sarà rigorosa.
Roadmap di implementazione per le aziende
Per le aziende che devono adeguarsi al CRA entro il 2027, una roadmap ragionevole è:
Fase 1 (Ora – Giugno 2026):
- Mappare il portafoglio prodotti rispetto al perimetro del CRA
- Identificare quali prodotti rientrano e quali no
- Per i prodotti rientranti, determinare la categoria di rischio (default, importante, critico)
- Avviare la valutazione dei rischi di cibersicurezza
Fase 2 (Luglio 2026 – Settembre 2026):
- Completare la valutazione dei rischi
- Implementare le misure di sicurezza identificate
- Istituire procedure di gestione delle vulnerabilità
- Predisporre la documentazione tecnica
- Preparare la dichiarazione di conformità
- Per i prodotti importanti/critici: contattare organismi notificati per la valutazione di terza parte
Fase 3 (Ottobre 2026 – Dicembre 2027):
- Finalizzare la certificazione (se richiesta)
- Applicare la marcatura CE
- Implementare i sistemi di incident reporting
- Aggiornare il materiale commerciale e le istruzioni per l’uso
- Avviare il monitoraggio post-commercializzazione
Questo timeline consente di affrontare le scadenze critiche (settembre 2026 per gli obblighi di segnalazione, dicembre 2027 per la piena applicazione) senza fretta eccessiva.
Fonte: https://www.cybersecurity360.it/legal/cyber-resilience-act-ecco-come-le-imprese-dovranno-adeguarsi/
