{"id":1315,"date":"2026-09-11T15:17:58","date_gmt":"2026-09-11T13:17:58","guid":{"rendered":"https:\/\/sites.unica.it\/ict4lawforensics\/?p=1315"},"modified":"2026-09-11T15:17:58","modified_gmt":"2026-09-11T13:17:58","slug":"segnalare-senza-esporre-il-cyber-resilience-act-e-la-nuova-governance-europea-delle-vulnerabilita","status":"publish","type":"post","link":"https:\/\/sites.unica.it\/ict4lawforensics\/2026\/09\/11\/segnalare-senza-esporre-il-cyber-resilience-act-e-la-nuova-governance-europea-delle-vulnerabilita\/","title":{"rendered":"Segnalare senza esporre. Il Cyber Resilience Act e la nuova governance europea delle vulnerabilit\u00e0"},"content":{"rendered":"\n

Abstract<\/strong>
Dall\u201911 settembre 2026<\/strong> trova applicazione l\u2019articolo 14 del Regolamento (UE) 2024\/2847<\/strong>, il Cyber Resilience Act (CRA), che introduce specifici obblighi di segnalazione a carico dei fabbricanti di prodotti con elementi digitali in presenza di vulnerabilit\u00e0 attivamente sfruttate o di incidenti gravi.<\/a>

As of <\/em>11 September 2026<\/em><\/strong>, Article 14 of <\/em>Regulation (EU) 2024\/2847<\/em><\/strong>, the Cyber Resilience Act (CRA), becomes applicable, introducing specific reporting obligations for manufacturers of products with digital elements in the event of actively exploited vulnerabilities or severe incidents.<\/em><\/em><\/p>\n\n\n\n

Sommario. 1. Introduzione<\/a> – 2. Non tutte le vulnerabilit\u00e0 devono essere segnalate<\/a> – 3. Le ventiquattro ore che collegano tecnica e diritto<\/a> – 4. La Single Reporting Platform<\/em> non \u00e8 soltanto un portale<\/a> – 5. Il problema della disclosure: informare pu\u00f2 rendere pi\u00f9 vulnerabili <\/a>– 6. Una nuova forma di accountability della sicurezza.<\/a><\/p>\n\n\n\n

1. Introduzione<\/h2>\n\n\n\n

Dall\u201911 settembre 2026<\/strong> trova applicazione l\u2019articolo 14 del Regolamento (UE) 2024\/2847<\/strong>, il Cyber Resilience Act (CRA), che introduce specifici obblighi di segnalazione a carico dei fabbricanti di prodotti con elementi digitali in presenza di vulnerabilit\u00e0 attivamente sfruttate o di incidenti gravi.<\/a><\/p>\n\n\n\n

Non si tratta ancora della piena applicazione del Regolamento, prevista per l\u201911 dicembre 2027. Il legislatore europeo ha per\u00f2 scelto di anticipare proprio il meccanismo di reporting. \u00c8 un dato che merita attenzione perch\u00e9 mostra una precisa priorit\u00e0 regolatoria: prima che l\u2019intera disciplina diventi operativa, deve gi\u00e0 esistere una rete capace di far circolare rapidamente le informazioni relative ai rischi pi\u00f9 rilevanti.<\/p>\n\n\n\n

La novit\u00e0 non si esaurisce quindi nell\u2019introduzione di un nuovo adempimento. Il vulnerability management<\/em>, attivit\u00e0 tradizionalmente affidata soprattutto a procedure tecniche e organizzative interne, entra in una sequenza disciplinata dal diritto. Diventa rilevante stabilire quando nasce l\u2019obbligo, chi deve attivarsi, entro quale termine, verso quali soggetti e con quale livello di dettaglio. Perfino la scelta di diffondere o temporaneamente trattenere alcune informazioni viene sottoposta a regole.<\/p>\n\n\n\n

<\/h3>\n\n\n\n

2. Non tutte le vulnerabilit\u00e0 devono essere segnalate<\/strong><\/a><\/h2>\n\n\n\n

Il punto di partenza \u00e8 la definizione dell\u2019evento che fa scattare l\u2019obbligo.<\/p>\n\n\n\n

Il CRA non impone al fabbricante di comunicare ogni vulnerabilit\u00e0 individuata nel prodotto. La soglia normativa \u00e8 diversa. Una vulnerabilit\u00e0 \u00e8 \u00abattivamente sfruttata\u00bb quando esistono elementi attendibili che dimostrano come un soggetto malevolo l\u2019abbia effettivamente utilizzata in un sistema senza il consenso del relativo proprietario.<\/p>\n\n\n\n

La semplice scoperta di una falla, pertanto, non \u00e8 sufficiente. Lo stesso Regolamento chiarisce che l\u2019individuazione della vulnerabilit\u00e0 nel corso di attivit\u00e0 svolte in buona fede (ad esempio testing, ricerca, correzione o disclosure coordinate) non deve essere automaticamente equiparata allo sfruttamento malevolo.<\/p>\n\n\n\n

Diversa \u00e8 la nozione di incidente grave<\/strong>, che guarda agli effetti prodotti sulla capacit\u00e0 del prodotto di proteggere disponibilit\u00e0, autenticit\u00e0, integrit\u00e0 o riservatezza di dati e funzioni sensibili o importanti. Vi rientra anche l\u2019ipotesi in cui l\u2019incidente consenta l\u2019introduzione o l\u2019esecuzione di codice malevolo nel prodotto o nei sistemi dell\u2019utente.<\/p>\n\n\n\n

La distinzione \u00e8 tutt\u2019altro che teorica. Un\u2019organizzazione pu\u00f2 disporre di strumenti efficaci per individuare anomalie o vulnerabilit\u00e0 e, nondimeno, non essere ancora in grado di stabilire rapidamente se l\u2019evento rilevato rientri nella fattispecie normativa che impone la segnalazione. Dal punto di vista della compliance, il problema non \u00e8 soltanto vedere ci\u00f2 che sta accadendo, ma qualificarlo correttamente e farlo in tempi molto brevi<\/strong>.<\/p>\n\n\n\n

<\/h3>\n\n\n\n

3. Le ventiquattro ore che collegano tecnica e diritto<\/strong><\/a><\/h2>\n\n\n\n

Una volta acquisita consapevolezza di una vulnerabilit\u00e0 attivamente sfruttata o di un incidente grave, il tempo diventa una componente essenziale dell\u2019obbligo.<\/p>\n\n\n\n

Entro 24 ore<\/strong> deve essere trasmesso un early warning<\/em>. Entro 72 ore<\/strong> deve seguire una notifica contenente informazioni pi\u00f9 complete. Le fasi successive differiscono poi a seconda che si tratti di una vulnerabilit\u00e0 o di un incidente: nel primo caso il rapporto finale deve essere presentato entro quattordici giorni dalla disponibilit\u00e0 di una misura correttiva o di mitigazione; nel secondo, entro un mese dalla notifica delle 72 ore.<\/p>\n\n\n\n

L\u2019obbligo interessa anche prodotti con elementi digitali immessi sul mercato prima dell\u201911 dicembre 2027. L\u2019articolo 69 del CRA, nel disciplinare il regime transitorio, riserva infatti un trattamento specifico proprio all\u2019articolo 14.<\/p>\n\n\n\n

Non deriva invece dal Regolamento un obbligo generalizzato di riportare retroattivamente ogni vulnerabilit\u00e0 conosciuta prima dell\u201911 settembre 2026. Ci\u00f2 che rileva \u00e8 il momento nel quale si realizza quella consapevolezza dell\u2019evento che il Regolamento assume come presupposto della notifica.<\/p>\n\n\n\n

\u00c8 soprattutto in questa scansione temporale che il diritto entra nell\u2019incident response<\/em>. Il momento in cui tecnicamente viene riconosciuto un evento potenzialmente rilevante pu\u00f2 coincidere con l\u2019inizio di una finestra normativa di sole ventiquattro ore. Detection, analisi tecnica, qualificazione giuridica, escalation interna e rapporto con le autorit\u00e0 non possono pi\u00f9 essere trattati come compartimenti separati.<\/p>\n\n\n\n

Una procedura interna che funzioni bene sul piano tecnico ma che non consenta di individuare tempestivamente chi deve assumere la decisione sulla notifica rischia, in concreto, di essere insufficiente.<\/p>\n\n\n\n

<\/h3>\n\n\n\n

4. La Single Reporting Platform<\/em> non \u00e8 soltanto un portale<\/strong><\/a><\/h2>\n\n\n\n

Le notifiche vengono gestite attraverso la Single Reporting Platform (SRP)<\/strong> prevista dall\u2019articolo 16 del CRA e affidata all\u2019European Union Agency for Cybersecurity (ENISA).<\/p>\n\n\n\n

Il fabbricante utilizza il punto elettronico del CSIRT designato come coordinatore nello Stato membro della propria sede principale. L\u2019ENISA accede contestualmente alle informazioni, fatte salve le eccezioni previste dal Regolamento, mentre il CSIRT destinatario assicura la successiva circolazione verso gli altri CSIRT interessati e rende disponibili alle Autorit\u00e0 di Vigilanza del mercato le informazioni necessarie all\u2019esercizio delle loro competenze.<\/p>\n\n\n\n

Anche la nozione di \u00absede principale\u00bb \u00e8 costruita in modo funzionale. Non coincide necessariamente con la sede legale dell\u2019impresa: assume rilievo, anzitutto, lo Stato membro nel quale vengono prevalentemente adottate le decisioni relative alla cybersicurezza dei prodotti.<\/p>\n\n\n\n

Ridurre la SRP a un nuovo portale europeo per le notifiche sarebbe quindi fuorviante. La piattaforma costituisce il punto di accesso a una rete istituzionale nella quale un\u2019informazione nata all\u2019interno dell\u2019organizzazione del fabbricante viene resa disponibile, secondo regole prestabilite, al CSIRT, all\u2019ENISA e all\u2019Autorit\u00e0 di Vigilanza.<\/p>\n\n\n\n

La vulnerabilit\u00e0 continua ad essere un problema tecnico da correggere, ma diventa contemporaneamente un\u2019informazione regolata. E la disciplina non si limita a imporne la comunicazione: ne governa anche la circolazione.<\/p>\n\n\n\n

<\/h3>\n\n\n\n

5. Il problema della disclosure: informare pu\u00f2 rendere pi\u00f9 vulnerabili<\/strong><\/a><\/h2>\n\n\n\n

\u00c8 proprio qui che emerge uno degli aspetti pi\u00f9 interessanti del nuovo sistema.<\/p>\n\n\n\n

La conoscenza di una vulnerabilit\u00e0 consente di predisporre contromisure, avvisare i soggetti interessati e coordinare la risposta. La stessa informazione, tuttavia, se circola troppo presto o raggiunge destinatari non adeguatamente protetti, pu\u00f2 rendere pi\u00f9 semplice lo sfruttamento della falla.<\/p>\n\n\n\n

Il CRA affronta espressamente questa tensione. L\u2019articolo 16 consente, in circostanze eccezionali e per giustificati motivi di cybersicurezza, di ritardare la diffusione della notifica.<\/p>\n\n\n\n

Il Regolamento delegato (UE) 2026\/881<\/strong> precisa i criteri da considerare. Il ritardo pu\u00f2 essere giustificato, ad esempio, quando le informazioni contenute nella notifica sarebbero sufficienti per costruire una tecnica di exploit, soprattutto se utilizzabile anche da soggetti dotati di capacit\u00e0 e risorse limitate. Assume rilievo anche l\u2019eventuale disponibilit\u00e0, entro un breve arco temporale, di una misura efficace di mitigazione. Il Regolamento delegato prende inoltre in considerazione il coordinamento con procedure di coordinated vulnerability disclosure<\/em>.<\/p>\n\n\n\n

La questione non pu\u00f2 essere liquidata come una semplice eccezione procedurale. Il sistema europeo deve fare due cose contemporaneamente: diffondere l\u2019informazione necessaria a ridurre il rischio e impedire che la stessa informazione generi un rischio ulteriore.<\/p>\n\n\n\n

La disclosure diventa cos\u00ec una forma di circolazione governata della conoscenza<\/strong>. Non conta soltanto ci\u00f2 che viene comunicato. Contano anche il destinatario, il momento, la necessit\u00e0 di conoscere l\u2019informazione e lo stato delle eventuali misure correttive.<\/p>\n\n\n\n

Il problema riguarda inevitabilmente anche la piattaforma. L\u2019articolo 16 impone all\u2019ENISA l\u2019adozione di misure tecniche, operative e organizzative adeguate e proporzionate per proteggere la SRP e i dati trattati. Il Regolamento delegato contempla persino la possibilit\u00e0 di sospendere la diffusione quando un incidente che colpisca la piattaforma faccia dubitare della riservatezza delle notifiche.<\/p>\n\n\n\n

L\u2019infrastruttura costruita per governare le vulnerabilit\u00e0 deve, essa stessa, essere trattata come una possibile superficie di rischio.<\/p>\n\n\n\n

<\/h3>\n\n\n\n

6. Una nuova forma di accountability della sicurezza<\/strong><\/a><\/h2>\n\n\n\n

Vista da questa prospettiva, la novit\u00e0 dell\u201911 settembre riguarda soprattutto l\u2019organizzazione interna del fabbricante.<\/p>\n\n\n\n

Occorre poter ricostruire quando l\u2019organizzazione ha avuto conoscenza dell\u2019evento, come lo ha qualificato, quali informazioni erano disponibili in quel momento, chi ha assunto le decisioni e quali comunicazioni sono state effettuate. La cybersecurity viene cos\u00ec accompagnata da una crescente esigenza di documentabilit\u00e0 del processo decisionale.<\/p>\n\n\n\n

Anche l\u2019informazione agli utenti fa parte della stessa catena. Il fabbricante deve informare i soggetti interessati della vulnerabilit\u00e0 o dell\u2019incidente e, quando opportuno, indicare le misure che possono adottare per mitigarne gli effetti.<\/p>\n\n\n\n

Al tempo stesso, il CRA precisa che il semplice fatto di effettuare una notifica ai sensi degli articoli 14 e 15 non comporta, di per s\u00e9, un incremento della responsabilit\u00e0 del soggetto notificante. Una previsione comprensibile: un sistema di reporting destinato a far emergere rapidamente gli eventi pi\u00f9 gravi non potrebbe funzionare efficacemente se la segnalazione fosse percepita essa stessa come una fonte automatica di aggravamento della posizione giuridica dell\u2019impresa.<\/p>\n\n\n\n

Le FAQ pubblicate dall\u2019ENISA alla vigilia dell\u2019avvio della Single Reporting Platform<\/em> mostrano quanto il profilo organizzativo sia gi\u00e0 concreto. La documentazione specifica le modalit\u00e0 di registrazione, i ruoli degli Assigned Representatives<\/em> e il flusso delle notifiche. Nella prima versione del sistema non \u00e8 inoltre disponibile un\u2019API per automatizzare direttamente l\u2019invio alla piattaforma, mentre le notifiche volontarie previste dall\u2019articolo 15 saranno implementate in una fase successiva.<\/p>\n\n\n\n

Il rispetto dell\u2019articolo 14, insomma, non comincia quando qualcuno apre la Single Reporting Platform. Comincia molto prima, nella struttura interna dell\u2019organizzazione: nelle procedure, nella distribuzione delle responsabilit\u00e0 e nella capacit\u00e0 di far dialogare competenze tecniche e giuridiche entro una finestra temporale estremamente ridotta.<\/p>\n\n\n\n

L\u201911 settembre 2026 rappresenta perci\u00f2 un passaggio rilevante nell\u2019attuazione del Cyber Resilience Act. La gestione delle vulnerabilit\u00e0 viene progressivamente sottratta a una dimensione esclusivamente tecnico-organizzativa e inserita in una catena europea di conoscenza, comunicazione e responsabilizzazione<\/strong>.<\/p>\n\n\n\n

Il successo del meccanismo non dipender\u00e0 soltanto dal numero o dalla rapidit\u00e0 delle notifiche. Dipender\u00e0 dalla qualit\u00e0 delle informazioni che circoleranno, dalla capacit\u00e0 degli operatori di riconoscere correttamente gli eventi rilevanti e, soprattutto, dalla possibilit\u00e0 di condividere la conoscenza necessaria senza amplificare il rischio che quella stessa conoscenza dovrebbe contribuire a contenere.<\/p>\n\n\n\n

\u00c8 su questo equilibrio operativo, pi\u00f9 che sulla piattaforma in s\u00e9, che il nuovo sistema sar\u00e0 chiamato a misurarsi.<\/p>\n\n\n\n

\n\n\n\n

Fonti e riferimenti essenziali<\/strong><\/a><\/h2>\n\n\n\n
    \n
  1. Regolamento (UE) 2024\/2847 del Parlamento europeo e del Consiglio, del 23 ottobre 2024<\/strong>, relativo a requisiti orizzontali di cybersicurezza per i prodotti con elementi digitali – Cyber Resilience Act, in particolare artt. 14-17, 69 e 71.
    https:\/\/eur-lex.europa.eu\/legal-content\/IT\/TXT\/?uri=CELEX:32024R2847<\/li>\n\n\n\n
  2. Commissione europea, Cyber Resilience Act \u2013 Reporting obligations<\/strong>, quadro degli obblighi di reporting applicabili dall\u201911 settembre 2026.
    https:\/\/digital-strategy.ec.europa.eu\/en\/policies\/cra-reporting<\/li>\n\n\n\n
  3. Commissione europea, Guidance on the application of the Cyber Resilience Act, C(2026) 5252<\/strong>, 27 luglio 2026.
    https:\/\/digital-strategy.ec.europa.eu\/en\/library\/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation<\/li>\n\n\n\n
  4. ENISA, Frequently Asked Questions \u2013 CRA Single Reporting Platform<\/strong>, aggiornate il 10 settembre 2026.
    https:\/\/www.enisa.europa.eu\/topics\/product-security\/single-reporting-platform-srp\/frequently-asked-questions<\/li>\n\n\n\n
  5. ENISA, CRA SRP Glossary<\/strong>, versione 1.1, 5 settembre 2026.
    https:\/\/www.enisa.europa.eu\/topics\/product-security\/single-reporting-platform-srp\/cra-srp-glossary<\/li>\n\n\n\n
  6. Regolamento delegato (UE) 2026\/881 della Commissione, dell\u201911 dicembre 2025<\/strong>, relativo ai motivi di cybersicurezza che consentono di ritardare la diffusione delle notifiche.
    https:\/\/eur-lex.europa.eu\/legal-content\/IT\/TXT\/?uri=CELEX:32026R0881<\/li>\n<\/ol>\n\n\n\n

    Di\u00a0Massimo Farina<\/strong>
    \u00a0Professore Associato di Informatica Giuridica presso il Dipartimento di Ingegneria Elettrica e Elettronica (DIEE) dell\u2019Universit\u00e0 di Cagliari. Responsabile della protezione dei dati personali (RPD), ai sensi dell’articolo 37 del Regolamento UE 2016\/679, dell\u2019Ateneo Cagliaritano e Coordinatore del \u201cICT4Law&Forensics Lab”. Abilitato alle funzioni di Professore di prima fascia per il settore concorsuale 12 H3 (Filosofia del diritto – GIUR-17\/A\u00a0). Avvocato del Foro di Cagliari abilitato al patrocinio davanti alle Giurisdizioni Superiori.<\/p>\n","protected":false},"excerpt":{"rendered":"

    AbstractDall\u201911 settembre 2026 trova applicazione l\u2019articolo 14 del Regolamento (UE) 2024\/2847, il Cyber Resilience Act (CRA), che introduce specifici obblighi di segnalazione a carico dei fabbricanti di prodotti con elementi digitali in presenza di vulnerabilit\u00e0 attivamente […]<\/p>\n","protected":false},"author":2239,"featured_media":929,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_coblocks_attr":"","_coblocks_dimensions":"","_coblocks_responsive_height":"","_coblocks_accordion_ie_support":"","footnotes":""},"categories":[1],"tags":[34,14],"class_list":["post-1315","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news-ed-eventi","tag-cyber","tag-cybersecurity"],"_links":{"self":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/users\/2239"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/comments?post=1315"}],"version-history":[{"count":2,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1315\/revisions"}],"predecessor-version":[{"id":1318,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/posts\/1315\/revisions\/1318"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/media\/929"}],"wp:attachment":[{"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/media?parent=1315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/categories?post=1315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.unica.it\/ict4lawforensics\/wp-json\/wp\/v2\/tags?post=1315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}