Il Regolamento sulla ciberresilienza dell'UE trasforma la pianificazione del periodo di supporto in una decisione di lancio del prodotto, non in un tema successivo. Il fabbricante deve decidere per quanto tempo gli utenti possono aspettarsi la gestione delle vulnerabilità, pubblicare la data di fine supporto al momento dell'acquisto e mantenere disponibili gli aggiornamenti di sicurezza per il periodo richiesto. Questa guida copre la meccanica della durata: quando parte il conteggio, come funziona l'eccezione per uso atteso più breve, come si sovrappongono i portafogli multi-versione e cosa devono coprire i contratti con fornitori a monte. Per la cadenza di distribuzione, veda aggiornamenti di sicurezza CRA; per la data di fine supporto destinata agli utenti, veda comunicazione di fine supporto.
Sintesi
- Cinque anni sono la soglia minima. Il CRA richiede la gestione delle vulnerabilità per almeno cinque anni, salvo che il prodotto sia atteso in uso per un periodo più breve.
- L'eccezione per uso atteso più breve è stretta. Deve essere valutata prima della messa sul mercato, documentata nella documentazione tecnica e comunicata agli utenti prima dell'acquisto.
- Il conteggio parte dalla messa sul mercato, non dall'acquisto del cliente. Le scorte ferme in magazzino prima della vendita hanno già consumato parte della finestra di supporto.
- I portafogli multi-versione possono sovrapporre finestre. Una via software limitata consente la correzione solo dell'ultima versione, ma solo se gli utenti delle versioni precedenti possono passare gratuitamente e senza costi di ambiente.
- Il rischio del fornitore a monte resta rischio del fabbricante. La fine supporto di un componente non è una difesa; i contratti di fornitura devono coprire tutto il periodo di supporto.
I quattro numeri che definiscono il periodo di supporto CRA: la durata minima, l'obbligo di gratuità, la soglia di conservazione documentale e il tetto sanzionatorio.
Cosa richiede il CRA per il periodo di supporto
Il periodo di supporto è la finestra in cui il fabbricante deve mantenere attivo il processo di gestione delle vulnerabilità del prodotto. Copre il prodotto e i suoi componenti, decorre dalla messa sul mercato UE e deve essere abbastanza lungo da corrispondere all'uso che gli utenti possono ragionevolmente aspettarsi. Il fabbricante dovrebbe fissarlo sulla base di prove pratiche: tipo di prodotto, finalità prevista, prodotti comparabili, norme dell'Unione applicabili sulla durata, disponibilità dell'ambiente operativo, supporto dei componenti terzi essenziali e orientamenti ADCO o Commissione. Il risultato pratico è semplice: il supporto va definito prima del lancio e mantenuto per tutta la finestra dichiarata.
L'obbligo ha tre componenti:
| Componente | Regola operativa | Prove da conservare |
|---|---|---|
| DurataQuanto dura il supporto | Usi almeno cinque anni, salvo che il periodo atteso di uso del prodotto sia più breve. | Motivazione del periodo di supporto nella documentazione tecnica e data chiara di fine supporto all'acquisto. |
| GestioneCosa deve restare attivo | Mantenga attivo il ciclo delle vulnerabilità: documentare i rilievi, correggere senza ritardo, divulgare i problemi risolti, gestire la CVD e distribuire aggiornamenti in modo sicuro. | Registri delle vulnerabilità, tempi di correzione, policy CVD, prove di distribuzione degli aggiornamenti e avvisi agli utenti. |
| Aggiornamenti di sicurezzaCosto e disponibilità | Diffonda gli aggiornamenti di sicurezza disponibili senza ritardo e gratuitamente, salvo la stretta eccezione per prodotti aziendali su misura. | Registri di rilascio che mostrino quando le correzioni erano disponibili e che le correzioni di sicurezza di base non erano dietro livelli a pagamento. |
Quando inizia il conteggio dei cinque anni
Il conteggio del supporto parte quando il prodotto entra nel mercato UE, non quando l'utente finale lo acquista. Nel diritto UE dei prodotti è la prima messa a disposizione del prodotto sul mercato dell'Unione per distribuzione o uso. Per pianificare il supporto, la data di messa sul mercato è la data che conta.
Il conteggio inizia: alla data in cui il prodotto è messo per la prima volta a disposizione di un distributore, rivenditore, importatore o utente per distribuzione o uso sul mercato 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 fabbricante deve 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'impegno di base di gestione delle vulnerabilità per v1.0 termina. Ulteriori avvisi agli utenti o rapporti con le autorità dipendono dai fatti.
Buona prassi: tracciare le date di messa sul mercato per versione di prodotto, non per singola unità. Un unico record della data di messa sul mercato per SKU è di solito la base probatoria pratica per calcolare le date di fine supporto.
L'eccezione per uso atteso più breve
La soglia di cinque anni può essere abbreviata solo quando il prodotto è realmente atteso in uso per meno di cinque anni. L'eccezione è più stretta di quanto sembri e deriva dall'articolo sul periodo di supporto:
- Il "periodo atteso di uso del prodotto" si valuta dal punto di vista delle ragionevoli aspettative degli utenti, in base alla natura del prodotto, all'uso tipico di prodotti simili e a ciò che comunica il fabbricante.
- Il periodo più breve deve essere documentato nella documentazione tecnica e comunicato agli utenti all'acquisto, includendo almeno mese e anno della data di fine supporto.
- Il fabbricante non può invocare l'eccezione dopo la scoperta di una vulnerabilità. La valutazione deve essere fatta prima della messa sul mercato e registrata nel fascicolo tecnico.
- Per la maggior parte dei software, dispositivi IoT e hardware connesso, cinque anni sono il minimo pratico. L'eccezione riguarda prodotti con vita utile oggettivamente breve, come hardware monouso o a cicli limitati, non prodotti per cui il fabbricante preferisce semplicemente un obbligo più breve.
Supporto multi-versione
La maggior parte dei fabbricanti ha più versioni del prodotto sul mercato contemporaneamente. Prodotti hardware e versioni software mantenute in modo indipendente possono creare finestre di supporto sovrapposte. I prodotti software hanno anche un percorso limitato solo-ultima-versione per versioni successive sostanzialmente modificate, ma solo se gli utenti delle versioni precedenti possono passare all'ultima versione gratuitamente e senza costi aggiuntivi di hardware o ambiente software.
Periodi di supporto sfalsati creano obblighi sovrapposti:
| Versione | Messa 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 fabbricante può essere tenuto a fornire aggiornamenti di sicurezza per tutte e tre le versioni simultaneamente, salvo che si applichi un percorso software idoneo solo-ultima-versione. Ogni versione ha la propria esposizione CVE, il proprio albero delle dipendenze e potenzialmente la propria base di clienti. Il backport delle patch tra versioni principali è tecnicamente complesso e costoso.
Strategie per ridurre il carico del supporto multi-versione:
- Codebase condivisa. Ove possibile, mantenga 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, strumenti di migrazione gratuiti e crediti di supporto accelerano il consolidamento delle versioni.
- Calendario EOL esplicito per versione. Pubblichi la data di fine supporto per ogni versione alla messa sul mercato. I clienti che sanno che v1.0 termina a gennaio 2033 hanno tempo per pianificare la migrazione senza pressione di emergenza.
- Via di sola ultima versione per software idoneo. Se usa questa via, documenti come gli utenti delle versioni precedenti ricevono l'ultima versione gratuitamente e senza costi di adeguamento dell'ambiente.
Obblighi contrattuali con fornitori e a monte
Il fabbricante mantiene l'obbligo del periodo di supporto anche quando una vulnerabilità proviene da un componente a monte. Se il prodotto non può essere corretto perché un fornitore di componenti ha interrotto il supporto, il fabbricante deve comunque avere una via di rimedio. La lacuna contrattuale a monte non è una difesa ai sensi della regola sul periodo di supporto.
Cosa significa in pratica:
- Se un prodotto include un sistema operativo, middleware o firmware di chipset di terze parti, il fabbricante deve garantire un accordo di fornitura che copra l'intero periodo di supporto. Un fornitore a monte che fornisce patch di sicurezza per tre anni obbliga il fabbricante a mantenere autonomamente le patch dopo il terzo anno, oppure a cessare di immettere il prodotto sul mercato UE dopo l'EOL a monte.
- Il tracciamento delle dipendenze tramite SBOM (veda la guida al cluster SBOM) è il meccanismo operativo: il fabbricante non può monitorare le vulnerabilità a monte senza sapere cosa c'è nel prodotto.
- I contratti di fornitura dovrebbero specificare: durata dell'impegno di patch a monte, obblighi di notifica per vulnerabilità di nuova scoperta, accesso al codice sorgente o agli strumenti di patch qualora il fornitore a monte dismetta il componente, e condizioni di indennizzo per vulnerabilità originate nei componenti a monte.
Importatori e distributori che immettono un prodotto sul mercato con il proprio nome o marchio, o che modificano sostanzialmente un prodotto già immesso sul mercato, sono trattati come fabbricanti e assumono gli obblighi del fabbricante, incluso il rischio contrattuale a monte. Veda la guida agli obblighi dell'importatore per il flusso di cambio ruolo.
Pianificazione della fine del ciclo di vita e transizioni responsabili del prodotto
Quando termina il periodo di supporto, termina l'impegno di base di gestione delle vulnerabilità per quella versione del prodotto, ma alcune responsabilità restano.
Cosa resta alla fine del supporto:
- La data di fine supporto comunicata all'acquisto resta l'impegno visibile per l'utente.
- La documentazione tecnica e la dichiarazione UE di conformità devono essere conservate per almeno 10 anni dalla messa sul mercato o per il periodo di supporto, se più lungo, e devono essere messe a disposizione agli utenti e alle autorità di vigilanza del mercato indipendentemente dal canale di distribuzione.
- Le informazioni e istruzioni per gli utenti devono restare disponibili sulla stessa base di 10 anni o periodo di supporto; quando sono fornite online, devono restare accessibili online per tale periodo.
- Ove tecnicamente fattibile, il fabbricante dovrebbe mostrare agli utenti una notifica nel momento in cui il prodotto raggiunge la fine del periodo di supporto.
- Le vulnerabilità dei prodotti non supportati richiedono ancora una gestione attenta. Il CRA non contiene una frase di esonero automatico per ogni questione di segnalazione degli incidenti alla fine del supporto, e le autorità di vigilanza del mercato possono ancora intervenire quando un prodotto presenta un rischio significativo di cibersicurezza. L'esposizione sanzionatoria è trattata nella guida a sanzioni ed enforcement.
Obblighi di comunicazione alla fine del supporto:
Il CRA non fissa un termine legale di preavviso per la fine del supporto. La comunicazione della data di fine supporto all'acquisto significa che gli utenti che hanno acquistato il prodotto dopo l'avvenuta comunicazione erano già informati. Per prodotti in cui la comunicazione iniziale mancava o era poco chiara, il preavviso è un controllo operativo del rischio, non una scadenza numerata del CRA.
Dopo l'EOL: il fabbricante dovrebbe mantenere un contatto di sicurezza per la divulgazione responsabile delle vulnerabilità, tenere accessibile la documentazione del prodotto e cooperare con eventuali indagini delle autorità di vigilanza del mercato.
Errori comuni
-
Non tracciare le date di messa sul mercato. Senza una data di messa sul mercato per versione, il fabbricante non può calcolare quando iniziano o terminano gli obblighi di supporto, produrre la data di fine supporto per gli utenti o dimostrare la conformità alle autorità di vigilanza del mercato.
-
Non pianificare l'EOL a monte. Se un fornitore di chipset, sistema operativo o middleware termina il supporto prima della scadenza del periodo di supporto del fabbricante, il fabbricante deve avere un piano. Scoprire tardi l'EOL a monte senza un accordo di fornitura è una modalità di fallimento comune e costosa.
-
Legare le patch di sicurezza alle release funzionali. Raggruppare correzioni di sicurezza in aggiornamenti di versione maggiore obbliga i clienti ad accettare nuove funzionalità e nuova superficie di rischio per ricevere una correzione. Le correzioni di sicurezza dovrebbero essere fornite come correzioni di sicurezza, senza imporre livelli a pagamento o grandi aggiornamenti funzionali.
Domande frequenti
Quando inizia il periodo di supporto di cinque anni?
Inizia quando il prodotto è immesso sul mercato UE, non quando un cliente lo acquista o lo attiva. La messa sul mercato è la prima messa a disposizione del prodotto sul mercato dell'Unione, quindi il tempo in magazzino o presso un distributore può consumare parte della finestra di supporto. Un prodotto immesso sul mercato a gennaio 2028 normalmente richiede gestione delle vulnerabilità almeno fino a gennaio 2033, anche se un singolo cliente lo acquista più tardi.
Il periodo di supporto può essere inferiore a cinque anni?
Sì, ma solo quando si prevede che il prodotto sia in uso per meno di cinque anni. Il periodo di supporto deve riflettere ragionevoli aspettative degli utenti, natura e finalità prevista del prodotto, diritto dell'Unione applicabile, prodotti comparabili, disponibilità dell'ambiente operativo, supporto dei componenti terzi essenziali e orientamenti ADCO o Commissione. Le informazioni usate per determinarlo appartengono alla documentazione tecnica, e la data finale deve essere chiara all'acquisto.
La segnalazione si applica dopo la fine del periodo di supporto?
Non tratti la scadenza del supporto come un'esenzione generale per la segnalazione degli incidenti. La regola sul periodo di supporto definisce la finestra di gestione delle vulnerabilità, mentre il dovere di segnalazione degli incidenti richiede separatamente la notifica delle vulnerabilità attivamente sfruttate e degli incidenti gravi di cui il fabbricante viene a conoscenza. Per un prodotto non supportato, documenti la valutazione giuridica prima di decidere di non segnalare e consideri comunque un avviso agli utenti quando il rischio è materiale.
Che cosa succede se un fornitore di componenti a monte termina il supporto in anticipo?
Il fabbricante conserva l'obbligo del periodo di supporto. La regola sul periodo di supporto copre le vulnerabilità nel prodotto e nei suoi componenti, e la regola di due diligence sui componenti richiede attenzione nell'integrazione di componenti terzi. Se un fornitore di chipset, sistema operativo, middleware o libreria esce in anticipo, il fabbricante ha bisogno di un'altra via: mantenere le patch, sostituire il componente o smettere di immettere la configurazione interessata sul mercato UE.