1. Definire il prodotto e l'operatore responsabile
Un consulente CRA deve chiarire ambito del prodotto, ruolo giuridico e percorso di valutazione della conformità prima di commissionare prove o redigere dichiarazioni. Il risultato utile è una decisione motivata per famiglia di prodotti, non un'offerta di certificazione generica.
Il regolamento (UE) 2024/2847 è in vigore. Dall'11 settembre 2026 i fabbricanti devono segnalare vulnerabilità attivamente sfruttate e incidenti gravi; la maggior parte degli altri obblighi si applica dall'11 dicembre 2027. Occorre distinguere le due fasi.
1. Definire il prodotto e l'operatore responsabile
Individuate cosa viene effettivamente fornito sul mercato UE e da chi. Termini commerciali come «piattaforma» o «IoT» non risolvono l'applicabilità del CRA.
- Inventariate hardware, software, componenti venduti separatamente, versioni, destinazione d'uso, interfacce ed elaborazione remota necessaria alle funzioni.
- Identificate fabbricante, titolare del marchio, importatore e distributore; esaminate sviluppo su contratto e modifiche sostanziali senza attribuire tutto alla fabbrica.
- Verificate commercializzazione, esclusioni e norme settoriali UE; per l'open source conta l'attività effettiva, non soltanto la licenza.
2. Matrice dei percorsi: categoria e intensità delle prove non coincidono
Confrontate la funzione principale con l'allegato III (prodotti importanti) e IV (critici), incluse le descrizioni tecniche della Commissione, prima di scegliere ai sensi dell'articolo 32.
| Categoria del prodotto | Percorso strategico di valutazione |
|---|---|
| Categoria ordinaria | È possibile il controllo interno con modulo A; il laboratorio esterno non è automaticamente obbligatorio. |
| Importante, classe I | Il modulo A può essere ammesso se sono integralmente soddisfatte le condizioni pertinenti relative a norme armonizzate, specifiche comuni o certificazioni idonee; altrimenti occorre B+C o H con organismo notificato, salvo l’applicazione della specifica deroga dell’articolo 32, paragrafo 5, per il software libero e open source. |
| Importante, classe II | Prevedete B+C o H con organismo notificato oppure un regime UE di certificazione della cibersicurezza espressamente applicabile e disponibile ai sensi di legge; verificate inoltre la deroga dell’articolo 32, paragrafo 5, per il software libero e open source. |
| Critico (allegato IV) | Assumete come base il coinvolgimento dell'organismo notificato; verificate articolo 32 ed eventuali alternative di certificazione legalmente disponibili. |
Eccezione per i prodotti qualificabili come software libero e open source: ai sensi dell’articolo 32, paragrafo 5, i fabbricanti dei prodotti di cui all’allegato III possono ricorrere a una procedura prevista al paragrafo 1, incluso il modulo A, purché la documentazione tecnica di cui all’articolo 31 sia pubblicamente disponibile al momento dell’immissione sul mercato. Non è un’esenzione generale dal CRA.
Per la classe I, citare una bozza di norma o testare un punto non prova il diritto al modulo A. Registrate disposizione di classificazione, motivazione tecnica e incertezze residue.
3. Fatti che possono cambiare la raccomandazione
Il percorso dipende dalla classificazione, non dal nome commerciale o da una marcatura CE già apposta.
- Funzione principale di sicurezza: la funzione firewall può contare più del nome del dispositivo; integrare un componente non riclassifica automaticamente il prodotto finito.
- Modello di fornitura: componente venduto separatamente, firmware incorporato, dipendenza dal cloud, open source non commerciale e modifica sostanziale successiva richiedono esami diversi.
- Stato delle norme: distinguete norme armonizzate pubblicate con copertura pertinente da bozze, norme volontarie e prove che non soddisfano le condizioni legali del percorso.
4. Analisi delle lacune: collegare ogni carenza a una decisione
Confrontate gli obblighi applicabili dell'allegato I con controlli effettivi e prove utilizzabili. Un processo assente è diverso da un documento mancante.
| Lacuna o elemento | Prova e decisione |
|---|---|
| Classificazione incerta | Sospendere la scelta del percorso; ottenere prima architettura, uso previsto e analisi della categoria negli allegati. |
| Rischio nella progettazione sicura | Collegare modello delle minacce, configurazioni sicure predefinite, controllo degli accessi e prove alla valutazione dei rischi del prodotto. |
| Gestione delle vulnerabilità non dimostrata | Verificare titolare delle segnalazioni, ricezione degli avvisi, divulgazione coordinata, correzioni, aggiornamenti e motivazione del periodo di supporto. |
| Catena probatoria debole | Riconciliare inventario componenti/SBOM, attestazioni dei fornitori, copertura dei test, versioni e fascicolo tecnico; identificare ciò che va rifatto. |
Date priorità alle lacune che cambiano il percorso legale o ostacolano i controlli. Annotate separatamente lacuna, responsabile, prova, decisione e incertezza residua.
5. Riutilizzare prove senza ereditare conclusioni non giustificate
Penetration test, materiali ISO/IEC 27001, relazioni dei fornitori e documenti CE possono evitare duplicazioni, ma non dimostrano da soli la conformità CRA.
- Riutilizzate una relazione solo per prodotto/versione, rischio, requisito e metodo comparabili; annotate ambiti di verifica non più attuali e nuove prove necessarie.
- Collegate componenti di terzi e dipendenze software alla valutazione propria del fabbricante; i certificati dei fornitori non trasferiscono automaticamente la responsabilità.
- Allineate valutazione dei rischi, documentazione tecnica e processi sulle vulnerabilità con il percorso scelto.
6. Ordinare le decisioni prima dell'attuazione
La consulenza strategica deve lasciare un piano tracciabile, non promettere approvazioni automatiche.
- Creare registro per prodotto di ambito, ruoli ed esclusioni; segnalare classificazioni aperte.
- Redigere una relazione motivata sul percorso con allegati, stato delle norme e procedura, compresa l'eventuale dipendenza da organismi notificati.
- Ordinare lacune dell'allegato I, fascicoli e processi di supporto; assegnare team e decisioni sul riuso delle prove.
- Attivare separatamente il canale di segnalazione obbligatorio dall'11 settembre 2026, quindi preparare la conformità per l'11 dicembre 2027 valutando transizioni e modifiche per prodotto.
7. Dove finisce la consulenza e inizia l'attuazione
Questa pagina riguarda la scelta prima dell'esecuzione. Implementazione, coordinamento dei test e fascicolo tecnico sono attività distinte; il budget richiede un'analisi autonoma dei costi. Chiedete una classificazione motivata e l'elenco delle ipotesi irrisolte.
Fonti ufficiali primarie
Domande frequenti
Un backend SaaS rivolto all'UE rientra automaticamente nel CRA?
No. Accertate se l'elaborazione remota sia parte del prodotto con elementi digitali e necessaria alle funzioni; un servizio autonomo non equivale automaticamente a hardware. Analizzate architettura e contratti.
La classe I permette sempre l'autovalutazione?
No. Verificate le condizioni dell’articolo 32, paragrafo 2, relative a norme armonizzate, specifiche comuni o certificazione pertinente. Se non sono rispettate, occorre una procedura con organismo notificato, salvo l’applicazione della specifica deroga dell’articolo 32, paragrafo 5, per il software libero e open source.
L'impiego di codice aperto esclude il prodotto finale?
No. Contano commercializzazione del prodotto e ruolo dell'organizzazione. Le attività non commerciali legate al software libero e open source e le organizzazioni che ne sostengono stabilmente lo sviluppo richiedono analisi distinte.
E i dispositivi già commercializzati nell'UE?
Le segnalazioni dei fabbricanti sono obbligatorie dall'11 settembre 2026 anche per i prodotti interessati già disponibili. Per il 2027 esaminate prima immissione, modifiche sostanziali successive e disposizioni transitorie.
Un test di penetrazione o certificato ISO sostituisce la valutazione CRA?
No. Usate prove pertinenti, ma documentate separatamente ambito, rischi, condizioni del percorso, conformità e obblighi lungo il ciclo di vita.