Torna alla home
Normative

Cosa impone davvero il Cyber Resilience Act

SM

Simone Mammola | CompTIA Security+ & CCST Cybersecurity Certified

· 12 min di lettura

Immagine di copertina: Cosa impone davvero il Cyber Resilience Act

Dall'11 settembre 2026 il Cyber Resilience Act impone ai fabbricanti di prodotti con elementi digitali di segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi entro ventiquattro ore dalla presa di conoscenza. È il primo obbligo del regolamento che ricade direttamente sui fabbricanti e arriva quindici mesi prima della piena applicazione. La tesi di questa analisi è che la difficoltà dell'adempimento non stia nella brevità dei termini, ma nella precisione richiesta nell'individuare il momento che fa partire la sequenza, e nel documentarlo.

Che cosa è scattato l'11 settembre

Il regolamento (UE) 2024/2847, adottato il 23 ottobre 2024 e pubblicato nella Gazzetta ufficiale dell'Unione europea il 20 novembre dello stesso anno, è in vigore dal 10 dicembre 2024. La sua applicazione è però scaglionata su tre date, e solo la terza riguarda il corpo principale delle disposizioni.

Il Cyber Resilience Act non è entrato in vigore venerdì scorso: è diventato applicabile un solo articolo, con quindici mesi di anticipo su tutto il resto del regolamento. L'11 giugno 2026 era entrato in applicazione il capo IV, sulla notifica degli organismi di valutazione della conformità: un passaggio amministrativo, rivolto agli Stati membri e agli organismi certificatori. L'11 settembre 2026 è diventato applicabile l'articolo 14, sugli obblighi di segnalazione dei fabbricanti, ed è il primo adempimento che tocca direttamente chi costruisce prodotti. L'11 dicembre 2027 arriverà tutto il resto: requisiti essenziali di cibersicurezza, valutazione della conformità, marcatura CE, documentazione tecnica.

Lo stesso 11 settembre l'ENISA ha messo in esercizio la capacità operativa iniziale della piattaforma unica di segnalazione. La scadenza normativa e l'infrastruttura tecnica destinata a riceverne gli effetti sono arrivate nello stesso giorno.

Che cosa si segnala, e che cosa no

È la distinzione che le sintesi divulgative perdono più spesso, e la sua ricaduta pratica è considerevole: senza di essa un'azienda finisce per credere di dover notificare ogni voce del proprio registro delle vulnerabilità.

L'obbligo non riguarda ogni vulnerabilità scoperta nel codice, ma solo quelle per cui esiste prova affidabile di sfruttamento e gli incidenti gravi che incidono sulla sicurezza del prodotto. Il regolamento definisce vulnerabilità attivamente sfruttata quella per cui esiste prova affidabile che un attore malevolo l'abbia sfruttata in un sistema senza il permesso del proprietario del sistema stesso. Una falla individuata durante un test interno, un'attività di ricerca o una divulgazione in buona fede non fa scattare alcun obbligo: il regolamento esclude esplicitamente dalla notifica obbligatoria le vulnerabilità individuate senza intento doloso a scopo di prova, indagine, correzione o divulgazione responsabile.

Il secondo binario riguarda gli incidenti gravi che hanno un impatto sulla sicurezza del prodotto: situazioni in cui un incidente incide negativamente, o è in grado di incidere, sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza di dati o funzioni. I criteri di gravità sono fissati dall'articolo 14, paragrafo 5.

Il regolamento porta un esempio concreto nei propri considerando: un attore malevolo che riesca a inserire codice maligno nel canale di distribuzione attraverso cui il fabbricante rilascia gli aggiornamenti di sicurezza. L'incidente non colpisce il prodotto in sé, ma i processi di sviluppo, produzione o manutenzione del fabbricante, in modo tale da aumentare il rischio per chi quel prodotto lo usa.

La cascata dei termini

La sequenza si articola in tre passaggi e, in entrambi i binari, parte dal momento in cui il fabbricante viene a conoscenza dell'evento:

  • 24 ore — preallarme: decorre dalla presa di conoscenza dell'evento
  • 72 ore — notifica con le informazioni generali e una valutazione iniziale: decorre dalla presa di conoscenza
  • 14 giorni — relazione finale per una vulnerabilità attivamente sfruttata: decorre dalla disponibilità della misura correttiva
  • 1 mese — relazione finale per un incidente grave: decorre dalla notifica delle 72 ore

Il termine finale non decorre dalla scoperta, ma dalla disponibilità della correzione: è l'unico dei tre orologi che il fabbricante può far partire con le proprie mani. Un fabbricante che impieghi due mesi a produrre una correzione non è in ritardo sulla relazione finale, purché abbia rispettato le prime due scadenze. Ma questo significa anche che l'orologio finale resta sospeso finché la correzione non esiste, e che la data della sua disponibilità va documentata.

