L'Articolo 13(8) del Regolamento sulla ciberresilienza dell'UE (Regolamento (UE) 2024/2847) stabilisce un minimo quinquennale per la gestione delle vulnerabilità, ancorato alla data in cui il prodotto è immesso sul mercato UE. Questa guida illustra i meccanismi di durata: quando inizia il conteggio, come funziona la deroga per prodotti a vita ridotta, come si sovrappongono i periodi nei portafogli multi-versione e cosa devono coprire i contratti con i fornitori upstream. Per la cadenza di rilascio degli aggiornamenti consulti gli aggiornamenti di sicurezza CRA; per la data di fine supporto comunicata agli utenti consulti la divulgazione della fine del supporto.
Sintesi
- Cinque anni è il minimo. L'Articolo 13(8) impone la gestione delle vulnerabilità per almeno cinque anni dalla data di immissione del prodotto sul mercato UE.
- La deroga per vita ridotta attesa è limitata. Deve essere valutata prima dell'immissione sul mercato, documentata nella valutazione dei rischi dell'Allegato I Parte I e comunicata agli utenti nelle informazioni dell'Allegato II prima dell'acquisto.
- Il conteggio inizia all'immissione sul mercato, non all'acquisto del cliente. Le scorte giacenti in magazzino prima della vendita hanno già consumato parte del periodo di supporto.
- I portafogli multi-versione accumulano finestre sovrapposte. Ogni versione ha il proprio conteggio ai sensi dell'Articolo 13(8); i produttori possono dover garantire supporto simultaneo su tre o più versioni attive.
- Il rischio del fornitore upstream è il rischio del produttore. La fine del ciclo di vita di un fornitore di componenti non costituisce un'esimente; i contratti di fornitura devono coprire l'intero periodo dell'Articolo 13(8).
I quattro numeri che definiscono il periodo di supporto CRA: la durata minima, l'obbligo di gratuità, il minimo di conservazione della documentazione e il tetto delle sanzioni.
L'Articolo 13(8) ancora il periodo quinquennale alla data in cui il prodotto è immesso sul mercato UE, ovvero la prima volta in cui è reso disponibile a qualsiasi canale distributivo o di vendita. Un'unità che rimane in magazzino per 18 mesi prima che un cliente la acquisti ha già consumato 18 mesi del proprio periodo di supporto. Ciò genera un rischio legato alle scorte: i produttori che non tracciano le date di immissione sul mercato per versione di prodotto non sono in grado di dimostrare la conformità all'Articolo 13(8).
Cosa richiede il CRA per il periodo di supporto
L'Articolo 13(8) del Regolamento sulla ciberresilienza stabilisce che il produttore "garantisce che le vulnerabilità del prodotto con elementi digitali, compresi i suoi componenti, siano gestite efficacemente e conformemente ai requisiti essenziali di cibersicurezza di cui alla parte II dell'allegato I" per un periodo non inferiore a cinque anni dalla data di immissione sul mercato, oppure per il periodo di utilizzo previsto del prodotto se inferiore.
L'obbligo comprende tre componenti:
Almeno cinque anni. La deroga relativa al "periodo di utilizzo atteso del prodotto se inferiore" è limitata e deve essere documentata e comunicata prima dell'acquisto. Il produttore non può invocarla retroattivamente. Se la documentazione indica cinque anni, il produttore è tenuto a rispettare cinque anni.
Le vulnerabilità devono essere gestite "efficacemente" ai sensi dell'Allegato I Parte II: identificarle e documentarle, correggerle senza indugio ingiustificato, divulgarle una volta risolte e gestire una politica di divulgazione coordinata. Non si tratta solo di rilasciare patch, ma dell'intero ciclo di vita delle vulnerabilità.
Gli aggiornamenti di sicurezza devono essere forniti gratuitamente agli utenti. Gli aggiornamenti funzionali e i livelli di supporto a pagamento sono separati. Includere le correzioni in un abbonamento a pagamento non soddisfa l'Articolo 13(8). Consulti gli aggiornamenti di sicurezza per i meccanismi di rilascio.
Quando Inizia il Conteggio dei Cinque Anni
L'Articolo 13(8) ancora il periodo di supporto alla data in cui il prodotto è "immesso sul mercato". In base al diritto europeo dei prodotti, l'immissione sul mercato coincide con la prima messa a disposizione del prodotto a qualsiasi soggetto della catena distributiva, non con la vendita al dettaglio al cliente finale.
Il conteggio inizia: alla data in cui il produttore (o un rappresentante autorizzato) rende per la prima volta il prodotto disponibile a un distributore, rivenditore o importatore ai fini della distribuzione nell'UE.
Il conteggio non inizia: all'acquisto del cliente, all'attivazione del cliente, alla spedizione di una specifica unità, né alla data in cui il cliente installa il prodotto.
Esempio pratico:
- Gennaio 2028. Il prodotto v1.0 è immesso sul mercato UE. Il periodo di supporto quinquennale ha inizio. Il produttore è tenuto a fornire aggiornamenti di sicurezza almeno fino a Gennaio 2033.
- Giugno 2029. Un cliente acquista v1.0 da un rivenditore. Il cliente dispone di circa 3,5 anni di supporto residuo, non cinque anni dall'acquisto.
- Gennaio 2033. Il periodo di supporto termina. L'obbligo del produttore di applicare patch a v1.0 cessa. Il cliente continua a utilizzare il prodotto a proprio rischio.
Buona prassi: tracciare le date di immissione sul mercato per versione di prodotto, non per singola unità. Un unico record della data di immissione per SKU è sufficiente ai fini dell'Articolo 13(8).
La Deroga per Vita Attesa Ridotta
L'Articolo 13(8) consente che il periodo di supporto sia inferiore a cinque anni qualora il periodo di utilizzo atteso del prodotto sia inferiore. Questa deroga è più limitata di quanto appaia:
- Il "periodo di utilizzo atteso del prodotto" è valutato in base alle ragionevoli aspettative degli utenti, tenendo conto della natura del prodotto, del tipico utilizzo di prodotti simili e di quanto comunicato dal produttore.
- Il periodo ridotto deve essere documentato nella valutazione dei rischi del prodotto (Allegato I Parte I) e comunicato agli utenti nelle informazioni sul prodotto dell'Allegato II prima dell'acquisto.
- Il produttore non può invocare la deroga dopo la scoperta di una vulnerabilità. La valutazione deve essere effettuata prima dell'immissione sul mercato e registrata nel fascicolo tecnico.
- Per la maggior parte dei prodotti software, dei dispositivi IoT e dell'hardware connesso, cinque anni rappresentano il minimo pratico. La deroga si applica a prodotti con una vita utile obiettivamente breve, come hardware monouso o a cicli limitati, non a prodotti per i quali il produttore preferisce semplicemente un obbligo più breve.
Supporto Multi-Versione
La maggior parte dei produttori ha simultaneamente più versioni di prodotto sul mercato, ciascuna con il proprio periodo di supporto ai sensi dell'Articolo 13(8).
Periodi di supporto sfalsati creano obblighi sovrapposti:
| Versione | Immissione sul mercato | Fine supporto (5 anni) |
|---|---|---|
| v1.0 | Gen 2028 | Gen 2033 |
| v1.1 | Lug 2028 | Lug 2033 |
| v2.0 | Gen 2029 | Gen 2034 |
Da Gennaio 2029 a Gennaio 2033 (quattro anni), il produttore è tenuto a fornire aggiornamenti di sicurezza per tutte e tre le versioni simultaneamente. Ogni versione ha la propria esposizione CVE, il proprio albero delle dipendenze e potenzialmente la propria base di clienti. Il backporting delle patch tra versioni principali è tecnicamente complesso e costoso.
Strategie per ridurre il carico del supporto multi-versione:
- Codebase condivisa. Ove possibile, mantenere un unico core con patch di sicurezza su cui tutte le versioni si basano. Le correzioni di sicurezza applicate una volta si propagano a tutte le versioni.
- Incentivi aggressivi alla migrazione. Intervalli più brevi tra i clienti sulle versioni precedenti riducono la matrice di supporto attiva. Prezzi di aggiornamento competitivi, strumenti di migrazione gratuiti e crediti di supporto accelerano il consolidamento delle versioni.
- Calendario esplicito di fine vita per versione. Pubblicare la data di fine supporto per ciascuna versione al momento dell'immissione sul mercato. I clienti che sanno che v1.0 termina a Gennaio 2033 hanno tempo per pianificare la migrazione senza pressioni di emergenza.
Obblighi Contrattuali con Fornitori e Upstream
L'Articolo 13(8) pone l'obbligo del periodo di supporto sul produttore. Un produttore che non è in grado di applicare patch al proprio prodotto perché un fornitore di componenti ha cessato il supporto è comunque in violazione dell'Articolo 13(8). Il gap contrattuale upstream non costituisce un'esimente.
Cosa significa in pratica:
- Se un prodotto include un sistema operativo di terze parti, middleware o firmware per chipset, il produttore deve garantire un accordo di fornitura che copra l'intero periodo di supporto. Un fornitore upstream che fornisce patch di sicurezza per tre anni obbliga il produttore a mantenere le patch autonomamente dopo il terzo anno, oppure a cessare l'immissione del prodotto sul mercato UE dopo la fine del ciclo di vita upstream.
- Il tracciamento delle dipendenze tramite SBOM (si consulti la guida al cluster SBOM) è il meccanismo operativo: il produttore non può monitorare le vulnerabilità upstream senza conoscere il contenuto del prodotto.
- I contratti di fornitura dovrebbero specificare: durata dell'impegno di patch upstream, obblighi di notifica per vulnerabilità di nuova scoperta, accesso al codice sorgente o agli strumenti di patch qualora il fornitore upstream dismetta il componente, e condizioni di indennizzo per vulnerabilità originate nei componenti upstream.
Gli importatori che attivano l'escalation del ruolo ai sensi dell'Articolo 22 (mediante rebranding o modifica sostanziale di un prodotto) ereditano l'intero obbligo dell'Articolo 13(8), incluso il rischio contrattuale upstream. Si consulti la guida agli obblighi dell'importatore per il flusso decisionale dell'Articolo 22.
Pianificazione della Fine del Ciclo di Vita e Transizioni Responsabili del Prodotto
Quando il periodo di supporto dell'Articolo 13(8) termina, l'obbligo del produttore di applicare patch alle vulnerabilità cessa, ma rimane un insieme di responsabilità.
Cosa richiedono l'Articolo 13(8) e le disposizioni correlate alla fine del supporto:
- La data di fine del periodo di supporto indicata nell'Allegato II, comunicata prima dell'acquisto, costituisce l'impegno assunto. Gli utenti devono aver ricevuto un preavviso adeguato.
- Il fascicolo tecnico deve essere conservato per almeno 10 anni dalla data di immissione del prodotto sul mercato UE (Articolo 31), indipendentemente da quando termina il supporto.
- La dichiarazione UE di conformità deve rimanere accessibile alle autorità di sorveglianza del mercato.
- Se il produttore viene a conoscenza di una vulnerabilità critica e attivamente sfruttata nel prodotto non più supportato che interessa una base installata significativa, non esiste un obbligo obbligatorio di segnalazione ai sensi dell'Articolo 14 dopo la fine del ciclo di vita. La divulgazione responsabile e la notifica agli utenti sono vivamente raccomandate. Consulti la segnalazione delle vulnerabilità per i meccanismi della tempistica dell'Articolo 14 applicabili durante il periodo di supporto.
Obblighi di comunicazione alla fine del supporto:
Il CRA non specifica un periodo di preavviso legale per la fine del supporto. Il requisito dell'Allegato II di comunicare la data di fine del periodo di supporto prima dell'acquisto implica che gli utenti che hanno acquistato il prodotto dopo che la comunicazione dell'Allegato II era disponibile erano già stati informati. Per i prodotti in cui la comunicazione originale dell'Allegato II era assente o poco chiara, 12 mesi di preavviso rappresentano il minimo standard del settore.
Dopo la fine del ciclo di vita: il produttore non è tenuto ad applicare patch alle nuove vulnerabilità, ma dovrebbe mantenere un contatto di sicurezza per la divulgazione responsabile delle vulnerabilità, tenere accessibile la documentazione del prodotto e collaborare con qualsiasi indagine dell'autorità di sorveglianza del mercato ai sensi dell'Articolo 58.
Per il playbook operativo completo sulla fine del ciclo di vita, che comprende modelli di notifica, framework di migrazione, scenari di prodotti acquisiti e la tempistica di pianificazione a 18 mesi, consulti Pianificazione della Fine del Ciclo di Vita CRA: Transizioni Responsabili del Prodotto.
Errori Comuni
Non tracciare le date di immissione sul mercato. Senza un record della data di immissione per versione, il produttore non può calcolare quando iniziano o terminano gli obblighi dell'Articolo 13(8), non può produrre la data di fine del periodo di supporto dell'Allegato II e non può dimostrare la conformità alle autorità di sorveglianza del mercato.
Non pianificare la fine del ciclo di vita upstream. Se un chipset, un sistema operativo o un fornitore di middleware termina il supporto prima della scadenza del periodo dell'Articolo 13(8) del produttore, il produttore deve disporre di un piano. La scoperta reattiva della fine del ciclo di vita upstream senza un accordo di fornitura in vigore è una modalità di fallimento comune e costosa.
Collegare le patch di sicurezza ai rilasci di funzionalità. Includere le correzioni di sicurezza negli aggiornamenti di versione principale costringe i clienti ad accettare nuove funzionalità e nuove superfici di rischio per ricevere una correzione di sicurezza. L'Articolo 13(8) richiede che le correzioni siano consegnate senza indugio ingiustificato. Un ciclo di rilascio di sei mesi non equivale a "senza indugio ingiustificato" per una vulnerabilità critica.
Domande Frequenti
Quando inizia il periodo di supporto quinquennale?
L'Articolo 13(8) ancora il periodo di supporto alla data di immissione del prodotto sul mercato UE: la prima volta in cui il produttore rende il prodotto disponibile a qualsiasi soggetto della catena distributiva ai fini della distribuzione nell'UE. Non inizia alla data di acquisto del cliente, all'attivazione, né alla data di spedizione di una specifica unità. Un prodotto immesso sul mercato a Gennaio 2028 deve garantire aggiornamenti di sicurezza almeno fino a Gennaio 2033, indipendentemente da quando ogni singolo cliente lo acquista.
Il periodo di supporto può essere inferiore a cinque anni?
Sì, in base alla deroga dell'Articolo 13(8), qualora il periodo di utilizzo atteso del prodotto sia inferiore a cinque anni. Tuttavia, il periodo ridotto deve essere determinato prima dell'immissione sul mercato, documentato nella valutazione dei rischi (Allegato I Parte I) e comunicato agli utenti nelle informazioni sul prodotto dell'Allegato II prima dell'acquisto. Il produttore non può invocare la deroga dopo la scoperta di una vulnerabilità, e la valutazione deve riflettere le ragionevoli aspettative degli utenti, non le preferenze interne sui costi. Per la maggior parte dei dispositivi IoT, dell'hardware connesso e dei prodotti software, cinque anni rappresentano il minimo pratico.
L'obbligo di segnalazione dell'Articolo 14 si applica dopo la fine del periodo di supporto?
No. Gli obblighi di segnalazione dell'Articolo 14 (l'allerta precoce di 24 ore, la notifica di 72 ore e il rapporto finale a 14 giorni per le vulnerabilità attivamente sfruttate) si applicano al produttore durante il periodo di supporto. Una volta scaduto il periodo di supporto dell'Articolo 13(8), il produttore non ha alcun obbligo obbligatorio di segnalazione ai sensi dell'Articolo 14 per le vulnerabilità scoperte in quella versione del prodotto. Le autorità di sorveglianza del mercato conservano il potere di indagare ai sensi dell'Articolo 58 se un prodotto non più supportato presenta un rischio significativo per la cibersicurezza, ma gli obblighi continuativi di gestione delle vulnerabilità e di segnalazione ai sensi degli Articoli 13 e 14 sono cessati.
Cosa succede se un fornitore di componenti upstream termina il supporto prima della scadenza del nostro periodo ai sensi dell'Articolo 13(8)?
L'Articolo 13(8) pone l'obbligo sul produttore, non sui fornitori upstream. Se un chipset, un sistema operativo o un fornitore di middleware termina il supporto per un componente prima della scadenza del periodo quinquennale del produttore, il produttore deve mantenere le patch autonomamente, reperire un componente alternativo supportato o ritirare il prodotto dal mercato UE. La decisione di fine ciclo di vita di un fornitore upstream non costituisce un'esimente nei confronti di un'autorità di sorveglianza del mercato che riscontri la non conformità all'Articolo 13(8). I contratti di fornitura negoziati in fase di progettazione del prodotto dovrebbero specificare il periodo di impegno per le patch upstream, l'accesso al codice sorgente o agli strumenti di patch, e gli obblighi di notifica, verificati rispetto al periodo di supporto previsto del prodotto prima dell'immissione sul mercato.