Cyber Resilience Act: a chi si applica, quali obblighi scattano e come prepararsi.

Il Cyber Resilience Act è il Regolamento (UE) 2024/2847 che introduce requisiti obbligatori di cybersicurezza per tutti i prodotti con elementi digitali immessi sul mercato europeo, dal software ai dispositivi connessi. Il principio è che la sicurezza diventa una condizione di accesso al mercato, allo stesso modo in cui la marcatura CE governa da anni la sicurezza fisica dei prodotti. Dall’11 settembre 2026 è scattato il primo obbligo operativo, cioè la segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi entro tempi cronometrati.

In questa guida vediamo che cosa prevede il CRA, quali prodotti e quali soggetti riguarda, come è costruito il calendario di applicazione fino alla piena efficacia dell’11 dicembre 2027, come funzionano nel dettaglio le finestre di segnalazione di 24 ore, 72 ore e un mese, quali sanzioni sono previste, come il regolamento si integra con la direttiva NIS2 e quali passi concreti servono per prepararsi. L’obiettivo è darti una checklist utilizzabile e una lettura chiara degli impatti organizzativi.

indice dei contenuti

• che cos’è il Cyber Resilience Act
• il calendario di applicazione
• gli obblighi di segnalazione in dettaglio
• sanzioni e responsabilità lungo la catena di fornitura
• Cyber Resilience Act e NIS2: come si integrano
• come prepararsi: la checklist operativa
• le competenze necessarie e come reperirle

che cos’è il Cyber Resilience Act.

Prima di entrare negli obblighi conviene capire che cosa il regolamento intende per prodotto con elementi digitali e chi risponde lungo la catena commerciale. Il perimetro è molto più ampio di quanto la maggior parte delle imprese si aspetti, e comprende anche software e componenti venduti separatamente.

obiettivi del Regolamento (UE) 2024/2847 e prodotti con elementi digitali.

Il Cyber Resilience Act nasce per colmare un vuoto. Fino a oggi un prodotto poteva essere venduto nell’Unione europea senza che nessuno ne verificasse il livello di sicurezza informatica, con il risultato che vulnerabilità note restavano aperte per anni e che l’onere della protezione ricadeva interamente sull’utilizzatore finale. Il regolamento ribalta questa impostazione e chiede che la sicurezza sia progettata nel prodotto e mantenuta per tutto il suo ciclo di vita, con aggiornamenti garantiti per un periodo definito.

L’ambito di applicazione è molto ampio. Rientra nel perimetro qualsiasi prodotto con elementi digitali, cioè ogni prodotto hardware o software il cui funzionamento dipenda, in tutto o in parte, da componenti digitali collegabili direttamente o indirettamente a una rete o a un altro dispositivo. Si va dal software gestionale alle applicazioni mobili, dai sensori industriali alle telecamere di sorveglianza, dagli elettrodomestici connessi ai componenti firmware. Il regolamento individua inoltre categorie a rischio crescente, con prodotti importanti di classe I e II e prodotti critici, a cui corrispondono procedure di valutazione della conformità più stringenti. Il tema si intreccia con l’intero percorso di digital innovation delle imprese manifatturiere e dei fornitori di software.

i soggetti coinvolti: fabbricanti, importatori, distributori.

Gli obblighi non sono uguali per tutti. Il fabbricante è il soggetto con la responsabilità più ampia, perché deve garantire i requisiti essenziali di sicurezza, gestire le vulnerabilità per tutto il periodo di supporto, redigere la documentazione tecnica, apporre la marcatura CE ed effettuare le segnalazioni previste. È considerato fabbricante anche chi immette sul mercato un prodotto sviluppato da terzi vendendolo con il proprio nome o marchio, una circostanza molto frequente tra le imprese italiane che commercializzano soluzioni realizzate da fornitori esterni.

L’importatore deve verificare che il fabbricante extraeuropeo abbia adempiuto ai propri obblighi e che il prodotto sia accompagnato dalla documentazione richiesta. Il distributore deve agire con la dovuta diligenza e non immettere sul mercato prodotti che sa non conformi. Il regolamento introduce infine la figura dello steward di software libero e open source, con obblighi specifici e proporzionati quando il software viene impiegato in prodotti commerciali. Vale il principio del mercato, quindi un produttore stabilito fuori dall’Unione europea che vende nell’Unione deve rispettare il regolamento esattamente come un produttore europeo.

