Segnalazione Vulnerabilità ENISA: Cosa Attiva il Conto alla Rovescia di 24 Ore sotto il CRA

11 settembre 2026. Da questa data, avete 24 ore per segnalare le vulnerabilità attivamente sfruttate a ENISA. Mancate la scadenza e affrontate azioni di enforcement.

Questa guida copre cosa attiva la segnalazione, cosa significa realmente "attivamente sfruttato" e come preparare il vostro processo interno prima della scadenza.

Cosa Attiva la Segnalazione CRA?

Il CRA definisce due categorie che richiedono notifica obbligatoria:

1. Vulnerabilità Attivamente Sfruttate

Una vulnerabilità nel vostro prodotto che:

• È nota a voi (scoperta internamente o segnalata dall'esterno)
• È stata sfruttata da un attore malevolo
• Colpisce o potrebbe colpire gli utenti del vostro prodotto

2. Incidenti Gravi

Incidenti di sicurezza che:

• Impattano la sicurezza del vostro prodotto
• Compromettono il vostro ambiente di sviluppo in modi che influenzano la sicurezza del prodotto
• Causano interruzione significativa del servizio agli utenti
• Risultano in una compromissione diffusa

Entrambe le categorie attivano le stesse tempistiche di segnalazione ma hanno finestre diverse per il report finale.

Cosa Significa "Attivamente Sfruttato"

Il CRA definisce una vulnerabilità attivamente sfruttata come una in cui "un attore malevolo fa uso di una falla".

Questo non è lo stesso di:

• Una vulnerabilità divulgata pubblicamente
• Una proof-of-concept pubblicata
• Un ricercatore che dimostra l'exploitabilità

Significa uso malevolo reale.

Scenari da Segnalare vs Non Segnalabili

Lo Standard della "Convinzione Ragionevole"

Non avete bisogno di prove forensi dello sfruttamento. Lo standard è una convinzione ragionevole basata sulle prove disponibili:

• Pattern di accesso insoliti coerenti con tecniche di exploit note
• Report di clienti di compromissione
• Intelligence sulle minacce che indica che il vostro prodotto è preso di mira
• Rilevamento di codice exploit progettato per il vostro prodotto

In caso di incertezza: Preferite segnalare. Un'allerta precoce prematura che si rivela infondata è molto meglio di una scadenza mancata per uno sfruttamento reale.

Tempistiche di Segnalazione

Sia le vulnerabilità che gli incidenti seguono un modello di segnalazione a stadi:

Timeline Vulnerabilità Attivamente Sfruttata

SCOPERTA → 24 ORE → 72 ORE → PATCH DISPONIBILE → 14 GIORNI
    │         │         │           │                 │
    │         │         │           │                 └── Report Finale
    │         │         │           └── Il conto riprende
    │         │         └── Notifica Dettagliata
    │         └── Allerta Precoce
    └── Il conto inizia

Timeline Incidente Grave

SCOPERTA → 24 ORE → 72 ORE → 1 MESE
    │         │         │        │
    │         │         │        └── Report Finale
    │         │         └── Notifica Dettagliata
    │         └── Allerta Precoce
    └── Il conto inizia

Cosa Contiene Ogni Report

Allerta Precoce (24 ore)

Informazioni minime per allertare le autorità:

• La vostra identità (fabbricante)
• Identificazione del/dei prodotto/i colpito/i
• Breve descrizione della vulnerabilità/incidente
• Valutazione iniziale della gravità
• Se lo sfruttamento è confermato o sospettato
• Indicazione della portata potenziale dell'impatto

Questa non è un'analisi completa. È un'allerta che qualcosa di serio sta accadendo.

Notifica Dettagliata (72 ore)

Informazioni espanse per la valutazione:

• Dettagli tecnici della vulnerabilità
• Versioni e configurazioni colpite
• Metodo di sfruttamento (se noto)
• Stato attuale della mitigazione
• Stima della timeline di rimedio
• Utenti/portata colpiti noti
• Coordinamento con altre parti (altri vendor, CSIRTs)

Report Finale (14 giorni per vuln / 30 giorni per incidenti)

Analisi completa dopo il rimedio:

• Analisi delle cause radice
• Descrizione tecnica completa
• Azioni di rimedio intraprese
• Lezioni apprese
• Misure di prevenzione implementate
• Valutazione dell'impatto (utenti colpiti confermati, esposizione dati, ecc.)

Dove Segnalare

Piattaforma Unica di Segnalazione ENISA (SRP)

A partire da settembre 2026, ENISA opererà un punto di ingresso unico per le notifiche CRA.

Cosa sappiamo:

• Piattaforma web per le sottomissioni
• Accesso API per segnalazione automatizzata (previsto)
• Routing simultaneo ai CSIRTs nazionali competenti
• Moduli di segnalazione standardizzati

VERIFICARE CON FONTE PRIMARIA: Specifiche esatte della piattaforma e URL in attesa di pubblicazione ENISA.

CSIRTs Nazionali

I report vanno simultaneamente a:

• ENISA (coordinamento a livello UE)
• CSIRT(s) nazionale/i dove il prodotto è disponibile

La SRP dovrebbe gestire il routing automaticamente basandosi sulla vostra dichiarazione di presenza sul mercato.

Per Prodotti in Più Stati Membri

Se il vostro prodotto è disponibile in più paesi UE:

• Una sottomissione alla SRP
• La piattaforma instrada a tutti i CSIRTs competenti
• Potreste ricevere follow-up da più autorità nazionali

Checklist di Preparazione Interna

Non aspettate settembre 2026. Costruite i vostri processi ora.

1. Canali di Ricezione Vulnerabilità

Stabilite percorsi chiari per i report di vulnerabilità:

File security.txt:

# https://vostroprodotto.com/.well-known/security.txt
Contact: mailto:security@vostraazienda.com
Contact: https://vostraazienda.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: it
Canonical: https://vostraazienda.com/.well-known/security.txt
Policy: https://vostraazienda.com/security/policy

Modulo web per report strutturati

Email dedicata monitorata 24/7 (o con SLA chiaro)

2. Processo di Triage Interno

Definite come vengono valutati i report:

TRIAGE RICEZIONE VULNERABILITÀ

1. Ricezione Iniziale (< 4 ore)
   - Confermare la ricezione
   - Assegnare a membro del team sicurezza
   - Verifica iniziale di validità

2. Triage Tecnico (< 24 ore)
   - Confermare che la vulnerabilità esiste
   - Determinare le versioni colpite
   - Valutare l'exploitabilità
   - Verificare evidenze di sfruttamento attivo

3. Valutazione della Gravità (< 24 ore)
   - Scoring CVSS (o equivalente)
   - Valutazione dell'impatto business
   - Probabilità di sfruttamento

4. Decisione di Segnalazione (IMMEDIATA se sfruttamento confermato)
   - Questo richiede notifica ENISA?
   - Se sì, avviare il conto alla rovescia di 24 ore

3. Percorsi di Escalation

Definite chi può attivare la segnalazione esterna:

Principio chiave: La persona che scopre un potenziale sfruttamento deve poter escalare immediatamente, 24/7.

4. Copertura Fuori Orario

Il conto alla rovescia di 24 ore non si ferma nei weekend o nei giorni festivi.

Opzioni:

• Rotazione di reperibilità per il team sicurezza
• Servizio di monitoraggio con autorità di escalation
• Catena di contatto fuori orario chiara
• Reporter pre-autorizzati che possono inviare allerte precoci

5. Template dei Report

Preparate i template prima di averne bisogno:

Template Allerta Precoce:

ALLERTA PRECOCE CRA ENISA

Fabbricante: [Nome Azienda]
Data Report: [Data/Ora UTC]
Tipo Report: [ ] Vulnerabilità Attivamente Sfruttata [ ] Incidente Grave

PRODOTTO/I COLPITO/I:
- Nome Prodotto:
- Versione/i:
- Categoria Prodotto:

SOMMARIO VULNERABILITÀ/INCIDENTE:
[Breve descrizione - 2-3 frasi]

STATO SFRUTTAMENTO:
[ ] Sfruttamento confermato
[ ] Sfruttamento sospettato
Evidenze: [Breve descrizione delle evidenze]

VALUTAZIONE INIZIALE GRAVITÀ:
[ ] Critica [ ] Alta [ ] Media [ ] Bassa
Base: [Score CVSS o altra giustificazione]

PORTATA POTENZIALE IMPATTO:
- Utenti colpiti stimati:
- Portata geografica:
- Dati a rischio:

STATO ATTUALE:
[ ] In corso di investigazione
[ ] Mitigazione in corso
[ ] Patch in sviluppo

CONTATTO PER FOLLOW-UP:
Nome:
Email:
Telefono:

Questa è un'allerta precoce. Notifica dettagliata a seguire entro 72 ore.

6. Testate il Vostro Processo

Eseguite esercitazioni tabletop prima di settembre 2026:

Scenario 1: Venerdì ore 17 - Un ricercatore di sicurezza segnala una vulnerabilità critica con PoC

• Quanto velocemente potete valutare il rischio di sfruttamento?
• Chi prende la decisione di segnalazione nel weekend?

Scenario 2: Un cliente segnala attività sospetta che suggerisce che il vostro prodotto è stato il punto di ingresso

• Come raccogliete evidenze per confermare/negare lo sfruttamento?
• Qual è la vostra soglia per la "convinzione ragionevole"?

Scenario 3: L'intelligence sulle minacce indica che il vostro prodotto è preso di mira da un gruppo APT

• Avete visibilità sullo sfruttamento effettivo?
• Come vi coordinate con provider esterni di threat intelligence?

Errori Comuni

Aspettare la Certezza

Problema: Volere prove forensi prima di segnalare.

Realtà: Il conto alla rovescia di 24 ore inizia quando avete una convinzione ragionevole. Se aspettate la certezza, mancherete la scadenza.

Soluzione: Segnalate presto. Potete aggiornare con "non più ritenuto sfruttato" nella notifica dettagliata se le evidenze non lo supportano.

Confondere CVD e Segnalazione

Problema: Trattare i report dei ricercatori come notifiche ENISA.

Realtà: La divulgazione coordinata delle vulnerabilità e la segnalazione ENISA sono processi separati.

• CVD: Come gestite i report dei ricercatori, concordate le timeline di divulgazione
• ENISA: Notifica obbligatoria quando si verifica lo sfruttamento

Soluzione: Il processo CVD dovrebbe includere un gate: "Ci sono evidenze di sfruttamento?" Se sì, attivare la segnalazione ENISA in parallelo al CVD.

Punto singolo di guasto

Problema: Solo una persona può autorizzare i report, ed è irraggiungibile.

Realtà: Lo sfruttamento può essere scoperto in qualsiasi momento. Weekend. Festivi. Alle 3 di notte.

Soluzione: Più reporter autorizzati. Delega chiara. Catena di contatto di emergenza.

Nessuna Relazione con i CSIRTs

Problema: Primo contatto con il vostro CSIRT nazionale durante un incidente.

Realtà: Costruire relazioni in anticipo rende la risposta agli incidenti più fluida.

Soluzione: Coinvolgete il vostro CSIRT nazionale ora. Capite i loro processi. Unitevi a eventuali programmi di outreach per fabbricanti.

Esenzioni per le PMI

Le piccole e medie imprese hanno qualche sollievo:

Esenzione tempistiche di notifica: Le PMI sono esenti da multe specificamente legate alle scadenze di notifica di 24 ore e 72 ore.

Ancora richiesto:

• La segnalazione (solo non penalizzati per ritardi nelle tempistiche)
• Tutti gli altri obblighi CRA
• I report finali

Definizione: PMI come definita nella Raccomandazione UE 2003/361/CE (meno di 250 dipendenti, fatturato ≤ 50 milioni EUR o bilancio ≤ 43 milioni EUR).

Questa esenzione è solo per le penalità sulle tempistiche. Le PMI devono comunque stabilire capacità di segnalazione.

Integrazione con Processi Esistenti

Se Avete Già Incident Response

Mappate la segnalazione CRA al vostro processo esistente:

PROCESSO IR ESISTENTE          INTEGRAZIONE CRA
───────────────────────────────────────────────
Rilevazione
    │
Triage ──────────────────→  Verifica: Sfruttamento prodotto CRA?
    │                             │
Contenimento                      ├─ SÌ: Avviare conto 24h
    │                             │      Inviare allerta precoce
Investigazione                    │
    │                             │
Rimedio ──────────────────→  Notifica dettagliata 72h
    │
Recovery
    │
Lezioni Apprese ──────────→  Report finale 14g/30g

Se Avete Obblighi NIS 2

Alcune organizzazioni hanno sia obblighi NIS 2 che CRA:

• NIS 2: Incidenti a livello organizzazione/servizio
• CRA: Vulnerabilità e incidenti a livello prodotto

Questi possono sovrapporsi. Un singolo incidente potrebbe richiedere:

• Notifica NIS 2 all'autorità competente
• Notifica CRA a ENISA/CSIRT

La SRP ENISA è progettata per gestire il routing per entrambi i regimi dove applicabile.

Checklist Preparazione Segnalazione ENISA

CHECKLIST PREPARAZIONE SEGNALAZIONE ENISA

PRIMA DI SETTEMBRE 2026:

CANALI & CONTATTI
[ ] security.txt pubblicato e aggiornato
[ ] Modulo di segnalazione vulnerabilità disponibile
[ ] Email sicurezza monitorata (definire SLA: ____ ore)
[ ] Contatto CSIRT nazionale identificato
[ ] Registrazione ENISA SRP (quando disponibile)

PROCESSO INTERNO
[ ] Criteri di triage documentati
[ ] Checklist valutazione sfruttamento creata
[ ] Percorso di escalation definito (nomi, contatti)
[ ] Reporter autorizzati identificati
[ ] Copertura fuori orario stabilita

DOCUMENTAZIONE
[ ] Template allerta precoce preparato
[ ] Template notifica dettagliata preparato
[ ] Template report finale preparato
[ ] Materiali briefing interno pronti

TEST
[ ] Esercitazione tabletop completata
[ ] Escalation fuori orario testata
[ ] Revisione template completata

QUANDO VIENE RILEVATO SFRUTTAMENTO:

IMMEDIATO (entro 4 ore)
[ ] Valutazione iniziale: Questo è attivamente sfruttato?
[ ] Ora di inizio conto documentata: ____________
[ ] Escalation al reporter autorizzato

ENTRO 24 ORE
[ ] Allerta precoce inviata a ENISA SRP
[ ] Conferma di sottomissione ricevuta
[ ] Stakeholder interni notificati

ENTRO 72 ORE
[ ] Notifica dettagliata inviata
[ ] Stato mitigazione aggiornato
[ ] Comunicazione cliente avviata (se appropriato)

ENTRO 14 GIORNI (vulnerabilità) / 30 GIORNI (incidente)
[ ] Report finale inviato
[ ] Lezioni apprese documentate
[ ] Miglioramenti processo identificati

Come CRA Evidence Aiuta

CRA Evidence include supporto al workflow di segnalazione ENISA:

• Tracciamento scadenze: Conto alla rovescia automatico dalla scoperta
• Template report: Pre-compilati con i dettagli del vostro prodotto
• Audit trail: Documentate la vostra timeline e decisioni
• Integrazione: Connettete vulnerability scanning al workflow di segnalazione

Siate pronti per settembre 2026 con app.craevidence.com.

Tempistiche: Scopri quando iniziano gli obblighi di segnalazione nel nostro cronoprogramma di attuazione del CRA.

CVD: Configura il tuo processo di ricezione vulnerabilita con il nostro template di policy CVD.

Sanzioni: Comprendi le conseguenze dell'applicazione nella nostra guida alle sanzioni.

Questo articolo è fornito solo a scopo informativo e non costituisce consulenza legale. Per una consulenza di conformità specifica, consultare un consulente legale qualificato esperto in regolamentazioni prodotti dell'UE.