Cyber Resilience Act (CRA) 2026–2027: cosa sappiamo già, cosa manca ancora e come preparare concretamente un prodotto — prima che arrivino le norme armonizzate

Cosa sappiamo con certezza oggi (e perché non è un “tema per il 2027”)

Il Cyber Resilience Act può sembrare l’ennesimo documento “da Bruxelles” che si può rimandare. È una reazione naturale, soprattutto se l’azienda vive secondo il ritmo dei progetti: prototipo, messa in servizio, produzione in serie, assistenza. Le normative spesso arrivano come “requisito finale”, qualcosa da chiudere sul traguardo. Il CRA cambia questa logica, perché non riguarda solo ciò che si vede nel prodotto il giorno della vendita. Riguarda se il produttore è in grado di mantenere la sicurezza del prodotto nel tempo e dimostrare di averlo fatto in modo consapevole, non per caso.

Il fatto più importante è semplice, ma ha conseguenze strategiche: il CRA è una normativa di prodotto, inserita nella logica del mercato UE (inclusa la marcatura CE). La Commissione europea indica esplicitamente che i prodotti devono riportare il marchio CE come segnale di conformità al CRA, e che l’applicazione è demandata alle autorità di vigilanza del mercato. Non è quindi uno “standard IT” da trattare come un programma interno di miglioramento. È un quadro che incide sulla possibilità di vendere.

Date che aiutano a fare chiarezza

Nel testo stesso del regolamento (UE) 2024/2847 si vede un’applicazione per fasi. Il CRA si applica dall’11 dicembre 2027, ma con eccezioni ben definite. L’articolo 14 (segnalazione) si applica dall’11 settembre 2026, e il capitolo sulla notifica degli organismi di valutazione della conformità (Chapter IV) dall’11 giugno 2026. Sono tre date da considerare come “milestone”, perché corrispondono a tre tipi diversi di prontezza: operativa, istituzionale e di prodotto.

La Commissione lo comunica in modo ancora più lineare: il CRA è entrato in vigore il 10 dicembre 2024, gli obblighi principali dall’11 dicembre 2027 e la segnalazione dall’11 settembre 2026. Se in azienda qualcuno dice “abbiamo tempo fino al 2027”, di solito intende i requisiti di progettazione e la valutazione della conformità. Ma la segnalazione arriva prima e riguarda eventi che non aspettano il calendario.

Segnalazione: un obbligo che impone un processo (non un documento)

Il requisito di segnalazione è un ottimo banco di prova, perché mostra come il CRA intende la “cybersecurity del prodotto”. Non è una dichiarazione d’intenti né una “policy”. È un processo che deve funzionare sotto pressione: quando emerge una vulnerabilità sfruttata attivamente oppure un incidente grave.

La Commissione lo descrive in modo inequivocabile: il produttore deve segnalare vulnerabilità sfruttate attivamente e severe incidents che incidono sulla sicurezza del prodotto. È richiesto un “early warning” entro 24 ore da quando se ne viene a conoscenza, una segnalazione completa entro 72 ore e un rapporto finale: entro 14 giorni dalla disponibilità della misura correttiva per le vulnerabilità sfruttate attivamente e entro un mese per i severe incidents.

In pratica significa che l’organizzazione ha bisogno di qualcosa di più di una checklist. Serve un meccanismo che risponda a tre domande: come veniamo a sapere che il problema esiste; chi stabilisce se è già “sfruttata attivamente” o “severe”; e come organizziamo la comunicazione e la correzione entro tempi che non lasciano spazio all’improvvisazione.

Se durante la formazione emerge confusione, spesso è perché il CRA colpisce un vuoto tra IT e prodotto. Per l’IT un “incidente” può essere un evento nell’infrastruttura. Per un produttore un “incidente” è un evento che riguarda il prodotto presso il cliente: versione, configurazione, modalità di implementazione. Il CRA impone di unire questi mondi in un’unica responsabilità.

