ENISA integra le prime CNAs: cosa significa per l'Articolo 14 del CRA

ENISA integra nuove CNA europee come CVE Root. Scopra come questo rafforza il flusso di segnalazione dell'Articolo 14 del CRA e la gestione delle vulnerabilità.

CRA Evidence Team Pubblicato 6 maggio 2026
ENISA CVE Root e segnalazione vulnerabilità Articolo 14 CRA: catena europea di identificazione delle vulnerabilità
In questo articolo

Il contatore delle 24 ore previsto dall'Articolo 14 del CRA parte nel momento in cui si ha ragionevole certezza di uno sfruttamento attivo. Questo contatore presuppone una catena di identificazione delle vulnerabilità funzionante. ENISA ha appena reso quella catena più diretta.

Il 6 maggio 2026, ENISA ha annunciato che quattro nuove organizzazioni sono entrate nel Programma CVE come CVE Numbering Authorities (CNA) sotto ENISA Root. Sette CNA europee già esistenti si sono trasferite da MITRE Root a ENISA Root. Per ogni fabbricante che si prepara alla conformità all'Articolo 14 del CRA, questa è la spina dorsale operativa che diventa reale.

Questo annuncio ha più peso di quanto sembri. Il CRA non esiste nel vuoto. Definisce obblighi legali, ma quegli obblighi dipendono da un'infrastruttura che deve esistere e funzionare prima dell'11 settembre 2026. ENISA che costruisce la propria CVE Root fa parte di quella infrastruttura. E il fatto che stia accadendo ora, con la scadenza del CRA così vicina, è al tempo stesso rassicurante e un promemoria che l'UE sta ancora assemblando i meccanismi mentre il contatore gira.

  • ENISA è una CVE Root per le entità europee. È diventata Root nel novembre 2025 e ha integrato le prime CNA nel maggio 2026.
  • 4 nuove CNA sono entrate nel Programma CVE sotto ENISA Root, formate e integrate direttamente da ENISA. 7 CNA europee esistenti si sono trasferite da MITRE Root.
  • Oltre 90 CNA europee sono eleggibili al trasferimento volontario sotto ENISA Root. L'Europa rappresenta già quasi un quinto delle 510 CNA presenti in 42 Paesi a livello globale.
  • L'Articolo 14 del CRA richiede ai fabbricanti di segnalare le vulnerabilità attivamente sfruttate entro 24 ore tramite la Piattaforma Unica di Segnalazione (SRP) di ENISA, attiva dall'11 settembre 2026.
  • Gli ID CVE sono l'identificatore comune per quella segnalazione. ENISA come CVE Root significa che l'Europa assegna ora gli ID CVE direttamente, senza passare per MITRE.
  • L'accelerazione dell'IA è un fattore esplicitamente citato. Hans de Vries di ENISA ha indicato i modelli di IA di frontiera come fattore che comprime il divario tra scoperta delle vulnerabilità e loro sfruttamento.
  • Il Cybersecurity Act 2 propone risorse operative aggiuntive per ENISA per far fronte al volume crescente.
4
Nuove CNA sotto ENISA Root
integrate nel maggio 2026
7
Trasferite da MITRE
CNA UE esistenti, nuova root
90+
CNA UE eleggibili
trasferimento volontario aperto
Nov 2025
ENISA diventa CVE Root
prime CNA integrate nel maggio 2026

Fonte: annuncio ENISA, 6 maggio 2026.

ID CVE e segnalazione ex Articolo 14

Quando l'Articolo 14 del CRA richiede di segnalare una vulnerabilità attivamente sfruttata, la segnalazione deve identificare la vulnerabilità con precisione. Gli ID CVE sono lo standard globale per quella identificazione. Li usa il Database Europeo delle Vulnerabilità (EUVD) di ENISA. Li richiederà la Piattaforma Unica di Segnalazione di ENISA.

Ottenere l'assegnazione di un ID CVE richiede una CNA. Se nessuna CNA europea copriva la categoria del software in questione, era necessario rivolgersi a MITRE. MITRE ha sede negli Stati Uniti. Il coordinamento funzionava, ma introduceva latenza. Con un contatore di 24 ore, la latenza è un rischio di conformità.

ENISA come CVE Root cambia il percorso. Le CNA europee coordinano ora l'assegnazione dei CVE direttamente con ENISA. Per la maggior parte dei fabbricanti, questo è invisibile nella quotidianità. Non è necessario essere una CNA. Ma il ricercatore di sicurezza che trova una vulnerabilità nel prodotto, o il CSIRT che gestisce la divulgazione, opera ora sotto un'autorità di root geograficamente allineata all'agenzia a cui si segnala ai sensi dell'Articolo 14.

Questa è l'infrastruttura da cui dipende la finestra delle 24 ore. In Italia, il CSIRT Italia (presso ACN, Agenzia per la Cybersicurezza Nazionale) è il punto di contatto operativo per le segnalazioni di vulnerabilità.

La catena di segnalazione ai sensi dell'Articolo 14