Un solo invio

Le notifiche passano attraverso la piattaforma unica di segnalazione, sviluppata e gestita dall'ENISA ai sensi dell'articolo 16 del regolamento. L'accesso avviene tramite un account EU Login personale con autenticazione a più fattori.

La piattaforma unica esiste per evitare che lo stesso evento debba essere notificato separatamente alle autorità di ventisette Stati membri. Chi invia seleziona il CSIRT designato come coordinatore competente. La regola generale è quella dello stabilimento principale nell'Unione, inteso come il luogo in cui sono prese prevalentemente le decisioni relative alla cibersicurezza dei prodotti. Per un fabbricante il cui stabilimento principale ricade in Italia il riferimento è il CSIRT Italia dell'Agenzia per la cybersicurezza nazionale.

Una volta inviata, la notifica è resa disponibile simultaneamente all'ENISA, mentre il CSIRT ricevente la diffonde senza ritardo agli altri CSIRT degli Stati membri in cui il prodotto è disponibile e, ove necessario, alle autorità di vigilanza del mercato. Per un dato evento è richiesta una sola notifica, anche quando il fabbricante ha più filiali nell'Unione o una capogruppo stabilita fuori dall'Unione: il coordinamento interno resta responsabilità dell'impresa.

In circostanze eccezionali il CSIRT ricevente può ritardare o trattenere la diffusione. Il regolamento delegato (UE) 2026/881, adottato l'11 dicembre 2025, ne specifica termini e condizioni: la natura dell'informazione notificata, l'impossibilità per il CSIRT di garantirne la riservatezza, la compromissione o l'indisponibilità temporanea della piattaforma.

La piattaforma è al primo rilascio, e i suoi limiti vanno conosciuti prima di costruirci sopra un processo. Non è disponibile alcuna interfaccia di programmazione: le notifiche vanno inserite a mano. L'interfaccia è in lingua inglese. Le segnalazioni volontarie previste dall'articolo 15 non sono ancora supportate.

Chi è obbligato davvero

Quando il fabbricante non ha uno stabilimento principale nell'Unione, l'articolo 14, paragrafo 7, prevede una cascata di criteri per individuare lo Stato membro competente: quello in cui il rappresentante autorizzato agisce per il maggior numero di prodotti; in mancanza, quello in cui l'importatore ne immette sul mercato il maggior numero; poi quello del distributore; infine quello con il maggior numero di utilizzatori.

L'obbligo segue il mercato, non la sede: un fabbricante extraeuropeo che immette prodotti nel mercato interno è tenuto a notificare esattamente come uno con sede a Milano. Sulla platea dei soggetti obbligati circola però un errore ricorrente. Dall'11 settembre 2026 l'obbligo riguarda i fabbricanti. I gestori di software libero e open source sono soggetti agli obblighi di segnalazione previsti dall'articolo 24, paragrafo 3, a decorrere dall'11 dicembre 2027, ai sensi dell'articolo 71, paragrafo 2. Sia la Commissione sia l'ENISA lo indicano esplicitamente.

Sui prodotti già in commercio la regola è meno intuitiva di quanto sembri. Gli obblighi di segnalazione si applicano a tutti i prodotti con elementi digitali che rientrano nell'ambito del regolamento, compresi quelli immessi sul mercato prima dell'11 dicembre 2027. Non è però richiesta una segnalazione retrospettiva quando il fabbricante era già a conoscenza dello sfruttamento attivo prima dell'11 settembre 2026. Se ne viene a conoscenza dopo quella data l'obbligo si applica, anche se la vulnerabilità sottostante esisteva o era già nota.

Le sanzioni, e l'unica deroga

L'articolo 64 costruisce tre livelli. La non conformità ai requisiti essenziali dell'allegato I e agli obblighi degli articoli 13 e 14 è soggetta a sanzioni amministrative pecuniarie fino a 15.000.000 di euro o, se l'autore è un'impresa, fino al 2,5 per cento del fatturato mondiale totale annuo dell'esercizio precedente, se superiore.

Gli obblighi procedurali di rappresentanti autorizzati, importatori e distributori, insieme a dichiarazione di conformità, marcatura CE e documentazione tecnica, si fermano a 10.000.000 di euro o al 2 per cento. La fornitura di informazioni inesatte, incomplete o fuorvianti alle autorità e agli organismi notificati si ferma a 5.000.000 di euro o all'1 per cento.