il calendario di applicazione.

Il regolamento non diventa efficace tutto insieme: le disposizioni si attivano in momenti distinti, e la prima scadenza è già alle porte. Vediamo quali obblighi sono operativi da subito e quali lasciano ancora tempo per organizzarsi.

l’obbligo di segnalazione in vigore dall’11 settembre 2026.

Il regolamento è entrato in vigore il 10 dicembre 2024, ma la sua applicazione è scaglionata. L’11 giugno 2026 è diventato applicabile il capo dedicato alla notifica degli organismi di valutazione della conformità, cioè i soggetti abilitati a certificare i prodotti delle classi più critiche. L’11 settembre 2026 è la prima scadenza che tocca direttamente le imprese produttrici, perché rende operativo l’articolo 14 e con esso gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi.

È una data che merita attenzione per un motivo pratico. L’obbligo riguarda anche i prodotti già in commercio da anni e installati presso i clienti, non solo quelli di nuova immissione. Un’azienda che ha venduto apparecchiature connesse negli ultimi cinque anni deve quindi essere in grado, da oggi, di accorgersi che una vulnerabilità di quei prodotti è oggetto di sfruttamento attivo e di attivare la segnalazione nei tempi previsti. Chi non ha ancora un processo interno per farlo si trova già fuori tempo massimo.

la piena conformità dall’11 dicembre 2027.

L’11 dicembre 2027 tutte le disposizioni del regolamento diventano pienamente applicabili. Da quella data un prodotto con elementi digitali può essere immesso sul mercato europeo solo se rispetta i requisiti essenziali di cybersicurezza dell’Allegato I, dispone di documentazione tecnica completa, ha superato la procedura di valutazione della conformità corrispondente alla propria classe di rischio e reca la marcatura CE. È il passaggio che trasforma la cybersicurezza in una condizione di accesso al mercato.

Per i prodotti già immessi sul mercato prima di quella data la regola generale è che restano fuori dal perimetro, salvo che siano oggetto di una modifica sostanziale a partire dall’11 dicembre 2027. Questo non significa che non vada fatto nulla: l’obbligo di segnalazione dell’articolo 14 vale già oggi anche per il parco installato. Il modello di scadenze progressive ricorda quello di altri regolamenti europei recenti, a partire dall’AI Act, dove il rinvio di alcuni obblighi ha convissuto con l’immediata applicabilità di altri come quelli sull’AI literacy. La lezione è la stessa, cioè conviene lavorare sul processo prima della scadenza formale.

gli obblighi di segnalazione in dettaglio.

La segnalazione non riguarda ogni difetto di sicurezza, ma due categorie precise di eventi, con tempi molto stretti. Vediamo che cosa va comunicato, entro quando e a chi, partendo dalla capacità di individuare le vulnerabilità in modo sistematico con un vulnerability assessment periodico.

vulnerabilità attivamente sfruttate e incidenti gravi.

Il regolamento non chiede di segnalare ogni difetto di sicurezza scoperto nel codice. L’obbligo scatta in due casi precisi. Il primo è la vulnerabilità attivamente sfruttata, cioè una falla per la quale esiste evidenza affidabile che un soggetto malevolo la stia già utilizzando per condurre attacchi. Non basta quindi la scoperta teorica di un bug. Il secondo è l’incidente grave che incide sulla sicurezza del prodotto, ossia un evento che compromette riservatezza, integrità o disponibilità e che può avere conseguenze per gli utilizzatori.

Accanto alla segnalazione alle autorità, il fabbricante deve informare gli utilizzatori interessati e, quando necessario, indicare gli aggiornamenti, le correzioni o i comportamenti che riducono il rischio. È un obbligo di trasparenza che cambia la relazione commerciale: la comunicazione di una vulnerabilità non è più una scelta di opportunità ma un adempimento. Molti degli eventi che faranno scattare questi obblighi avranno la forma di un attacco informatico su larga scala, ed è utile conoscere le dinamiche tipiche di un attacco ransomware per capire quanto poco tempo resti per decidere.

