Cyber Resilience Act: cosa chiede all'hardware

Due date, e la più vicina viene mancata

Il regolamento (UE) 2024/2847, il Cyber Resilience Act (CRA), riguarda i «prodotti con elementi digitali» messi a disposizione sul mercato dell’Unione. In pratica: tutto ciò che contiene firmware. Per l’hardware di consumo e per la salute significa quasi tutto ciò che si spedisce oggi.

Nella maggior parte dei piani compare una data: 11 dicembre 2027, quando scatta la piena conformità e un prodotto non conforme non può più essere immesso sul mercato. Le roadmap sono costruite su quella.

Prima ne arriva un’altra: 11 settembre 2026, inizio degli obblighi di notifica dell’articolo 14. Viene mancata perché non è una scadenza di progettazione, quindi non compare in nessun piano hardware.

Dovrebbe comparirci. Ecco perché.

L’orologio di notifica guarda all’indietro

Dall’11 settembre 2026, un fabbricante che venga a conoscenza di una vulnerabilità attivamente sfruttata nel proprio prodotto, o di un incidente grave che ne compromette la sicurezza, entra in un orologio a scaglioni:

Fase	Termine dalla conoscenza
Allerta precoce	24 ore
Notifica tecnica	72 ore
Relazione finale	14 giorni (vulnerabilità sfruttata) / 1 mese (incidente grave)

I destinatari sono ENISA e il CSIRT nazionale competente.

Il passaggio da rileggere: l’obbligo di notifica si applica ai prodotti già messi a disposizione sul mercato UE, comprese le unità immesse prima della scadenza. I requisiti di progettazione dell’allegato I valgono per i prodotti immessi dal dicembre 2027, e per quelli precedenti solo in caso di modifica sostanziale. L’obbligo di notifica non ha questo confine.

La domanda concreta per un brand a settembre 2026 non è più «il mio prossimo prodotto è conforme». Diventa:

Un dispositivo spedito nel 2023 ha una vulnerabilità sotto sfruttamento attivo. Lo sapremo entro 24 ore, e conosciamo il suo contenuto abbastanza da descrivere il problema?

Per la maggior parte dei brand hardware la risposta onesta alla seconda metà è no. È un problema di documentazione di produzione prima di essere un problema di sicurezza.

→ Un’altra scadenza europea che diventa una decisione di involucro: Regolamento europeo batterie 2027

Il periodo di supporto è una decisione di distinta base

L’allegato I richiede un periodo di supporto dichiarato di almeno cinque anni, o la vita attesa del prodotto se inferiore, con una data di fine nota all’acquirente al momento dell’acquisto. In quel periodo il fabbricante gestisce le vulnerabilità e fornisce patch di sicurezza gratuite.

Leggetelo come un vincolo di approvvigionamento, perché è quello che è.

Se il modulo radio del vostro progetto gira su un SDK del fornitore che al terzo anno smette di ricevere patch, non potete più correggere ciò che vi sta sopra. Avrete dichiarato cinque anni di supporto alla vendita e perso la capacità di onorarlo al terzo anno, per una decisione presa in fase di selezione componenti.

Due domande entrano quindi nella qualifica di un modulo, accanto a prezzo, tempi e seconda fonte:

• Per quanto tempo questo fornitore rilascerà patch di sicurezza per questo componente, per iscritto, e cosa succede a fine vita?
• Esiste una seconda fonte con uno stack su cui potremmo migrare senza riprogettare la scheda?

Nessuna delle due compare di norma in una revisione di distinta base. Entrambe appartengono alla stessa conversazione del rischio di fornitura, perché è lo stesso tipo di rischio: un componente diventa indisponibile, in un caso commercialmente, nell’altro giuridicamente.

→ Come si classificano i codici e cosa significa un rosso: Matrice di rischio di fornitura componenti

L’SBOM deve descrivere cosa c’è davvero dentro

L’allegato I parte II richiede una distinta base del software in un formato diffuso e leggibile da macchina, che copra almeno le dipendenze di primo livello.