La violazione degli obblighi di segnalazione sta nella fascia sanzionatoria più alta del regolamento, alla pari con i requisiti essenziali di cibersicurezza. Esiste una sola deroga, ed è più stretta di come viene raccontata. L'articolo 64, paragrafo 10, lettera a), esclude dalle sanzioni amministrative le imprese che si qualificano come microimprese o piccole imprese per il mancato rispetto del termine del preallarme.

L'obbligo di segnalare resta integro: cambia solo che il ritardo su quelle ventiquattro ore, per quelle imprese, non è sanzionabile. Il termine delle 72 ore e la relazione finale non sono coperti, e le medie imprese non rientrano nella deroga.

Le sanzioni sono stabilite e irrogate dalle autorità nazionali di vigilanza del mercato, non dalla Commissione, e gli importi indicati sono massimali. Lo stesso articolo 64 impone di tenere conto della natura, gravità e durata della violazione, delle misure adottate per attenuarne le conseguenze, dei precedenti e della dimensione dell'impresa.

Che cosa preparare adesso

Nessuno dei passaggi che rendono l'adempimento praticabile richiede un budget, ma vanno compiuti prima del primo incidente, non durante. Il CSIRT designato come coordinatore va individuato in anticipo: se si seleziona quello sbagliato la notifica può essere invalidata e deve essere reinviata. Va stabilito per iscritto chi, in azienda, ha l'autorità di inviare una notifica e chi lo sostituisce fuori orario, perché una segnalazione che arriva il venerdì sera mette alla prova la catena decisionale prima di quella tecnica. L'account EU Login si prepara in qualsiasi momento e la registrazione richiede pochi minuti.

Resta un adempimento che nessuna piattaforma può svolgere al posto del fabbricante: registrare, in modo indipendente e con marca temporale, il momento esatto in cui si è venuti a conoscenza dell'evento. Da lì decorrono i primi due termini. Il terzo ha una decorrenza propria: la disponibilità della misura correttiva per le vulnerabilità attivamente sfruttate, la notifica delle 72 ore per gli incidenti gravi. Quel momento non è comunque un dettaglio documentale: è ciò che distingue un preallarme tempestivo da uno tardivo, e la piattaforma non lo ricostruisce al posto di chi segnala.

Da tenere presente

  • Per le vulnerabilità attivamente sfruttate e per gli incidenti gravi la relazione finale ha decorrenza diversa: la differenza è sostanziale in sede di adempimento e non va appiattita su un unico termine.
  • La deroga dell'articolo 64, paragrafo 10, lettera a), copre esclusivamente il mancato rispetto del termine del preallarme: non copre la notifica delle 72 ore né la relazione finale, e non si estende alle medie imprese.
  • Al primo rilascio la piattaforma non espone interfacce di programmazione, è in lingua inglese e non supporta le segnalazioni volontarie dell'articolo 15: un processo costruito sull'automazione dell'invio non è attuabile in questa fase.
  • Nella versione corrente della piattaforma il contatore delle 72 ore mostra una scadenza calcolata a quarantotto ore dall'invio del preallarme: una notifica può quindi apparire in ritardo prima che siano trascorse 72 ore. L'ENISA ha indicato che la logica sarà aggiornata; i contatori hanno finalità di promemoria e non sostituiscono la responsabilità del fabbricante.

Le figure citate nell'articolo sono ricostruzioni originali dell'autore a fini illustrativi. Questo articolo è un'analisi tecnica indipendente, redatta a scopo di studio e divulgazione: non costituisce consulenza legale. Le disposizioni citate sono verificate sul testo del regolamento (UE) 2024/2847 e sulla documentazione ufficiale della Commissione europea e dell'ENISA alla data di redazione.

Condividi

Commenti (0)

Il tuo commento viene pubblicato subito, sotto il tuo nome.

    Continua a leggere

    Immagine di copertina: Premi "chiudi", ma la chiamata non si chiude: il caso Signal
    Sicurezza Mobile

    Premi "chiudi", ma la chiamata non si chiude: il caso Signal

    Una vulnerabilità in RingRTC, la libreria delle chiamate di Signal, poteva tenere aperti microfono e forse telecamera dopo il "chiudi". La crittografia non è stata violata: ecco cosa è successo e cosa fare.

    Simone Mammola | CompTIA Security+ & CCST Cybersecurity Certified · 23 ottobre 2026 · 6 min di lettura

    Immagine di copertina: DNS: la rubrica di Internet che puoi rendere più sicura
    Sicurezza

    DNS: la rubrica di Internet che puoi rendere più sicura

    Prima di aprire qualsiasi sito, il tuo dispositivo fa una domanda a un server DNS. Quasi nessuno sa a quale. Come scegliere un resolver che aggiunga un livello di protezione contro phishing e malware.

    Simone Mammola | CompTIA Security+ & CCST Cybersecurity Certified · 6 ottobre 2026 · 5 min di lettura