Security by design: i requisiti essenziali dell'Allegato I CRA

L'Allegato I del Regolamento (UE) 2024/2847 (CRA) fissa il principio guida per ogni prodotto con elementi digitali: deve essere progettato, sviluppato e prodotto per garantire un livello di cybersicurezza adeguato ai rischi. Non è uno slogan da manuale marketing: è un requisito essenziale che devi dimostrare, non solo rispettare. Se fabbrichi macchine connesse, dispositivi IoT o qualsiasi prodotto con software integrato, questo allegato ti riguarda direttamente.

Cosa chiede in concreto l'Allegato I

Tre requisiti tornano più spesso nelle contestazioni di non conformità.

Primo: il prodotto non deve avere vulnerabilità note al momento dell'immissione sul mercato. Non basta dire "lo abbiamo testato": devi dimostrare che hai verificato le vulnerabilità pubblicamente note per i componenti usati, incluse le librerie di terze parti.

Secondo: la configurazione di default deve essere sicura. Il prodotto, appena tolto dalla scatola, deve già proteggersi da solo, senza che l'utente debba attivare nulla.

Terzo: i dati trattati dal prodotto vanno protetti per impostazione predefinita e per progettazione. Non è un requisito GDPR duplicato: è un requisito di sicurezza tecnica che riguarda come il prodotto gestisce le informazioni che elabora.

L'errore che torna sempre: la password uguale per tutti

Password identica su ogni esemplare uscito dalla linea di produzione è l'esempio più citato di configurazione non sicura di default. Il ragionamento è semplice: se un attaccante scopre la password su un esemplare, la conosce per tutti gli altri in circolazione. Non è un dettaglio da manuale utente, è una falla strutturale nella progettazione.

L'Allegato I chiede che ogni prodotto abbia una configurazione sicura propria, oppure un meccanismo che obblighi l'utente a cambiare le credenziali di default al primo utilizzo. Password condivise e statiche non superano nessuna valutazione di conformità seria.

se il tuo prodotto esce di fabbrica con credenziali identiche per tutti gli esemplari e senza obbligo di modifica, hai un problema di conformità all'Allegato I, non solo un problema di sicurezza teorica.

Documentare le scelte, non solo farle

Qui sta il punto che molti fabbricanti sottovalutano: progettare in sicurezza non basta, devi documentare perché hai scelto quella soluzione e non un'altra. La valutazione dei rischi di cybersicurezza deve risultare per iscritto: quali minacce hai considerato, quali contromisure hai adottato, perché le ritieni adeguate al rischio.

Questo significa tenere traccia di:

• l'analisi delle vulnerabilità note sui componenti usati, con data e fonte della verifica;
• la logica della configurazione di default e perché la ritieni sicura;
• le misure di protezione dei dati trattati dal prodotto, distinte da quelle previste per la privacy;
• le decisioni di progettazione scartate e il motivo, se rilevanti per dimostrare un percorso ragionato.

Un fascicolo tecnico che mostra solo il risultato finale, senza il percorso decisionale, lascia scoperto proprio il punto che un organismo di controllo verifica per primo: hai valutato il rischio o hai solo copiato una configurazione standard.

Cosa significa per te

• Verifica se il tuo prodotto ha vulnerabilità note sui componenti software prima di immetterlo sul mercato, non dopo.
• Elimina le password di default condivise: imponi il cambio al primo avvio o genera credenziali uniche per esemplare.
• Scrivi la valutazione dei rischi di cybersicurezza come documento a parte, con data e motivazioni, non come nota a margine del fascicolo tecnico.
• Distingui nella documentazione la protezione dei dati richiesta dal CRA da quella richiesta dal GDPR: sono requisiti diversi, anche se si sovrappongono.
• Rivedi periodicamente la configurazione di default quando aggiorni firmware o software, perché il requisito vale per tutto il ciclo di vita, non solo al lancio.

Clausify verifica che il fascicolo tecnico e le istruzioni documentino davvero le scelte di sicurezza richieste dal CRA, non solo che le dichiarino.