Per un’applicazione web è un output degli strumenti di build. Per un prodotto fisico è una questione di assemblaggio, perché il firmware raramente è tutto vostro. Un tipico dispositivo di consumo connesso contiene:

• il firmware applicativo scritto per questo prodotto
• un SDK del fornitore arrivato con il modulo radio
• uno stack di protocollo (Bluetooth, Wi-Fi, Thread) consegnato come blob binario
• un sistema operativo real-time
• librerie open source portate da uno qualsiasi dei precedenti

Il brand possiede di norma la prima voce e non ha visibilità sul resto, perché è arrivato attraverso la fabbrica e i suoi fornitori di moduli. Mettere insieme un SBOM reale significa chiedere alla fabbrica, e farle chiedere ai suoi fornitori.

Questa richiesta costa molto meno durante lo sviluppo che dopo un incidente. Vi dice anche se il produttore del modulo è disposto a dichiarare cosa c’è nel suo binario, informazione che conviene avere prima di progettarlo dentro.

Sicuro per impostazione predefinita, e aggiornabile

Altri due requisiti dell’allegato I ricadono su decisioni hardware molto precoci.

Sicuro per impostazione predefinita significa che il prodotto esce con una configurazione sicura: nessuna password predefinita condivisa, nessun servizio o porta aperta non necessari, superficie di attacco ridotta. Sono impostazioni del firmware, e le imposta di solito chi il firmware lo scrive. Se è il vostro contoterzista, l’attuazione è sua e la specifica è vostra.

Aggiornamenti di sicurezza gratuiti per tutto il periodo di supporto presuppongono che il prodotto possa riceverli. Se possa farlo non è una questione software:

• Budget di flash. Uno schema a due partizioni per aggiornamenti over-the-air sicuri raddoppia all’incirca lo spazio necessario. Accorgersene dopo il congelamento della distinta lascia solo il cambio di memoria o la rinuncia all’OTA.
• Connettività. Un dispositivo senza percorso verso Internet si aggiorna solo sul campo o tramite app companion, entrambi con tassi di completamento molto inferiori a quanto un obbligo quinquennale presuppone.
• Alimentazione. Un aggiornamento che parte con batteria scarica e rende il dispositivo inservibile è peggio di nessun aggiornamento: la logica di aggiornamento ha bisogno di una soglia di carica, che ha bisogno di un misuratore.

Nessuna di queste cose si aggiunge a poco prezzo. Tutte si decidono nel riesame di ingegneria, prima dello stampo.

→ Il riesame in cui questi vincoli emergono: Riesame di rischio DFX prima dello stampo

Cosa cambia davvero in un progetto

Per un prodotto che entra ora in sviluppo e sarà venduto nell’Unione, cambiano tre cose:

1. La qualifica dei moduli acquisisce una domanda sulla durata delle patch. Chiedete per iscritto l’impegno di supporto del fornitore, e trattate «non lo pubblichiamo» per quello che è: una risposta.
2. L’SBOM diventa un deliverable. Nominatelo nel contratto di sviluppo accanto a disegni e rapporti di prova, così arriva con il prodotto invece di essere ricostruito sotto un orologio di 24 ore.
3. L’aggiornabilità si specifica prima dello stampo. Riserva di flash, schema di partizioni e canale di aggiornamento costano poco in fase di concetto e molto una volta che l’involucro esiste.

Per i prodotti già sul mercato la domanda a breve è più stretta e più urgente: riuscite a sapere cosa c’è dentro, e in quanto tempo?

Nota sull’ambito

Questa è una lettura di testi normativi pubblicati, non un parere legale, e i dettagli attuativi del CRA continuano a essere definiti tramite norme tecniche e linee guida. Fate confermare da un consulente qualificato come si applichi alla vostra classe di prodotto e ai vostri mercati prima di costruirci sopra un piano. Ciò che è abbastanza stabile per progettare è la direzione: il supporto di sicurezza è diventato un impegno dichiarato e datato, e le decisioni che lo rendono possibile o impossibile si prendono nell’hardware, presto.

→ Il dettaglio a livello scheda, dallo schema alla linea SMT: Produzione conto terzi di elettronica di consumo