Il Cyber Resilience Act sta entrando nella fase in cui le imprese non possono piu leggerlo come una norma europea lontana. La Commissione europea ha aggiornato a giugno 2026 le pagine operative sul regolamento e ha chiarito un passaggio molto concreto: dall'11 settembre 2026 i produttori dovranno segnalare vulnerabilita sfruttate attivamente e incidenti gravi che impattano la sicurezza dei prodotti con elementi digitali. Le altre obbligazioni principali del regolamento si applicheranno dall'11 dicembre 2027, ma la parte sulle segnalazioni arriva prima.
Questa anticipazione cambia il modo in cui un'impresa dovrebbe guardare ai propri prodotti software, ai dispositivi connessi, alle piattaforme digitali e ai fornitori tecnologici. Non basta chiedersi se un prodotto "funziona" o se il contratto e conveniente. Diventa necessario sapere chi gestisce le vulnerabilita, chi decide quando una criticita e rilevante, quali evidenze tecniche esistono, come si comunica un incidente e se la supply chain software e abbastanza trasparente da permettere una risposta rapida.
Per molte aziende, soprattutto PMI che sviluppano software, integrano soluzioni digitali o vendono prodotti con componenti connesse, il CRA non e solo un tema legale. E un tema di organizzazione interna, controllo dei fornitori e qualita del ciclo di vita digitale.
Che cosa cambia dall'11 settembre 2026
La pagina della Commissione sulle reporting obligations indica tre elementi chiave. Primo: i produttori dovranno inviare un early warning entro 24 ore da quando vengono a conoscenza di una vulnerabilita sfruttata attivamente o di un incidente grave. Secondo: dovranno trasmettere una notifica completa entro 72 ore. Terzo: dovranno presentare una relazione finale entro 14 giorni dalla disponibilita di una misura correttiva per le vulnerabilita sfruttate attivamente, oppure entro un mese per gli incidenti gravi.
La segnalazione passera attraverso la CRA Single Reporting Platform, che ENISA dovra rendere operativa entro l'11 settembre 2026. L'obiettivo dichiarato e evitare duplicazioni: il produttore segnala una sola volta attraverso la piattaforma, con indirizzamento al CSIRT competente e disponibilita delle informazioni a ENISA, salvo specifiche eccezioni.
Per un'impresa, pero, il punto non e solo "a quale portale inviare la notifica". Il punto e essere pronti prima che l'orologio delle 24 ore inizi a correre. Se un'azienda scopre una vulnerabilita critica e non sa quali versioni sono coinvolte, quali clienti usano il prodotto, quale componente open source e interessato o chi deve validare la comunicazione, il problema non e amministrativo. E operativo.
La supply chain software entra nella gestione del rischio
Il CRA copre prodotti con elementi digitali e introduce obblighi di cybersecurity lungo il ciclo di vita. La Commissione richiama espressamente pianificazione, progettazione, sviluppo e manutenzione. Questo significa che la sicurezza non puo essere aggiunta a valle, dopo il rilascio, come se fosse un controllo finale.
Nella pratica, molte imprese dipendono da librerie open source, package manager, framework, servizi cloud, componenti firmware, API di terze parti e moduli sviluppati da fornitori. La domanda diventa semplice: se domani una dipendenza critica risulta vulnerabile, l'azienda sa dove viene usata?
Qui entra in gioco la SBOM, la Software Bill of Materials. ENISA ha pubblicato a giugno 2026 un report sullo stato di adozione della SBOM, collegandolo proprio alla spinta del Cyber Resilience Act. Secondo la sintesi dell'Agenzia, le organizzazioni stanno investendo in generazione e automazione della SBOM per integrarla nel ciclo di sviluppo software e accelerare i tempi di maturazione.
La SBOM non e una bacchetta magica e non sostituisce una vera gestione delle vulnerabilita. Ma puo diventare una base concreta per rispondere a tre domande che in caso di incidente sono decisive: che cosa c'e dentro il prodotto, quali versioni sono coinvolte e quali clienti o ambienti potrebbero essere esposti.
PMI: il rischio e scoprire troppo tardi di non essere pronte
ENISA ha pubblicato il 24 giugno 2026 anche un report dedicato alle PMI e al CRA, basato su una survey condotta tra febbraio e marzo 2026. L'obiettivo era capire quanto le piccole e medie imprese conoscano il regolamento, quanto comprendano i requisiti pratici, che cosa stiano gia facendo in cybersecurity e quali difficolta prevedano nel percorso di adeguamento.
Questo punto e importante perche molte PMI non si percepiscono come "produttori digitali", anche quando vendono software verticale, dispositivi IoT, sistemi di automazione, componenti embedded o piattaforme integrate in processi industriali. In altri casi sono integratori o distributori che non sviluppano tutto internamente, ma mettono insieme soluzioni che finiscono dentro l'operativita del cliente.
Il rischio e trattare il CRA come un fascicolo normativo da aprire nel 2027. In realta, la scadenza dell'11 settembre 2026 sulle segnalazioni impone di anticipare almeno alcune decisioni: chi e responsabile della gestione delle vulnerabilita, come vengono raccolte le informazioni dai fornitori, quali canali esistono per ricevere segnalazioni esterne, come si valuta la gravita di un incidente e chi autorizza le comunicazioni.
Fornitori: il contratto deve parlare anche di sicurezza
Per gli imprenditori e i responsabili IT, una conseguenza pratica e la revisione dei rapporti con i fornitori. Non serve trasformare ogni contratto in un trattato tecnico, ma alcune clausole e alcuni allegati diventano indispensabili.
Prima domanda: il fornitore consegna informazioni sufficienti sui componenti software usati? Seconda: esiste un impegno chiaro sulla comunicazione delle vulnerabilita che impattano il prodotto o il servizio? Terza: sono definiti tempi, ruoli e canali per patch, workaround e aggiornamenti? Quarta: l'impresa cliente ha diritto a ricevere evidenze tecniche comprensibili, non solo rassicurazioni generiche?
Queste domande sono particolarmente rilevanti nei progetti ERP, nelle integrazioni dati, nei sistemi di produzione, nei portali clienti e nelle soluzioni cloud personalizzate. Un prodotto puo essere perfettamente utile dal punto di vista funzionale e debole dal punto di vista della tracciabilita. Il CRA spinge il mercato verso una maggiore responsabilita documentale: non basta dire che un sistema e sicuro, bisogna poter dimostrare come viene mantenuto sicuro.
Prepararsi senza burocratizzare tutto
Una risposta efficace non richiede necessariamente strutture pesanti. Richiede metodo. Il primo passo e censire i prodotti e servizi digitali che l'impresa sviluppa, vende, integra o mantiene. Il secondo e distinguere i ruoli: produttore, distributore, importatore, integratore, cliente utilizzatore. Il terzo e costruire una procedura minima di vulnerability handling: ricezione della segnalazione, triage, valutazione impatto, decisione tecnica, comunicazione, rilascio correzione e conservazione delle evidenze.
Il quarto passo riguarda la supply chain. Per ogni prodotto critico bisogna sapere quali componenti esterne sono usate, chi le monitora, dove sono documentate e con quale frequenza vengono aggiornate. Se una SBOM completa non e ancora disponibile, si puo partire dai prodotti piu esposti e dalle dipendenze piu rilevanti, evitando di trasformare il progetto in un esercizio enciclopedico che non produce decisioni.
Il quinto passo e formare le persone giuste. Non solo gli sviluppatori. Anche commerciale, assistenza clienti, legal, procurement e direzione devono capire quando una segnalazione tecnica puo diventare un tema regolatorio e reputazionale.
Una checklist operativa per i prossimi mesi
Prima dell'11 settembre 2026, un'impresa dovrebbe riuscire almeno a rispondere a queste domande.
Quali prodotti o servizi rientrano potenzialmente nel perimetro del Cyber Resilience Act? Chi e il responsabile interno per la gestione delle vulnerabilita? Esiste un canale documentato per ricevere segnalazioni da clienti, ricercatori o fornitori? I tempi interni consentono di rispettare una finestra di early warning di 24 ore? I fornitori sono obbligati a comunicare rapidamente vulnerabilita e incidenti rilevanti? Esiste un inventario, anche progressivo, dei componenti software piu critici? Le decisioni tecniche vengono conservate in modo verificabile?
Questa checklist non esaurisce il CRA, ma aiuta a spostare il lavoro dal piano astratto al piano gestionale.
Il punto vero: rendere governabile il rischio digitale
Il Cyber Resilience Act non riguarda solo chi produce tecnologia in senso stretto. Riguarda un mercato in cui quasi ogni prodotto, servizio o processo d'impresa contiene software, connessioni, dati e dipendenze esterne. Le scadenze europee servono a fissare un perimetro, ma la qualita della risposta dipende dalla capacita delle aziende di conoscere cio che vendono, acquistano e mantengono.
Per questo il CRA dovrebbe essere letto insieme alla governance IT e alla gestione dei fornitori. Le imprese piu pronte non saranno necessariamente quelle con piu documenti, ma quelle che sapranno trasformare vulnerabilita, SBOM, incidenti e contratti in un sistema di responsabilita chiaro.
Prepararsi ora significa evitare la corsa dell'ultimo minuto. Significa soprattutto costruire un modo piu maturo di governare il digitale: meno affidato alla fiducia implicita, piu basato su evidenze, ruoli e tempi di reazione.
Fonti
- Commissione europea, "Cyber Resilience Act – Reporting obligations", aggiornamento 8 giugno 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- Commissione europea, "Cyber Resilience Act", aggiornamento 22 giugno 2026: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- ENISA, "SBOM Adoption State of Play – 2026", 9 giugno 2026: https://www.enisa.europa.eu/publications/sbom-adoption-state-of-play-2026
- ENISA, "SME CRA Survey Report", 24 giugno 2026: https://www.enisa.europa.eu/publications/sme-cra-survey-report
- ENISA, "Technical Advisory for Secure Use of Package Managers", 10 marzo 2026: https://www.enisa.europa.eu/publications/enisa-technical-advisory-for-secure-use-of-package-managers