L'Articolo 13(8) del Regolamento sulla ciberresilienza dell'UE (Regolamento (UE) 2024/2847) impone ai fabbricanti di fornire aggiornamenti di sicurezza a titolo gratuito e senza indugio ingiustificato per tutta la durata del periodo di supporto. Questa pagina tratta i meccanismi di consegna degli aggiornamenti nelle architetture embedded, standalone, SaaS e ibride. Per i meccanismi di durata consulti il Periodo di Supporto CRA: Basi; per la divulgazione pre-acquisto consulti la Divulgazione della Fine del Supporto.
Sintesi
- Gli aggiornamenti di sicurezza non sono aggiornamenti funzionali. Una modifica che risolve una vulnerabilità è disciplinata dalle regole di costo e cadenza dell'Articolo 13(8); una modifica che aggiunge nuove funzionalità non lo è.
- Gratuiti ai sensi dell'Articolo 13(8). I fabbricanti non possono includere le correzioni di sicurezza in abbonamenti a pagamento, livelli premium o aggiornamenti di versione principale.
- Automatici ove possibile ai sensi dell'Allegato I Parte II. La lettera 7) richiede meccanismi di distribuzione sicuri con consegna automatica ove applicabile; la lettera 8) richiede la diffusione senza ritardo.
- "Senza indugio ingiustificato" segue la gravità. Le aspettative standard del settore prevedono giorni per le vulnerabilità critiche attivamente sfruttate, 30 giorni per la gravità alta, 90 giorni per la gravità media e il prossimo ciclo regolare per quella bassa.
- L'architettura cambia il modello di consegna. Firmware embedded, software standalone, SaaS e prodotti ibridi hanno ciascuno meccanismi di aggiornamento distinti che il fascicolo tecnico deve documentare.
- L'Articolo 14 interagisce con il ciclo di vita degli aggiornamenti. Quando viene rilevata una vulnerabilità attivamente sfruttata, l'allerta precoce di 24 ore all'ENISA decorre parallelamente al processo di patch; il meccanismo di aggiornamento deve essere integrato nel flusso di segnalazione.
I quattro punti di riferimento della conformità agli aggiornamenti di sicurezza CRA: regola sui costi, preferenza di distribuzione, aspettativa di cadenza e tetto delle sanzioni.
Addebitare costi per gli aggiornamenti di sicurezza è uno dei percorsi più diretti verso una constatazione di non conformità. Se una correzione che risolve una vulnerabilità è disponibile solo per i clienti con un livello di supporto a pagamento, dietro un abbonamento premium o all'interno di un aggiornamento di versione principale venduto come nuova release, tale configurazione non soddisfa l'Articolo 13(8). Le patch di sicurezza di base devono essere disponibili per tutti gli utenti del prodotto immesso sul mercato, senza costi aggiuntivi, per tutta la durata del periodo di supporto. Le release di funzionalità, i servizi professionali e le funzionalità opzionali possono comunque essere a pagamento. Il discrimine è se la modifica risolve una vulnerabilità.
Cosa Costituisce un Aggiornamento di Sicurezza
L'Articolo 13(2) del Regolamento sulla ciberresilienza impone ai fabbricanti di progettare e produrre prodotti che siano "sicuri per impostazione predefinita" e che garantiscano "la riservatezza, l'integrità e la disponibilità dei dati". L'Articolo 13(8) richiede poi che le vulnerabilità scoperte dopo l'immissione sul mercato vengano gestite per la durata del periodo di supporto.
Un aggiornamento di sicurezza ai sensi del Regolamento sulla ciberresilienza è una modifica che risolve una vulnerabilità, ovvero una debolezza del prodotto che potrebbe essere sfruttata per compromettere riservatezza, integrità o disponibilità. La distinzione rispetto a un aggiornamento funzionale è rilevante per due motivi: gli aggiornamenti di sicurezza devono essere gratuiti e devono essere consegnati senza indugio ingiustificato, mentre gli aggiornamenti funzionali non sono soggetti a nessuno dei due obblighi.
| Tipo di aggiornamento | Obbligo dell'Articolo 13(8) | Può essere addebitato? |
|---|---|---|
| Patch che corregge un CVE noto | Sì (aggiornamento di sicurezza) | No |
| Modifica di hardening che riduce la superficie di attacco | Sì (aggiornamento di sicurezza) | No |
| Nuova funzionalità senza rilevanza per la sicurezza | No | Sì |
| Versione principale con nuove funzionalità | No (salvo che includa correzioni di sicurezza) | Sì |
| Aggiornamento di dipendenza per eliminare una vulnerabilità nota | Sì (aggiornamento di sicurezza) | No |
| Modifica di configurazione per chiudere una lacuna di sicurezza | Sì (aggiornamento di sicurezza) | No |
"Senza indugio ingiustificato" non è definito numericamente nel regolamento, ma le aspettative generali delle autorità di sorveglianza del mercato e le indicazioni dell'ENISA si allineano alla prassi del settore. Il diagramma seguente mostra la finestra di patch per livello di gravità, misurata dal momento in cui la vulnerabilità viene divulgata (T0):
| Gravità | Aspettativa standard del settore |
|---|---|
| Critica (attivamente sfruttata) | Giorni, non settimane |
| Alta (facilmente sfruttabile da remoto) | Entro 30 giorni |
| Media | Entro 90 giorni |
| Bassa | Inclusa nel prossimo ciclo di aggiornamento regolare |
Non si tratta di tempistiche imposte dal Regolamento sulla ciberresilienza, ma rappresentano il parametro rispetto al quale "senza indugio ingiustificato" sarà valutato nei procedimenti di enforcement.
Come consegnare gli aggiornamenti di sicurezza CRA
Aggiornamenti Automatici
Ove tecnicamente fattibile e opportuno, l'Articolo 13(8) e l'Allegato I Parte II favoriscono gli aggiornamenti di sicurezza automatici. Il prodotto deve essere in grado di ricevere e applicare aggiornamenti senza richiedere all'utente di intervenire manualmente.
Requisiti per un meccanismo di aggiornamento automatico conforme:
- Canale di download sicuro (TLS, pacchetti firmati)
- Verifica dell'integrità prima dell'installazione
- Capacità di rollback in caso di aggiornamento fallito
- Gestione appropriata dei problemi di connettività
- Visibilità per l'utente sullo stato degli aggiornamenti
L'utente deve conservare la possibilità di rifiutare gli aggiornamenti automatici, con un avvertimento chiaro sulle conseguenze per la sicurezza di tale scelta. Per gli aggiornamenti di sicurezza critici, il fabbricante può progettare il sistema in modo che l'aggiornamento venga applicato senza possibilità di rinvio. L'Articolo 13(8) lo consente quando il rischio lo giustifica.
Aggiornamenti Manuali
I prodotti che non possono ricevere aggiornamenti automatici (sistemi industriali air-gapped, dispositivi embedded senza connettività, alcune apparecchiature medicali o critiche per la sicurezza) richiedono un processo di consegna degli aggiornamenti manuale:
- Pacchetti di aggiornamento scaricabili con versioning chiaro
- Firme crittografiche e chiavi pubbliche pubblicate per la verifica
- Documentazione di installazione
- Notifica attraverso tutti i canali disponibili (email, portale web, interfaccia del prodotto, avviso fisico se necessario)
Embedded e SaaS: Modelli di Aggiornamento Diversi
Il meccanismo di consegna degli aggiornamenti differisce sostanzialmente in base all'architettura del prodotto:
| Tipo di prodotto | Modello di aggiornamento | Considerazione chiave per il CRA |
|---|---|---|
| Firmware embedded (IoT, industriale) | Il fabbricante invia il firmware firmato; il cliente lo applica | Deve disporre di capacità OTA o di un processo manuale documentato; le lunghe durate di vita dei dispositivi possono portare il periodo di utilizzo atteso vicino a cinque anni |
| Software standalone (desktop, server) | Il fabbricante rilascia il pacchetto; il cliente lo installa | Si preferisce un agente di aggiornamento automatico; il blocco delle versioni da parte dei clienti enterprise crea un carico di supporto multi-versione |
| SaaS / cloud-hosted | Il fabbricante controlla l'ambiente; gli aggiornamenti sono trasparenti per l'utente | Il conteggio inizia comunque all'immissione sul mercato; il periodo di supporto è rilevante principalmente per le componenti on-premises o ibride; il versioning delle API crea propri impegni di supporto |
| Ibrido (agente on-prem + backend cloud) | Gli aggiornamenti dell'agente sono controllati dal fabbricante; gli aggiornamenti del backend sono trasparenti | Ogni componente ha il proprio conteggio del periodo di supporto; l'agente è il prodotto con elementi digitali e il suo conteggio prevale |
Per la gestione delle vulnerabilità dell'Allegato I Parte II al di là della consegna degli aggiornamenti (politica CVD, divulgazione pubblica, segnalazione di terze parti), consulti la guida alla gestione delle vulnerabilità.
Obblighi di segnalazione delle vulnerabilità durante e dopo il periodo di supporto
L'Articolo 14 impone obblighi di segnalazione con scadenze precise ai fabbricanti per le vulnerabilità attivamente sfruttate e gli incidenti gravi. Tali obblighi si applicano durante il periodo di supporto.
L'interazione chiave:
| Fase | Obbligo di segnalazione dell'Articolo 14 |
|---|---|
| Durante il periodo di supporto | L'Articolo 14 si applica integralmente: allerta precoce di 24 ore, notifica di 72 ore, rapporto finale a 14 giorni per le vulnerabilità attivamente sfruttate; 24 ore / 72 ore / 1 mese per gli incidenti gravi. Tramite la Piattaforma Unica di Segnalazione ENISA. |
| Dopo la fine del periodo di supporto | Nessun obbligo di segnalazione ai sensi dell'Articolo 14 per le vulnerabilità scoperte dopo la fine del ciclo di vita. Se il fabbricante viene a conoscenza di una vulnerabilità critica attivamente sfruttata in un prodotto non supportato che interessa una base installata significativa, non sussiste alcun obbligo di segnalazione obbligatoria. La divulgazione responsabile e la notifica agli utenti sono vivamente raccomandate per ragioni reputazionali e di cooperazione con la sorveglianza del mercato. |
La data di fine del periodo di supporto costituisce pertanto anche il limite dell'Articolo 14. Una volta scaduto il periodo di supporto, il fabbricante non ha alcun obbligo di investigare, correggere o segnalare le vulnerabilità scoperte in quella versione del prodotto. Le autorità di sorveglianza del mercato possono comunque condurre indagini ai sensi dell'Articolo 58 se il prodotto presenta un rischio significativo per la cibersicurezza, ma l'obbligo continuativo di gestione delle vulnerabilità ai sensi dell'Articolo 13(8) è cessato.
Per i meccanismi completi della tempistica dell'Articolo 14, incluso il contenuto di ciascuna segnalazione e le differenze tra i due flussi di segnalazione (vulnerabilità attivamente sfruttate e incidenti gravi), consulti la guida alla segnalazione delle vulnerabilità.
Errori Comuni
Ignorare le dipendenze transitive. La maggior parte delle vulnerabilità nei prodotti connessi origina in librerie e componenti di terze parti, non nel codice di prima parte. L'obbligo dell'Articolo 13(8) riguarda l'intero prodotto, non solo il codice scritto dal fabbricante. Un SBOM è il prerequisito. Consulti la guida al cluster SBOM per il framework di tracciamento delle dipendenze che rende operativo il monitoraggio delle vulnerabilità transitive.
Addebitare costi per gli aggiornamenti di sicurezza. Includere le correzioni di sicurezza in un livello di supporto a pagamento viola l'Articolo 13(8). Le patch di sicurezza di base devono essere gratuite.
Domande Frequenti
Gli aggiornamenti di sicurezza devono essere sempre gratuiti?
Sì. L'Articolo 13(8) impone che gli aggiornamenti di sicurezza siano forniti a titolo gratuito. Un fabbricante non può includere una correzione di sicurezza in un abbonamento a pagamento, in un livello di supporto premium o in un aggiornamento di versione principale e dichiarare la conformità all'Articolo 13(8). Gli aggiornamenti funzionali, le nuove funzionalità e i servizi professionali a pagamento sono separati e possono essere addebitati normalmente. L'obbligo è limitato agli aggiornamenti che risolvono vulnerabilità: modifiche che correggono una debolezza di sicurezza nel prodotto immesso sul mercato.
Con quale rapidità un fabbricante deve rilasciare un aggiornamento di sicurezza ai sensi del CRA?
L'Articolo 13(8) del Regolamento sulla ciberresilienza richiede aggiornamenti di sicurezza "senza indugio ingiustificato" ma non definisce numericamente una scadenza. Le autorità di sorveglianza del mercato e le indicazioni dell'ENISA si allineano alla prassi del settore legata alla gravità: le vulnerabilità critiche attivamente sfruttate devono essere corrette entro giorni, quelle ad alta gravità entro circa 30 giorni, quelle a media gravità entro 90 giorni, e quelle a bassa gravità incluse nel prossimo ciclo di aggiornamento regolare. Non si tratta di tempistiche imposte dal Regolamento sulla ciberresilienza, ma rappresentano il parametro rispetto al quale "senza indugio ingiustificato" sarà valutato nell'enforcement. I fabbricanti dovrebbero tracciare il tempo effettivo per la patch per ogni CVE in modo che le deviazioni da questa base siano visibili e difendibili.
Gli aggiornamenti automatici sono richiesti dal CRA?
Non in tutti i casi. L'Allegato I Parte II, lettera 7), impone ai fabbricanti di fornire meccanismi di distribuzione sicuri con consegna automatica "ove applicabile". Per i prodotti con connettività affidabile e senza motivi operativi per rinviare, gli aggiornamenti automatici sono l'impostazione predefinita attesa. Per i sistemi industriali air-gapped, alcuni dispositivi medici o apparecchiature critiche per la sicurezza in cui l'installazione automatica di patch potrebbe interrompere le operazioni, è accettabile un processo di aggiornamento manuale documentato. Il fascicolo tecnico dell'Allegato VII deve giustificare l'approccio scelto. Gli utenti devono conservare la possibilità di rifiutare gli aggiornamenti automatici con chiari avvertimenti sulle conseguenze per la sicurezza, salvo nei casi in cui il rischio giustifichi una correzione critica non rinviabile.
Un prodotto SaaS ha un periodo di supporto ai sensi del CRA?
Dipende dal fatto che il prodotto SaaS rientri nell'ambito di applicazione del Regolamento sulla ciberresilienza come prodotto con elementi digitali. I servizi SaaS puri che non sono abbinati a un componente hardware o a un software agent scaricabile sono generalmente fuori dall'ambito di applicazione ai sensi dell'Articolo 2(1). Laddove un prodotto SaaS includa un agente on-premises, un client scaricabile o un gateway hardware immesso sul mercato UE, tale componente rientra nell'ambito e il suo conteggio del periodo di supporto ai sensi dell'Articolo 13(8) inizia all'immissione sul mercato. Il backend cloud-hosted, quando è sotto il controllo del fabbricante e continuamente aggiornato, soddisfa tipicamente l'obbligo di patch "senza indugio ingiustificato" attraverso il deployment trasparente, ma il fabbricante deve comunque documentare l'impegno di supporto nelle informazioni dell'Allegato II per il componente in ambito.
Cosa accade agli aggiornamenti di sicurezza dopo la fine del periodo di supporto CRA?
Gli obblighi dell'Articolo 13(8) cessano con il periodo di supporto. Una volta trascorsa la data di fine comunicata, il fabbricante non ha alcun obbligo CRA di investigare, correggere o distribuire aggiornamenti di sicurezza per quella versione del prodotto, e anche gli obblighi di segnalazione dell'Articolo 14 scadono in quanto si applicano solo durante il periodo di supporto. Le autorità di sorveglianza del mercato possono comunque condurre indagini ai sensi dell'Articolo 58 se il prodotto presenta un rischio significativo per la cibersicurezza dopo la fine del ciclo di vita, ma l'obbligo quotidiano di gestione delle vulnerabilità è cessato. I fabbricanti dovrebbero comunicare chiaramente in anticipo agli utenti la fine del supporto; la divulgazione della data di fine dell'Allegato II, lettera k), è lo strumento rivolto agli utenti a tal fine. Continuare a fornire patch a titolo di buona volontà dopo la fine del ciclo di vita è consentito ma non obbligatorio.