Cosa copre il CRA: il prodotto come relazione con la rete, non “un dispositivo sul tavolo”

In pratica, nelle valutazioni del rischio delle macchine abbiamo imparato che il rischio non è una caratteristica della macchina in sé: nasce nella relazione uomo–macchina. Nel CRA c’è uno spostamento di prospettiva simile: la sicurezza non esiste “nel dispositivo”, ma nella relazione del prodotto con l’ambiente digitale, nel modo d’uso e nella capacità del produttore di reagire.

La Commissione, riassumendo il CRA, richiama l’attenzione sulla definizione di “prodotti con elementi digitali” e sul fatto che gli obblighi di segnalazione riguardano tutti questi prodotti messi a disposizione sul mercato UE, anche quelli immessi prima dell’11 dicembre 2027. È un chiarimento fondamentale, perché elimina un mito ricorrente: “per i prodotti vecchi non conta”. La segnalazione, invece, sì.

Cosa ancora manca (norme armonizzate) e perché non dovrebbe paralizzare

W discussioni sul CRA ricorre spesso la frase: “non ci sono ancora norme armonizzate, quindi non si può fare nulla”. Sembra logico, ma nasconde una trappola. Le norme armonizzate sono uno strumento che facilita la dimostrazione della conformità (presunzione di conformità), ma non sono l’unica strada per costruire una sicurezza reale del prodotto. E non sono una condizione per iniziare a progettare correttamente.

La Commissione gestisce esplicitamente il tema degli standard tramite la pagina “CRA Standardisation” e informa di aver adottato la standardisation request M/606, che comprende un insieme di 41 standard a supporto del CRA — sia orizzontali sia verticali (di prodotto). È importante, perché mostra che l’UE comprende il problema del mercato: senza standard, le aziende costruiranno la conformità ciascuna a modo proprio, e la vigilanza del mercato avrà vita più difficile.

Standard orizzontali e verticali: cosa significa per il produttore

In sintesi:

• gli standard orizzontali dovrebbero descrivere “come” costruire e mantenere la sicurezza del prodotto indipendentemente dalla categoria (processi, metodi, approccio basato sul rischio),
• gli standard verticali dovrebbero precisare i requisiti per specifiche classi di prodotti (laddove rischi e architetture sono tipici).

Questa distinzione ha conseguenze pratiche. Se realizzi un prodotto industriale, in cui parte dell’ambiente è “OT” e il ciclo di vita è lungo, avrai bisogno di standard che non siano pensati per un’applicazione SaaS. Ed è proprio per questo che gli standard verticali contano: aiutano a scendere dal livello dei principi generali a ciò che va controllato nelle architetture reali.

Pianificazione dei lavori: gli standard arriveranno per fasi, non “in un pacchetto prima del 2027”

La Commissione, nei materiali sull’implementazione del CRA, mostra che il CRA viene introdotto in modo graduale e che gli standard dovranno supportare questo processo nel tempo. Sul piano dei fatti oggi certi: abbiamo un regolamento formalmente adottato e abbiamo attivato il meccanismo di standardizzazione (M/606).

Per la pratica, la cosa più importante è capire una frase: anche quando uno standard viene elaborato dagli organismi di normazione, la “presunzione di conformità” in senso giuridico nasce solo quando il riferimento alla norma viene pubblicato come norma armonizzata nella Gazzetta ufficiale dell’UE. È una dinamica comune all’approccio europeo all’armonizzazione: gli standard sono il ponte tra il diritto e la pratica ingegneristica, ma quel ponte deve essere formalmente “riconosciuto” dall’UE.

Dal punto di vista del produttore, questo significa che gli anni 2026–2027 saranno un periodo in cui alcune aziende opereranno sulla base di propri metodi per dimostrare la conformità (basati sul rischio + evidenze), mentre altre inizieranno già ad allinearsi agli standard via via disponibili. Ed è normale.

“Assenza di norme” non significa “assenza di obblighi” — significa più peso alle evidenze

