L’11 settembre 2026 inizia per i produttori di prodotti con elementi digitali uno dei primi obblighi operativi del Cyber Resilience Act (CRA): le vulnerabilità sfruttate attivamente e gli incidenti di sicurezza gravi devono essere segnalati tramite la nuova piattaforma centrale di segnalazione. Non si tratta soltanto di una nuova scadenza di conformità. Nel giro di poche ore devono essere riuniti l’identità del prodotto, i mercati interessati, la valutazione tecnica e le misure adottate.
Un passaporto digitale del prodotto o una pagina di prodotto collegata tramite QR può aiutare ad associare un dispositivo in modo univoco e a informare successivamente gli utenti di un aggiornamento. Tuttavia, non è né il canale di segnalazione previsto dalla legge né il luogo adatto per conservare dettagli riservati sugli exploit. I produttori dovrebbero quindi separare già da ora tre percorsi di dati: la segnalazione alle autorità, le informazioni pubbliche sul prodotto e la cronologia interna degli aggiornamenti.
La nuova occasione: linee guida del 27 e del 31 luglio
La Commissione europea ha pubblicato il 27 luglio 2026 la sua prima linea guida completa sul CRA. Il documento tratta, tra l’altro, gli obblighi di segnalazione, la valutazione dei rischi, i periodi di supporto e le modifiche sostanziali. La linea guida non è vincolante, ma chiarisce con 67 esempi come le aziende possano applicare concretamente il regolamento.
Quattro giorni dopo, il 31 luglio, ENISA ha aggiornato le sue informazioni sulla Single Reporting Platform. Sono ora disponibili il flusso previsto, i campi da compilare e le indicazioni per la registrazione. La piattaforma dovrebbe essere operativa entro l’11 settembre 2026; secondo la Commissione, i test funzionali e di sicurezza sono già in corso.
La scansione temporale è importante: gli obblighi principali del CRA si applicano in linea generale dall’11 dicembre 2027. L’articolo 14, tuttavia, con i relativi obblighi di segnalazione, si applica già dall’11 settembre 2026. Lo confermano sia l’articolo 71 del regolamento (UE) 2024/2847 sia la panoramica della Commissione sulla procedura di segnalazione CRA, aggiornata il 31 luglio.
Tre spazi di dati invece di un passaporto del prodotto sovraccarico
La segnalazione CRA e una pagina pubblica del prodotto perseguono obiettivi diversi. Chi rappresenta entrambi in un unico set di dati rischia di fornire al team che gestisce l’incidente informazioni insufficienti oppure di esporre sul web pubblico troppi dettagli sensibili.
1. Segnalazione riservata a SRP, CSIRT ed ENISA
La Single Reporting Platform è il canale di ingresso previsto dalla legge. Devono essere segnalati due tipi di eventi: una vulnerabilità sfruttata attivamente, per la quale esistono indicazioni affidabili di uno sfruttamento non autorizzato, e un incidente di sicurezza grave che compromette la disponibilità, l’autenticità, l’integrità o la riservatezza di dati o funzioni.
La segnalazione non contiene soltanto la denominazione del prodotto. ENISA indica tra i campi, tra gli altri, gli Stati membri interessati, una prima valutazione, le contromisure già adottate, le possibili misure per gli utenti e la sensibilità delle informazioni. Le fasi successive possono includere il livello di gravità, gli impatti, le informazioni sull’aggressore e i dettagli tecnici relativi all’aggiornamento di sicurezza. Tali informazioni non appartengono automaticamente a una pagina DPP liberamente accessibile.
2. Informazioni pubbliche sul prodotto e sulla sicurezza
Il percorso pubblico dei dati risponde ad altre domande: quale prodotto e quale versione possiedo? È ancora supportato? È disponibile un aggiornamento di sicurezza? Che cosa devo fare concretamente come utente? A questo scopo può essere utile una pagina stabile del prodotto raggiungibile tramite un codice QR o un altro supporto dati.
La pagina pubblica dovrebbe mostrare soltanto informazioni approvate: intervalli di modelli e versioni interessati, versione sicura disponibile, istruzioni per l’installazione, contatto del supporto e data di pubblicazione. I dettagli dell’exploit, le regole interne di rilevamento, i percorsi di attacco non corretti o i dati personali relativi all’incidente restano nella procedura protetta. La decisione su un avviso pubblico non spetta al codice QR: ai sensi dell’articolo 17 del CRA, il CSIRT coordinatore può informare il pubblico o chiedere al produttore di farlo quando ciò è necessario per la prevenzione o il contenimento.
3. Cronologia interna degli aggiornamenti e delle evidenze
Il terzo percorso è il fascicolo operativo tracciabile. Collega l’ID del prodotto, la versione hardware e software, la distinta software, il momento in cui si è venuti a conoscenza del problema, le decisioni di triage, i livelli di segnalazione, l’approvazione della patch e la comunicazione pubblica. Questa cronologia deve versionare le modifiche, invece di sovrascrivere silenziosamente le valutazioni precedenti.
Per un’attività DPP questa differenza è fondamentale: la vista pubblica mostra lo stato attuale approvato; la cronologia interna documenta come ci si è arrivati. Chi gestisce già i dati dei prodotti sulla base degli eventi può usare lo stesso principio applicato agli DPP-aggiornamenti e ai webhook: un evento attiva processi successivi, ma ogni destinatario riceve soltanto i campi previsti per il proprio ruolo.
Il tempo previsto dal CRA inizia quando si viene a conoscenza del problema
L’articolo 14 prevede scadenze articolate. Per una vulnerabilità sfruttata attivamente è necessario, senza indebito ritardo e al più tardi entro 24 ore dalla conoscenza, un preallarme. Entro 72 ore segue la segnalazione più dettagliata della vulnerabilità. La relazione finale deve essere disponibile al più tardi 14 giorni dopo che è stata resa disponibile una misura correttiva o di mitigazione.
Per un incidente di sicurezza grave valgono anch’essi 24 ore per il preallarme e 72 ore per la segnalazione dell’incidente. La relazione finale segue entro un mese dalla segnalazione a 72 ore. Le scadenze quindi non decorrono dalla pubblicazione di un CVE né dalla successiva versione ordinaria, ma dal momento in cui si considera che il produttore sia stato informato.
Nella pratica è consigliabile un flusso chiaro:
- Registrare con indicazione temporale l’ingresso della segnalazione dal supporto, dal monitoraggio, dalla ricerca o dalla catena di fornitura.
- Ricondurre il prodotto e la versione a un ID interno stabile del prodotto.
- Valutare lo sfruttamento o la gravità dell’incidente tramite il team competente.
- Generare il set di dati per le 24 ore a partire dalle informazioni minime confermate e inviarlo tramite la SRP.
- Integrare le evidenze tecniche fino alla fase delle 72 ore, senza perdere lo stato originario.
- Approvare separatamente la patch, la misura per gli utenti e le informazioni pubbliche.
- Collegare tra loro la relazione finale e la cronologia interna.
Questa sequenza dovrebbe essere simulata prima di settembre. ENISA osserva che le organizzazioni possono automatizzare i propri processi interni e database, ma che al momento del lancio la piattaforma non offrirà un’API. Perciò un processo di esportazione e doppia verifica è più realistico di un’integrazione diretta non verificata.
Un ID comune del prodotto, ma diritti di accesso separati
Separare non significa gestire tre copie non collegate. L’approccio migliore è un riferimento comune e immutabile al prodotto, con viste dipendenti dal ruolo.
Dovrebbero essere disponibili almeno queste associazioni:
- ID interno del prodotto e riferimento al modello, al lotto o al numero di serie;
- versione hardware, firmware e software;
- Stati membri nei quali è stata resa disponibile la configurazione interessata;
- stato della valutazione di sicurezza e momento in cui si è venuti a conoscenza del problema;
- riferimenti alla segnalazione delle 24 e delle 72 ore e alla relazione finale;
- misura per gli utenti approvata e versione sicura di destinazione;
- stato di pubblicazione della pagina pubblica del prodotto.
L’autorizzazione dovrebbe essere concepita a livello di singolo campo. Il team che gestisce gli incidenti e i responsabili del CRA hanno bisogno del fascicolo completo. Il supporto e le vendite necessitano di istruzioni operative approvate. Gli utenti vedono soltanto la segnalazione pubblica. Idealmente, un codice QR trasporta soltanto un indirizzo stabile del prodotto; la piattaforma sottostante decide, in base allo stato e al ruolo, quali informazioni fornire.
Che cosa dovrebbero testare i produttori entro settembre
Un caso di test valido non richiede una vulnerabilità reale. Scegliete un prodotto connesso, una versione firmware interessata e tre Stati membri. Simulate la presa di conoscenza in un giorno lavorativo e verificate:
- Il team è in grado di confermare entro 24 ore la copertura del prodotto e le informazioni minime?
- È chiaro chi debba accedere alla SRP come rappresentante tramite EU Login?
- È possibile aggiungere le informazioni delle 72 ore senza rendere pubblici dettagli riservati?
- L’approvazione della patch porta a un’informazione per gli utenti verificata in tutte le lingue necessarie?
- L’URL pubblico rimane stabile quando cambiano versione e misure?
- È possibile ricostruire chi ha approvato quale stato e quando?
Per quest’ultimo punto è utile una gestione dei dati coerente e versionata. Il contributo di qr3 sull’aggiornamento continuo di DPP illustra l’idea di base: l’identità resta stabile, mentre i dati specialistici vengono aggiornati in modo controllato. Nel processo CRA si aggiunge un livello più rigoroso di riservatezza e approvazione.
Conclusione: il passaporto del prodotto è un distributore, non un punto di segnalazione
Le nuove linee guida rendono operativo l’appuntamento di settembre. I produttori non devono integrare nel proprio passaporto digitale del prodotto un database riservato delle vulnerabilità. Hanno invece bisogno di un passaggio affidabile tra tre aree chiaramente separate: segnalazione alle autorità, evidenze interne e informazioni approvate per gli utenti.
Un ID comune del prodotto tiene unite queste aree. Ruoli, approvazioni e versionamento impediscono che dettagli riservati finiscano all’esterno o che gli utenti vengano informati troppo tardi di una misura disponibile. Il codice QR resta utile, ma volutamente poco appariscente: conduce in modo permanente al contesto corretto del prodotto. La vera conformità CRA nasce dai processi sottostanti.
