Il 11 settembre 2026 è una data che segnerà un cambio radicale nella gestione della cybersecurity per chi opera nel mercato europeo. Da quel giorno, i produttori di prodotti con elementi digitali devono comunicare vulnerabilità attivamente sfruttate e incidenti gravi attraverso la Single Reporting Platform (SRP) dell’ENISA, entro tempi molto stretti: 24 ore per l’avviso iniziale, 72 ore per la notifica completa, 14 giorni per il rapporto finale.
Nella mia esperienza come System Administrator, ho visto come questa normativa sia diventata realtà proprio quest’anno. Inizialmente, molte organizzazioni pensavano che il Cyber Resilience Act fosse una preoccupazione futura. Invece, le obbligazioni di segnalazione del CRA dall’articolo 14 si applicano dal 11 settembre 2026. Il problema? Il Cyber Resilience Act introduce nuove obbligazioni di segnalazione a partire dall’11 settembre 2026, richiedendo ai produttori di notificare determinate vulnerabilità e gravi incidenti in meno di 24 ore.
In questo articolo vi mostro come ho costruito la mia procedura interna di compliance, come tracciare CVE attivamente sfruttati e come automatizzare il flusso di incident reporting. Questo è operativo da settembre, non è più una discussione teorica.
Il Quadro Normativo: CRA e l’ENISA Single Reporting Platform
L’Agenzia europea per la cybersecurity ha acceso la Single Reporting Platform del Cyber Resilience Act l’11 settembre 2026, lo stesso giorno in cui gli obblighi di segnalazione della legge hanno iniziato a vincolare i produttori. Non è un’infrastruttura ausiliaria: è il canale unico per comunicare con le autorità competenti.
Chi immette un prodotto con elementi digitali sul mercato dell’UE ora segnala le vulnerabilità attivamente sfruttate e gli incidenti gravi attraverso quel portale. Il timer inizia quando il produttore viene a conoscenza dell’evento. Un avviso iniziale deve arrivare entro 24 ore, una notifica più completa con una valutazione iniziale entro 72 ore, e un rapporto finale entro 14 giorni da quando una misura correttiva o mitigante diventa disponibile.
La mia scoperta iniziale: il sistema non è solo sulla compliance, è sulla velocità. Se fallisci nel comunicare in tempo, il danno reputazionale è immediato.
Definire Cosa Deve Essere Segnalato: Actively Exploited Vulnerabilities
Prima di qualsiasi processo tecnico, bisogna capire cosa rientra nell’obbligo. Non è “qualsiasi bug”, ma specificamente:
- Vulnerabilità attivamente sfruttate: Vulnerabilità attivamente sfruttate contenute in un prodotto con elementi digitali. Una vulnerabilità è attivamente sfruttata quando c’è una prova affidabile che un attore malintenzionato l’ha sfruttata in un sistema senza il permesso del proprietario del sistema
- Incidenti gravi: Incidenti in cui la sicurezza del prodotto non può essere mantenuta
All’inizio mi ero confuso su questo. Pensavo dovesse coprire ogni CVE pubblicato. Sbagliato. Il CRA si concentra su due eventi: ciò che viene realmente sfruttato e ciò che rompe completamente la sicurezza del prodotto.
Per tracciare le vulnerabilità attivamente sfruttate, ho impostato un monitoraggio continuo del CISA Known Exploited Vulnerabilities (KEV) Catalog. Senserva traccia 1.328 CVE non-Microsoft attivamente sfruttati su 282 vendor, 243 di essi legati a campagne di ransomware, e 7 aggiunti negli ultimi 7 giorni. Questo mi dice che il numero di vulnerabilità rilevanti cambia quotidianamente.
Implementare la Gestione delle Vulnerabilità: Inventory e Triage
Ho dovuto costruire un processo a tre livelli:
Fase 1: Inventario dei Prodotti
Identifichiamo tutti i prodotti con elementi digitali che distribuiamo nell’UE. Nel mio caso, sono applicazioni web, moduli Plesk, componenti WordPress e servizi cloud. La chiave è essere esplicito e aggiornato.
Ho creato un foglio di tracking (GitHub o un database interno) che include:
- Nome prodotto e versioni supportate
- Componenti e dipendenze open-source
- Paesi UE dove è distribuito
- Responsabile di sicurezza per il prodotto
- Data dell’ultima revisione
Fase 2: Triage e Identificazione
Quando una vulnerabilità viene pubblicata o scoperta, devo eseguire triage rapido:
- Affetta il nostro prodotto? Controllo versione e configurazione
- È attivamente sfruttata? Verifico CISA KEV, thread di sicurezza, prove pubbliche
- Impatto sulla sicurezza: Esecuzione di codice remoto (RCE), bypass di autenticazione, accesso non autorizzato ai dati sensibili
- Tempo disponibile: C’è una patch? Quando sarà disponibile?
Questo è dove automazione aiuta davvero. Ho impostato uno script che:
- Monitora CISA KEV ogni ora via API
- Incrocia i CVE con il nostro inventario prodotti
- Crea automaticamente un ticket di triage con priorità alta se c’è una corrispondenza
- Avvisa il responsabile del prodotto tramite Slack
Fase 3: Escalation e Decision Point
Se un CVE affetta un nostro prodotto e ha prove di sfruttamento attivo, scatta il protocollo CRA. Ho stabilito una riunione di crisi con product owner, security team e legal in meno di 2 ore. Decidiamo:
- Severity reale (potrebbe essere più bassa di CVSS in caso specifico)
- Se è un “incidente grave” (quando la sicurezza del prodotto non può essere mantenuta)
- Timeline di patch
- Se segnalare entro 24 ore (avviso iniziale)
La Procedura di Segnalazione: Dalla Discovery al Submission
Il CRA richiede ai produttori di notificare le vulnerabilità attivamente sfruttate e gli incidenti gravi che hanno un impatto sulla sicurezza dei loro prodotti con elementi digitali. Devono presentare un avviso iniziale entro 24 ore da quando diventano consapevoli, e una notifica completa entro 72 ore.
La mia procedura operativa:
Ora 0-1: Early Warning (24 ore)
Quando diventati consapevoli (il timer inizia qui), compilo il modulo Early Warning dell’ENISA SRP. Il dataset delle 24 ore si concentra strettamente sui dati amministrativi e di avviso di base: Tipo e Gravità della Notifica (AEV o Incidente), Identificazione dell’Entità (nome legale del produttore e dettagli del rappresentante designato), Identificazione del Prodotto (titolo, modello o versione software interessati), Flag di Intento Malazioso (per incidenti gravi, indicazione se l’evento è sospettato risultare da atti illegittimi o dolosi), Distribuzione Geografica (elenco degli Stati Membri dell’UE dove il prodotto interessato è stato reso disponibile).
I campi obbligatori sono minimali per una ragione: avrai 24 ore per raccogliere informazioni, non giorni.
Ora 24-72: Full Notification (72 ore)
Con il modulo completo, aggiungi valutazione tecnica, impatto, i sistemi affetti, e il tuo assessment di mitigazione. La notifica copre 39 campi, 18 comuni più 12 per una vulnerabilità attivamente sfruttata e 9 per un incidente grave, e per ogni campo fornisce il significato, come compilarlo, un esempio, il formato previsto, e se il campo è obbligatorio, opzionale, obbligatorio se l’informazione è disponibile, o riportato dalla fase precedente.
Ho creato un template interno (documento Google Docs + automazione Zapier) che pre-compila i campi comuni e lancia il workflow interno di raccolta dati. Il team tecnico ha 48 ore per completare l’assessment dettagliato.
Ora 72+: Final Report (14 giorni da quando patch è disponibile)
Quando pubblichiamo la patch o la misura di mitigazione, il clock per il rapporto finale inizia. Entro 14 giorni, comunico a che punto siamo: patch rilasciata, test completati, rollout globale avviato.
Automazione e Integrazione nella Procedura
Non posso gestire tutto manualmente. Ho integrato l’ENISA SRP nel nostro stack di sicurezza:
Tool di Monitoraggio CVE
Uso una combinazione di:
- CISA KEV API: Aggiornamento quotidiano dei CVE attivamente sfruttati
- Snyk Intelligence o Dependabot: Vulnerabilità nei nostri componenti open-source
- GitHub Security Advisories: Repository che monitoriamo
- Vendor Security Bulletins: Notifiche dirette da fornitori di componenti critiche
Uno script Python centralizzato aggrega tutto questo e invia alert qualificati.
Workflow di Incident Response
Ho impostato automazione in ServiceNow (o Jira + zapier per SMB) che:
- Crea ticket automatico quando vulnerabilità affetta un prodotto
- Assegna al team di security con deadline di triage (6 ore)
- Se confermata come attiva exploitation, scala a PSIRT (Product Security Incident Response Team)
- Genera timeline di notifica SRP con reminder a 12, 48, 72 ore
- Traccia remediation e auto-popola il final report
I sistemi AI possono gestire compiti come raccolta dati, analisi e reporting, creando processi coerenti e ripetibili. Questo riduce l’errore umano e accelera i tempi di risoluzione garantendo documentazione corretta per compliance e analisi futura.
CSIRT Coordinator Assignment
Questo è un passaggio spesso trascurato. L’elenco dei CSIRT designati come coordinatori dell’ENISA è datato 10 settembre 2026 e contiene una pagina di contatto per ogni Stato Membro. Confermando il coordinatore rispetto a quel elenco e scrivendo la ragione della scelta, l’ENISA ora dichiara che una notifica presentata al coordinatore errato potrebbe essere invalidata e deve essere rilanciata a quello corretto. Il deadline corre dalla consapevolezza piuttosto che da un nuovo inizio, quindi le ore perse in una rinotifica escono dal tuo budget.
Ho un foglio di calcolo con i CSIRT designati per ogni paese UE dove distribuiamo prodotti. Lo aggiorno ogni mese basandomi sulla lista ENISA ufficiale.
Tracciamento dei CVE e Monitoraggio in Tempo Reale
La procedura di tracciamento CVE che ho implementato funziona così:
Dashboard di Monitoraggio
Ho una dashboard interna (Grafana + Prometheus) che visualizza:
- Nuovi CVE nel CISA KEV (aggiornamento ogni ora)
- Match contro il nostro inventario prodotti
- Severity e EPSS score (Exploit Prediction Scoring System)
- Patch availability per vendor
- Timeline di notificazione se applicabile
Integrazione con Vulnerability Management
Se usi Nessus, Qualys o simili, configura esportazione automatica dei CVE scoperti nei tuoi asset in CSV, poi incrocia con CISA KEV. I tuoi strumenti di scanning continuo troveranno prima i problemi rispetto alle notifiche manuali.
Threat Intelligence Feeds
Mi sono iscritto a:
- CISA alerts via email (settimanale)
- Exploit-DB notifications per PoC pubblici
- Darkweb threat feeds (tramite azienda di threat intel)
- Slack di security communities dove discutono nuovi exploit
Tutto converge in un’unica riunione settimanale dove il team di security valuta priorità real-time.
FAQ
Cosa succede se non segnalo entro 24 ore?
Con gli obblighi di segnalazione di 24 ore che entrano in vigore l’11 settembre 2026, le organizzazioni dovrebbero ora trattare la preparazione al reporting CRA come priorità di compliance immediata. Coloro che aspettano fino al primo evento di vulnerabilità potrebbero scoprire che il rischio maggiore non è l’evento cyber stesso, ma l’incapacità di rispondere abbastanza velocemente per soddisfare il regolatore. In pratica, il mancato rispetto è sanzionabile. Non conosco ancora l’importo esatto delle multa, ma è probabile che sia significativo.
La Single Reporting Platform richiede un accesso speciale?
Sì. Lo raggiungi selezionando il ruolo di Rappresentante Assegnato e autenticandoti tramite EU Login con autenticazione multi-fattore. Serve un’identità digitale europea verificata. Non è immediato, quindi configura gli accessi con almeno 4-6 settimane di anticipo.
Se faccio open-source, sono obbligato?
In conformità all’articolo 24(3) del CRA, queste obbligazioni di segnalazione si applicheranno anche ai curatori di software open-source nella misura in cui sono coinvolti nello sviluppo di prodotti con elementi digitali. Questo articolo si applicherà a partire dal 11 dicembre prossimo. Se mantieni una libreria open-source usata in prodotti digitali commerciali, dal dicembre 2027 dovrai rispondere anche tu.
Come coordino se ho più divisioni?
Solo una notifica è richiesta per una data vulnerabilità attivamente sfruttata o incidente grave, anche quando il produttore ha più rami o filiali nell’UE, o una società madre al di fuori di essa. Centralizza il processo: una unica squadra di sicurezza presenta, non ciascuna divisione singolarmente.
Posso delegare la notificazione a un rappresentante autorizzato?
Sì, ma il responsabile legale rimane tuo. ENISA accetta designazione di un Assigned Representative (AR) che gestisce il portale, ma il produttore rimane accountable per contenuto e tempistiche. Ho delegato il tecnico a un collega IT specialist di fiducia, ma revisiono personalmente ogni notifica prima della submission.
Conclusione
Il CRA Compliance con la Single Reporting Platform ENISA da settembre 2026 non è una raccomandazione: è legge operativa. La procedura che ho implementato si basa su automazione, monitoraggio real-time dei CVE attivamente sfruttati, e workflow rigido di incident reporting. Gli obblighi di segnalazione del CRA si applicano dall’11 settembre 2026 a tutti i prodotti con elementi digitali che rientrano nell’ambito del CRA.
Se distribuisci prodotti con elementi digitali in Europa, inizia oggi: mappa il tuo inventario, definisci chi è responsabile della sicurezza per ogni prodotto, imposta il monitoraggio CVE automatizzato, e soprattutto testa il tuo flusso di segnalazione prima che un incidente reale lo metta sotto pressione.
Come sempre, la prevenzione mediante preparazione è la miglior difesa. Condividete la vostra esperienza nei commenti: come state preparandovi per questa scadenza?