Cyber Resilience Act: impatti per aziende

Il Cyber Resilience Act arriva in un punto in cui molte aziende hanno già capito che la sicurezza del software non può più restare affidata a policy interne o dichiarazioni di principio. Il cambio vero, però, sta altrove: il CRA non chiede soltanto prodotti più sicuri, chiede di dimostrarne la tenuta lungo il ciclo di vita, tra aggiornamenti, vulnerabilità, componenti di terzi e canali distributivi.

Per questo il regolamento non riguarda soltanto chi produce dispositivi connessi. Coinvolge chi sviluppa software, chi importa, chi distribuisce, chi integra componenti digitali dentro prodotti più ampi e chi deve gestire supporto e incidenti in modo tracciabile. Secondo la pagina ufficiale sugli obblighi di reporting e la sintesi della Commissione europea, gli obblighi di reporting sono entrati in applicazione l'11 settembre 2026 e la piena applicazione del regolamento è fissata all'11 dicembre 2027: con una parte degli obblighi già operativa e la piena applicazione ormai dentro l'orizzonte di pianificazione di prodotto.

Perché il Cyber Resilience Act cambia il contesto europeo

Il CRA sposta il baricentro della cybersecurity dal perimetro aziendale al prodotto. Chiede che hardware e software immessi sul mercato europeo arrivino con requisiti di sicurezza incorporati, processi di gestione delle vulnerabilità e responsabilità chiare lungo la filiera.

Dalla sicurezza opzionale alla security by design

La sintesi ufficiale della normativa spiega che il regolamento si applica ai prodotti con elementi digitali immessi sul mercato UE e impone requisiti essenziali di cybersecurity già nelle fasi di progettazione, sviluppo e produzione, oltre che per il periodo in cui il prodotto è destinato a restare in uso. Non basta correggere una falla quando il problema è ormai pubblico: bisogna poter dimostrare che la sicurezza è stata pensata a monte, governata nelle release e sostenuta nel tempo.

Questo mette pressione soprattutto sui modelli di sviluppo frammentati. Chi lavora con componenti open source, librerie di terzi, firmware fornito da partner o software integrato in prodotti fisici deve collegare più strettamente security engineering, documentazione tecnica e gestione del supporto. La guidance definitiva pubblicata dalla Commissione il 27 luglio 2026 chiarisce, tra gli altri aspetti, perimetro, modifiche sostanziali, periodo di supporto, software open source, remote data processing, reporting e valutazione del rischio: temi che trasformano il CRA da requisito legale a disciplina di prodotto.

Perché il tema riguarda anche le filiere

Il CRA non si ferma al produttore finale. Nella lettura delle FAQ ufficiali sull'implementazione, importatori e distributori hanno obblighi propri: devono verificare che il prodotto riporti marcatura CE, informazioni per l'utente, dati del fabbricante e indicazione del periodo di supporto; inoltre devono reagire se hanno motivo di ritenere che un prodotto non sia conforme. La conformità esce così dal reparto sviluppo ed entra nei contratti, nella qualifica fornitori e nelle verifiche di chi mette davvero il prodotto sul mercato.

Chi e coinvolto e quali prodotti rientrano nel perimetro

Molte letture superficiali trattano il CRA come se riguardasse soltanto device IoT o prodotti consumer. In realtà il campo è più ampio e tocca parecchi contesti B2B, industriali e software-based. Capire il perimetro con precisione serve a evitare sia sottovalutazioni sia adeguamenti costosi su prodotti già disciplinati da altre norme specifiche.

Nel manifatturiero, la convergenza tra OT e IT rende il tema particolarmente concreto per prodotti, macchine e piattaforme connesse, dove sicurezza, dato e continuità operativa si incontrano lungo lo stesso ciclo di vita.

Produttori, importatori, distributori e software

Il CRA definisce un quadro normativo orizzontale che riguarda prodotti hardware e software con elementi digitali, comprendendo sia i prodotti finiti sia i componenti commercializzati separatamente. Il perimetro interessa quindi anche chi sviluppa software stand-alone, moduli embedded o componenti destinati all’integrazione in soluzioni di terzi: non commercializzare un dispositivo fisico completo non significa, di per sé, essere esclusi dagli obblighi previsti dal regolamento.

Cambia anche la posizione di chi importa prodotti da fuori UE o li distribuisce a valle. Per aziende che operano come hub commerciali o system integrator, la domanda non e più soltanto se il prodotto funzioni: bisogna capire se il produttore ha impostato un modello credibile di compliance, aggiornamento e gestione delle vulnerabilità.

Cosa cambia per i prodotti con elementi digitali

La Commissione chiarisce che rientrano nel CRA i prodotti il cui uso previsto o ragionevolmente prevedibile comporta una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete. Questo amplia parecchio il perimetro: non si parla solo di oggetti esplicitamente connessi in cloud, ma di tutto ciò che incorpora funzioni digitali e dialoga in qualche modo con altri sistemi.

Non tutti i prodotti, però, seguiranno lo stesso percorso di conformità. La Commissione europea ha adottato il 28 novembre 2025 un atto di esecuzione che descrive tecnicamente le categorie di prodotti importanti e critici, e la sintesi ufficiale del CRA specifica che per i prodotti importanti di classe II e per quelli critici è richiesta una valutazione di terza parte oppure, quando disponibile, uno schema europeo di certificazione.

