Il playbook di reporting del Cyber Resilience Act — 24h/72h, dall'11 settembre 2026

Usa questo playbook se fabbrichi, sviluppi o immetti sul mercato UE un prodotto con elementi digitali — hardware o software il cui uso previsto o ragionevolmente prevedibile include una connessione dati diretta o indiretta verso un dispositivo o una rete (art. 3, Regolamento (UE) 2024/2847). Dall'11 settembre 2026 i doveri di reporting dell'articolo 14 si applicano a te e — punto cruciale — si applicano ai prodotti già sul mercato, non solo a quelli che spedisci dopo quella data.

Scatta nel momento in cui una di due cose diventa vera:

• Hai evidenza che una vulnerabilità nel tuo prodotto è attivamente sfruttata — cioè un attore malevolo l'ha usata con successo, non semplicemente che esiste un proof-of-concept.
• Un incidente grave ha un impatto sulla sicurezza del tuo prodotto con elementi digitali — per esempio una compromissione del tuo ambiente di sviluppo o distribuzione che potrebbe incidere sul prodotto, o un incidente che degrada la capacità del prodotto di proteggere confidenzialità, integrità o disponibilità.

NON scatta per: un incidente di sicurezza lato operatore sull'infrastruttura che gestisci per il tuo business (è territorio NIS2/DORA — vedi la timeline NIS2 Title 13); una vulnerabilità trovata internamente senza evidenza di sfruttamento (registrala nel processo di gestione vulnerabilità, non filare un early warning a 24 ore); o le categorie di prodotto escluse dal CRA (dispositivi medici sotto MDR/IVDR, veicoli, aviazione, prodotti già coperti da regimi settoriali). Se sei solo distributore o importatore, i tuoi doveri sono più stretti — ma devi informare il produttore e l'autorità di sorveglianza del mercato, quindi leggi comunque la Fase A.

Ci sono due binari di reporting paralleli ex art. 14 e condividono la stessa cadenza a tre gate. Predisponili entrambi adesso; non li improvvisi all'ora 1.

Binario 1 — vulnerabilità attivamente sfruttata (art. 14(1)): - Early warning — entro 24 ore dalla awareness. - Notifica di vulnerabilità — entro 72 ore dalla awareness. - Report finale — non oltre 14 giorni dalla disponibilità di una misura correttiva o di mitigazione.

Binario 2 — incidente grave che impatta la sicurezza del prodotto (art. 14(2)): - Early warning — entro 24 ore dalla awareness. - Notifica di incidente — entro 72 ore dalla awareness. - Report finale — entro un mese dalla notifica a 72 ore.

Entrambi i binari filano alla CRA Single Reporting Platform (SRP). La notifica è instradata al CSIRT designato coordinatore nello Stato membro del tuo stabilimento principale, ed è resa disponibile a ENISA in simultanea. Notifichi una volta, in un'unica piattaforma — non mandi email a 27 CSIRT nazionali.

La parola-trigger è awareness. Il countdown a 24 ore parte quando una persona competente nella tua organizzazione avrebbe dovuto concludere che la vulnerabilità è sfruttata o che è avvenuto un incidente grave — non quando un comitato firma formalmente. Il calcolo all'indietro si applica, esattamente come sotto NIS2 Title 13.

Obiettivo: inviare l'early warning alla SRP prima del limite di 24 ore dalla awareness.

Il contenuto minimo dell'early warning è volutamente scarno — non ritardarlo per completezza:

• Se stai segnalando una vulnerabilità attivamente sfruttata o un incidente grave.
• Nome e versione/i del prodotto con elementi digitali interessato.
• Lo/gli Stato/i membro/i dove il prodotto è messo a disposizione, se noto.
• Se, per quanto ti risulta, la vulnerabilità è sfruttata, o l'incidente è sospettato illecito o malevolo.
• Un singolo punto di contatto.

Checklist delle prime 24 ore:

