Cyber Resilience Act: le scadenze del 2026 e del 2027

Il regolamento sui prodotti con elementi digitali è in vigore dal 10 dicembre 2024: obblighi di segnalazione dall'11 settembre 2026, obblighi principali dall'11 dicembre 2027.

— Studio LX20 Law Firm

Un regolamento che tocca chi "fa" software, non solo chi lo usa.

Per anni la disciplina europea della cybersicurezza è stata letta dagli operatori finanziari come un tema di sicurezza organizzativa: misure di governo del rischio informatico, continuità operativa, gestione degli incidenti. Il Cyber Resilience Act sposta l'asse. Non regola in primo luogo l'utilizzatore, ma il prodotto: hardware e software immessi sul mercato europeo.

La Commissione lo descrive in termini espliciti: «The Cyber Resilience Act (CRA) aims to safeguard consumers and businesses buying software or hardware products with digital elements». L'oggetto della tutela sono quindi i consumatori e le imprese che acquistano prodotti con elementi digitali; il destinatario degli obblighi è chi quei prodotti li progetta, li sviluppa e li mantiene.

Per un istituto bancario o una società fintech questa distinzione non è accademica. Un gruppo che sviluppa un'applicazione di pagamento, un modulo di onboarding, un dispositivo di autenticazione, e lo fornisce a terzi nel corso della propria attività, non si trova necessariamente nel ruolo dell'utilizzatore finale. Può trovarsi in quello del fabbricante. Prima di chiedersi quali obblighi gravino su quel ruolo, però, conviene chiedersi se il regolamento si applichi affatto.

Il perimetro, prima del merito.

La norma sull'ambito di applicazione è l'art. 2 del Regolamento (UE) 2024/2847, e va letta insieme alle definizioni dell'art. 3. Tre filtri decidono quasi tutto.

Il primo è l'immissione sul mercato. Il regolamento si applica ai prodotti con elementi digitali «messi a disposizione sul mercato» la cui finalità prevista o il cui utilizzo ragionevolmente prevedibile include una connessione dati logica o fisica, diretta o indiretta, a un dispositivo o a una rete (art. 2, par. 1). E la messa a disposizione sul mercato è, ai sensi dell'art. 3, punto 22), la fornitura, a titolo oneroso o gratuito, di un prodotto «perché sia distribuito o usato sul mercato dell'Unione nel corso di un'attività commerciale». Un applicativo sviluppato e utilizzato soltanto all'interno del gruppo non è, per ciò solo, messo a disposizione sul mercato: lo sviluppo interno non è il fatto generatore, lo è la fornitura a terzi nell'esercizio di un'attività commerciale.

Il secondo filtro è il più rilevante per chi eroga in modalità as a service. Le soluzioni di elaborazione dati da remoto rientrano nella definizione di prodotto con elementi digitali soltanto quando il software è stato progettato e sviluppato dal fabbricante o sotto la sua responsabilità e la sua assenza impedirebbe al prodotto di svolgere una delle sue funzioni (art. 3, punti 1 e 2). Il considerando 12 lo esplicita in negativo: i servizi cloud «la cui progettazione e il cui sviluppo esulano dalla responsabilità del fabbricante di un prodotto con elementi digitali non rientrano nell'ambito di applicazione», e ai modelli SaaS, PaaS e IaaS si applica la direttiva (UE) 2022/2555. Per un operatore che distribuisce in prevalenza servizi, e non prodotti, questa è la prima verifica da compiere, non l'ultima.

Il terzo filtro riguarda le esclusioni espresse. L'art. 2 esclude i prodotti soggetti alla disciplina dei dispositivi medici e diagnostici in vitro e dei veicoli a motore (par. 2), quelli certificati ai sensi del Regolamento (UE) 2018/1139 in materia di aviazione civile (par. 3), l'equipaggiamento marittimo (par. 4), i pezzi di ricambio identici (par. 6) e i prodotti sviluppati per scopi di sicurezza nazionale o di difesa (par. 7): nessuna di queste ipotesi intercetta l'attività bancaria o fintech, e sono richiamate qui perché il lettore possa constatare che sono state esaminate. Va invece tenuto d'occhio l'art. 2, par. 5, che consente di limitare o escludere l'applicazione del regolamento, con atto delegato, ai prodotti già coperti da altre norme dell'Unione che affrontino gli stessi rischi con un livello di protezione pari o superiore. È il meccanismo di uscita che interessa i soggetti già destinatari di una disciplina settoriale di sicurezza.

Il calendario: quattro date, due delle quali già decorse

Il punto operativamente più rilevante è la scansione temporale, che l'art. 71 fissa in questi termini:

10 dicembre 2024: entrata in vigore del regolamento, ventesimo giorno successivo alla pubblicazione in Gazzetta ufficiale; 11 giugno 2026: applicazione del capo IV, articoli da 35 a 51, sulla notifica degli organismi di valutazione della conformità; 11 settembre 2026: applicazione dell'art. 14, obblighi di segnalazione dei fabbricanti; 11 dicembre 2027: applicazione del regolamento in via generale.

