← Tutti gli articoli
Cyber Resilience Act: mancano meno di tre settimane all'11 settembre

Cyber Resilience Act: mancano meno di tre settimane all'11 settembre

2 min di lettura

A luglio abbiamo spiegato perché la prima scadenza vincolante del CRA è l'11 settembre 2026, non il 2027. Adesso il tempo è finito: dall'11 settembre scattano gli orologi di 24 e 72 ore per le vulnerabilità sfruttate. La checklist finale, senza teoria.

Un mese fa abbiamo scritto che quasi tutti avevano archiviato il Cyber Resilience Act sotto una data sbagliata, dicembre 2027, mentre il primo obbligo vincolante scatta l'11 settembre 2026. Da allora non è cambiato nulla, tranne il calendario: mancano meno di tre settimane. Se sviluppate o vendete un prodotto con elementi digitali, questa è la checklist da chiudere adesso, non l'articolo da leggere con calma.

Cosa scatta l'11 settembre

Dall'articolo 14 il fabbricante ha tre orologi: allerta precoce entro 24 ore da quando viene a conoscenza di una vulnerabilità sfruttata attivamente o di un incidente grave, notifica completa entro 72 ore, relazione finale entro 14 giorni dalla disponibilità di una correzione per le vulnerabilità e un mese per gli incidenti gravi. La segnalazione passa dalla piattaforma unica che ENISA sta rendendo operativa per quella data e arriva insieme al vostro CSIRT nazionale. Per un fabbricante italiano è CSIRT Italia, lo stesso interlocutore di NIS2.

Il paracadute PMI, e i suoi limiti

Microimprese e piccole imprese non possono essere sanzionate per il mancato rispetto della scadenza delle 24 ore. Attenzione a come si legge: l'obbligo di segnalare resta comunque, salta solo la multa per il ritardo. E il SaaS autonomo, in generale, è fuori dal perimetro del CRA, mentre il trattamento remoto dei dati senza cui il prodotto non funziona rientra: è un test funzione per funzione, non un sì o un no.

La checklist finale, in quest'ordine

  • Assegnare le 24 ore a una persona: nome e cognome, reperibile, non una casella condivisa. L'orologio parte da quando si viene a conoscenza, non da quando qualcuno apre il ticket.
  • Preparare l'EU Login: le credenziali si creano in anticipo. ENISA chiede di registrarsi sulla piattaforma solo quando c'è una segnalazione vera da inviare, ma l'accesso va provato prima.
  • SBOM in pipeline: su una build Node o PHP è lavoro di CI, non un foglio di calcolo aggiornato una volta l'anno. Serve per sapere cosa segnalare quando la falla è in una dipendenza.
  • Verificare il periodo di supporto: minimo cinque anni salvo vita attesa più breve, da conciliare con framework dagli LTS molto più corti.
  • Scrivere la procedura: chi decide che un evento è segnalabile, chi redige, chi invia. La finestra di 24 ore non si improvvisa alle tre di notte.

Verdetto

Se costruite software per un manifatturiero, il problema CRA del vostro cliente sta per diventare una clausola del vostro contratto, e la conversazione è molto più semplice se arrivate all'11 settembre con la procedura già scritta. Le sanzioni sulla segnalazione arrivano a 15 milioni di euro o al 2,5% del fatturato mondiale, ma per una PMI il rischio vero non è la multa remota: è trovarsi con una vulnerabilità sfruttata e nessuno che sappia chi chiamare e in quante ore. Chiudete i cinque punti prima di settembre.