Articolo di esempio — questo è un placeholder per testare la content collection e il routing del blog.
Il CRA (Cyber Resilience Act) entra in applicazione il 10 dicembre 2027 per la maggior parte delle categorie di prodotti. In molte aziende la risposta standard è aprire un progetto di documentazione. È la risposta sbagliata.
Il problema non è la documentazione
La documentazione è l’output. Il problema è il processo che la genera — o meglio, la sua assenza.
I requisiti tecnici del CRA — SBOM aggiornata, gestione delle vulnerabilità, aggiornamenti sicuri, periodo di supporto dichiarato — non si soddisfano compilando moduli. Si soddisfano costruendo pratiche di sviluppo diverse da quelle che la maggior parte delle aziende manifatturiere ha oggi.
Un’azienda che non ha mai prodotto una SBOM del proprio firmware non ha un problema di documentazione. Ha un problema di toolchain, di processo di rilascio e di visibilità sulle dipendenze. La documentazione viene dopo.
Cosa cambia davvero
Tre aree dove il CRA impatta le decisioni di R&D:
-
Gestione delle dipendenze software: ogni componente open source incluso nel firmware diventa una responsabilità tracciabile. Non basta sapere che usi OpenSSL — devi sapere quale versione, da dove arriva, chi monitora le CVE su quel componente.
-
Meccanismo di aggiornamento: il CRA richiede che i prodotti possano ricevere patch di sicurezza. Per prodotti embedded che oggi non hanno OTA, questo cambia il design hardware e firmware, non solo la documentazione.
-
Periodo di supporto: devi dichiarare per quanto tempo manterrai il prodotto sicuro. Per molti produttori industriali, dove i prodotti durano 10–15 anni sul campo, questa è una decisione strategica, non tecnica.
Il passo successivo
Se stai valutando l’impatto del CRA sul tuo prodotto, il modo più efficiente è una sessione di 45 minuti per mappare il tuo profilo normativo. È gratuita e non richiede impegno.