Il CRA Riceve il Suo Manuale d'Istruzioni: Cosa Significa per Lei la Guida della Commissione

Il Cyber Resilience Act dispone del suo testo dalla fine del 2024. Quello che mancava era un manuale d'istruzioni. Il 3 marzo 2026, la Commissione europea ha pubblicato esattamente questo: la bozza di Comunicazione Ares(2026)2319816 — circa 70 pagine di guida pratica su come interpretare il regolamento.

Questa è la guida dell'Articolo 26 che il settore attendeva. Ecco cosa dice e cosa significa per Lei.

Introduzione

La bozza di Comunicazione Ares(2026)2319816, datata 3 marzo 2026, è il primo documento di orientamento completo della Commissione europea sul Cyber Resilience Act. Con circa 70 pagine, affronta le domande che hanno tenuto svegli di notte i team di conformità: Cosa si intende per "elaborazione dati da remoto"? I prodotti legacy necessitano di una riprogettazione completa? Quando un aggiornamento software diventa un nuovo prodotto?

Questo articolo distilla le nove decisioni più rilevanti in orientamenti pratici per produttori, importatori e distributori di prodotti con elementi digitali.

1. SaaS e Cloud: il Test RDPS

La Commissione introduce un rigoroso test a tre domande per determinare se un componente cloud o SaaS si qualifica come "soluzioni di elaborazione dati da remoto" (RDPS) e rientra quindi nell'ambito della valutazione di conformità del prodotto.