• Timestampa la awareness in un log immutabile — questo timestamp è l'inizio di ogni countdown a valle.
• Convoca il CRA reporting lead, il product-security owner e il legale. Un singolo decisore nominato possiede la notifica.
• Conferma che il trigger raggiunga la soglia dell'art. 14 — attivamente sfruttata (evidenza di sfruttamento riuscito) o grave — e verbalizza il ragionamento. Sovra-segnalare una questione non grave brucia credibilità; sotto-segnalare una falla sfruttata è una violazione da €15M.
• Identifica versioni interessate e Stati membri di disponibilità da SBOM e registri di distribuzione.
• Fila l'early warning tramite la SRP. La sotto-comunicazione a questo gate è attesa; l'early warning è preliminare per design.
• Se esiste già una misura correttiva o di mitigazione — una patch, un cambio di config, un kill-switch — dichiarala. Sul Binario 1 fa partire il countdown dei 14 giorni per il report finale a tuo favore.

Obiettivo: inviare la notifica più completa entro il limite di 72 ore dallo stesso timestamp di awareness.

Contenuto da aggiungere rispetto all'early warning:

• Per una vulnerabilità: natura, severità e impatto, e — dove disponibili — misure correttive o di mitigazione che gli utenti possono adottare. Includi l'identificativo CVE se assegnato.
• Per un incidente grave: natura e impatto, root cause valutata dove nota, e le misure di mitigazione applicate o raccomandate.
• Se la vulnerabilità o l'incidente riguarda altri prodotti, e ogni indicatore di compromissione noto.

Checklist a 72 ore:

• Assegna o richiama un CVE — registrati come CVE Numbering Authority in anticipo se spedisci fix di sicurezza di routine, così non richiedi un ID sotto scadenza.
• Pubblica o prepara l'advisory di coordinated disclosure richiesto dall'Allegato I, Parte II — il report al regolatore e l'advisory pubblico non devono contraddirsi.
• Allega la porzione di SBOM del componente interessato così il CSIRT può valutare la portata a valle.
• Dichiara il containment: cosa hai spedito, cosa hai ritirato, cosa devono fare i clienti adesso.
• Segnala onestamente cosa è ancora ipotesi. Una root cause preliminare chiaramente marcata come tale va bene; una conclusione confidente che poi rimangi al report finale no.

Binario 1 (vulnerabilità): non oltre 14 giorni dopo che una misura correttiva o di mitigazione è disponibile. Se non spedisci mai un fix, quel countdown non parte — ma lasciare non risolta una vulnerabilità nota e sfruttata viola il dovere dell'Allegato I, Parte II di indirizzare le vulnerabilità senza ritardo, quindi non è una scappatoia.

Binario 2 (incidente): entro un mese dalla notifica a 72 ore.

Contenuto del report finale:

• La root cause verificata, o una spiegazione documentata del perché non è determinabile.
• L'insieme completo delle misure correttive e di mitigazione dispiegate, con la versione che porta il fix.
• Lo scope confermato: versioni interessate, Stati membri, e — per un incidente — cosa è stato acceduto o degradato.
• Le lessons applicate al processo di gestione vulnerabilità.

Questo report è un documento di sintesi se gli artefatti sottostanti sono stati catturati e firmati strada facendo. Se SBOM, advisory, provenance della patch ed evidenza dello sfruttamento sono stati assemblati a mano dopo il fatto, il report finale diventa una riconciliazione di settimane che collide con la tua prossima release.

Non puoi filare un report a 24 ore il 12 settembre se la macchina non è in piedi il 10 settembre. Il dovere di reporting presuppone il processo di gestione vulnerabilità dell'Allegato I, Parte II — anche se quell'Allegato è formalmente obbligatorio solo dall'11 dicembre 2027, e il quadro di notifica degli organismi di valutazione della conformità si applica dall'11 giugno 2026, non puoi conformarti all'art. 14 senza il processo di gestione vulnerabilità già in funzione. Costruisci adesso:

• Un SBOM machine-readable per artefatto spedito (CycloneDX o SPDX), che copra almeno le dipendenze di primo livello, generato al build time e mantenuto aggiornato. Vedi la definizione di SBOM per il dettaglio di formato. Senza, non puoi rispondere a "quali prodotti contengono il componente sfruttato" entro 24 ore.
• Un CRA reporting lead nominato e un deputy, con accesso SRP predisposto e testato. ENISA ha indicato una finestra di test prima del go-live — usala.
• Un template di notifica a 24/72 ore pre-scritto per entrambi i binari, così la prima ora è data entry, non stesura.
• Una policy di coordinated vulnerability disclosure, pubblicata, con un canale di contatto presidiato anche nei weekend.
• Capacità di detection dello sfruttamento — "attivamente sfruttata" è uno standard di prova, e il countdown della awareness parte da quando avresti dovuto sapere. Se non vedi lo sfruttamento del tuo prodotto in campo, sei esposto a filare in ritardo.
• Una traccia di evidenza firmata: SBOM, advisory, provenance della patch, telemetria di detection e log di remediation, ciascuno datato e tamper-evident. La guidance pratica pubblicata dalla Commissione europea il 27 luglio 2026 è il riferimento attuale per cosa significhi "adeguato".