Le prime due scadenze sostanziali sono maturate. Gli obblighi di segnalazione sono in vigore: la Commissione li descrive come «already applying as of 11 September 2026». La decorrenza dell'11 giugno 2026 è quella che ha aperto la designazione degli organismi notificati, e va letta insieme ai tempi di un procedimento di certificazione, che non sono comprimibili a piacere.

Non si tratta, peraltro, di una gradualità che protegga il parco prodotti esistente. L'art. 69, par. 2, limita i requisiti sostanziali ai prodotti immessi sul mercato prima dell'11 dicembre 2027 solo se, da quella data, siano oggetto di una modifica sostanziale; ma il par. 3 deroga espressamente: gli obblighi di segnalazione dell'art. 14 «si applicano a tutti i prodotti con elementi digitali che rientrano nell'ambito di applicazione del presente regolamento e che sono stati immessi sul mercato prima dell'11 dicembre 2027». La segnalazione, quindi, riguarda oggi anche ciò che è già installato presso i clienti.

Che cosa va segnalato, a chi ed entro quando

L'art. 14 individua due fatti generatori, non uno.

Il primo è la vulnerabilità attivamente sfruttata contenuta nel prodotto, di cui il fabbricante venga a conoscenza (par. 1). Il secondo è l'incidente grave che abbia un impatto sulla sicurezza del prodotto (par. 3): è grave, ai sensi del par. 5, l'incidente che incide o è in grado di incidere negativamente sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti, ovvero che ha portato o può portare all'introduzione o all'esecuzione di codice maligno nel prodotto o nei sistemi dell'utilizzatore.

In entrambi i casi la notifica è simultanea al CSIRT designato come coordinatore e all'ENISA, e transita per la piattaforma unica di segnalazione istituita ai sensi dell'art. 16. I termini sono stringenti: preallarme entro 24 ore dalla conoscenza; notifica entro 72 ore; relazione finale entro 14 giorni dalla messa a disposizione di una misura correttiva, per le vulnerabilità, ed entro un mese dalla notifica, per gli incidenti.

Chi ha già costruito procedure di notifica per altri quadri normativi non parte da zero, ma non può nemmeno riutilizzarle senza verifica: il presupposto soggettivo (il fabbricante), l'oggetto (il prodotto con elementi digitali), i fatti generatori e i destinatari sono diversi da quelli delle discipline di sicurezza delle reti e dei servizi finanziari.

Che cosa chiede il regolamento al fabbricante

La Commissione sintetizza il contenuto degli obblighi in modo utile a impostare una gap analysis: «The CRA introduces mandatory cybersecurity requirements for manufacturers, covering the planning, design, development and maintenance of such products. These obligations must be met at every stage of the value chain.»

Due elementi vanno letti con attenzione.

Il primo è l'estensione temporale. Gli obblighi coprono pianificazione, progettazione, sviluppo e manutenzione, e non si esauriscono con l'immissione sul mercato: la gestione delle vulnerabilità accompagna il periodo di assistenza, definito dall'art. 3, punto 20), come il periodo durante il quale il fabbricante garantisce che le vulnerabilità siano gestite conformemente ai requisiti essenziali dell'allegato I, parte II. La determinazione della sua durata è una scelta di prodotto e di contratto, non un adempimento successivo. Per chi commercializza software con rilasci frequenti, il tema è un processo con documentazione, tracciabilità e responsabilità assegnate.

Il secondo è l'estensione soggettiva lungo la catena del valore: gli obblighi «must be met at every stage of the value chain». Chi integra componenti di terzi in un proprio prodotto non può considerare la questione delegata al fornitore a monte. Sul piano contrattuale, questo suggerisce una revisione delle clausole di fornitura software: livelli di servizio sulla gestione delle vulnerabilità, obblighi informativi reciproci, durata del supporto, diritti di verifica.

Valutazione di conformità e marcatura CE

Il regolamento adotta l'impianto tipico della legislazione europea di prodotto. La Commissione indica che «Products will bear the CE marking to indicate that they comply with the CRA requirements and national market surveillance authorities will ensure enforcement of the rules».

Il regime ordinario, ai sensi dell'art. 32, par. 1, è la procedura di controllo interno basata sul modulo A dell'allegato VIII: la valutazione resta interna al fabbricante. Il coinvolgimento di un organismo notificato dipende dalla classe del prodotto. Per i prodotti importanti rientranti nella classe I dell'allegato III, l'esame UE del tipo o la garanzia della qualità totale sono richiesti soltanto se il fabbricante non ha applicato, o ha applicato solo in parte, norme armonizzate, specifiche comuni o sistemi europei di certificazione — ovvero se questi non esistono (art. 32, par. 2). È una condizione che oggi, in assenza di norme armonizzate consolidate, va verificata prodotto per prodotto e che può spostare l'esito. Per i prodotti importanti di classe II la procedura con organismo terzo è sempre necessaria (art. 32, par. 3). Per i prodotti critici, l'art. 8 consente di imporre con atto delegato una certificazione europea di cibersicurezza.