le finestre temporali di 24 ore, 72 ore e un mese.

La sequenza prevista dall’articolo 14 è a cascata e parte dal momento in cui il fabbricante viene a conoscenza dell’evento. Entro 24 ore va trasmessa un’allerta precoce, cioè una prima comunicazione sintetica che segnala l’esistenza del problema. Entro 72 ore va inviata una notifica completa, con le informazioni disponibili sulla vulnerabilità o sull’incidente e sulle misure correttive adottate o previste. La relazione finale chiude il ciclo entro 14 giorni dalla disponibilità di una misura correttiva nel caso di vulnerabilità attivamente sfruttata, ed entro un mese dalla notifica nel caso di incidente grave.

Ventiquattro ore sono poche, soprattutto se l’evento si manifesta di venerdì sera o durante un periodo di chiusura. Rispettare la prima finestra richiede che qualcuno sia reperibile, che sappia riconoscere quando un evento rientra nell’obbligo e che disponga già delle credenziali per accedere alla piattaforma di segnalazione. Sono tre condizioni organizzative, non tecniche, e sono esattamente il punto in cui la maggior parte delle imprese scopre di non essere pronta.

la piattaforma unica ENISA e il ruolo dell’ACN in Italia.

Le segnalazioni passano attraverso la piattaforma unica di segnalazione prevista dal regolamento e gestita da ENISA, l’Agenzia dell’Unione europea per la cybersicurezza, operativa dall’11 settembre 2026. Il meccanismo è pensato per evitare duplicazioni: il fabbricante effettua una sola comunicazione, che raggiunge il CSIRT nazionale competente e, salvo circostanze eccezionali, viene resa disponibile contemporaneamente a ENISA. Non è quindi necessario inviare la stessa segnalazione alle autorità di ogni Paese interessato.

Per l’Italia il CSIRT competente opera presso l’Agenzia per la Cybersicurezza Nazionale, che è il punto di riferimento per la gestione degli incidenti e per il rapporto con le imprese. ENISA ha chiarito che, se la piattaforma risulta temporaneamente indisponibile, la segnalazione va comunque trasmessa una volta ripristinato il servizio, e che nei casi in cui serva una comunicazione immediata è possibile contattare direttamente il CSIRT competente, senza che questo sostituisca il successivo invio attraverso la piattaforma.

sanzioni e responsabilità lungo la catena di fornitura.

Il regolamento accompagna gli obblighi con un impianto sanzionatorio articolato e con una responsabilità che si estende ai componenti realizzati da terzi. Vediamo gli importi previsti, i criteri con cui vengono applicati e perché la catena di fornitura diventa una voce del risk management aziendale.

gli importi previsti e i criteri di applicazione.

L’articolo 64 del regolamento costruisce un sistema sanzionatorio su tre livelli. La violazione dei requisiti essenziali di cybersicurezza dell’Allegato I e degli obblighi degli articoli 13 e 14, quindi anche degli obblighi di segnalazione, rientra nella fascia più alta e può comportare sanzioni fino a 15 milioni di euro o fino al 2,5 per cento del fatturato mondiale annuo dell’esercizio precedente, se superiore. La violazione di altri obblighi, compresi quelli procedurali di importatori e distributori e quelli su dichiarazione di conformità, marcatura CE e documentazione tecnica, arriva fino a 10 milioni di euro o al 2 per cento del fatturato. La comunicazione di informazioni inesatte, incomplete o fuorvianti alle autorità e agli organismi notificati può costare fino a 5 milioni di euro o l’1 per cento del fatturato.

Gli importi indicati sono massimali. Le sanzioni vengono stabilite e applicate dagli Stati membri, che devono garantirne l’efficacia, la proporzionalità e il carattere dissuasivo, e il regolamento prevede alcune attenuazioni a favore delle micro e piccole imprese. Accanto alla sanzione pecuniaria esiste una conseguenza spesso più temuta, cioè il potere delle autorità di vigilanza di ordinare il ritiro o il richiamo del prodotto dal mercato, con un impatto commerciale immediato.

perché il fabbricante risponde anche delle vulnerabilità ereditate.