Quest'ultimo punto è dove la maggior parte delle organizzazioni prodotto scopre che il proprio tooling era costruito per audit annuali, non per clock a 24 ore. Il layer di Automatic Compliance di Zero Hunt mantiene questa traccia in continuo: 32 framework mappati con cross-framework control mapping e report firmati ECDSA con chain-of-custody by construction, esportati dal Trust Center con un click. La stessa base di evidenze che risponde a una notifica NIS2 o DORA alimenta la notifica CRA — così un early warning a 24 ore diventa un export e una review, non una ricostruzione forense sotto il clock di un regolatore.

1. Trattare l'11 dicembre 2027 come la scadenza CRA. Gli obblighi di reporting mordono 15 mesi prima, l'11 settembre 2026, e si applicano ai prodotti già sul campo. I team prodotto che si tarano sulla data 2027 mancano del tutto il primo gate reale.

2. Filare su un proof-of-concept. L'art. 14(1) è per vulnerabilità attivamente sfruttate — evidenza che un attaccante è riuscito. Un PoC pubblicato senza sfruttamento osservato va nel processo di gestione vulnerabilità, non in un early warning a 24 ore. Segnalare riflessivamente ogni PoC allena il CSIRT a ignorarti.

3. Niente SBOM, quindi nessuna risposta sul blast radius. Quando il componente sfruttato sta tre dipendenze sotto, un team senza un SBOM per-artefatto aggiornato spende le prime 24 ore a ricostruire cosa è stato spedito dove — tempo che il countdown non concede.

4. Il gap di awareness. Il countdown parte da quando avresti dovuto sapere. Un produttore senza telemetria sullo sfruttamento del prodotto in campo non è solo più lento a segnalare — è strutturalmente in ritardo, e "non avevamo modo di rilevarlo" non è una difesa per un dovere di sicurezza del prodotto.

5. Un report al regolatore e un advisory pubblico che divergono. La notifica ex art. 14 e l'advisory di coordinated disclosure dell'Allegato I sono scritti da persone diverse sotto pressione. Se severità CVE, versioni interessate o mitigazione differiscono tra i due, entrambi perdono credibilità. Una fonte di verità, due render.

6. Improvvisare l'accesso alla SRP all'ora 1. Predisporre e testare l'accesso alla Single Reporting Platform è un compito pre-incidente. Scoprire all'ora 20 che nessuno ha le credenziali trasforma una scadenza a 24 ore in una mancata.

Un singolo evento può far scattare il CRA più altri regimi in una volta, su countdown diversi, e il CRA non li rimpiazza:

• CRA vs NIS2: se sei anche entità essenziale o importante, un incidente che tocca la continuità del tuo servizio è una notifica NIS2 Title 13 (24h/72h/1-mese) in parallelo al report CRA lato prodotto. Stesso evento, due vesti — produttore e operatore.
• CRA vs DORA: un'entità finanziaria o un fornitore ICT terzo che spedisce un prodotto può dover fare anche un report di incidente grave DORA (4h/72h/1-mese).
• CRA vs GDPR: se l'incidente ha esposto dati personali, l'art. 33 GDPR scatta con il suo countdown a 72 ore verso l'autorità di protezione dati.
• CRA vs AI Act: dove il prodotto è anche un sistema AI ad alto rischio, gli obblighi di reporting di incidente grave dell'AI Act si sommano.

Il CRA mitiga una parte del problema per design: notifichi una volta nella Single Reporting Platform e lei dissemina. Ma quel sollievo a piattaforma unica è interno al CRA — non fonde le tue notifiche NIS2, DORA o GDPR. Costruisci una base di evidenze, mappala tra i regimi, e rendi un report per regolatore. I produttori che mantengono un pacchetto di evidenze per-artefatto filano quattro report allineati da un unico record; chi non lo fa ne fila quattro divergenti e passa l'audit a spiegare le differenze.