Le linee guida sul Cyber Resilience Act: dieci esempi per una PMI
Il 27 luglio 2026 la Commissione europea ha pubblicato le linee guida per l'applicazione del Cyber Resilience Act (CRA): oltre 80 pagine e 67 esempi che dicono come la Commissione legge i punti più discussi del regolamento. Non cambiano il testo e non sono vincolanti, ma sono il documento a cui le autorità di vigilanza faranno riferimento. Qui trovi i dieci esempi che contano per una PMI che fabbrica prodotti con software, e che cosa comportano nei fatti.
In sintesi
L'articolo 26 del regolamento obbliga la Commissione a pubblicare linee guida con particolare attenzione alle microimprese e alle PMI. Il documento (comunicazione C(2026) 5252) arriva dopo una bozza di marzo e una consultazione pubblica chiusa il 13 aprile 2026. Otto capitoli: che cosa è messo sul mercato, il software libero e open source, le modifiche sostanziali e i ricambi, il periodo di assistenza, i prodotti importanti e critici, la valutazione del rischio, l'elaborazione remota dei dati, le segnalazioni e la gestione delle vulnerabilità.
Tre avvertenze. Gli esempi non sostituiscono la valutazione caso per caso; l'interpretazione autorevole spetta solo alla Corte di giustizia; e il 27 luglio la Commissione ha approvato il contenuto, mentre l'adozione formale avverrà quando saranno pronte tutte le versioni linguistiche. Il testo è quello definitivo, ma oggi esiste solo in inglese.
I dieci esempi
La numerazione è quella del documento. Per ciascuno: la situazione, la risposta della Commissione e che cosa comporta per chi fabbrica.
1. L'app del dispositivo fa parte del prodotto (esempi 8 e 9)
Una stampante di rete con i driver scaricabili dal sito; un braccialetto fitness con l'app che mostra i dati e lo configura. Hardware e software formano un solo prodotto, anche se l'app arriva da un altro canale, perché senza di essa il prodotto non svolge le sue funzioni. Per te: l'app del tuo dispositivo entra nella SBOM (Software Bill of Materials, la distinta base del software), nella valutazione del rischio e nel periodo di assistenza.
2. Il portale web non è un prodotto, il gestionale installato sì (esempi 5 e 6)
Un'applicazione usata solo dal browser non è un prodotto con elementi digitali; un sito che presenta informazioni nemmeno. Un programma installato sul computer o sul server del cliente lo è, e se dipende da un'elaborazione a distanza progettata dal fabbricante, anche quella parte rientra nel prodotto. Per te: il discrimine è dove gira il codice. Il gestionale venduto come installazione è nel CRA; la versione solo web resta fuori, salvo che serva a far funzionare un prodotto.
3. Il catalogo esistente non va riprogettato (esempio 12)
Un microcontrollore progettato prima del CRA continua a essere venduto dopo l'11 dicembre 2027. La Commissione non chiede di riprogettarlo: chiede una valutazione del rischio attuale che dimostri che le misure esistenti sono sufficienti, la documentazione tecnica, la marcatura CE e il processo di gestione delle vulnerabilità. Non serve ricostruire i test della progettazione originale. Per te: i prodotti a catalogo non sono esenti, ma il lavoro è di valutazione e documentazione. Le unità vendute prima di quella data restano soggette solo alle segnalazioni dell'articolo 14 (punto 210).
4. La libreria open source è responsabilità di chi la integra (esempi 27 e 34)
Uno sviluppatore pubblica una libreria gratuita con un collegamento per le donazioni; tre aziende la integrano nei loro prodotti. Lo sviluppatore non ha obblighi; le aziende devono esercitare la dovuta diligenza sul componente (articolo 13, paragrafo 5). Per te: il componente gratuito non è «di nessuno» ai fini del regolamento: è tuo. Serve sapere quale versione hai, se è mantenuta, quali vulnerabilità ha, e conservare le evidenze della verifica.
5. Il ricambio identico è esente, quello diverso è un prodotto nuovo (esempi 36 e 37)
Un modulo di comunicazione sostituito con uno identico, fornito come ricambio, non è soggetto al CRA. Un chip sostitutivo con cifratura e avvio sicuro diversi dall'originale sì, perché sono cambiate caratteristiche che toccano la sicurezza. Per te: il post-vendita entra nel perimetro. Se il fornitore cambia un componente, verifica che cosa è cambiato e conserva la prova che lo hai fornito come ricambio per un prodotto identificato.
6. Una funzione piccola può essere una modifica sostanziale, un aggiornamento di sicurezza no (esempi 44 e 46)
Il «ricordami» aggiunto al login memorizza credenziali sul dispositivo: rischi nuovi, non valutati, quindi modifica sostanziale. La correzione di una vulnerabilità che non cambia la destinazione d'uso non lo è, anche se tecnicamente profonda. Il documento dà quattro domande per ogni aggiornamento (punto 110): introduce nuove vie di attacco, abilita nuovi scenari, cambia la probabilità o l'impatto di quelli già valutati? Per te: ogni rilascio ha bisogno di una valutazione documentata, anche di poche righe. Non conta la dimensione della modifica, conta l'effetto sul rischio.
7. Con versioni frequenti si può correggere solo l'ultima (esempio 53)
Un software esce in versioni nuove ogni pochi mesi, ciascuna con il suo periodo di assistenza. Il fabbricante può smettere di correggere le versioni precedenti se il passaggio all'ultima è gratuito e non impone costi aggiuntivi, come nuovo hardware (articolo 13, paragrafo 10). Il minimo di cinque anni non è un valore predefinito: il periodo va stabilito sulla durata d'uso prevista. Per te: dichiara il periodo di assistenza, almeno mese e anno, al momento della vendita; se il tuo modello è «aggiorna sempre», rendilo esplicito e gratuito.
8. La classe del prodotto dipende dalla funzionalità principale (esempi 58 e 61)
Uno smartphone contiene un sistema operativo, che è un prodotto importante; lo smartphone non lo diventa per questo. Una suite di sicurezza venduta a moduli separati, invece, va classificata modulo per modulo. Per te: confronta gli Allegati III e IV con la funzionalità principale del tuo prodotto, non con i componenti che integra. Un prodotto ha una sola funzionalità principale, e la descrizione commerciale deve coincidere con la documentazione tecnica.
9. Il cloud che fa funzionare il prodotto è parte del prodotto (casi del termostato e del robot)
Un termostato e un robot industriale dipendono da un servizio remoto sviluppato dal fabbricante e ospitato su un'infrastruttura di terzi. Quel software è una «soluzione di elaborazione remota dei dati» e rientra nel prodotto; l'infrastruttura no, ma va valutata come un componente, chiedendo per esempio le evidenze degli obblighi NIS2 del fornitore. Un servizio di terzi pronto all'uso (SaaS) resta fuori dal prodotto, ma va trattato come un componente. Per te: se il tuo prodotto ha un back-end, quel codice è nel perimetro, con la sua SBOM e le sue vulnerabilità.
10. Una vulnerabilità nel componente non è sempre da segnalare (punti 213 e 218)
Il fabbricante «viene a conoscenza» quando, dopo una prima verifica immediata, ha un ragionevole grado di certezza che la vulnerabilità è sfruttata nel suo prodotto. Se il componente è vulnerabile ma nel prodotto il codice non è raggiungibile, o nessuno lo sfrutta lì, la segnalazione in 24 ore non è dovuta: restano la gestione della vulnerabilità e la comunicazione a chi mantiene il componente. Per te: è la logica del caso PHP2Shell. Serve una verifica rapida, prodotto per prodotto, e una decisione documentata anche quando l'esito è «non ci riguarda».
Tre punti oltre gli esempi
- Il costo non giustifica un rischio non trattato. Tolleranza interna, strategia commerciale e considerazioni di costo non contano per decidere se un rischio è stato affrontato, e il rischio non si trasferisce agli utenti (punti 158 e 161).
- Una vulnerabilità è «nota» quando è nelle banche dati pubbliche, come la banca dati europea delle vulnerabilità, o quando è stata segnalata in via riservata o riportata dalla stampa specializzata (punti 233 e 234). Il prodotto va messo sul mercato senza vulnerabilità sfruttabili note.
- Prove e riesami «regolari» non significa ripetere gli stessi test a scadenze fisse: significa riesaminarli quando emergono nuove minacce o nuove vulnerabilità, ed eseguirli di conseguenza (punto 238).
Che cosa resta aperto
La Commissione annuncia possibili documenti successivi, a cominciare dai rapporti con il regolamento sull'intelligenza artificiale e con il DORA. Le linee guida non dicono quali licenze contano come open source, non parlano del formato della SBOM e non sostituiscono le norme armonizzate in preparazione. La versione italiana non c'è ancora, e con essa l'adozione formale. Per una PMI il senso pratico non cambia: i dieci esempi descrivono il metodo che l'autorità si aspetta di trovare.
Che cosa fa Assiduo con le linee guida
Tre punti del documento descrivono il lavoro quotidiano del Presidio Continuo. La dovuta diligenza sui componenti (esempio 4) parte dalla SBOM di ogni prodotto, che Assiduo confronta ogni giorno con le banche dati delle vulnerabilità e gli avvisi dei fornitori. Il riesame regolare (punto 238) è quel confronto: ogni vulnerabilità nuova è un input da valutare. La decisione sulla segnalazione (esempio 10) resta alle persone: il team Algor valuta l'esposizione con il cliente, apre un caso con responsabile e scadenza e documenta l'esito, compreso «non applicabile». Assiduo prepara, le persone decidono.
Domande frequenti
Le linee guida sono obbligatorie?
No. Il documento lo dice al punto 8: non vincola gli operatori economici e l'interpretazione autorevole spetta alla Corte di giustizia. Esprime però l'interpretazione della Commissione, scritta anche per le autorità di vigilanza e gli organismi notificati. Discostarsene è possibile, ma va motivato.
Esiste la versione italiana?
Al 26 ottobre 2026 sul sito della Commissione ci sono solo la comunicazione e l'allegato in inglese. L'adozione formale, dalla quale il documento «si applica», avverrà quando saranno pronte tutte le versioni linguistiche. Il contenuto è approvato ed è quello su cui lavorare.
Vale anche per i prodotti già in vendita?
In parte. Le segnalazioni dell'articolo 14 si applicano dall'11 settembre 2026 a tutti i prodotti in ambito, anche a quelli messi sul mercato prima dell'11 dicembre 2027 e a quelli non più assistiti. La gestione delle vulnerabilità dell'Allegato I, Parte II, non si applica ai prodotti messi sul mercato prima di quella data, salvo modifica sostanziale successiva (punto 210 e articolo 69).
Da dove cominciare
Dall'esempio 4: l'elenco dei componenti di ogni prodotto, con le versioni. Senza quello nessuno degli altri nove ha una risposta documentabile. Il configuratore ti dice in pochi minuti quanto costa un presidio continuo sul tuo perimetro.
Fonti: Commissione europea, comunicazione C(2026) 5252 del 27 luglio 2026 e allegato «Commission guidance on the application of the Cyber Resilience Act» (punti, esempi e casi d'uso citati nel testo); pagina della Commissione «Commission publishes new guidance to support timely Cyber Resilience Act implementation», 27 luglio 2026; regolamento (UE) 2024/2847, articoli 2, 3, 13, 14, 26 e 69; regolamento di esecuzione (UE) 2025/2392. Consultate il 26 ottobre 2026. Leggi anche: a chi si applica il CRA, vulnerabilità attivamente sfruttata, il caso PHP2Shell.