Scadenza CRA all'11 settembre 2026: obblighi di segnalazione, sanzioni fino a 15 milioni di euro e cosa deve fare chi produce macchinari o software connessi. Guida pratica per PMI manifatturiere.
Il 11 settembre 2026 non segna la scadenza finale del Cyber Resilience Act (CRA) — fissata per il dicembre 2027 — ma rappresenta il primo impegno con effetti immediati e vincolanti. In quella data, infatti, entra in vigore l'articolo 14 del Regolamento, che obbliga i fabbricanti di prodotti con elementi digitali a segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi entro tempistiche stringenti, a partire da un pre-allarme di 24 ore. Per un'azienda manifatturiera che produce macchinari, impianti o sistemi di automazione connessi, questo implica la necessità di avere già oggi — e non tra un anno — un processo di incident response funzionante e documentabile.
Cosa cambia esattamente con l'articolo 14
Il CRA (Regolamento UE 2024/2847) introduce per la prima volta requisiti orizzontali di cybersecurity per tutti i "prodotti con elementi digitali" immessi sul mercato UE: qualsiasi hardware o software, incluse le soluzioni di elaborazione dati da remoto, la cui connessione a un dispositivo o a una rete sia diretta o indiretta. L'obbligo di segnalazione previsto dall'articolo 14 si articola su tre passaggi, verso ENISA e verso il CSIRT nazionale competente (in Italia l'Agenzia per la Cybersicurezza Nazionale):
- Pre-allarme entro 24 ore dal momento in cui l'azienda viene a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave: notifica sintetica.
- Notifica completa entro 72 ore: analisi preliminare dell'impatto, gravità del problema, eventuali contromisure o patch già predisposte.
- Rapporto finale: entro 14 giorni dalla disponibilità di una misura correttiva (per una vulnerabilità) o entro un mese dalla notifica a 72 ore (per un incidente grave), con descrizione completa, gravità, impatto e correzione applicata.
Comprendere questa sequenza è fondamentale: il regolamento presuppone che l'azienda abbia già internamente chi individua la vulnerabilità, chi ne valuta la gravità e chi scrive la notifica nei tempi previsti — non un processo da costruire dopo il primo incidente.
Le sanzioni: multe fino a 15 milioni di euro
Il regime sanzionatorio del CRA è, per portata, paragonabile a quello di GDPR e NIS2. La mancata osservanza degli obblighi di notifica dell'articolo 14 comporta sanzioni fino a:
- 15 milioni di euro, oppure il 2,5% del fatturato globale annuo dell'esercizio precedente, se superiore;
- fino a 10 milioni di euro (o il 2% del fatturato mondiale) per la non conformità su rappresentanti autorizzati, marcatura CE, documentazione tecnica e valutazione di conformità;
- fino a 5 milioni di euro (o l'1% del fatturato) per informazioni inesatte o fuorvianti fornite alle autorità.
Ma l'impatto economico diretto della multa non è, quasi mai, il rischio più rilevante per una PMI fornitrice. In una filiera B2B, un fornitore che gestisce male una vulnerabilità nota può innescare una compromissione a catena presso i clienti a valle — con richieste di risarcimento, esclusione da gare pubbliche e perdita di fiducia commerciale che pesano più della sanzione stessa. La sicurezza dei prodotti connessi, inoltre, non è più confinata all'IT: diventa responsabilità diretta del management, esposto a contestazioni per governance inadeguata.
Glossario tecnico semplificato
- Vulnerabilità attivamente sfruttata: Non è un bug teorico o ipotetico. È una falla di sicurezza che gli attaccanti stanno già usando ora per penetrare nei sistemi. La notifica di 24 ore scatta solo in questo caso specifico.
- Incidente grave: Qualsiasi evento che comprometta la riservatezza, l'integrità o la disponibilità dei dati o del sistema, causando danni significativi agli utenti o alle infrastrutture critiche.
- SBOM (Software Bill of Materials): È la "ricetta" o la distinta base del software. È un elenco strutturato di tutti i componenti, librerie e dipendenze usate nel prodotto. Serve per verificare rapidamente se una vulnerabilità nota (come Log4j) riguarda i vostri sistemi.
- Secure SDLC (Software Development Life Cycle): L'insieme di processi e pratiche integrate nel ciclo di sviluppo software per garantire la sicurezza fin dalla prima fase di progettazione, non come aggiunta finale. Include test di vulnerabilità e penetration test.
- CVD (Coordinated Vulnerability Disclosure): Un processo formale che permette ai ricercatori di sicurezza di segnalare le vulnerabilità ai produttori in modo sicuro e coordinato, evitando la pubblicazione pubblica del bug prima che sia stata rilasciata una patch.
- CSIRT (Computer Security Incident Response Team): Il team nazionale di risposta agli incidenti informatici. In Italia, è gestito dall'Agenzia per la Cybersicurezza Nazionale (ACN). È l'ente a cui bisogna inviare le notifiche.
- ENISA: L'Agenzia dell'Unione Europea per la cybersicurezza. È l'ente europeo di riferimento per la supervisione e la raccolta delle segnalazioni relative al CRA.
Cosa chiedono in pratica le linee guida UE
Oltre alla scadenza di settembre, le linee guida interpretative della Commissione Europea chiariscono alcuni punti operativi utili a chi pianifica l'adeguamento:
| Tema | Cosa prevede |
|---|---|
| Periodo di supporto | Il minimo di 5 anni indicato dal regolamento non è un tetto: per un macchinario industriale pensato per durare 10-15 anni, le patch di sicurezza vanno garantite per l'intera vita utile attesa. |
| Open source | Sviluppo no-profit escluso dal campo di applicazione; se un'azienda integra codice open source in un prodotto commerciale o lo distribuisce con assistenza a pagamento, la responsabilità della conformità passa interamente a lei. |
| SBOM | La distinta base del software (elenco strutturato di componenti, librerie e dipendenze) è ciò che permette di verificare in poche ore se una vulnerabilità nota — come nel caso storico di Log4j — riguarda i propri sistemi. |
| Classificazione del rischio | I prodotti sono divisi in Standard, Importanti (Classe I/II) e Critici in base alla funzione svolta. Un sistema con funzioni di sicurezza primaria (firewall, gestione identità) richiede la certificazione di un ente terzo, non la sola autovalutazione. |
Cosa fare da qui a settembre: la checklist pratica
Per non arrivare impreparati alla scadenza:
- Censire i prodotti connessi, a catalogo e in sviluppo, e assegnare a ciascuno la classe di rischio in base alla funzione svolta.
- Costruire e mantenere aggiornata la SBOM, con strumenti automatizzati capaci di verificare rapidamente l'esposizione a vulnerabilità note su componenti terzi.
- Integrare un Secure SDLC (Software Development Life Cycle, ovvero il ciclo di vita dello sviluppo software sicuro), con vulnerability assessment e penetration test periodici, allineandosi a standard come ISO/IEC 27001 e ISO/IEC 62443.
- Formalizzare il processo di incident response e Coordinated Vulnerability Disclosure (CVD), con un canale pubblico dedicato alle segnalazioni di ricercatori esterni e un flusso testato — non un documento in un cassetto — che rispetti i tempi 24h/72h/14gg.

Il nodo per una PMI manifatturiera
Il problema pratico non è capire cosa fare — gli obblighi dell'articolo 14 sono pubblici — ma arrivare a settembre con un processo che funzioni davvero nei tempi richiesti: rilevare una vulnerabilità, valutarne la gravità e notificarla entro 24 ore richiede visibilità continua sugli asset connessi, non solo una policy interna. È il tipo di lavoro dove uno strumento dedicato, capace di tenere SBOM, inventario asset e triage delle vulnerabilità in un unico posto, fa la differenza tra gestire l'obbligo o rincorrerlo a ridosso della scadenza — o del primo incidente.
FAQ: Domande frequenti sul Cyber Resilience Act
Quando scattano gli obblighi di segnalazione del CRA? Dall'11 settembre 2026 entra in vigore l'articolo 14, con obbligo di notifica delle vulnerabilità attivamente sfruttate e degli incidenti gravi entro 24/72 ore e un rapporto finale successivo.
Quali sono le sanzioni per la mancata segnalazione? Fino a 15 milioni di euro o al 2,5% del fatturato globale annuo, se superiore. Sanzioni minori (fino a 10 milioni/2% o 5 milioni/1%) si applicano ad altre violazioni di conformità.
Chi deve rispettare il CRA? Fabbricanti, importatori e distributori di "prodotti con elementi digitali" — qualsiasi hardware o software che si connette, direttamente o indirettamente, a un dispositivo o a una rete.
Cos'è la SBOM e perché serve? È l'elenco strutturato di tutti i componenti software, librerie e dipendenze usati in un prodotto. Permette di verificare rapidamente l'esposizione a una vulnerabilità nota su un componente terzo.
Il CRA riguarda anche il software open source? No, se sviluppato senza scopo di lucro. Se un'azienda lo integra in un prodotto commerciale o lo distribuisce con assistenza a pagamento, la responsabilità della conformità passa a lei.
Quando si applica pienamente il CRA? La piena applicazione del Regolamento è fissata per dicembre 2027, ma gli obblighi di segnalazione dell'articolo 14 sono vincolanti già dall'11 settembre 2026.
Fonti:
- Regolamento (UE) 2024/2847 (Cyber Resilience Act) — testo consolidato su EUR-Lex — link
- Commissione Europea, "Cyber Resilience Act", Shaping Europe's Digital Future — link
Contenuti correlati:
- Scadenza NIS2 e Multe: Cosa Cambia da Settembre e Chi Deve Muoversi
- Digitalizzazione Carpenteria Metallica: Riduci Scarti, AI e Conformità CE
- Il problema non è solo subire un attacco: quando lo scopri è già tardi
- Cybersecurity nelle PMI Manifatturiere Italiane: Perché Antivirus e Firewall Non Bastano Più
Contatta il nostro team per affrontare il Cyber Resilience Act
Basta compilare il form e sarai contattato non appena possibile dal nostro team.

