Il regolamento è in vigore dal 2024 ma le segnalazioni scattano ora, mentre le obbligazioni principali arriveranno nel 2027
Cosa succede quando il dispositivo connesso che avete progettato viene sfruttato attivamente a partire da domani, 11 settembre 2026? Non è più soltanto un problema tecnico: è un obbligo formale di notifica a ENISA e ai CSIRT nazionali entro 24 ore. Il Cyber Resilience Act (CRA), entrato in vigore il 10 dicembre 2024, disegna un paradosso temporale: le principali obbligazioni arriveranno solo l’11 dicembre 2027, mentre gli obblighi di segnalazione scattano già da domani.
Il percorso era partito il 15 settembre 2022, quando la Commissione europea aveva presentato la proposta legislativa per il Cyber Resilience Act, che introduce requisiti obbligatori di cibersicurezza per i prodotti con elementi digitali.
Domani non è un test: parte l’obbligo di segnalazione
Il calendario del CRA non è lineare. Il regolamento è in vigore dal 10 dicembre 2024, ma le principali obbligazioni si applicheranno solo dall’11 dicembre 2027; le segnalazioni, invece, diventano obbligatorie da domani. Per chi progetta, certifica o gestisce prodotti con elementi digitali, la scena del dispositivo sfruttato a partire dall’11 settembre non è più un’ipotesi: gli articoli 14 e 15 del regolamento impongono di informare l’Agenzia dell’Unione europea per la cibersicurezza (ENISA) e i CSIRT nazionali entro 24 ore dall’identificazione di vulnerabilità sfruttate attivamente o di incidenti gravi. Ma cosa significa operativamente per chi progetta e certifica? La risposta non sta nel calendario, bensì nei ruoli e nei processi.
Chi progetta, chi fa open source, chi certifica: cosa cambia davvero
La scadenza di domani obbliga a guardare dentro i ruoli. Quando un prodotto con elementi digitali viene sfruttato, la responsabilità non ricade più soltanto sull’ufficio tecnico: scatta una procedura formale che va eseguita entro 24 ore. Per i costruttori, il primo passo concreto è predisporre un canale interno di rilevazione e una procedura documentata di segnalazione, perché il termine decorre dall’identificazione della vulnerabilità o dell’incidente, non dalla conferma esterna.
Sul fronte del software open source, cambia la natura della responsabilità. Per la prima volta, l’Open Source Software Steward è ora un ruolo ufficiale ai sensi del diritto dell’Unione: la responsabilità si estende oltre la gestione leggera che diversi steward svolgono oggi. Stando a quanto indicato dalla Commissione, la guida di luglio 2026 ha affrontato specificamente le preoccupazioni relative all’ambito di applicazione del software open source (FOSS), rendendo più chiaro il perimetro per chi distribuisce o mantiene componenti aperti.
Per le microimprese e le PMI, il carico non è un’opinione. Il report SME CRA Survey di ENISA, pubblicato lo scorso giugno, quantifica l’onere di conformità che il CRA impone alle imprese più piccole. Secondo la Commissione, è questa la ragione per cui la nuova guida è destinata proprio alle microimprese e alle PMI. Fin qui i vincoli: ma come si trasformano in un piano d’azione, senza subire il carico amministrativo?
Tre azioni concrete e l’orizzonte transatlantico
Le leve sono tre. Primo, per i costruttori: attivare subito la procedura di notifica entro 24 ore a ENISA e ai CSIRT prevista dagli articoli 14 e 15 e usare il tempo fino all’11 dicembre 2027 per allineare prodotti e documentazione alle principali obbligazioni del CRA. Secondo, per gli steward open source: passare da una gestione leggera a un modello documentato, riconoscendo che l’Open Source Software Steward è ora un ruolo ufficiale e che la guida della Commissione di luglio 2026 chiarisce il perimetro FOSS. Terzo, per le microimprese e le PMI: usare il report ENISA per dimensionare il carico e la guida mirata della Commissione per pianificare le risorse, distinguendo l’obbligo di segnalazione, che scatta domani, dalle obbligazioni principali che arriveranno nel 2027.
Il mercato globale si muove nella stessa direzione. La Federal Communications Commission ha annunciato in queste ore la selezione di ioXt Alliance come Lead Administrator del programma U.S. Cyber Trust Mark, un programma volontario di etichettatura di cibersicurezza per prodotti IoT wireless di consumo, supervisionato dal Public Safety and Homeland Security Bureau. La differenza tra i due contesti è netta: negli Stati Uniti l’adesione al Cyber Trust Mark è volontaria, nell’Unione europea il quadro è cogente. Chi parte prima trasforma l’adempimento in un differenziale, in Europa e oltre.
Adeguarsi bene e per tempo al CRA non è una concessione alla complessità normativa: è il modo per trasformare un obbligo normativo in una licenza a competere, in Europa e oltre.
