Architettura degli aggiornamenti e guasti
Un aggiornamento over-the-air (OTA) distribuisce software o firmware tramite connessione wireless. L’aggiornamento remoto può anche usare reti cablate; l’installazione automatica è una proprietà distinta. Un progetto sicuro autentica aggiornamento e destinazione, protegge le chiavi di firma, controlla le versioni e gestisce la perdita di alimentazione. Le partizioni A/B sono una strategia di recupero, non un obbligo universale. RFC 9019 descrive un’architettura di aggiornamento IoT, non un formato manifesto definitivo obbligatorio. Il dispositivo necessita di materiale di verifica, non della chiave privata di firma dell’intera flotta. Testare immagini corrotte, destinazioni errate, scritture interrotte, chiavi revocate e versioni precedenti vietate.
CRA: requisiti e scelte tecniche
I requisiti CRA sono orientati ai risultati e tecnologicamente neutrali, in base alla valutazione dei rischi e all’applicabilità. Secure boot, radice hardware di fiducia, TPM, TrustZone e OTA wireless possono essere misure opportune; non sono obblighi universali per ogni prodotto. Documentare perché i controlli scelti soddisfano i requisiti, senza equiparare una singola architettura alla conformità.
Assistenza, aggiornamenti e SBOM
L’allegato I CRA richiede i meccanismi applicabili per gestione delle vulnerabilità e aggiornamenti sicuri. Gli aggiornamenti automatici hanno condizioni ed eccezioni; automatico non significa wireless. L’articolo 13(8) determina l’assistenza, normalmente almeno cinque anni; con uso previsto più breve, corrisponde a tale uso, mentre fattori relativi a un uso più lungo possono richiedere più assistenza. La SBOM deve essere leggibile da macchina e coprire almeno le dipendenze di primo livello.
Ambito e date CRA
Il CRA è entrato in vigore il 10 dicembre 2024. Le segnalazioni dell’articolo 14 si applicano dall’11 settembre 2026; i requisiti principali dall’11 dicembre 2027. L’articolo 69 contiene regole transitorie per prodotti già immessi sul mercato. I prodotti soggetti a MDR o IVDR sono esclusi dall’articolo 2(2); verificare anche altre esclusioni e il software libero/open-source non commerciale.
Lista di controllo pratica
- Identificare prodotto, uso previsto, mercato e ambito normativo.
- Registrare disposizioni precise, date ed edizioni delle norme, comprese le restrizioni.
- Scegliere la procedura consentita e definire le evidenze necessarie.
- Collegare rischi, prove, versioni e dichiarazioni nella documentazione tecnica.
- Assegnare responsabilità per modifiche, assistenza e risposte alle autorità.
La lista aiuta la pianificazione; i requisiti normativi pertinenti determinano la valutazione finale.