# Cyber Resilience Act: progettare prodotti connessi conformi

> Guida al Cyber Resilience Act per prodotti connessi: classificazione, requisiti, SBOM, supply chain, articolo 14 e un caso applicativo embedded.

Pubblicato: 2026-09-17
Categoria: regolatorio
Tag: cyber-resilience-act, cybersecurity, prodotti-connessi, iot, conformita-ce, sbom

Pagina: <https://www.stline.it/blog/cyber-resilience-act-prodotti-connessi/>

---

Il [Regolamento (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj), Cyber Resilience Act, è in vigore dal 10 dicembre 2024 e sarà pienamente applicabile dall'11 dicembre 2027. Una parte degli obblighi è però già operativa: dall'11 giugno 2026 si applica il capo sulla notifica degli organismi di valutazione della conformità, e dall'11 settembre 2026 l'articolo 14 con il sistema europeo di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi. Questi obblighi riguardano anche prodotti già immessi sul mercato.

Prima di entrare nel merito serve una distinzione. Il CRA stabilisce requisiti e risultati, spesso proporzionati al rischio; non prescrive tecnologie come il secure boot, dm-verity o una specifica versione di TLS. Nell'articolo teniamo quindi separati gli obblighi normativi, le interpretazioni della Commissione, le indicazioni operative e le nostre scelte progettuali.

---

## 1. Il perimetro: quali prodotti rientrano nel CRA

La definizione dell'articolo 3 del CRA è ampia: qualsiasi prodotto software o hardware, e le sue soluzioni di elaborazione dati remota, la cui destinazione d'uso o uso ragionevolmente prevedibile comprende una connessione dati diretta o indiretta, logica o fisica, a un dispositivo o a una rete.

Tre conseguenze pratiche.

**La connessione indiretta conta.** Un data logger privo di interfaccia di rete, che scarica i dati via USB su un PC o viene configurato via Bluetooth da un'app, rientra nel perimetro. Il criterio della definizione è lo scambio di dati, non la presenza su Internet.

**Il backend segue il prodotto.** Il regolamento include nel prodotto le soluzioni di elaborazione dati remota progettate e sviluppate dal fabbricante o sotto la sua responsabilità, la cui assenza impedirebbe al prodotto di svolgere una delle sue funzioni. Gli orientamenti sull'applicazione del CRA adottati dalla Commissione il 27 luglio 2026 con il [documento C(2026) 5252](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation), che non sono vincolanti ma esprimono l'interpretazione cui guardano autorità di vigilanza e organismi notificati, propongono un criterio a tre condizioni: l'elaborazione avviene a distanza, la sua assenza impedirebbe al prodotto di svolgere una delle sue funzioni, il software è stato progettato e sviluppato dal fabbricante o sotto la sua responsabilità. Gli stessi orientamenti aggiungono che una web application usata solo tramite browser, o un sito che si limita a presentare informazioni, non sono di norma prodotti con elementi digitali, e rientrano solo quando qualificano come elaborazione dati remota a supporto di una funzione del prodotto.

**CRA e NIS2 sono complementari** e possono incidere sulla stessa organizzazione su piani diversi. Un servizio SaaS fruito solo via browser può restare fuori dal CRA, salvo che costituisca elaborazione dati remota di un prodotto; la NIS2 dipende invece dalla qualificazione dell'entità e del servizio, non dalla natura di prodotto. Un fabbricante può quindi trovarsi soggetto al CRA per i propri prodotti e alla NIS2 per la propria organizzazione, con obblighi di notifica distinti e non sostituibili l'uno con l'altro.

Il regolamento esclude i prodotti coperti da normativa settoriale equivalente: dispositivi medici (Reg. 2017/745 e 2017/746), veicoli a motore (Reg. 2019/2144), aeronautica civile (Reg. 2018/1139), equipaggiamento marittimo (Dir. 2014/90/UE), e i prodotti sviluppati esclusivamente per finalità di sicurezza nazionale, difesa o trattamento di informazioni classificate. L'esclusione opera per prodotto, non per azienda.

Il software libero e open source fornito al di fuori di un'attività commerciale è fuori perimetro. Il CRA introduce la figura dell'*open-source software steward*, con obblighi proporzionati e attenuati. Chi integra componenti open source in un prodotto commerciale resta pienamente fabbricante di quel prodotto.

### Chi è il fabbricante (anche senza saperlo)

Il regolamento qualifica come fabbricante chi immette il prodotto sul mercato UE col proprio nome o marchio. Rientrano quindi il *private label* (acquistare una centralina da un fornitore terzo, apporre il proprio marchio e venderla comporta l'obbligo di produrre il fascicolo tecnico e di gestire le vulnerabilità), l'importatore o distributore che modifica il prodotto o lo commercializza a proprio nome, e chiunque effettui una **modifica sostanziale** su un prodotto già immesso sul mercato.

Secondo gli orientamenti non vincolanti della Commissione, il criterio della modifica sostanziale guarda all'impatto sul rischio di cybersicurezza e non all'entità della modifica. Un aggiornamento software che introduce nuovi vettori di minaccia o altera materialmente gli scenari di attacco può essere sostanziale anche toccando poche righe di codice; un refactoring esteso che non cambia la superficie di attacco può non esserlo. Il regolamento stabilisce che, se la modifica è sostanziale, il prodotto si considera nuovamente immesso sul mercato e richiede una nuova valutazione della conformità, a carico di chi la effettua o la commissiona.

---

## 2. Classificazione e valutazione della conformità

Questa sezione, fino a metà 2026, si scriveva leggendo l'Allegato III del CRA. Oggi non basta più.

Il **[Regolamento di esecuzione (UE) 2025/2392](https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj)**, adottato dalla Commissione il 28 novembre 2025 ai sensi dell'articolo 7(4) del CRA, pubblicato in Gazzetta il 1° dicembre 2025 ed entrato in vigore il 21 dicembre 2025, è vincolante. Contiene nell'allegato I la descrizione tecnica delle categorie di classe I e II dell'Allegato III del CRA e nell'allegato II quella delle categorie di prodotti critici dell'Allegato IV, con esempi illustrativi e non esaustivi di prodotti la cui funzionalità principale ricade in ciascuna categoria. È quindi il riferimento da usare nei casi limite: nel 2026 non basta più confrontare il prodotto con il solo nome della categoria riportato nell'Allegato III.

Il criterio è la **funzionalità principale** del prodotto, ed è attraverso la categoria che si determina il percorso di valutazione della conformità. La categoria non coincide però con la procedura: per la classe I il controllo interno resta disponibile, alle condizioni dell'articolo 32 illustrate sotto; per la classe II e per i prodotti critici il regime è di terza parte.

**Categoria di default.** La grande maggioranza dei prodotti. Controllo interno (modulo A dell'Allegato VIII): il fabbricante verifica da sé la conformità ai requisiti essenziali, redige il fascicolo tecnico, emette la dichiarazione di conformità UE e appone la marcatura CE. Nessun organismo notificato.

**Prodotti importanti, classe I.** Allegato III del CRA, letto con le descrizioni tecniche del Reg. 2025/2392. Comprendono, fra gli altri:

- sistemi operativi, browser e interfacce di rete fisiche e virtuali;
- password manager, gestione delle identità e degli accessi privilegiati, PKI e software di emissione di certificati, boot manager;
- VPN, SIEM, sistemi di gestione di rete, antimalware;
- router, modem per la connessione a Internet e switch;
- microprocessori, microcontrollori, ASIC e FPGA con funzioni relative alla sicurezza;
- alcune categorie di domotica, sorveglianza, assistenti vocali, giocattoli connessi e dispositivi indossabili.

Per questa classe l'articolo 32 consente il controllo interno quando il prodotto è conforme a norme armonizzate, specifiche comuni o schemi europei di certificazione della cybersicurezza che coprano integralmente i requisiti essenziali applicabili. In mancanza, occorre un organismo notificato (moduli B+C oppure H).

**Prodotti importanti, classe II.** Hypervisor e runtime di container, firewall, IDS/IPS, microprocessori e microcontrollori resistenti alla manomissione. Sempre terza parte: esame UE del tipo più conformità al tipo, garanzia qualità totale, oppure certificazione europea a livello di affidabilità almeno "sostanziale".

**Prodotti critici.** Allegato IV del CRA: dispositivi hardware con security box, gateway per contatori intelligenti, smart card ed elementi sicuri, come descritti nell'allegato II del Reg. 2025/2392. L'articolo 8 consente alla Commissione di imporre con atto delegato la certificazione obbligatoria secondo uno schema europeo. In assenza di tale obbligo i prodotti critici non ricadono nel controllo interno: l'articolo 32 li assoggetta comunque a un percorso di terza parte (B+C, H) o a certificazione europea.

**Componenti e prodotti finiti.** Un componente commercializzato autonomamente è a sua volta un prodotto con elementi digitali e si classifica per conto proprio. La classe del componente non si trasferisce però al prodotto finito che lo integra: un data logger che monta un microcontrollore con funzioni relative alla sicurezza non diventa per questo un prodotto importante di classe I, mentre quel microcontrollore lo è per il suo fabbricante.

Nella nostra esperienza le richieste commerciali tardive sono il punto in cui la classificazione può cambiare senza che nessuno se ne accorga: una funzione VPN per esporre la rete del sito, o una funzione di gestione degli altri dispositivi installati in campo. Una funzione accessoria non sposta automaticamente il prodotto di categoria, perché la classificazione segue la funzionalità principale, e una centralina che misura rumore e dispone incidentalmente di un tunnel VPN non diventa per ciò solo un prodotto VPN ai sensi dell'Allegato III. Richieste di questo tipo impongono però di riesaminare la classificazione, in particolare quando modificano la funzionalità principale o la destinazione d'uso dichiarata, ed è opportuno presidiarle in fase di raccolta requisiti: il passaggio dal controllo interno al coinvolgimento di un organismo notificato ha effetti rilevanti su tempi e costi di progetto.

### Sanzioni

L'articolo 64 fissa tre fasce: fino a 15 milioni di euro o il 2,5% del fatturato mondiale annuo per la violazione dei requisiti essenziali dell'Allegato I e degli obblighi degli articoli 13 e 14; fino a 10 milioni o il 2% per gli altri obblighi; fino a 5 milioni o l'1% per informazioni errate, incomplete o fuorvianti fornite a organismi notificati e autorità di vigilanza.

Il paragrafo 10 dello stesso articolo introduce due deroghe da conoscere. Le sanzioni amministrative dei paragrafi da 3 a 9 non si applicano ai fabbricanti che si qualificano come microimprese o piccole imprese per il mancato rispetto del termine di 24 ore di cui all'articolo 14(2), lettera a), e 14(4), lettera a), né agli steward di software open source per qualsiasi violazione del regolamento. Il considerando 120, che orienta la lettura del dispositivo senza costituire di per sé un obbligo autonomo, indica agli Stati membri di non imporre a questi soggetti altre sanzioni di carattere pecuniario.

La portata della deroga va letta con attenzione: riguarda la sola allerta precoce. Restano dovute la notifica a 72 ore e la relazione finale, e restano applicabili le altre fasce sanzionatorie. La dimensione dell'impresa è inoltre, in tutti gli altri casi, un criterio di commisurazione della sanzione e non di esenzione.

---

## 3. Dai requisiti essenziali alle scelte di progetto

L'Allegato I del CRA è diviso in due parti: la Parte I riguarda le proprietà del prodotto, la Parte II la gestione delle vulnerabilità. Si apre con un principio che condiziona tutto il resto: i prodotti devono essere progettati, sviluppati e fabbricati in modo da garantire un livello adeguato di cybersicurezza **sulla base dei rischi**, e i requisiti che seguono si applicano nella misura in cui sono pertinenti al prodotto, con qualificazioni esplicite (*ove applicabile*, *ove opportuno*, *ove tecnicamente fattibile*).

Non esiste quindi una checklist di controlli da applicare meccanicamente. Esiste un'analisi dei rischi da fare, documentare e mantenere, da cui discendono le scelte. Un'autorità di vigilanza che apre il fascicolo cerca la coerenza fra rischi identificati e contromisure adottate, non la presenza di una tecnologia specifica.

Nella tabella che segue, la colonna di sinistra riporta il requisito come lo pone il regolamento; quella di destra una possibile implementazione su prodotto embedded, che è una scelta progettuale fra molte e non una prescrizione normativa.

| Requisito del CRA (Allegato I, Parte I) | Implementazione possibile su embedded |
|---|---|
| Fornitura senza vulnerabilità sfruttabili note | Gate in pipeline che correla l'SBOM con basi dati pubbliche immediatamente prima del rilascio e blocca la build. Fonti possibili: NVD, OSV, CISA KEV, advisory dei fornitori |
| Configurazione sicura per default, con possibilità di ripristino | Nessuna credenziale di fabbrica identica su tutti gli esemplari; password univoca per dispositivo o impostazione obbligatoria al primo accesso; servizi non necessari disabilitati; factory reset con cancellazione sicura |
| Protezione da accessi non autorizzati tramite meccanismi di controllo appropriati | Autenticazione e gestione dei ruoli; dove il profilo di rischio lo giustifica, radice di fiducia hardware: chiave pubblica in OTP, catena di firma fino al kernel, rootfs verificata (dm-verity o equivalente), chiavi private in elemento sicuro, console di debug e JTAG chiusi sulle immagini di produzione |
| Riservatezza e integrità dei dati, anche mediante cifratura | Cifratura a riposo dei dati sensibili sul dispositivo; TLS per i dati in transito, con versione e suite scelte in funzione del profilo di rischio e del ciclo di vita del prodotto; identità crittografica per dispositivo anziché chiavi di flotta condivise |
| Minimizzazione dei dati | Raccolta limitata a quanto necessario alla funzione, con particolare attenzione a registrazioni audio, metadati di posizione e log di accesso |
| Superficie di attacco ridotta al minimo | Riduzione di servizi, porte e parser esposti; ogni interfaccia che resta aperta va motivata nell'analisi dei rischi |
| Protezione della disponibilità delle funzioni essenziali e limitazione dell'impatto su altri dispositivi e reti | Rate limiting, watchdog, segmentazione fra sottosistemi, degrado controllato in caso di perdita del backend |
| Registrazione e monitoraggio degli eventi rilevanti per la sicurezza, con possibilità di disattivazione da parte dell'utente | Log di accesso e di modifica su partizione dedicata, esportabili, disattivabili con informativa |
| Distribuzione di aggiornamenti di sicurezza | Vedi sotto: è il requisito con più qualificazioni condizionali |

Sugli aggiornamenti conviene essere precisi, perché la formulazione circola spesso semplificata. L'Allegato I, Parte II, richiede che le vulnerabilità siano corrette senza indugio, anche mediante aggiornamenti di sicurezza; che gli aggiornamenti di sicurezza siano distribuiti senza indugio e gratuitamente, con l'eccezione prevista per i prodotti *tailor-made*; che, **ove tecnicamente fattibile**, siano forniti separatamente dagli aggiornamenti funzionali; che siano accompagnati da avvisi che descrivono la vulnerabilità e l'azione richiesta all'utente; e che restino disponibili per almeno 10 anni dal rilascio o per la parte restante del periodo di supporto, se più lunga. Il meccanismo di distribuzione automatica per default con possibilità di disattivazione e notifica all'utente è previsto **ove applicabile**, e il regolamento riconosce contesti, tipicamente industriali e professionali, in cui l'aggiornamento automatico non è ragionevole.

La separabilità fra patch di sicurezza e aggiornamenti funzionali, anche se condizionata dalla fattibilità tecnica, è un vincolo architetturale che si paga se affrontato tardi: richiede repository, canali di rilascio e versionamento pensati per questo fin dall'inizio.

La Parte II richiede inoltre di identificare e documentare i componenti (SBOM), effettuare test e revisioni periodiche, pubblicare informazioni sulle vulnerabilità corrette, adottare una politica di divulgazione coordinata, facilitare la segnalazione da parte di terzi e mettere a disposizione un recapito per le segnalazioni.

---

## 4. Componenti e catena di fornitura

L'articolo 13(5) impone la dovuta diligenza sui componenti di terzi, inclusi quelli open source, verificando che non compromettano la sicurezza del prodotto. L'articolo 13(6) aggiunge un obbligo meno noto: quando si individua una vulnerabilità in un componente integrato, occorre segnalarla a chi mantiene quel componente e condividere la correzione, se sviluppata dal fabbricante.

Questo sposta il rapporto col fornitore dal piano commerciale a quello contrattuale. Le domande che poniamo prima di congelare la BOM:

- esiste una politica di divulgazione coordinata e un *security contact* documentato?
- con quale preavviso e con quale SLA vengono rilasciate le patch di sicurezza, e con quale impegno scritto?
- fino a che data è garantito il supporto **software** del componente, distinto dalla disponibilità del silicio: BSP, firmware del modem, stack di protocollo?
- il fornitore consegna un SBOM del proprio componente, in formato macchina, aggiornato a ogni rilascio?
- sono disponibili documenti VEX o equivalenti per dichiarare la non esposizione a CVE che emergono dalla scansione ma non sono raggiungibili nel contesto d'uso?
- come si comporterà il fornitore rispetto all'articolo 14 quando la vulnerabilità sarà nel suo componente dentro il nostro prodotto?

Il nodo più frequente, sui prodotti embedded, è il disallineamento fra il periodo di supporto dichiarato e il ciclo di vita del software dei fornitori. Un periodo di supporto decennale su un prodotto che monta un modulo con BSP basato su un kernel il cui LTS termina fra quattro anni è un impegno che non si regge con la configurazione iniziale. Le strade percorribili sono tre, non alternative fra loro: mettere a budget la migrazione, scegliere piattaforme con programmi di longevità dichiarati contrattualmente, oppure isolare la parte aggiornabile in modo che sia sostituibile senza riprogettare il prodotto. La scelta va fatta in fase di architettura.

Il CRA richiede che il periodo di supporto sia determinato in funzione della durata di utilizzo ragionevolmente prevedibile del prodotto, con un minimo di cinque anni salvo che la vita utile attesa sia inferiore, e comunicato all'utente in modo chiaro e comprensibile prima dell'acquisto. Gli orientamenti della Commissione insistono su questo punto, correggendo la lettura secondo cui cinque anni sarebbero un valore standard: sono un pavimento, non un default. Per uno strumento di misura installato in campo, la vita attesa che riscontriamo raramente scende sotto i dieci anni.

---

## 5. Norme armonizzate: dove siamo

La distinzione che conta è fra ciò che esiste come progetto e ciò che è citato nella Gazzetta Ufficiale: solo la citazione attiva la presunzione di conformità dell'articolo 27.

Con la [richiesta di normazione M/606](https://ec.europa.eu/growth/tools-databases/enorm/mandate/606_en), adottata con decisione di esecuzione C(2025) 618 del 3 febbraio 2025 e accettata da CEN, CENELEC ed ETSI in aprile 2025, sono state commissionate 41 norme armonizzate, articolate in norme di tipo A (principi orizzontali), di tipo B (temi orizzontali specifici, in primis la gestione delle vulnerabilità) e di tipo C (specifiche di prodotto, mappate sugli Allegati III e IV).

Le famiglie principali:

- **EN 40000** (CEN-CLC/JTC 13 WG 9), strato orizzontale: vocabolario, principi, controlli di sicurezza generici, gestione delle vulnerabilità. Costruisce sul lavoro della serie EN 18031 sviluppata per la direttiva RED.
- **EN 50770**, profili verticali OT: firewall e IDS/IPS, sistemi di gestione di rete, prodotti VPN, router e switch, largamente basati sul framework IEC 62443.
- **EN 304 6xx** (ETSI TC CYBER, gruppo EUSR), categorie software e prodotti connessi di consumo. Sono i lavori più avanzati e i draft sono pubblici.
- **EN 5076x** e i lavori di CEN/TC 224 per semiconduttori, elementi sicuri e gestione delle identità.

> **Stato verificato al 17 settembre 2026**
> Alla data di questo aggiornamento nessuna norma armonizzata CRA risulta citata nella Gazzetta Ufficiale dell'Unione europea, e la presunzione di conformità non è quindi disponibile per alcuna categoria di prodotto.

Le scadenze originarie sono slittate; la parte sulla gestione delle vulnerabilità, prEN 40000-1-3, è indicata come la più vicina alla citazione, mentre le parti su principi e controlli generici seguono una traiettoria più lunga. È l'informazione che invecchia più rapidamente in questo articolo, e va verificata alla fonte prima di fondarci una decisione.

Le norme esistenti su cui i draft si appoggiano — IEC 62443-4-1 e -4-2, ETSI EN 303 645, la serie EN 18031 — nella forma attualmente pubblicata non conferiscono presunzione di conformità al CRA.

La presunzione resta comunque una comodità probatoria e non l'unica strada: il controllo interno è percorribile dimostrando la conformità ai requisiti essenziali con mezzi propri, e l'articolo 27 contempla anche le specifiche comuni che la Commissione può adottare con atto di esecuzione se le norme non arrivano nei tempi. La nostra scelta, nel frattempo, è progettare contro IEC 62443-4-1 per il processo di sviluppo sicuro e 62443-4-2 per i requisiti tecnici di componente, integrando ETSI EN 303 645 sui prodotti connessi di consumo, ISO/IEC 29147 e 30111 per divulgazione e gestione delle vulnerabilità, e BSI TR-03183-2 per l'SBOM. Quest'ultima è una guida tecnica del BSI tedesco, quindi volontaria e di origine nazionale, e resta l'interpretazione tecnica più dettagliata disponibile sull'SBOM in assenza dell'atto di esecuzione previsto dall'articolo 13(24). Il corpo di evidenze così prodotto è in larga parte riutilizzabile quando le norme armonizzate verranno citate, ma non equivale alla presunzione di conformità.

---

## 6. Il fascicolo tecnico

L'Allegato VII del CRA elenca il contenuto della documentazione tecnica. Riassumerlo è utile a patto di dire che si tratta di una sintesi e non di un elenco completo: in sede di redazione va letto il testo dell'allegato. I contenuti principali:

- descrizione generale del prodotto, destinazione d'uso, versioni software e hardware, fotografie o illustrazioni delle caratteristiche esterne, della marcatura e del layout interno;
- le informazioni destinate all'utente ai sensi dell'Allegato II;
- descrizione della progettazione, dello sviluppo e della produzione, incluse architettura software, interfacce e informazioni sui processi di produzione e monitoraggio;
- valutazione dei rischi di cybersicurezza contro cui il prodotto è progettato;
- motivazione della determinazione del periodo di supporto;
- elenco delle norme armonizzate, specifiche comuni o schemi europei di certificazione applicati integralmente o in parte, e descrizione delle soluzioni adottate dove non applicati;
- relazioni sulle prove effettuate, incluse quelle di validazione;
- descrizione delle soluzioni adottate per la distribuzione sicura degli aggiornamenti;
- SBOM in formato comunemente usato e leggibile da macchina, che copra almeno le dipendenze di primo livello;
- politica di divulgazione coordinata delle vulnerabilità e recapito per le segnalazioni;
- descrizione dei processi di gestione delle vulnerabilità per il periodo di supporto;
- copia della dichiarazione di conformità UE.

La documentazione va conservata per almeno 10 anni dall'immissione sul mercato, o per il periodo di supporto se più lungo. Per una serie in produzione fino al 2035 con supporto decennale, significa conservare e saper recuperare la versione esatta dell'SBOM di ogni build fino a metà degli anni Quaranta. È un requisito di infrastruttura documentale: archiviazione versionata, integrità protetta, capacità di associare un numero di serie a una build.

L'Allegato II definisce le informazioni da fornire all'utente: identificazione e recapito del fabbricante, punto di contatto unico per le segnalazioni di vulnerabilità, destinazione d'uso, funzionalità di cybersicurezza, data di fine del periodo di supporto espressa in modo comprensibile e disponibile prima dell'acquisto, indicazioni su come ottenere gli aggiornamenti, istruzioni per la messa fuori servizio sicura. La data di fine supporto tocca quindi anche il materiale precontrattuale, non solo il manuale.

L'SBOM non deve essere reso pubblico; il considerando 77 è esplicito su questo. Va però consegnato all'autorità di vigilanza su richiesta motivata, il che presuppone saperlo produrre nella versione corretta in tempi ragionevoli.

---

## 7. Articolo 14: vulnerabilità e incidenti da segnalare

Dall'11 settembre 2026 i fabbricanti devono segnalare, attraverso la piattaforma unica prevista dall'articolo 16 e gestita da ENISA, due categorie di eventi.

**Vulnerabilità attivamente sfruttate.** Le vulnerabilità di cui il fabbricante ha conoscenza e per cui esiste evidenza affidabile di uno sfruttamento in atto da parte di un soggetto malevolo in un proprio prodotto con elementi digitali. La scoperta o la pubblicazione di una CVE, di per sé, non fa scattare questo obbligo.

**Incidenti gravi con impatto sulla sicurezza del prodotto.** La definizione ha due rami: gli eventi che incidono negativamente sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni sensibili o importanti, e gli eventi che hanno portato all'introduzione o all'esecuzione di codice malevolo nel prodotto o nelle reti e nei sistemi informativi dell'utente. Il secondo ramo viene spesso omesso nelle sintesi e cambia il perimetro di ciò che va valutato.

| Fase | Vulnerabilità attivamente sfruttata | Incidente grave |
|---|---|---|
| Allerta precoce | 24 ore dalla conoscenza | 24 ore dalla conoscenza |
| Notifica | 72 ore, con informazioni generali e misure correttive o mitigative | 72 ore, con valutazione iniziale e indicatori di compromissione disponibili |
| Relazione finale | 14 giorni dalla disponibilità di una misura correttiva | 1 mese dalla notifica a 72 ore |

L'articolo 14(8) aggiunge un obbligo distinto e spesso trascurato: dopo essere venuto a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave, il fabbricante informa gli utenti interessati del prodotto e, ove opportuno, tutti gli utenti, dell'evento e delle misure correttive o mitigative che possono adottare. È un obbligo verso il mercato, autonomo rispetto alla politica di divulgazione coordinata e rispetto alla segnalazione all'autorità.

Sul funzionamento operativo della piattaforma, le [FAQ ENISA](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) indicano che la segnalazione raggiunge il CSIRT coordinatore competente ed è di regola resa disponibile anche a ENISA; che è sufficiente una sola comunicazione, senza replicarla alle autorità dei diversi Stati membri interessati; che, se la piattaforma è indisponibile, la segnalazione va trasmessa una volta ripristinata, e in caso di necessità immediata si può contattare direttamente il CSIRT, senza che ciò sostituisca il successivo invio. Sempre secondo le FAQ, il rappresentante del fabbricante deve disporre di un account personale EU Login con autenticazione a due fattori, l'associazione fra persona e fabbricante viene validata dal CSIRT e la validazione pendente non blocca l'invio iniziale, e nella fase iniziale non sono previste API: il processo non va quindi costruito su un'integrazione automatica che non esiste. Sono indicazioni operative e soggette ad aggiornamento frequente, da riverificare prima di congelare una procedura interna.

Il vincolo delle 24 ore è, prima che tecnico, un problema di organizzazione. Ventiquattro ore comprendono la notte, il fine settimana e le ferie. Nella nostra prassi mettiamo in piedi:

1. un canale di ingresso pubblico e monitorato: casella `security@` con reindirizzamento a più persone e file `/.well-known/security.txt` secondo [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116), che è il percorso canonico dello standard;
2. un criterio scritto per stabilire quando si configura la "conoscenza" dell'evento, che è il momento da cui parte il termine, con verbalizzazione dell'orario e del ragionamento;
3. una persona di turno con delega a decidere, e un sostituto;
4. account EU Login già creati e provati;
5. modelli precompilati per le tre fasi, con i campi dipendenti dal prodotto già popolati;
6. un'esercitazione da tavolo almeno annuale, con cronometro.

Da considerare il coordinamento a valle: i clienti soggetti a NIS2 hanno propri obblighi di notifica e chiederanno informazioni in tempi compatibili con le loro scadenze. Le clausole di notifica nei contratti di fornitura vanno allineate a queste finestre.

Gli orientamenti della Commissione hanno reso esplicito che l'obbligo di segnalazione si applica a tutti i prodotti in perimetro, compresi quelli immessi sul mercato prima della piena applicazione del regolamento, e che prosegue anche dopo la fine del supporto. Il parco installato non è escluso. Trattandosi di interpretazione non vincolante, la lettura è autorevole ma non definitiva.

---

## 8. Le criticità che emergono nei progetti reali

**Il legacy.** L'articolo 69 assoggetta ai requisiti di progettazione i prodotti immessi sul mercato dall'11 dicembre 2027, e quelli precedenti solo se subiscono modifiche sostanziali, ma estende l'articolo 14 anche al parco già immesso sul mercato. L'obbligo che ne deriva è di segnalare entro i termini; il regolamento non prescrive di possedere entro 24 ore un inventario completo del campo. Resta che senza un inventario che leghi numero di serie, cliente, versione firmware e SBOM corrispondente, la notifica a 72 ore è difficile da compilare con dati attendibili, e la stima delle unità esposte diventa una congettura. Lo consideriamo un obiettivo operativo prioritario, non un adempimento formale.

**La modifica sostanziale come deriva silenziosa.** Il criterio basato sull'impatto sul rischio implica che un prodotto pre-2027 possa attraversare la soglia dopo una serie di aggiornamenti funzionali, senza che nessun singolo rilascio abbia acceso un allarme. Introduciamo un gate di valutazione a ogni rilascio maggiore, con esito documentato anche quando l'esito è "non sostanziale": il valore sta nella tracciabilità della decisione, non nel suo contenuto.

**Il silicio che non si aggiorna.** Microcontrollori senza secure boot, moduli radio con stack chiusi e senza patch, componenti a fine vita prima della fine del periodo di supporto. Sono decisioni prese anni fa che determinano se il prodotto è adeguabile o va riprogettato, e su questo non esistono scorciatoie documentali. Il rischio residuo, quando il componente non è sostituibile nel breve, va dichiarato nell'analisi e compensato a livello di sistema, con la consapevolezza che la compensazione perimetrale non elimina la vulnerabilità del componente.

**L'open source dentro il prodotto.** La dovuta diligenza sui componenti open source non è trasferibile a un fornitore. Criteri di selezione (progetto attivo, politica di sicurezza pubblicata, tempi di risposta storici), mirror interno delle dipendenze, e capacità di produrre la patch quando l'upstream non la produce. L'ultimo punto è quello che le organizzazioni piccole sottostimano: richiede competenza sul codice di terzi, non solo sul proprio.

**Il rumore delle CVE.** Un'immagine embedded tipica genera un numero di riscontri molto superiore alle vulnerabilità effettivamente rilevanti nel contesto d'uso. Senza un processo VEX strutturato il triage satura il team. Il triage va documentato: l'autorità può chiedere perché una CVE nota non è stata corretta, e la risposta "non raggiungibile nel nostro contesto" va sostenuta con evidenze, non asserita.

**Il costo fisso per le PMI.** Processi, strumenti, documentazione e presidio delle 24 ore hanno un costo largamente indipendente dai volumi, e pesano quindi su chi immette sul mercato poche migliaia di unità. La leva praticabile è un impianto di conformità unico riutilizzabile su tutta la gamma, invece di un fascicolo artigianale per prodotto.

**La capacità degli organismi notificati.** Per la classe II e i prodotti critici il numero di organismi notificati sotto il CRA è ancora limitato, e la coda si allungherà avvicinandosi al dicembre 2027. Il contatto va preso con largo anticipo rispetto alla data di lancio.

---

## 9. Caso applicativo: centralina di monitoraggio acustico

Le scelte tecniche di questa sezione sono nostre: una configurazione possibile, non l'unica conforme. Dove una scelta discende da un obbligo, la fonte è indicata.

**Il prodotto.** Centralina di monitoraggio acustico permanente per installazione in esterno. Catena di misura conforme a IEC 61672-1 classe 1 (microfono da 1/2", preamplificatore, condizionamento, ADC dedicato, calcolo dei livelli su MCU dedicato). Parte connessa su modulo Linux embedded: interfaccia web locale per configurazione, modem LTE per il backhaul, Wi-Fi e BLE per la messa in servizio, client MQTT su TLS verso una piattaforma cloud sviluppata dal fabbricante, aggiornamento firmware over-the-air, memorizzazione locale di livelli, spettri e clip audio di evento.

**Assunzione dichiarata.** Ipotizziamo un impiego in cui la centralina è soggetta a un regime di metrologia legale, per esempio in monitoraggi con valenza di controllo ai fini di provvedimenti. La nozione di firmware *legalmente rilevante* non discende dalla IEC 61672-1, che definisce requisiti prestazionali per fonometri e le relative prove, ma dal regime metrologico applicabile e dall'uso previsto. In un impiego puramente conoscitivo o di monitoraggio interno l'assunzione cade, e con essa parte dei vincoli architetturali della sezione 9.3.

### 9.1 Perimetro e classificazione

La centralina è un prodotto con elementi digitali. La piattaforma cloud è sviluppata dal fabbricante e senza di essa il prodotto perde la funzione di trasmissione e archiviazione remota: rientra quindi come soluzione di elaborazione dati remota, ed entra nel perimetro e nel fascicolo tecnico.

La verifica di classificazione si fa contro l'Allegato III del CRA letto insieme alle descrizioni tecniche dell'allegato I del Reg. di esecuzione 2025/2392, applicando il criterio della funzionalità principale. La funzionalità principale del prodotto è l'acquisizione e la misura di grandezze acustiche; non è la gestione di rete, non è l'instradamento di traffico, non è il filtraggio, e non ricade nelle descrizioni delle categorie di classe I o II. Il fatto che il SoC integri un elemento sicuro non sposta il prodotto finito, per quanto detto alla sezione 2.

Esito: categoria di default, controllo interno. La verifica va verbalizzata nel fascicolo con l'estremo dell'atto di esecuzione e la motivazione, non lasciata implicita.

### 9.2 Analisi dei rischi, con rischio residuo

La tabella riporta per ogni superficie la contromisura e ciò che la contromisura **non** risolve. È la colonna di destra quella che l'analisi dei rischi deve sostenere.

| Superficie | Contromisura | Assunzioni e rischio residuo |
|---|---|---|
| Web UI locale | Credenziale univoca per dispositivo, cambio obbligatorio al primo accesso, HTTPS, blocco dopo tentativi falliti | Il modello di fiducia del certificato va definito: vedi 9.5. Resta il rischio di accesso da rete locale compromessa del cliente |
| Modem LTE | APN privato, filtraggio del traffico in uscita sul dispositivo, SLA di patch contrattualizzato sullo stack del modem | L'APN privato riduce l'esposizione ma non corregge una vulnerabilità dello stack del modem. Se il fornitore non rilascia patch, il rischio resta e va dichiarato |
| MQTT verso cloud | mTLS con certificato per dispositivo, CA privata, revoca gestita | Richiede un processo di revoca realmente esercitato e una gestione del ciclo di vita dei certificati per 10 anni. La scadenza dei certificati è un rischio di disponibilità, non solo di sicurezza |
| OTA | Firma verificata prima dell'attivazione, schema A/B, contatore anti-rollback | La combinazione richiede una strategia a due fasi: vedi 9.4 |
| UART/JTAG | Console disabilitata in produzione, JTAG chiuso via fuse, secure boot | Riduce l'attacco fisico opportunistico, non un attaccante determinato con accesso prolungato. Va valutato il costo di un attacco a canale laterale rispetto al valore del bene protetto |
| Storage locale | Cifratura a riposo con chiave derivata da HUK, cancellazione al factory reset | La derivazione da HUK protegge solo se boot chain, policy di accesso alla chiave e debug sono coerenti. Una sola incoerenza annulla la misura |
| BLE di messa in servizio | Finestra di pairing limitata e attivata da azione fisica | Il rischio si sposta sulla fase di installazione: richiede procedura operativa, non solo firmware |
| Catena metrologica | Separazione fra MCU metrologico e SoC applicativo, canale a senso unico, firmware metrologico firmato | L'integrità della parte legalmente rilevante discende dal regime metrologico prima ancora che dal CRA. La separazione risolve entrambi i vincoli, ma la sua adeguatezza va verificata contro il regime applicabile, non presunta |

L'ultima riga è quella che distingue questo prodotto da un IoT generico: l'architettura a due processori serve contemporaneamente a preservare l'integrità della parte legalmente rilevante e a separare i domini di fiducia.

### 9.3 Scelte architetturali

- SoM Linux con programma di longevità dichiarato contrattualmente e BSP su kernel LTS coerente col periodo di supporto.
- Secure boot: chiave pubblica in OTP, bootloader firmato, kernel e device tree firmati, rootfs read-only verificata, partizione dati separata e cifrata.
- Elemento sicuro per la chiave privata del dispositivo e il certificato mTLS, con generazione della chiave a bordo in fase di produzione: la chiave privata non esiste mai fuori dal chip. Il costo è un vincolo sulla logistica di produzione e sulla riparabilità in assistenza, che va accettato consapevolmente.
- Immagine minimale: nessuna shell di rete, nessun servizio non necessario, servizio di diagnostica attivabile solo localmente e a tempo.
- Log di sicurezza su partizione dedicata, con rotazione, esportabili, disattivabili dall'utente con informativa.

### 9.4 OTA: A/B e anti-rollback insieme

I due meccanismi sono compatibili solo se si definisce quando il contatore monotòno viene avanzato. Se lo si incrementa al momento della scrittura della nuova immagine, il rollback alla versione precedente, che è la ragione stessa dello schema A/B, viene vietato dall'anti-rollback.

La strategia che adottiamo è a due fasi: installazione e avvio della nuova immagine con lo slot precedente ancora valido e il contatore invariato; health check applicativo post-boot su un insieme definito di condizioni (catena di misura operativa, connettività, integrità della configurazione); solo al superamento dell'health check si esegue il commit, che marca lo slot come valido e avanza il contatore anti-rollback. Il contatore va avanzato solo per correzioni di sicurezza che si intende rendere irreversibili, non a ogni rilascio, perché ogni incremento chiude definitivamente la possibilità di tornare indietro.

### 9.5 Modello di fiducia della UI locale

"HTTPS con certificato per dispositivo" non risolve da solo la fiducia del browser, ed è un punto dove molti prodotti si fermano a metà. Le opzioni realistiche:

- certificato emesso da CA privata del fabbricante, con la CA da installare sulla macchina del tecnico: funziona in contesti gestiti, è impraticabile per l'utente occasionale;
- certificato pubblico su nome DNS risolvibile, con rinnovo che dipende dalla connettività: introduce una dipendenza esterna su un'interfaccia che deve funzionare anche in campo isolato;
- app di messa in servizio che effettua il pinning del certificato del dispositivo, ottenuto durante un onboarding autenticato via BLE o via codice stampato: sposta la fiducia sull'app e richiede un canale di provisioning sicuro;
- accesso amministrativo solo via app, con la UI web limitata alla consultazione locale in sola lettura.

Nessuna opzione è dominante. La scelta dipende da chi installa, da quanto spesso si accede localmente e dalla presenza o meno di connettività in fase di messa in servizio, e va documentata nell'analisi dei rischi insieme al rischio residuo che comporta.

### 9.6 SBOM e pipeline

La build Yocto genera nativamente l'SBOM in formato SPDX tramite la classe [`create-spdx`](https://docs.yoctoproject.org/ref-manual/classes.html#create-spdx) documentata in OpenEmbedded. Per ottenere anche CycloneDX serve un layer dedicato o una conversione a valle, che va documentata nel processo di build. Il regolamento richiede un formato comunemente usato e leggibile da macchina, che copra almeno le dipendenze di primo livello; la scelta fra SPDX e CycloneDX è del fabbricante.

L'artefatto viene firmato e archiviato con l'immagine e l'hash della build, indicizzato per versione.

Prima del rilascio: correlazione dell'SBOM con le basi dati di vulnerabilità, gate che blocca il rilascio in presenza di vulnerabilità sfruttabili note, produzione del documento VEX per le CVE presenti ma non raggiungibili, con motivazione tecnica per ciascuna.

In esercizio: rescansione periodica degli SBOM di **tutte** le versioni in campo, non solo dell'ultima. La cadenza che adottiamo è giornaliera, ed è una nostra scelta di processo: il CRA non prescrive una frequenza di scansione. La ragione non è che una CVE faccia scattare il termine dell'articolo 14, che decorre invece dalla conoscenza dello sfruttamento attivo, ma che senza sapere rapidamente quali versioni contengono un componente vulnerabile non si riesce né a correggere senza indugio, come il regolamento richiede, né a rispondere in modo attendibile se lo sfruttamento attivo emerge.

### 9.7 Periodo di supporto, tradotto in una data

Vita utile attesa stimata: 10-12 anni. Politica aziendale: supporto per 10 anni dall'immissione sul mercato dell'ultima unità della serie.

Questa formula, però, non è comunicabile all'utente: il CRA richiede una data di fine supporto espressa in modo comprensibile e disponibile prima dell'acquisto, e chi compra la prima unità non può sapere quando uscirà dal listino l'ultima. La traduzione operativa è dichiarare una data calendario certa fin dalla prima immissione, calcolata sulla fine di produzione pianificata, con l'impegno pubblico a estenderla se la produzione prosegue oltre. Una data che si allunga nel tempo è ammissibile; una data che si accorcia non lo è, e questo va tenuto presente quando si sceglie il valore iniziale.

Conseguenze da mettere a budget in fase di progetto:

- un ciclo di manutenzione pianificato, nel nostro caso semestrale, con le relative attività di test e regressione sulla catena di misura;
- indipendentemente dal ciclo pianificato, le correzioni di sicurezza vanno distribuite senza indugio, come richiede il regolamento: una vulnerabilità sfruttabile non attende il rilascio di manutenzione successivo. Servono quindi due canali distinti, uno programmato e uno fuori ciclo, con procedure di test ridotte ma definite per il secondo;
- almeno una migrazione di kernel/BSP nell'arco del decennio, pianificata e finanziata;
- copertura contrattuale col fornitore del SoM e del modulo LTE verificata rispetto alla stessa scadenza;
- conservazione di SBOM e fascicolo tecnico secondo i termini dell'Allegato VII;
- dichiarazione della data di fine supporto nel manuale, nella scheda prodotto e nel materiale precontrattuale.

### 9.8 La segnalazione, in concreto

Scenario. Martedì, ore 22:40: il fornitore del modulo LTE pubblica un avviso su una vulnerabilità nello stack TLS del proprio firmware. Mercoledì mattina un cliente segnala traffico anomalo verso un host esterno su due centraline del proprio sito, con evidenze compatibili con lo sfruttamento di quella vulnerabilità.

- **T0.** Il termine decorre dalla conoscenza dello sfruttamento attivo, quindi dal momento in cui il team dispone di evidenza affidabile, non dalla pubblicazione dell'avviso del fornitore. Il criterio è scritto nella procedura interna e la determinazione viene verbalizzata con orario e motivazione, perché è il dato su cui si misurerà a posteriori il rispetto dei termini.
- **T0 + 24h, allerta precoce.** Identificazione del fabbricante e del prodotto, natura della vulnerabilità, stato di sfruttamento, Stati membri potenzialmente interessati.
- **T0 + 72h, notifica.** Descrizione tecnica, versioni firmware interessate, stima delle unità esposte, misure di mitigazione comunicate ai clienti, stato dell'interlocuzione col fornitore.
- **In parallelo.** Informazione agli utenti interessati e, ove opportuno, a tutti gli utenti, come richiede l'articolo 14(8), sulle misure correttive o mitigative adottabili. Segnalazione al fornitore del modulo ai sensi dell'articolo 13(6). Comunicazione ai clienti soggetti a NIS2 nei tempi e nel formato che consentono loro di adempiere ai propri obblighi.
- **T_patch + 14 giorni, relazione finale.** Vulnerabilità e gravità, impatto, causa radice, misura correttiva distribuita, copertura dell'aggiornamento sul parco installato.

Il punto critico dello scenario è organizzativo: disporre dei dati di campo in poche ore e avere una persona autorizzata a inviare la segnalazione senza attendere una decisione collegiale. Entrambe le condizioni si costruiscono prima.

---

## 10. Piano di adeguamento fino a dicembre 2027

**Già dovuto.** Procedura di segnalazione articolo 14 operativa e inventario minimo del parco installato, nei termini della sezione 7.

**Entro tre mesi.** Censimento della gamma con determinazione del perimetro e della categoria per ciascun prodotto, verbalizzata contro il Reg. di esecuzione 2025/2392. Analisi delle lacune del fascicolo tecnico rispetto all'Allegato VII, concentrata su architettura software, gestione delle vulnerabilità e valutazione dei rischi. Pubblicazione della politica di divulgazione coordinata e del punto di contatto.

**Entro sei mesi.** Generazione automatica dell'SBOM in pipeline per tutti i prodotti in produzione, correlazione con le fonti di vulnerabilità, processo VEX. Revisione contrattuale coi fornitori critici su SLA di patch, EOL del supporto software e obblighi di notifica.

**Entro dodici mesi.** Determinazione e dichiarazione del periodo di supporto per prodotto, con il relativo budget di manutenzione e i due canali di rilascio. Adeguamento dei prodotti in sviluppo ai requisiti dell'Allegato I, con test e relative relazioni. Contatto con un organismo notificato per i prodotti classificati come importanti di classe II o critici.

**Entro la scadenza.** Fascicoli tecnici completi, dichiarazioni di conformità UE, marcatura CE, informazioni all'utente conformi all'Allegato II, processi di gestione delle vulnerabilità in esercizio e verificabili.

Il CRA sposta una parte della conformità a monte, nelle decisioni di architettura, nella scelta dei componenti e nei processi di manutenzione. Per i prodotti connessi, affrontarlo a progetto finito significa spesso scoprire troppo tardi che alcuni requisiti non sono più risolvibili con la sola documentazione.

---

## Riferimenti

**Fonti vincolanti**

- [Regolamento (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) del 23 ottobre 2024 (Cyber Resilience Act), testo consolidato su EUR-Lex
- [Regolamento di esecuzione (UE) 2025/2392](https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj) della Commissione del 28 novembre 2025, descrizione tecnica delle categorie di prodotti importanti e critici
- Decisione di esecuzione C(2025) 618 final, [richiesta di normazione M/606](https://ec.europa.eu/growth/tools-databases/enorm/mandate/606_en)

**Interpretazione della Commissione, non vincolante**

- [Orientamenti sull'applicazione del CRA](https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation), C(2026) 5252 final del 27 luglio 2026, con allegato e 67 esempi
- [FAQ della Commissione sull'attuazione del CRA](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act-implementation-frequently-asked-questions)

**Materiali operativi, soggetti ad aggiornamento**

- ENISA, [FAQ](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions) e factsheet sulla [Single Reporting Platform](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp)

**Norme e guide tecniche, volontarie**

- [IEC 62443-4-1](https://webstore.iec.ch/en/publication/33615) e [IEC 62443-4-2](https://webstore.iec.ch/en/publication/34421)
- [ETSI EN 303 645](https://www.etsi.org/deliver/etsi_en/303600_303699/303645/)
- [ISO/IEC 29147](https://www.iso.org/standard/72311.html) e [ISO/IEC 30111](https://www.iso.org/standard/69725.html)
- [BSI TR-03183](https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html), parti 1, 2 e 3
- [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116), formato e collocazione del file `security.txt`
- OpenEmbedded/Yocto Project, [documentazione della classe `create-spdx`](https://docs.yoctoproject.org/ref-manual/classes.html#create-spdx)

*Contenuto tecnico-informativo aggiornato a settembre 2026. Non costituisce consulenza legale né parere di conformità. Lo stato delle norme armonizzate, degli orientamenti della Commissione e dei materiali operativi ENISA evolve rapidamente: verificare le fonti primarie prima di assumere decisioni di conformità.*