Il punto più impegnativo del regolamento riguarda la catena di fornitura. Un prodotto moderno è composto in larga parte da componenti di terzi, librerie open source, moduli acquistati, firmware di fornitori. Il regolamento stabilisce che il fabbricante risponde della sicurezza del prodotto finito, comprese le vulnerabilità che derivano da questi componenti. Non è possibile scaricare la responsabilità sul fornitore del modulo difettoso quando il prodotto viene venduto con il proprio marchio.

La conseguenza operativa è che occorre sapere con precisione cosa contiene ciò che si vende. Questo richiede una distinta dei componenti software, la cosiddetta SBOM, mantenuta aggiornata, e un processo per monitorare le vulnerabilità che vengono pubblicate su quei componenti. Richiede anche una revisione dei contratti con i fornitori, con obblighi di notifica tempestiva e tempi di rilascio delle correzioni. Per le aziende che si appoggiano a un fornitore di servizi gestiti per la parte tecnologica, questa ripartizione di responsabilità va messa nero su bianco prima che si verifichi un incidente.

Cyber Resilience Act e NIS2: come si integrano.

I due provvedimenti vengono spesso confusi, ma hanno oggetti e destinatari diversi e possono applicarsi contemporaneamente alla stessa impresa. Vediamo dove i perimetri si sovrappongono e come evitare di costruire due procedure parallele che si ostacolano a vicenda.

perimetri diversi, obblighi di notifica che si sovrappongono.

I due provvedimenti sono spesso confusi ma hanno oggetti diversi. La direttiva NIS2 riguarda le organizzazioni, cioè impone misure di gestione del rischio e obblighi di notifica ai soggetti essenziali e importanti di determinati settori, in funzione di quello che fanno e di quanto sono grandi. Il Cyber Resilience Act riguarda invece i prodotti, cioè impone requisiti a chi li fabbrica, importa o distribuisce, indipendentemente dal settore in cui opera il cliente finale.

La sovrapposizione si crea perché molte imprese ricadono in entrambi i perimetri. Un’azienda manifatturiera che rientra tra i soggetti importanti ai fini NIS2 e che produce macchinari connessi è tenuta sia a notificare gli incidenti che colpiscono la propria organizzazione, sia a segnalare le vulnerabilità sfruttate e gli incidenti che riguardano i prodotti venduti. Le due catene di notifica hanno finestre temporali simili, entrambe con un’allerta iniziale entro 24 ore, ma destinatari, soglie e contenuti differenti.

come impostare un unico processo interno di gestione degli incidenti.

Gestire due procedure separate moltiplica il rischio di errore proprio nel momento di massima pressione. La soluzione praticabile è un processo unico di rilevazione e classificazione, con una diramazione a valle. All’ingresso c’è un canale unico attraverso cui arrivano le segnalazioni, interne ed esterne. Subito dopo interviene una fase di triage che risponde a due domande: l’evento riguarda la nostra organizzazione, riguarda un nostro prodotto, oppure entrambe le cose.

In base alla risposta si attivano i percorsi corrispondenti, con modelli di comunicazione già predisposti per ciascun destinatario e con le scadenze calcolate automaticamente a partire dal momento della conoscenza dell’evento. Serve un registro unico degli eventi, perché le autorità possono chiedere di ricostruire la cronologia delle decisioni. Serve infine un responsabile unico del processo, con l’autorità di far partire una notifica senza attendere passaggi gerarchici che consumerebbero gran parte delle 24 ore disponibili.

come prepararsi: la checklist operativa.

Il percorso verso la conformità si costruisce su due binari, uno tecnico e uno organizzativo, che vanno avanti insieme. Vediamo da dove partire sul fronte dei prodotti e quali presidi interni servono, a cominciare da una policy aziendale che definisca ruoli, responsabilità e tempi di reazione.

censimento dei prodotti, SBOM e gap analysis.

Il primo passo è il censimento. Occorre elencare tutti i prodotti che l’azienda immette sul mercato con il proprio nome o marchio e verificare quali contengono elementi digitali o funzioni di connettività, comprese le applicazioni di supporto e i moduli acquistati da terzi. Per ciascun prodotto va poi stabilita la classificazione, cioè se rientra tra i prodotti standard, importanti di classe I o II, oppure critici, perché da questa collocazione dipendono la procedura di conformità applicabile e i relativi costi.

