Il Cyber Resilience Act chiede sicurezza fin dalla progettazione e, per la maggior parte dei prodotti, apre all’autovalutazione. Molte PMI leggono “checklist interna e siamo a posto”. Ma una dichiarazione firmata non è una prova. E per una parte dei prodotti l’autovalutazione non è nemmeno sul tavolo.
Francesco Not è progettista hardware e specialista di sicurezza embedded, con oltre venticinque anni tra progettazione, firmware e penetration testing sull’hardware. Con il marchio Hard Probe offre diagnostica e security assessment su schede e dispositivi. In questo articolo spiega perché, con il CRA, il test resta il passaggio che nessuna dichiarazione può sostituire.
Da quando il Cyber Resilience Act — Regolamento (UE) 2024/2847 — è entrato in vigore, tra i produttori di elettronica circola una lettura ottimistica: “secure by design” più autovalutazione uguale meno burocrazia. Basta compilare una checklist interna, firmare la dichiarazione, apporre la marcatura CE, fatto.
“È la scorciatoia che sento più spesso”, commenta Francesco Not. “E parte da un equivoco: che secure by design sia un’etichetta che ti dai. Non lo è. È una proprietà del prodotto, o sai dimostrarla o non c’è.”
Il punto non è normativo-formale. È tecnico. E riguarda direttamente chi progetta, chi decide gli acquisti e chi mette la firma in fondo alla dichiarazione di conformità.
1. “Secure by design” è un principio, non un’etichetta
Il CRA impone che i prodotti con elementi digitali siano sicuri fin dalla progettazione e restino tali lungo il ciclo di vita. La piena applicazione scatta l’11 dicembre 2027; dall’11 settembre 2026 sono già operativi gli obblighi di segnalazione delle vulnerabilità sfruttate. Ma “sicuro fin dalla progettazione” non è uno slogan da mettere sulla scheda tecnica: è un insieme di requisiti essenziali che il fabbricante deve saper documentare.
“Il regolamento non ti chiede di dichiarare che il prodotto è sicuro”, precisa Not. “Ti chiede di dimostrarlo. E la differenza tra dichiarare e dimostrare, sul banco, è tutta lì: è la differenza tra una riga in un documento e un report di test che dice cosa hai provato, come, e cosa è successo.”
Tra i requisiti essenziali del CRA c’è un elemento che molti non hanno ancora messo a fuoco: il fabbricante deve predisporre un piano di test di sicurezza ed eseguire attività di verifica delle vulnerabilità sul prodotto — o su una build rappresentativa — prima di immetterlo sul mercato. Non è un extra facoltativo. È parte di ciò che rende valida la conformità.
NOTA TECNICA · Cosa chiede davvero l’Allegato I
I requisiti essenziali di cibersicurezza del CRA (Allegato I) includono, tra gli altri: assenza di vulnerabilità note al momento dell’immissione sul mercato, configurazioni sicure di default, superficie d’attacco ridotta, meccanismo di aggiornamento autenticato e con verifica di integrità, e — punto spesso trascurato — un piano di test dedicato alla sicurezza e la verifica delle vulnerabilità, documentati nel fascicolo tecnico. In pratica: la sicurezza va progettata e provata, e la prova va conservata e mantenuta durante tutta la vita del prodotto.
2. Autovalutazione non significa autocertificazione a occhi chiusi
Per la maggior parte dei prodotti — quelli che il CRA chiama “standard”, cioè fuori dagli elenchi degli importanti e critici, l’autovalutazione è effettivamente la via prevista. Il fabbricante valuta il proprio prodotto, compila il fascicolo tecnico, firma la dichiarazione UE di conformità, appone la marcatura CE. Nessun organismo esterno.
È qui che nasce l’illusione della checklist. “Autovalutazione non vuol dire che ti autocertifichi e nessuno controlla”, taglia corto Not. “Vuol dire che ti prendi la responsabilità piena, per iscritto. Quella firma regge a due cose: la vigilanza del mercato, che può chiederti il fascicolo tecnico e le evidenze; e un incidente reale, il giorno in cui il tuo prodotto viene bucato e qualcuno ti chiede su cosa avevi basato quella dichiarazione.”
E una checklist compilata a tavolino, senza test alle spalle, davanti a quelle due cose non tiene. “Un elenco di controlli spuntati non è un’evidenza tecnica. È un’intenzione. Il giorno in cui serve, l’autorità o l’assicurazione non ti chiedono se avevi pensato alla sicurezza. Ti chiedono cosa hai verificato.”
NOTA TECNICA · Modulo A in due righe
L’autovalutazione del CRA è il “Modulo A” (controllo interno). Il fabbricante conduce e documenta la valutazione nel fascicolo tecnico, sottoscrive la dichiarazione UE di conformità e appone la sola marcatura CE, senza numero di organismo notificato. Il fascicolo va conservato per dieci anni. Il modulo è “leggero” sul piano procedurale, non sul piano probatorio: le evidenze tecniche devono esserci comunque.
3. Per i prodotti “importanti” l’autovalutazione non è prevista
C’è poi una parte di prodotti per cui il discorso “checklist e via” non è nemmeno teoricamente possibile. Il regolamento di esecuzione (UE) 2025/2392, pubblicato a dicembre 2025, ha definito le categorie tecniche dei prodotti importanti (Allegato III, classi I e II) e critici (Allegato IV). Sono categorie che toccano da vicino il mondo embedded: microcontrollori con funzioni di sicurezza, firewall, VPN, sistemi operativi, elementi sicuri, smart card, gateway per smart meter e per IIoT.
Per questi la via cambia:
- Importante Classe I — l’autovalutazione resta possibile solo se si applicano integralmente norme armonizzate, specifiche comuni o uno schema europeo di certificazione. In loro assenza — ed è la situazione attuale per molti tipi di prodotto — serve un organismo notificato.
- Importante Classe II e Critico — la valutazione di terzi da parte di un organismo notificato è obbligatoria. Autovalutarsi non è un’opzione: renderebbe la valutazione di conformità semplicemente non valida, e il prodotto non immettibile legalmente sul mercato UE.
“E qui c’è un dettaglio operativo che nessuno vi dice”, aggiunge Not. “Gli organismi notificati per il CRA, a metà 2026, si contano sulle dita. La coda si formerà. Se il vostro prodotto è di Classe I o II e vi svegliate nel 2027, non fate in tempo. Il testing serio a monte non è solo un requisito: è ciò che vi fa arrivare pronti quando finalmente è il vostro turno.”
NOTA TECNICA · Le quattro vie di conformità
| Categoria | Via di valutazione della conformità |
|---|---|
| Standard (default) | Autovalutazione — Modulo A |
| Importante Classe I | Modulo A solo con norme armonizzate applicate integralmente; altrimenti organismo notificato (Modulo B+C o H) |
| Importante Classe II | Organismo notificato obbligatorio (B+C o H) |
| Critico | Organismo notificato + eventuale certificato europeo di cibersicurezza (livello almeno “sostanziale”) |
La classificazione segue la funzionalità principale del prodotto: se una funzione rientra negli Allegati III o IV, l’intero prodotto è valutato a quel livello, a prescindere da come viene commercializzato.
4. Cosa vuol dire “testare” davvero
A questo punto la domanda pratica è: cosa conta come test? Perché anche sul termine “testing” c’è un equivoco.
“Passare uno scanner automatico sul firmware e stampare il PDF non è un security assessment”, chiarisce Not. “È un punto di partenza. Uno scanner trova quello che è già in un database. Un prodotto embedded lo attacchi dove il database non arriva: sui bus di debug lasciati aperti, sulle memorie non protette, sull’aggiornamento firmware che accetta immagini non firmate, sui punti in cui il fisico e il logico si toccano.”
È il lavoro che Not svolge sotto il marchio Hard Probe Cybersec: security assessment hardware e firmware, penetration testing fisico e logico, reverse engineering. “Il metodo è quello di un attaccante metodico. Prima lo scenario: chi userà il prodotto, chi vi ha accesso, chi avrebbe interesse a comprometterlo. Poi i vettori: errore umano, concorrente, attaccante opportunista, insider. Poi si mette le mani sul dispositivo e si prova a entrare. Quello che regge diventa evidenza. Quello che cede diventa una correzione, fatta prima che lo trovi qualcun altro.”
Il valore, ai fini del CRA, è duplice. Da un lato il test produce le evidenze che riempiono il fascicolo tecnico e reggono davanti alla vigilanza del mercato. Dall’altro trova i problemi finché costano poco — in fase di progetto — invece che dopo, quando costano un richiamo o una notifica di incidente all’ENISA.
5. Il punto per chi decide
Per un CTO, R&D manager o un ufficio acquisti, la traduzione è immediata.
Primo: il testing di sicurezza non è una voce di spesa opzionale da tagliare a fine budget. Con il CRA è, di fatto, un requisito di ingresso al mercato — per i prodotti standard perché senza evidenze la dichiarazione è scoperta, per gli importanti perché senza evidenze non passate nemmeno l’organismo notificato.
Secondo: quando valutate un fornitore o un componente, la domanda giusta non è “è conforme al CRA?” ma “mostrami come lo hai verificato”. Una dichiarazione di conformità che parla solo di generici “requisiti di cybersecurity”, senza riferimento all’Allegato I e alla procedura di valutazione usata, è un segnale d’allarme.
Terzo: i tempi. Le scadenze del CRA sembrano lontane, ma la disponibilità di organismi notificati e di norme armonizzate no. Chi ha prodotti di classe importante e aspetta il 2027 è già fuori mercato.
“Mi chiedono se un prodotto è ‘a posto per il CRA'”, chiude Not. “La risposta onesta è: fammi vedere cosa hai provato. Se la risposta è una checklist, non hai provato niente, hai scritto un’intenzione. Il mercato, prima o poi, ti chiede il conto della promessa.”
Francesco Not opera con il marchio Hard Probe (hardprobe.eu). Il servizio di security assessment hardware e firmware è Hard Probe Cybersec.