La verifica da parte di un organismo notificato, dove richiesta, si colloca prima dell'immissione sul mercato. È un vincolo che va inserito nella pianificazione dei rilasci, non gestito a valle.

Il rapporto con le altre discipline

Un punto da non sottovalutare nel disegno della compliance interna: il regolamento non sostituisce le altre normative in materia. La Commissione precisa che il CRA «complements other legislation in this area, specifically the NIS2 Directive» e si inserisce nel solco della strategia dell'Unione per la cibersicurezza del 2020 e della strategia dell'Unione della sicurezza.

Per gli operatori finanziari, però, la sovrapposizione che conta non è soltanto quella con la direttiva NIS2. Il Regolamento (UE) 2022/2554 (DORA) non è oggetto di alcuna esclusione nell'art. 2 del CRA, e il considerando 125 indica anzi che il CRA «faciliterà il rispetto degli obblighi di sicurezza della catena di approvvigionamento» da parte dei soggetti che rientrano in DORA e in NIS2 e utilizzano prodotti con elementi digitali. Il considerando 72 colloca DORA tra le discipline che pongono obblighi di segnalazione complementari, e incoraggia gli Stati membri a valutare punti di accesso unici nazionali proprio per ridurre l'onere di notifiche parallele.

Complementarità significa sovrapposizione parziale, non alternatività. Lo stesso gruppo può essere destinatario di obblighi organizzativi in quanto entità finanziaria, di obblighi di segnalazione in quanto tale, e di obblighi di prodotto e di notifica in quanto fabbricante, con soglie, termini e destinatari che non coincidono. La mappatura dei perimetri — quali società del gruppo, quali prodotti, quali servizi, quali processi — è un'attività preliminare, non una conseguenza.

Piccole e medie imprese, software libero, standard

Il quadro prevede alcune direttrici specifiche. L'art. 33 detta misure di sostegno per le microimprese e le piccole e medie imprese. Gli artt. 24 e 25 disegnano un regime proprio per il software libero e open source, distinguendo la figura del gestore di software open source — definita dall'art. 3, punto 14) — da quella del fabbricante e prevedendo un'attestazione di sicurezza volontaria. L'art. 27 àncora infine la presunzione di conformità alle norme armonizzate: la normazione tecnica è lo strumento attraverso cui i requisiti generali diventano specifiche verificabili, ed è quindi il cantiere da monitorare per anticipare le scelte progettuali, tanto più perché da essa dipende, per i prodotti di classe I, la necessità o meno di un organismo notificato.

Documentazione della Commissione

Il 27 luglio 2026 la Commissione ha pubblicato la comunicazione C(2026) 5252 e il relativo allegato, contenenti orientamenti pratici «to help manufacturers, developers, and businesses of all sizes meet their obligations under the Cyber Resilience Act». Gli orientamenti — adottati nella cornice dell'art. 26 del regolamento e dichiaratamente non vincolanti — affrontano, tra l'altro, l'ambito di applicazione con riguardo alle soluzioni di elaborazione dati da remoto e al software libero e open source, la nozione di modifica sostanziale, il periodo di assistenza e le modalità di adempimento degli obblighi di segnalazione. Sono disponibili inoltre il testo legale, una sintesi delle disposizioni e un documento di domande frequenti sull'attuazione. Si tratta di materiale di natura esplicativa: utile per orientare le scelte operative, ma non sostitutivo del testo normativo, che resta l'unico parametro di conformità.

Cosa fare ora

Una sequenza ragionevole, per chi non ha ancora avviato il lavoro:

Perimetro: stabilire, prima di ogni altra cosa, se e per quali offerte il regolamento si applichi — prodotto o servizio, messa a disposizione sul mercato o uso interno, responsabilità di progettazione delle componenti erogate da remoto — e quali entità del gruppo assumano il ruolo di fabbricante ai sensi dell'art. 3, punto 13). Censimento: individuare i prodotti con elementi digitali già immessi sul mercato, compresi quelli rilasciati in passato, dato che gli obblighi di segnalazione li raggiungono ai sensi dell'art. 69, par. 3. Processo di segnalazione: essendo l'obbligo già in vigore, verificare senza attendere la capacità di rilevare, qualificare e notificare entro 24 e 72 ore tanto le vulnerabilità attivamente sfruttate quanto gli incidenti gravi, e la coerenza con i flussi di notifica già esistenti. Classificazione: verificare quali prodotti ricadono nelle classi dell'allegato III e quale procedura di valutazione ne consegue, tenendo conto della disponibilità di norme armonizzate. Periodo di assistenza: determinarlo in sede di progettazione e rifletterlo nella documentazione e nei contratti. Contratti di fornitura: adeguare le clausole con i fornitori di componenti software, in coerenza con l'estensione degli obblighi lungo la catena del valore. Documentazione tecnica: impostare fin dalla progettazione la tracciabilità richiesta per la marcatura CE.

Il 2027 può sembrare lontano. Non lo è per chi deve rivedere l'architettura di un prodotto o negoziare una certificazione — e non lo è affatto per gli obblighi di segnalazione, che non sono una scadenza da preparare ma un adempimento in corso.