Qui emerge una conseguenza importante: se mancano norme che offrano il percorso più semplice per dimostrare la conformità, aumenta il valore di ciò che, nella pratica di audit, è sempre decisivo: una traccia decisionale coerente.

Quali rischi abbiamo valutato? Quali scenari abbiamo considerato realistici? Come abbiamo scelto le misure di protezione? Come gestiamo le vulnerabilità? Per quanto tempo supportiamo il prodotto? Come informiamo il cliente? Il CRA non richiede che il produttore “indovini le future norme EN”. Richiede che il produttore sappia dimostrare che le sue decisioni non sono state casuali, ma basate sul rischio e sullo stato dell’arte.

Come preparare concretamente un prodotto al CRA (roadmap per produttore e integratore)

Il valore più grande del CRA è che impone maturità: la cybersicurezza smette di essere un’aggiunta al prodotto e diventa una sua caratteristica intrinseca. Solo che la maturità non nasce dalle dichiarazioni. Nasce da un processo sufficientemente preciso da funzionare nella pratica e sufficientemente semplice da non essere aggirato dall’ingegneria.

Nella valutazione dei rischi delle macchine, le migliori decisioni progettuali arrivano quando smettiamo di chiederci “quali pericoli ha la macchina” e iniziamo a chiederci “in quali compiti e stati la persona è esposta”. Nel CRA, in modo analogo: smettiamo di chiederci “quali vulnerabilità ha il prodotto” e iniziamo a chiederci “in quali condizioni il prodotto diventa esposto e cosa il produttore è in grado di fare in quel momento”. Questo cambio di prospettiva mette ordine nel lavoro.

Passo 1: Definisci il prodotto come un sistema (non come un dispositivo)

Inizia definendo che cosa, nel tuo caso, è un “prodotto con elementi digitali”. Non solo hardware e firmware, ma anche ciò che spesso viene trascurato perché non entra nella scatola: componenti, librerie, meccanismi di aggiornamento, servizi senza i quali il prodotto non svolge la sua funzione. Nel CRA questo è importante, perché la responsabilità del produttore riguarda ciò che viene immesso sul mercato come prodotto — e non solo ciò che ha realizzato il reparto meccanico.

È anche il primo momento in cui gli integratori dovrebbero essere sinceri con sé stessi: se integri componenti e li configuri in un modo che crea un “prodotto finale” agli occhi del cliente, non sei solo un “implementatore”. Sei co-autore del rischio e co-autore della responsabilità.

Passo 2: Esegui la valutazione del rischio CRA in modo che sia uno strumento decisionale

Non si tratta di una “matrice” nelle slide. Si tratta di una valutazione del rischio che porta a decisioni di progettazione ed è ripetibile.

In pratica, un buon approccio alla CRA parte da una domanda semplice: quali sono gli scenari reali di uso improprio nell’ambiente del cliente, e non solo in laboratorio? Chi ha accesso per l’assistenza? Com’è fatta la rete? Con quale frequenza aggiorniamo? Quali sono le conseguenze di un fermo? Nell’industria queste domande sono più scomode che nell’IT, perché spesso le risposte sono: “non possiamo aggiornare ogni settimana” oppure “non abbiamo telemetria”. Ed è proprio per questo che vanno poste. La CRA è legge, ma i suoi effetti sono progettuali.

Krok 3: Costruisci il “vulnerability handling” come un processo produttivo, non come una reazione di crisi

I requisiti di segnalazione descritti dalla Commissione (24h/72h/14 giorni/un mese) sono spietati per un’organizzazione che non ha un processo. Se vuoi essere pronto per l’11 settembre 2026, devi trattare il “vulnerability handling” come parte del ciclo di vita del prodotto, non come un “compito del team security”.

Questo significa:

• un unico canale per ricevere le segnalazioni (CVD policy + contatto),
• un triage con un responsabile e criteri definiti,
• un meccanismo per creare e distribuire security updates,
• un modello di comunicazione verso i clienti che non sia improvvisato,
• prontezza per la segnalazione (chi segnala, con quali dati, con quale rapidità).