L'Articolo 14, paragrafo 1 del CRA richiede ai fabbricanti di segnalare simultaneamente al CSIRT coordinatore e a ENISA, tramite la Piattaforma Unica di Segnalazione di ENISA. Si presenta una sola notifica. Entrambi la ricevono.

La SRP ha bisogno di un ID CVE per ancorare la segnalazione. Il ruolo di ENISA come CVE Root significa che la fase di identificazione e la fase di segnalazione si trovano ora sotto la stessa agenzia. L'organismo che attribuisce il nome alla vulnerabilità è lo stesso a cui si notifica ai sensi del CRA. Questo chiude un vuoto di coordinamento che esisteva quando le due funzioni erano gestite da organizzazioni separate su continenti diversi.

Un'agenzia, due ruoli

ENISA assegna ora gli ID CVE per le entità europee e riceve le segnalazioni ai sensi dell'Articolo 14 tramite la SRP. L'agenzia che attribuisce il nome alla vulnerabilità è la stessa a cui si segnala in base al CRA.

Consulti la guida alla segnalazione ex Articolo 14 per la cadenza completa delle 24 ore, 72 ore e 14 giorni e per i contenuti della notifica alla SRP.

Il problema dell'accelerazione dell'IA

Hans de Vries, Chief Cybersecurity and Operations Officer di ENISA, è stato diretto sulla ragione per cui questo è rilevante ora:

In un momento in cui i modelli di IA di frontiera stanno accelerando la scoperta e lo sfruttamento delle vulnerabilità, la capacità europea di gestione delle vulnerabilità deve tenere il passo e fornire un supporto operativo affidabile alla più ampia comunità della cibersicurezza.

Hans de Vries, Chief Cybersecurity and Operations Officer, ENISA · 6 maggio 2026

Gli strumenti di IA comprimono il tempo tra la scoperta di una vulnerabilità e il suo sfruttamento. La finestra tra «un ricercatore la individua» e «il contatore delle 24 ore ex Articolo 14 parte» si sta restringendo. Da questo derivano due considerazioni. Prima: il processo interno di triage deve essere calibrato su una linea temporale delle minacce più rapida. Seconda: anche la fase di assegnazione del CVE nella catena deve stare al passo. ENISA sta costruendo questa capacità ora. Il Cybersecurity Act 2 propone risorse operative aggiuntive per ENISA specificamente per questa funzione.

Cosa non è necessario fare

Non è necessario diventare una CNA. Lo status di CVE Numbering Authority è riservato alle organizzazioni che scoprono e pubblicano i record di vulnerabilità. La maggior parte dei fabbricanti non sono CNA e il CRA non lo richiede.

Ciò che l'Allegato I, Parte II del CRA richiede è una politica di divulgazione coordinata delle vulnerabilità (CVD). Quella politica descrive come l'organizzazione riceve, gestisce e divulga le vulnerabilità. In base a tale politica, si collabora con CNA o CSIRT che si occupano dell'assegnazione dei CVE. ENISA come CVE Root significa che questi interlocutori operano ora sotto una struttura di autorità UE più diretta. In Italia, ACN e CSIRT Italia sono i riferimenti istituzionali per questa catena.

Prima dell'11 settembre 2026, verifichi la propria politica CVD rispetto a tre domande:

  1. Indica il percorso di segnalazione? La politica deve fare riferimento alla SRP di ENISA come canale di notifica per le segnalazioni ex Articolo 14.
  2. Specifica come gestire le segnalazioni in entrata? Quando un ricercatore segnala una vulnerabilità al fabbricante, la politica deve descrivere i tempi di risposta e il processo di richiesta del CVE.
  3. Identifica il CSIRT coordinatore? L'Articolo 14, paragrafo 7 richiede ai fabbricanti di designare un CSIRT coordinatore. Quella designazione deve comparire nella politica.

Consulti il modello di politica CVD per un punto di partenza strutturato.

La nostra analisi

La posizione «rafforzare, non frammentare» è quella corretta. Il rischio con qualsiasi infrastruttura specifica dell'UE è la frammentazione. Un silo europeo dei CVE che diverge da MITRE danneggerebbe tutti, compresi i fabbricanti europei che lavorano con catene di approvvigionamento globali. L'annuncio è esplicito: ENISA collabora con CISA e MITRE nell'ambito di un impegno condiviso verso il programma globale.

Il messaggio principale per i fabbricanti è una questione di tempistica. L'infrastruttura viene assemblata nello stesso momento in cui si è tenuti a rispettarla. La SRP non è ancora attiva. La CVE Root ha 11 CNA su oltre 90 eleggibili. Queste strutture saranno pronte entro settembre 2026, ma è necessario essere pronti anche da parte del fabbricante, e costruire il proprio processo su un'infrastruttura ancora in fase di completamento è più difficile che costruirlo su basi stabili.

Domande frequenti

ENISA che diventa CVE Root cambia i miei obblighi di segnalazione ex Articolo 14?

No. Gli obblighi ai sensi dell'Articolo 14 sono invariati. Il fabbricante deve segnalare le vulnerabilità attivamente sfruttate entro 24 ore tramite la SRP di ENISA a partire dall'11 settembre 2026. Ciò che cambia è l'infrastruttura alla base della piattaforma. ENISA gestisce ora l'assegnazione degli ID CVE direttamente per le entità europee, riducendo la latenza di coordinamento tra identificazione della vulnerabilità e fase di segnalazione. Consulti la guida alla segnalazione ex Articolo 14 per i dettagli completi sugli obblighi.