Il secondo passo è la costruzione della distinta dei componenti software per i prodotti in perimetro, con l’indicazione delle librerie e dei moduli utilizzati e delle rispettive versioni. Il terzo è la gap analysis rispetto ai requisiti essenziali dell’Allegato I, che confronta lo stato attuale di ogni prodotto con quanto il regolamento richiede in termini di sicurezza per progettazione, gestione delle vulnerabilità, aggiornamenti e documentazione. L’esito è un piano di lavoro con priorità e scadenze intermedie fino all’11 dicembre 2027.

punto di contatto, procedure interne ed esercitazioni.

Sul piano organizzativo servono tre elementi. Un punto di contatto unico per le segnalazioni di sicurezza, pubblicato e presidiato, attraverso cui ricercatori, clienti e partner possano comunicare una vulnerabilità. Una procedura interna scritta che definisca chi valuta la segnalazione, in base a quali criteri si stabilisce se scatta l’obbligo di notifica, chi autorizza l’invio e chi cura la comunicazione ai clienti. Le credenziali di accesso alla piattaforma di segnalazione già attive e note a più persone, per non dipendere da una sola.

L’ultimo elemento è l’esercitazione. Una simulazione periodica che parta da una segnalazione verosimile e arrivi fino alla bozza di notifica delle 24 ore fa emergere in poche ore i punti deboli reali, come un reperibile non raggiungibile, un’ambiguità sulla soglia di gravità o la mancanza di un modello pronto. Queste procedure vanno inserite nei percorsi di formazione aziendale delle funzioni coinvolte, perché la conformità dipende da comportamenti ripetuti e non da un documento archiviato.

le competenze necessarie e come reperirle.

La conformità al regolamento richiede figure che uniscono competenza tecnica e conoscenza normativa, oggi tra le più difficili da reperire sul mercato italiano. Vediamo quali profili servono, a partire dal cyber security expert, e quali strade esistono per coprirli.

i profili di sicurezza e compliance più richiesti sul mercato.

Il Cyber Resilience Act richiede competenze che stanno a metà strada tra il tecnico e il normativo, e che per questo sono particolarmente difficili da trovare. Servono figure di product security in grado di tradurre i requisiti essenziali in scelte di progettazione, specialisti di gestione delle vulnerabilità che presidino il monitoraggio dei componenti di terzi e la pubblicazione degli aggiornamenti, profili di compliance che curino documentazione tecnica, valutazione di conformità e rapporti con gli organismi notificati.

Nella maggior parte delle imprese italiane queste competenze non esistono come ruoli dedicati, ma sono distribuite tra la funzione IT, l’ufficio tecnico e la qualità. Il primo intervento utile è quindi una ricognizione delle capacità già presenti, per capire quali possono essere sviluppate internamente e quali vanno inserite dall’esterno. È lo stesso metodo di una skill gap analysis applicato a un obbligo normativo con una scadenza certa, e il vantaggio è che permette di distribuire l’investimento su più esercizi invece di concentrarlo a ridosso del termine.

come noi di Randstad supportiamo le aziende su competenze e progetti.

Noi di Randstad affianchiamo le imprese lungo tutto il percorso di adeguamento, partendo dalle persone. Supportiamo la ricerca e la selezione dei profili di sicurezza e compliance necessari, costruiamo percorsi di sviluppo per le competenze già presenti nei team tecnici e mettiamo a disposizione soluzioni di inserimento flessibile quando il fabbisogno è concentrato nella fase di progetto e non richiede un organico stabile.

Sul fronte dei progetti, i servizi di consulenza e le soluzioni gestite di Randstad Digital coprono l’analisi dello stato attuale, il presidio operativo della gestione delle vulnerabilità e il supporto continuativo nelle attività che richiedono competenze specialistiche difficili da mantenere internamente. L’obiettivo è trasformare un obbligo normativo in un processo stabile, sostenibile per l’organizzazione e utilizzabile come elemento di fiducia nei rapporti con clienti e committenti.