Sommario
Dall’11 settembre 2026 sono applicabili gli obblighi di segnalazione
previsti dall’articolo 14 del Cyber Resilience Act. La disciplina non
riguarda genericamente tutte le imprese che subiscono un attacco
informatico: si concentra sui fabbricanti di prodotti con elementi
digitali e impone di comunicare vulnerabilità attivamente sfruttate e
incidenti gravi. Per rispettare termini molto brevi occorrono
responsabilità e procedure definite prima dell’evento.
Che cos’è il Cyber Resilience
Act
Il Regolamento UE 2024/2847, noto come Cyber Resilience Act o CRA,
introduce requisiti orizzontali di cybersicurezza per i prodotti con
elementi digitali immessi sul mercato dell’Unione. Il concetto comprende
prodotti hardware e software e, in determinati casi, le soluzioni di
trattamento remoto dei dati necessarie al loro funzionamento.
L’obiettivo è accompagnare il prodotto lungo il suo ciclo di vita:
progettazione sicura, gestione delle vulnerabilità, aggiornamenti,
informazioni agli utilizzatori e cooperazione con le autorità.
Il regolamento è entrato in vigore il 10 dicembre 2024 e sarà
pienamente applicabile dall’11 dicembre 2027. Alcune disposizioni
operano prima. Tra queste, dall’11 settembre 2026, figurano gli obblighi
di segnalazione dell’articolo 14.
Chi deve prestare attenzione
Il soggetto centrale è il fabbricante, cioè chi sviluppa o fa
progettare e commercializza con il proprio nome o marchio un prodotto
con elementi digitali. La qualificazione non dipende soltanto da chi
materialmente scrive il codice. Un’impresa che integra componenti,
appone il proprio marchio o modifica sostanzialmente un prodotto può
assumere responsabilità proprie.
Importatori e distributori hanno obblighi distinti di verifica e
cooperazione. Devono quindi conoscere la filiera, identificare il
fabbricante e sapere come trasmettere rapidamente informazioni su
vulnerabilità e incidenti.
Non ogni software è automaticamente incluso. Il regolamento contiene
esclusioni e regole particolari, ad esempio per alcune categorie già
disciplinate da normative settoriali e per specifiche forme di software
libero e open source. La prima attività consiste quindi nel censire i
prodotti e motivarne la classificazione.
Vulnerabilità
attivamente sfruttata e incidente grave
L’articolo 14 distingue due eventi.
La vulnerabilità attivamente sfruttata è una debolezza rispetto alla
quale esistono prove affidabili che un soggetto malevolo l’abbia
utilizzata in un sistema senza autorizzazione. Non basta, quindi, una
vulnerabilità teorica o segnalata in astratto: occorre valutarne lo
sfruttamento effettivo secondo le definizioni del regolamento.
L’incidente grave che incide sulla sicurezza di un prodotto con
elementi digitali riguarda invece un evento capace di compromettere la
capacità del prodotto di proteggere disponibilità, autenticità,
integrità o riservatezza di dati o funzioni e che abbia prodotto, o
possa produrre, effetti rilevanti secondo i criteri normativi.
La distinzione è importante perché determina il percorso di notifica
e le informazioni da raccogliere. Nella pratica, però, la fase iniziale
può essere incerta: per questo l’impresa deve prevedere un meccanismo di
escalation che consenta di segnalare tempestivamente anche quando
l’analisi tecnica è ancora in corso.
Termini molto
brevi e informazioni progressive
Il sistema è costruito su comunicazioni progressive. La prima
segnalazione deve essere effettuata senza ingiustificato ritardo e, in
ogni caso, entro termini che possono partire dalle prime 24 ore dalla
conoscenza dell’evento. Seguono comunicazioni più dettagliate,
normalmente entro 72 ore, e una relazione finale nei tempi previsti per
la specifica fattispecie.
L’impresa non può attendere di avere ricostruito ogni dettaglio. Deve
essere in grado di comunicare ciò che sa, indicare la natura dell’evento
e aggiornare le informazioni successivamente.
Dal settembre 2026 le notifiche vengono convogliate tramite la Single
Reporting Platform predisposta da ENISA. Il sistema mira a consentire
una comunicazione unica e a indirizzare le informazioni al CSIRT
competente e alle altre autorità coinvolte.
Che cosa
deve fare l’organizzazione prima di un evento
I termini dell’articolo 14 rendono insufficiente una gestione
improvvisata. Occorre predisporre almeno:
- un inventario dei prodotti con elementi digitali e delle relative
versioni; - criteri per distinguere vulnerabilità, sfruttamento attivo e
incidente grave; - canali interni attraverso i quali sviluppatori, assistenza e
fornitori possano segnalare anomalie; - un gruppo responsabile della valutazione tecnica e giuridica;
- credenziali, deleghe e sostituzioni per l’utilizzo della piattaforma
ENISA; - modelli di comunicazione e registri delle decisioni;
- procedure per informare, quando necessario, utilizzatori e
clienti; - coordinamento con le procedure di gestione degli incidenti e
continuità operativa.
I contratti con sviluppatori e fornitori sono decisivi. Se il
soggetto che rileva la vulnerabilità non ha l’obbligo di avvisare
tempestivamente il fabbricante, le prime ore possono essere perse prima
ancora che inizi la valutazione.
Il rapporto con la NIS2
CRA e NIS2 appartengono alla strategia europea di cybersicurezza, ma
hanno oggetto e destinatari differenti. La NIS2 disciplina la gestione
del rischio e la segnalazione degli incidenti per soggetti essenziali e
importanti appartenenti ai settori individuati. Il CRA riguarda la
sicurezza dei prodotti con elementi digitali e si concentra soprattutto
sulla filiera del prodotto.
La stessa impresa può ricadere in entrambi i regimi. Un incidente può
quindi attivare più obblighi, con destinatari, presupposti e termini non
coincidenti. La soluzione non è creare procedure isolate, ma una matrice
che identifichi quale normativa si applica, chi decide e quali
informazioni possono essere riutilizzate senza confondere i diversi
adempimenti.
Anche il GDPR può entrare in gioco se l’evento comporta una
violazione di dati personali. In quel caso la valutazione del data
breach deve procedere in parallelo.
Dal team tecnico agli
organi direttivi
La segnalazione nasce spesso da un dato tecnico, ma la responsabilità
organizzativa non può essere lasciata esclusivamente all’IT. Bisogna
decidere la qualificazione del prodotto, valutare gli impatti,
comunicare con autorità e clienti e documentare le scelte.
Gli organi direttivi devono assicurare risorse, ruoli e flussi
informativi adeguati. Una procedura efficace stabilisce chi riceve
l’allerta anche di notte o durante le festività, chi può autorizzare la
comunicazione e chi verifica l’attuazione delle misure correttive.
Domande frequenti
Ogni vulnerabilità
deve essere notificata
No. L’obbligo anticipato riguarda in particolare le vulnerabilità
attivamente sfruttate secondo le condizioni del regolamento. Le altre
vulnerabilità restano comunque soggette agli obblighi di gestione e
trattamento previsti dal CRA.
Il
CRA si applica soltanto alle grandi imprese tecnologiche
No. Può interessare anche PMI che sviluppano o commercializzano con
il proprio marchio hardware, software o componenti digitali. Dimensione
e ruolo nella filiera devono essere valutati caso per caso.
Una segnalazione
NIS2 sostituisce quella CRA
Non automaticamente. I due regimi hanno ambiti e procedure
differenti. Occorre verificare se l’evento attivi entrambi e coordinare
le comunicazioni.
Conclusioni
L’11 settembre 2026 non segna la piena applicazione di tutto il Cyber
Resilience Act, ma rende già operativo uno dei suoi meccanismi più
delicati. Fabbricanti e operatori della filiera possono verificare
l’applicabilità del regolamento e predisporre una procedura interna di
escalation e segnalazione. La capacità di reagire entro poche ore si
costruisce prima dell’incidente, non dopo.
Collegamento interno
principale
Fonti
- Regolamento UE 2024/2847, Cyber Resilience Act, in particolare
articolo 14 e disposizioni transitorie. - Commissione europea, sintesi del Cyber Resilience Act.
- ENISA, Single Reporting Platform per le segnalazioni CRA.