È necessario diventare una CVE Numbering Authority per conformarsi al CRA?

No. Lo status di CNA è riservato alle organizzazioni che scoprono e pubblicano record di vulnerabilità. Il CRA richiede una politica di divulgazione coordinata delle vulnerabilità ai sensi dell'Allegato I, Parte II, e la segnalazione ai sensi dell'Articolo 14 tramite la SRP di ENISA. Questi obblighi sono distinti dall'appartenenza a una CNA. La maggior parte dei fabbricanti rispetta i requisiti collaborando con CNA o CSIRT esistenti, senza detenere direttamente lo status di CNA.

Quando ENISA è diventata CVE Root e cosa significa in pratica?

ENISA è diventata CVE Root per le entità europee nel novembre 2025. Come Root, recluta, integra, forma e gestisce le CNA nel suo perimetro, e facilita l'assegnazione degli ID CVE e la pubblicazione dei record per le entità europee. Le prime integrazioni di CNA sotto ENISA Root sono state annunciate il 6 maggio 2026: quattro nuove CNA e sette trasferite da MITRE Root. In pratica, le CNA europee coordinano ora l'assegnazione dei CVE con ENISA invece di passare per l'organizzazione statunitense MITRE.

Cos'è il Database Europeo delle Vulnerabilità e come si collega a ENISA Root?

ENISA gestisce il Database Europeo delle Vulnerabilità (EUVD), che cataloga le vulnerabilità utilizzando gli ID CVE come identificatore comune. Come CVE Root, ENISA controlla ora l'assegnazione di quegli ID per le entità europee. Il database e l'autorità di assegnazione sono allineati sotto un'unica agenzia. I fabbricanti possono usare l'EUVD per verificare se una vulnerabilità è già stata registrata prima di presentare una segnalazione ex Articolo 14 tramite la SRP.

Perché l'accelerazione dell'IA è rilevante per la preparazione al CRA?

Il Chief Cybersecurity and Operations Officer di ENISA ha citato i modelli di IA di frontiera come fattore che comprime il tempo tra scoperta e sfruttamento di una vulnerabilità. Una finestra più breve tra scoperta e sfruttamento significa meno margine tra il momento in cui un ricercatore individua una vulnerabilità e l'avvio del contatore delle 24 ore ex Articolo 14. Il processo interno di triage deve essere calibrato su quella velocità. Prima dell'11 settembre 2026, esegua un esercizio tabletop sulla finestra delle 24 ore per verificare che il processo regga.

Qual è la differenza tra MITRE Root e ENISA Root per le CNA europee?

MITRE è l'organizzazione statunitense che storicamente ha svolto il ruolo di root globale del CVE. Le CNA europee sotto MITRE Root coordinavano l'assegnazione dei CVE tramite MITRE. Sotto ENISA Root, quelle CNA coordinano direttamente con ENISA. Il formato degli ID CVE e le regole del Programma CVE sono invariati. La differenza è nell'autorità di root: europea, con mandato UE, integrata con la SRP di ENISA e con l'EUVD attraverso cui i fabbricanti soggetti al CRA segnalano.

Cosa fare prima dell'11 settembre 2026

  1. Verifichi la propria politica di divulgazione coordinata delle vulnerabilità. Confermi che indichi la SRP di ENISA come canale di segnalazione ex Articolo 14 e che designi un CSIRT coordinatore. Utilizzi il modello di politica CVD come riferimento.
  2. Esegua un esercizio tabletop sulla finestra delle 24 ore prevista dall'Articolo 14. Identifichi chi nella propria organizzazione avvia il contatore, chi presenta la segnalazione e come si ottiene l'ID CVE. Consulti la guida alla segnalazione ex Articolo 14 per la cadenza completa.
  3. Identifichi le CNA o i CSIRT con cui collabora per le richieste di ID CVE. Se sono europei, verifichi se operano sotto ENISA Root. Questo determina il primo punto di contatto quando una vulnerabilità ha bisogno di un ID prima della segnalazione. In Italia, il riferimento è CSIRT Italia presso ACN.
  4. Monitori la SRP di ENISA per il periodo di test e la data di attivazione. Non è ancora stato pubblicato un URL di registrazione. Seguire la pagina SRP di ENISA per aggiornamenti prima della scadenza di settembre.

Questo articolo ha finalità puramente informative e non costituisce consulenza legale. Per una guida specifica alla conformità, si rivolga a un legale qualificato.

CRA ENISA Gestione delle vulnerabilità Sicurezza
Share

Il CRA si applica al tuo prodotto?

Rispondi a 6 semplici domande per scoprire se il tuo prodotto rientra nell'ambito del Cyber Resilience Act dell'UE. Ottieni il risultato in meno di 2 minuti.

Pronto a raggiungere la conformità CRA?

Inizia a gestire i tuoi SBOM e la documentazione di conformità con CRA Evidence.