flowchart TD
    A["La soluzione elabora dati
'a distanza'?"] -->|No| B["Non è RDPS"]
    A -->|Sì| C["Il prodotto perderebbe una funzione
essenziale senza questa soluzione?"]
    C -->|No| D["Non è RDPS
(trattare come componente,
applicare la dovuta diligenza ex Art. 13(5))"]
    C -->|Sì| E["Progettata dal produttore o sotto
la sua responsabilità?"]
    E -->|No| F["Non è RDPS
(SaaS di terze parti = componente,
applicare la dovuta diligenza ex Art. 13(5))"]
    E -->|Sì| G["RDPS: rientra nell'ambito della
valutazione di conformità del prodotto"]

La guida illustra questo con cinque scenari concreti: un'app bancaria, un termostato intelligente, un e-Reader, un robot industriale e un dispositivo di rete cellulare.

2. Prodotti Legacy

I prodotti già presenti sul mercato UE prima di dicembre 2027 non devono essere riprogettati da zero. Ma non sono nemmeno esenti.

La Commissione chiarisce tre aspetti:

Nessuna ricostruzione storica richiesta. Non è necessario ricostruire la documentazione di sviluppo di anni fa. Ciò che conta è una valutazione del rischio di cybersecurity aggiornata al giorno d'oggi che dimostri che il prodotto soddisfa i requisiti essenziali in base al suo scopo previsto.

Le famiglie di prodotti possono essere raggruppate. Se più prodotti legacy condividono la stessa architettura e lo stesso profilo di rischio, è possibile effettuare una singola valutazione del rischio che copra l'intera famiglia, anziché valutare ogni singolo SKU.

La conformità piena rimane applicabile. I prodotti legacy necessitano comunque della marcatura CE, di una Dichiarazione di Conformità e di una gestione attiva delle vulnerabilità. L'agevolazione riguarda la documentazione storica, non gli obblighi in sé.

Per una panoramica dettagliata del processo di valutazione di conformità, si veda la nostra Guida alle Decisioni di Valutazione della Conformità. Per la pianificazione del periodo di supporto per i prodotti legacy, si veda Pianificazione del Periodo di Supporto.

3. Software e le "Copie Infinite"

Quando si considera il software "immesso sul mercato"? La Commissione conferma: una sola volta. La distribuzione digitale iniziale costituisce l'immissione sul mercato. I successivi aggiornamenti minori (ad esempio, da v1.0.0 a v1.0.1) non azzerano il calendario normativo.

Questo si applica specificamente al software standalone distribuito digitalmente. I prodotti hardware con software incorporato seguono le regole standard di immissione sul mercato per i beni fisici.

4. Quando gli Aggiornamenti Diventano "Modifiche Sostanziali"

Questa sezione è la parte più operativa dell'intera guida. La Commissione fornisce esempi concreti per distinguere gli aggiornamenti di routine dalle modifiche che richiedono una nuova valutazione di conformità.

La Commissione suggerisce quattro domande che ogni produttore dovrebbe porsi prima di rilasciare un aggiornamento:

1. L'aggiornamento introduce nuovi vettori di minaccia?
2. Consente nuovi scenari di attacco?
3. Modifica la probabilità degli scenari di attacco esistenti?
4. Modifica l'impatto degli scenari di attacco esistenti?

Se la risposta a una qualsiasi di queste domande è affermativa, l'aggiornamento costituisce probabilmente una modifica sostanziale che richiede una nuova valutazione di conformità.

Per ulteriori informazioni sulla classificazione dei prodotti e sulla sua interazione con le modifiche, si veda la nostra Guida alla Classificazione dei Prodotti.

5. Norme Open Source

La guida fornisce diversi importanti chiarimenti su come il CRA si applica al software open source:

• La pubblicazione del codice sorgente in repository pubblici non costituisce "immissione sul mercato". Il CRA si applica al momento della distribuzione commerciale, non al momento della disponibilità del codice.
• Edizione community vs. edizione a pagamento = prodotti diversi. Se si offre una versione community gratuita e una versione commerciale a pagamento, solo la versione a pagamento comporta obblighi per il produttore.
• Le donazioni da sole non rendono il FOSS commerciale — a meno che l'accesso al software non sia condizionato alla donazione. Le donazioni volontarie sono esplicitamente escluse.
• Gli enti no-profit il cui avanzo è destinato interamente a obiettivi no-profit sono esenti dagli obblighi del produttore, anche se monetizzano.
• I contributori privi di controllo su release, roadmap o governance NON sono considerati produttori — anche se dispongono di accesso in commit. La responsabilità spetta a chi controlla il processo di rilascio.
• Gli obblighi degli steward open source sono proporzionati al livello di supporto fornito. La gestione non tecnica comporta obblighi più leggeri rispetto al supporto commerciale completo.

Per ulteriori indicazioni sulla divulgazione coordinata delle vulnerabilità in contesti open source, si veda il nostro Modello di Policy CVD.

6. Periodo di Supporto: Cinque Anni Sono un Minimo

La Commissione chiarisce che il periodo di supporto predefinito di cinque anni è un minimo, non un obiettivo. I prodotti che si prevede rimangano in uso per più di cinque anni devono avere periodi di supporto proporzionalmente più lunghi.

La guida chiarisce inoltre il percorso previsto dall'Articolo 13(10): i produttori possono smettere di applicare patch alle versioni precedenti se gli utenti possono eseguire l'upgrade gratuitamente a una versione supportata. "Costi aggiuntivi" in questo contesto significa acquisti hardware obbligatori — i normali sforzi di test, riconfigurazione o distribuzione a carico dell'utente non sono considerati tali.

Per strategie di pianificazione dettagliate, si veda la nostra Guida alla Pianificazione del Periodo di Supporto.

7. Valutazione del Rischio: La Propensione al Rischio Interna è Irrilevante

La Commissione è inequivocabile: le valutazioni del rischio ai sensi del CRA devono basarsi su criteri di cybersecurity oggettivi, non sulla propensione al rischio interna del produttore. Nello specifico:

• La strategia commerciale e le considerazioni sui costi non rientrano nella valutazione del rischio di cybersecurity.
• Non è possibile trasferire il rischio di cybersecurity agli utenti tramite documentazione, esclusioni di responsabilità o condizioni di servizio.
• Se i rischi identificati non possono essere affrontati con misure tecniche od organizzative, il prodotto potrebbe richiedere modifiche progettuali prima di poter essere immesso sul mercato.

Si tratta di una dichiarazione significativa. Significa che un produttore non può consapevolmente commercializzare un prodotto con rischi di cybersecurity non mitigati semplicemente perché l'azienda ha "accettato" tale rischio.

Per una panoramica delle implicazioni in termini di costi di conformità, si veda la nostra Guida alla Stima dei Costi di Conformità.

8. Vulnerabilità Sfruttabili Note

La guida chiarisce cosa significa "nota" nel contesto del requisito del CRA di commercializzare prodotti privi di vulnerabilità sfruttabili note:

• Elencate in database pubblici: EU Vulnerability Database, CVE/MITRE, NVD.
• Divulgate tramite canali non pubblici: programmi di divulgazione coordinata delle vulnerabilità, test di sicurezza interni, penetration test di terze parti.
• Ampiamente riportate da fonti mediatiche affidabili: una vulnerabilità grave coperta da pubblicazioni mainstream di cybersecurity si qualifica come "nota".

I produttori dispongono di un periodo di indagine limitato per confermare se una vulnerabilità segnalata si applica effettivamente al loro prodotto. Ma "indagine" non è una scappatoia — il conto alla rovescia parte dalla consapevolezza, e i ritardi saranno esaminati attentamente.

Per una guida pratica sulla documentazione delle vulnerabilità, si veda la nostra Guida VEX.

9. Obblighi di Segnalazione (Settembre 2026)

Gli obblighi di segnalazione di settembre 2026 sono la prima scadenza del CRA con effettivi strumenti di applicazione. La guida conferma la struttura delle tempistiche:

• 24 ore: Allerta precoce a ENISA dopo aver acquisito consapevolezza dello sfruttamento attivo
• 72 ore: Notifica dettagliata con indicatori tecnici
• 14 giorni: Report finale per le vulnerabilità / 30 giorni per gli incidenti

"Consapevole" significa ragionevole certezza dopo una valutazione iniziale — non una conferma forense completa. Se si dispone di prove credibili di sfruttamento attivo, il conto alla rovescia è già partito.

Sulla notifica agli utenti: la Commissione conferma che questa dovrebbe essere basata sul rischio e proporzionata. Non esiste un obbligo di divulgazione pubblica obbligatoria se la divulgazione aumenterebbe il rischio per la sicurezza.

Per una panoramica completa del processo di segnalazione, si veda la nostra Guida alla Segnalazione ENISA in 24 Ore. Per la cronologia completa della conformità, si veda la nostra Cronologia di Implementazione.

Cosa Significa per Lei

Questa guida non modifica i requisiti del CRA. Ma riduce notevolmente le incertezze interpretative. I produttori dispongono ora di test concreti (RDPS), esempi concreti (modifiche sostanziali) e tempistiche concrete (segnalazione) su cui basarsi.

Tre azioni immediate:

1. Esegua il test RDPS su ogni servizio cloud da cui dipende il Suo prodotto. CRA Evidence automatizza questa valutazione come parte della sua analisi del rischio di prodotto.
2. Riveda il Suo processo di aggiornamento alla luce delle quattro domande sulle modifiche sostanziali. Le integri nella Sua checklist di rilascio.
3. Si prepari per la segnalazione di settembre 2026. I processi interni di triage, i percorsi di escalation e i modelli di report devono essere pronti prima della scadenza.

Il periodo di feedback è aperto tramite il portale Better Regulation. Se ha osservazioni sulla guida, questo è il momento di presentarle.

Per un approccio passo dopo passo alla conformità al CRA, si veda la nostra Guida alla Conformità per Startup.

Questo articolo si basa sulla bozza di Comunicazione Ares(2026)2319816, datata 3 marzo 2026. Questa guida non è ancora stata formalmente adottata dalla Commissione europea e sarà finalizzata non appena saranno disponibili tutte le versioni linguistiche dell'UE.