Tutto questo suona come lavoro “organizzativo”. In pratica è lavoro di prodotto, perché riguarda versioni, compatibilità, architettura degli aggiornamenti e strategia di supporto.

Krok 4: Scegli il support period come una decisione di business, non come un requisito minimo

Se i tuoi prodotti restano in uso nell’industria per 10–15 anni, il support period è una scelta strategica. La CRA impone che il supporto non sia una promessa senza copertura. Questo significa che il support period dovrebbe derivare da un’analisi: per quanto tempo il prodotto verrà utilizzato, com’è strutturata la supply chain dei componenti, per quanto tempo sarai in grado di fornire correzioni. In pratica, il support period inizia a “tirare” tutto l’ecosistema: contratti con i fornitori, disponibilità del build environment, mantenimento delle toolchain e perfino decisioni su funzioni remote o isolamento del prodotto.

Se tratti il support period come una formalità, al più tardi nel 2027 finirai in conflitto: il cliente si aspetta supporto, ma tu non hai più risorse né dipendenze per erogarlo. La CRA non crea questo problema — la CRA lo rende soltanto evidente.

Krok 5: Metti in ordine la supply chain: parlare con i fornitori è parte della conformità

Nella CRA non c’è alcuna “magia” che renda sicuri i componenti esterni. Se il tuo dispositivo si basa su librerie, moduli di comunicazione, sistema operativo, SDK o componenti hardware, il tuo rischio dipende direttamente dalla qualità delle pratiche del fornitore.

Per questo vale la pena, già da ora, di avviare una conversazione su aspetti che non suonano come marketing, ma come ingegneria:

• se il fornitore è in grado di comunicare le vulnerabilità in modo prevedibile,
• quali sono i suoi tempi di reazione,
• se ha un processo di pubblicazione delle correzioni,
• se è in grado di mantenere il componente per un periodo coerente con il tuo support period.

È qui che la CRA tocca davvero il business: un fornitore che non sa gestire le vulnerabilità non è “più economico”. È un rischio regolatorio.

Krok 6: Costruisci la documentazione come una traccia coerente: legge → rischio → decisione → evidenza

Negli audit di conformità vince sempre la coerenza. Se dalla valutazione del rischio risulta che una certa interfaccia è critica e la documentazione non descrive come la proteggi; se dichiari che gli aggiornamenti sono sicuri ma non sai mostrare come garantisci l’integrità dei pacchetti; se dici di avere un processo di gestione delle vulnerabilità ma non sai mostrare come fai il triage delle segnalazioni — non è “mancanza di carta”. È mancanza di evidenza che il processo funzioni.

Nella CRA, in assenza di norme armonizzate, questa traccia è particolarmente importante. Perché sarà la base del confronto con l’autorità di vigilanza del mercato, con il cliente enterprise e, in alcune categorie di prodotti, anche con l’organismo di valutazione della conformità. E, cosa altrettanto importante, sarà la base della stabilità interna. Il team sa perché facciamo qualcosa, non solo “che dobbiamo farlo”.

Conclusione: la CRA come nuovo requisito di progettazione, non come “progetto di compliance”

Se dovessi lasciare un solo pensiero che tenga insieme le tre parti: la CRA non è un problema da risolvere alla fine. È un quadro che cambia il modo di pensare al prodotto. Così come ISO 12100 insegna che il rischio nasce nella relazione uomo–macchina, la CRA insegna che la cybersicurezza nasce nella relazione prodotto–ambiente–ciclo di vita del produttore.

Le norme armonizzate arriveranno e semplificheranno alcuni percorsi. Ma la loro assenza non è un motivo per restare fermi. È un motivo per concentrarsi su ciò che la CRA valuta sempre: decisioni, evidenze e capacità di agire nella realtà — non in una presentazione.