Gli obblighi più rilevanti per le aziende

Il valore pratico del CRA si misura negli obblighi che costringe a mettere a terra. Alcuni sono intuitivi sulla carta, molto meno quando bisogna calarli in roadmap di sviluppo, supporto clienti e processi di prodotto che oggi magari vivono ancora separati.

Vulnerability handling, aggiornamenti e documentazione

Il Regolamento (UE) 2024/2847 e la sintesi ufficiale del CRA insistono su un punto semplice da dire e complicato da governare: il produttore deve avere processi per gestire vulnerabilità, distribuire aggiornamenti di sicurezza e accompagnare il prodotto con informazioni e istruzioni comprensibili per l'utente. Il periodo di supporto, in linea generale, non può essere inferiore a cinque anni, salvo i prodotti attesi in uso per un periodo più breve; durante quel periodo le vulnerabilità devono essere gestite efficacemente. Questo trasforma la fine del supporto da scelta soltanto commerciale a decisione da documentare e sostenere operativamente.

Per chi sviluppa software, il tema si intreccia subito con backlog, rilascio patch, dependency management e capacità di mantenere una distinta aggiornata dei componenti. Per chi produce apparati o macchine connesse, entrano in gioco anche firmware, accessi remoti e compatibilità tra aggiornamenti e continuità operativa.

In questo quadro, la threat intelligence può aiutare a correlare vulnerabilità, sistemi esposti e priorità di intervento, migliorando la qualità del triage e rendendo più tempestive le decisioni di remediation.

Valutazione della conformità e incident reporting

Un altro passaggio concreto riguarda la conformità prima dell'immissione sul mercato e la gestione delle notifiche quando qualcosa va storto. La pagina della Commissione europea dedicata alla valutazione della conformità nel Cyber Resilience Act chiarisce che, prima di immettere un prodotto sul mercato, il fabbricante deve verificare il rispetto dei requisiti applicabili attraverso la procedura prevista per la relativa categoria di prodotto. Per molti prodotti è possibile ricorrere all'autovalutazione, mentre per alcune categorie considerate importanti o critiche può essere necessario il coinvolgimento di un organismo notificato. La scelta del percorso di conformità incide quindi direttamente su tempi, costi e organizzazione della documentazione tecnica.

Sul fronte del reporting, gli obblighi sono già operativi. Dall’11 settembre 2026 i fabbricanti devono utilizzare la CRA Single Reporting Platform (SRP), istituita da ENISA, per notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali. Le tempistiche richiedono processi interni già definiti: un early warning entro 24 ore dalla conoscenza dell’evento e una notifica completa entro 72 ore. Per le vulnerabilità attivamente sfruttate, il report finale deve essere trasmesso entro 14 giorni dalla disponibilità di una misura correttiva o di mitigazione; per gli incidenti gravi, entro un mese dalla notifica effettuata a 72 ore. Rispettare queste finestre implica stabilire in anticipo chi valuta l’evento, chi raccoglie le informazioni necessarie e come coordinare security, product management, legal e supporto.

Il mancato rispetto degli obblighi può avere conseguenze economiche rilevanti. Il Regolamento (UE) 2024/2847 prevede, per la violazione dei requisiti essenziali di cybersecurity e degli obblighi previsti dagli articoli 13 e 14, sanzioni amministrative fino a 15 milioni di euro oppure, per le imprese, fino al 2,5% del fatturato mondiale annuo dell’esercizio precedente, se superiore. Il sistema sanzionatorio rafforza quindi un principio centrale del CRA: sicurezza del prodotto, gestione delle vulnerabilità e capacità di reporting diventano responsabilità verificabili lungo l’intero ciclo di vita.

Come prepararsi senza leggerlo come un semplice adempimento

Le aziende che si muoveranno meglio non saranno per forza quelle con la documentazione più elegante, ma quelle capaci di usare il CRA per rimettere ordine in aspetti che spesso erano già fragili prima della norma: ownership del prodotto, visibilità sulle dipendenze, regole di supporto, governance degli aggiornamenti e coordinamento con la supply chain.

Allineare sviluppo, procurement e gestione fornitori

Una prima linea di lavoro consiste nel mettere intorno allo stesso tavolo funzioni che di solito si parlano tardi: sviluppo, product management, security, procurement, quality e legale. Se il prodotto incorpora componenti acquistati o software di terzi, la conformità si gioca anche nei requisiti contrattuali, nelle evidenze richieste ai partner e nella capacità di ricostruire rapidamente quali dipendenze siano coinvolte da una vulnerabilità.

Usare il CRA per ripulire il ciclo di vita del prodotto

C'è poi una lettura più utile della sola compliance: usare il regolamento come leva per ripensare il ciclo di vita del prodotto in modo più disciplinato. Significa avere criteri più chiari su release, hardening, fine supporto, comunicazioni agli utenti, gestione delle vulnerabilità e tracciabilità tecnica.

In questo senso il CRA va letto anche come un test di maturità industriale. Costringe le aziende a rendere esplicito quanto siano credibili le loro promesse di sicurezza dopo la vendita, quando il prodotto inizia davvero a vivere tra clienti, partner, integrazioni e incidenti possibili. Il vantaggio sta nel togliere ambiguità da tutto ciò che oggi rende fragile il rapporto tra prodotto digitale, filiera e fiducia del mercato.