# Da segnalazione a notifica: quando una segnalazione esterna diventa una notifica SRP > Non ogni segnalazione che arriva dall'esterno fa scattare l'obbligo del CRA. Il trigger è stretto e definito. Come un'azienda decide, spesso in 24 ore e magari a portoni chiusi, se aprire una notifica sulla piattaforma ENISA. Con un caso concreto: il sensore WiFi compromesso. - URL: https://albertoscarpa.com/blog/it/da-segnalazione-a-notifica-srp/ - Lingua / Language: Italiano - Pubblicato: 2026-08-12 - Tag: CRA --- Arriva una segnalazione dal form del sito: un cliente dice che il vostro prodotto è stato hackerato. Parte l'obbligo di notifica entro 24 ore, oppure no? La risposta sbagliata costa in due direzioni: notificare tutto intasa i CSIRT e logora il processo, non notificare un caso reale espone a una scadenza già attiva. La decisione va presa in fretta, e con un criterio, non a sensazione. Questo articolo è quel criterio. Per il quadro della piattaforma e delle scadenze, la guida [La Single Reporting Platform del CRA](/guide/it/single-reporting-platform-guida/); per chi decide e con quale autorità, [Come si sceglie l'Assigned Representative](/blog/it/assigned-representative-srp-scelta/). ## Il trigger è stretto, non generico Il punto di partenza è che non ogni segnalazione esterna fa scattare l'art. 14 del CRA. L'obbligo mira a due casi definiti. La vulnerabilità attivamente sfruttata (art. 3, punto 42): una vulnerabilità per cui esistono prove attendibili che un soggetto malintenzionato l'ha sfruttata in un sistema senza l'autorizzazione del proprietario. Le due parole che pesano sono "attivamente" e "prove attendibili". Una segnalazione di responsible disclosure che descrive un difetto, senza evidenza di sfruttamento reale, resta sul canale di divulgazione coordinata (art. 13; il punto di contatto unico dell'art. 13, par. 17), fuori dall'obbligo dell'art. 14. L'incidente grave (art. 3, punto 44, e criteri di gravità all'art. 14, par. 5): un incidente che incide o può incidere sulla capacità del prodotto di proteggere disponibilità, autenticità, integrità o riservatezza, o che ha portato all'introduzione o esecuzione di codice malevolo nel prodotto o nella rete dell'utilizzatore. ## Il concetto pivot: "di cui viene a conoscenza" Le 24 ore decorrono dal momento in cui il fabbricante viene a conoscenza dello sfruttamento o dell'incidente (art. 14, par. 1 e 3). Conoscenza significa avere prove attendibili e una base per ritenerle credibili, non la semplice ricezione di un messaggio. La guidance della Commissione discute quando il fabbricante si considera "venuto a conoscenza" (FAQ sez. 5.1 e orientamenti sez. 9.1, non vincolanti). Il punto delicato: non si può evitare la conoscenza non presidiando il canale. Se un processo diligente avrebbe visto la segnalazione, la conoscenza si può imputare a quel momento, non a quando è stata letta di fatto. La triage quindi non rinvia l'orologio, serve a stabilire se le prove attendibili esistono, e va fatta senza indebito ritardo. ## Il perno vero: difetto del prodotto o configurazione dell'utente Qui si decide se apri. L'obbligo scatta se lo sfruttamento ha origine in una vulnerabilità del prodotto: firmware bacato, credenziali di default, accesso non autenticato, un servizio esposto per come è progettato. Se invece la compromissione nasce solo dal lato utente, come un dispositivo esposto su internet con una password scelta da lui, resta un incidente sul suo sistema, non necessariamente un incidente grave che ha un impatto sulla sicurezza del prodotto nel senso dell'art. 14. La triage deve puntare tutta a questa distinzione. Ed è aggredibile anche senza telemetria propria, come mostra il caso qui sotto. > Caso concreto. Piccola azienda B2C, sensori di temperatura WiFi, nessun cloud e quindi nessun log lato produttore. Un utente segnala che il sensore è stato compromesso e usato per attaccare la sua rete domestica. Un sensore WiFi arruolato in una botnet è lo scenario da manuale di Mirai o Mozi, plausibile e quasi sempre riconducibile a un difetto del prodotto. Senza telemetria la verifica si sposta su tre fonti raggiungibili in 24 ore: i log del router e i dettagli dell'utente, la threat intelligence pubblica su quel firmware o chipset, l'analisi diretta di un'unità con quel firmware. Se la superficie d'attacco mostra credenziali di default o un servizio non autenticato, il difetto è del prodotto e la notifica va aperta. ## Come si verifica in 24 ore senza telemetria Non avere log lato produttore non toglie l'obbligo, sposta la verifica su tre fonti che restano disponibili. L'evidenza ce l'ha l'utente. Richiamalo subito e chiedi il concreto: log del router, IP e orari, cosa ha osservato, versione firmware, se aveva cambiato la password di default, se il device era raggiungibile da internet. Il grosso della prova attendibile arriva da qui. La threat intelligence pubblica. Esiste una CVE nota per quel firmware? Ci sono botnet documentate su quel modello? Mezz'ora di lavoro che pesa molto sulla plausibilità. Il prodotto stesso. Prendi un'unità con quel firmware e guarda la superficie d'attacco: credenziali di default, porte aperte, servizi non autenticati, meccanismo di update. Se il difetto è strutturale, si vede senza i log dell'utente. ## Quando l'evidenza non arriva in tempo Tre situazioni bloccano la triage prima ancora della decisione. Vanno previste, perché sono la norma, non l'eccezione. Il segnalante non risponde. L'orologio non aspetta lui. La conoscenza rilevante è avere prove attendibili, e le prove attendibili arrivano da tre fonti: se il segnalante tace, ne perdi una, non tutte. La decisione si prende al ventiquattresimo dell'ora sulla migliore evidenza disponibile. Se la tua analisi indipendente trova una superficie d'attacco reale, apri anche senza la sua conferma; se non trova nulla e la segnalazione resta vaga, documenti che le prove attendibili mancano e continui a indagare. Quello che non regge davanti a un'autorità è "aspettavamo l'utente": usa l'irreperibilità altrui per fermare un orologio che è tuo. Il segnalante non è tecnico. In B2C è la regola. Il rimedio sta nell'intake, non nella sua competenza: il form del punto di contatto (art. 13, par. 17) chiede quello che un profano può dare, marca e modello del router, screenshot, cosa ha visto e quando, versione firmware se leggibile dall'app. Un canale che dipende dalla fluenza tecnica del cliente è progettato male. L'AR non ha le competenze per valutare. Il CRA chiede che il fabbricante notifichi, non che chi opera la piattaforma sia anche l'analista. La competenza di valutazione deve esistere ed essere raggiungibile nei tempi, anche su una persona diversa da chi invia. Per la piccola azienda senza security in casa la risposta è pre-costruirla all'esterno: un retainer con un consulente o un PSIRT chiamabile per il triage, deciso prima. L'helpdesk ENISA/CSIRT per le PMI (FAQ Q19) supporta la valutazione, ma non decide al posto tuo e non ferma l'orologio. L'AR interno resta un dispatcher addestrato, che sa far girare la checklist e sa quando scalare. Il filo comune: nelle 24 ore la copertura deve raggiungere sia chi valuta sia chi ha l'autorità di aprire. Il meccanismo che la rende sostenibile, la pre-delega dell'early warning, è in [Come si sceglie l'Assigned Representative](/blog/it/assigned-representative-srp-scelta/). Qualunque sia l'esito, il registro dei tempi (arrivo della segnalazione, allerta, triage, evidenza raccolta, decisione e motivazione) è ciò che dimostra la diligenza quando il segnalante è silenzioso o la chiamata è al limite. ## La decisione, e cosa fare nel dubbio > Nota operativa (mia indicazione, non testo di legge). Segnalazione specifica e credibile, classe di prodotto intrinsecamente esposta, nessun elemento che entro le 24 ore la smentisca: apri l'early warning entro le 24 ore. È deliberatamente minimale e preliminare, con la valutazione iniziale marcata come incerta. Non stai dichiarando una vulnerabilità confermata, stai adempiendo all'obbligo di preallarme su un sospetto credibile. Nelle 72 ore approfondisci, la relazione finale porta la conclusione. Meglio un early warning che poi precisi, che una scadenza persa su un caso reale. Il caso in cui non apri esiste, ed è quando la triage mostra entro le 24 ore che non c'è un difetto del prodotto: device diverso, misconfigurazione pura dell'utente, segnalazione non credibile. Quella conclusione va raggiunta e documentata, non ottenuta per inerzia perché "non avevamo i log". Davanti a un'autorità, la differenza tra le due posture è tutta qui: una decisione tracciata contro un silenzio. Per i casi credibili ma non ancora provati esiste anche la valvola della segnalazione volontaria (art. 15), che permette di segnalare senza far scattare i tempi dell'obbligo. Utile quando vuoi essere proattivo su un sospetto che non regge ancora la soglia delle prove attendibili. ## I due obblighi che scattano insieme Se la verifica conferma il difetto, sulla stessa conoscenza scatta anche l'informativa agli utilizzatori (art. 14, par. 8): informare gli utenti interessati e indicare le misure di attenuazione, come cambiare password, aggiornare, scollegare il dispositivo. La notifica sulla piattaforma è metà del lavoro, l'altra metà è la comunicazione al parco installato. Se il fabbricante non informa tempestivamente, il CSIRT può farlo al suo posto. ## Il presupposto: un canale presidiato Tutto questo regge su una condizione: il punto di contatto unico (art. 13, par. 17) deve allertare attivamente AR e backup, non essere una casella letta al rientro. Durante una chiusura serve una reperibilità minima, anche esternalizzata. Per un B2C che vende a utenti che segnalano a qualsiasi ora, la reperibilità sul canale è parte dell'adempimento, perché è ciò che tiene la conoscenza, e quindi l'orologio delle 24 ore, sotto controllo dell'azienda invece che di un calendario di ferie. --- *Riferimenti: Regolamento (UE) 2024/2847 (CRA), art. 3 (punti 42 e 44), art. 13 (in particolare par. 17), art. 14 (par. 1, 3, 5, 8), art. 15 e Allegato I, parte II, punto 5. Guidance non vincolante: FAQ della Commissione sull'attuazione del CRA (sez. 5.1) e relativi orientamenti (sez. 9.1), pagine ENISA sulla SRP e FAQ (aggiornate al 3 agosto 2026). Le note segnalate come operative e il caso concreto sono mie interpretazioni, non testo normativo. Numeri di articolo verificati sul testo ufficiale del CRA in lingua italiana.*