Se siamo una software house italiana, e sviluppiamo gestionali, soluzioni cloud, MES o applicazioni per l’industria 4.0, probabilmente nelle ultime settimane avremo sentito parlare del Cyber Resilience Act.
Qualcuno lo descrive come il GDPR del software. Altri, più cautamente, lo definiscono il tentativo dell’Unione Europea di mettere ordine nella giungla di prodotti digitali che ogni giorno vengono immessi sul mercato, spesso senza garanzie minime di sicurezza.
Ma cosa cambia davvero? E soprattutto: cosa significa questo nuovo regolamento per chi scrive codice tutti i giorni, per chi costruisce piattaforme, API, soluzioni verticali? Per chi lavora in Italia, tra bandi, gare pubbliche e clienti industriali sempre più esigenti?
In questo articolo, cerchiamo di andare oltre i titoli sensazionalistici e offrire una lettura utile, concreta, “da dentro”, per aiutare le aziende italiane del software a orientarsi tra categorie di rischio, obblighi, certificazioni e scadenze.
Indice degli argomenti
Cyber Resilience Act: una legge nata da un’urgenza
Negli ultimi anni, la cyber security è uscita dal perimetro degli “addetti ai lavori” ed è diventata una questione di interesse pubblico. Troppi incidenti, troppe vulnerabilità banali in prodotti venduti a milioni di utenti, troppi dispositivi connessi che entrano nelle nostre case, negli ospedali, nelle fabbriche, senza alcuna garanzia strutturale di sicurezza.
Da qui nasce il Cyber Resilience Act: un regolamento europeo che impone requisiti minimi di sicurezza informatica per tutti i prodotti digitali immessi nel mercato UE siano essi hardware o software.
L’idea è semplice, ma potente: chi sviluppa e vende tecnologia deve garantire che quella tecnologia sia sicura per tutto il suo ciclo di vita.
Non tutti i software sono uguali: la classificazione è tutto
Il punto più delicato – e più importante – del CRA è la classificazione dei prodotti. In base al loro livello di rischio per la sicurezza informatica, i prodotti digitali vengono suddivisi in tre categorie:
- Categoria predefinita: include la maggior parte dei prodotti software e hardware comuni. Qui il produttore può effettuare un’autovalutazione interna della conformità, predisporre la documentazione tecnica prevista e apporre il marchio CE in autonomia.
- Prodotti “importanti”: sono strumenti che svolgono funzioni rilevanti per la sicurezza o che operano in contesti sensibili, come sistemi di autenticazione, software di gestione delle identità, piattaforme di sicurezza. Per questi è obbligatorio il coinvolgimento di un organismo notificato indipendente, che effettui una valutazione tecnica della conformità.
- Prodotti “critici”: comprendono firewall, sistemi di rilevamento delle intrusioni, HSM, strumenti di controllo industriale, firmware per dispositivi connessi in ambienti ad alta esposizione. Qui il percorso di certificazione è ancora più rigoroso e richiede prove formali di sicurezza, audit e verifiche strutturate.
È questa classificazione a determinare il percorso che ogni software dovrà affrontare per essere conforme.
E i software aziendali dove stanno?
Qui arriva la domanda che molti si pongono: “Il mio software gestionale, il mio ERP, il mio CRM SaaS… deve essere certificato da un ente terzo oppure posso cavarmela con l’autovalutazione?”.
La risposta, in generale, è rassicurante. La grande maggioranza delle soluzioni aziendali, se non interagisce direttamente con ambienti OT o non svolge funzioni di sicurezza avanzata, resterà nella categoria predefinita.
Questo significa che sarà sufficiente predisporre la documentazione richiesta, fare un’analisi del rischio coerente con i requisiti del CRA e mantenere una gestione trasparente delle vulnerabilità.
Molto diverso invece è il discorso per i MES, i SCADA, i software di supervisione industriale, i programmi per la programmazione di PLC o la gestione dei robot. Questi strumenti, anche se tecnicamente sono “software”, sono di fatto parte integrante dell’ecosistema OT, e quindi soggetti a un rischio molto più alto.
Il regolamento li tratta come prodotti critici, e per loro sarà necessario passare da un processo di certificazione strutturato, con test, audit, documentazione e verifica esterna.
Le scadenze del Cyber Resilience Act
Le scadenze del CRA sono state pensate per dare tempo alle aziende di adeguarsi, ma non sono così lontane come potrebbe sembrare: c’è tempo, ma serve partire ora.
Il regolamento è entrato in vigore ufficialmente il 10 dicembre 2024, ma i primi obblighi scatteranno già l’11 settembre 2026, quando diventerà obbligatoria la notifica delle vulnerabilità e degli incidenti rilevanti.
La scadenza più importante è fissata per l’11 dicembre 2027: da quel giorno, nessun prodotto digitale potrà essere venduto nell’Unione Europea se non sarà conforme al CRA.
Tre anni possono sembrare tanti, ma per un’azienda che deve ripensare i propri processi di sviluppo, aggiornare la documentazione tecnica, formare i team e – se necessario – affrontare un percorso di certificazione con un ente terzo, non sono affatto un’eternità.
Una checklist per partire con il piede giusto
Per chi si trova oggi a capo di una software house – grande o piccola che sia – e vuole capire da dove cominciare, ecco una breve checklist operativa:
- Analizzare i propri prodotti: a chi sono destinati? In che contesti vengono usati?
- Identificare le componenti digitali e le eventuali dipendenze (librerie, moduli, framework).
- Valutare se si rientra nella categoria predefinita o se esiste un rischio di classificazione come “importante” o “critico”.
- Predisporre una SBOM (Software Bill of Materials), che sarà uno dei requisiti principali di trasparenza.
- Iniziare a documentare i processi di sviluppo, i test di sicurezza, le misure di gestione delle vulnerabilità.
- Coinvolgere un consulente esperto in sicurezza software e normativa UE, per una gap analysis preliminare.
Il CRA come occasione per cambiare marcia
Se da un lato il Cyber Resilience Act impone nuovi obblighi, dall’altro rappresenta anche una straordinaria opportunità di crescita per le aziende italiane del software. Perché costringe a strutturarsi, a pensare alla sicurezza come parte integrante del processo di sviluppo, a dotarsi di strumenti e procedure che aumentano il valore del prodotto.
Chi sarà in grado di dimostrare – con documenti, metriche e processi – che il proprio software è sicuro, mantenuto, aggiornato e conforme, avrà un vantaggio competitivo enorme. Non solo sul mercato europeo, ma ovunque la sicurezza stia diventando un criterio di scelta, e non solo un costo da giustificare.
Il CRA è un cambiamento profondo, e non sarà indolore. Ma proprio per questo, è il momento giusto per investire in cultura, formazione, strumenti e relazioni.
Perché la vera cyber resilienza non si compra: si costruisce.
