Il Cyber Resilience Act (CRA) stabilisce requisiti di sicurezza del prodotto e gestione delle vulnerabilità. Non prescrive un TPM esterno, un MCU specifico, OTA o un bootloader A/B per ogni dispositivo. Scegliete i controlli dalla valutazione del rischio informatico e documentate come soddisfano i requisiti applicabili.
Ambito e categoria del prodotto
Verificate l’articolo 2 del CRA: riguarda prodotti con elementi digitali il cui uso previsto o ragionevolmente prevedibile comprende una connessione dati logica o fisica, diretta o indiretta, a un dispositivo o una rete. Esistono esclusioni settoriali per prodotti coperti da specifiche norme su dispositivi medici, veicoli e aviazione. Il software libero e open-source non commerciale ha un trattamento diverso; i relativi steward hanno obblighi specifici.
Documentate funzionalità principale e categoria. L’allegato III distingue prodotti importanti di classe I e II. La classe II comprende hypervisor e runtime di container che supportano sistemi operativi virtualizzati, firewall/IDS/IPS e microprocessori/microcontrollori resistenti alle manomissioni. L’allegato IV comprende categorie critiche come smart card e dispositivi analoghi, inclusi secure element. Non ogni contatore intelligente o componente di sicurezza appartiene alla classe II. Usate le descrizioni tecniche 2025/2392 per classificare il prodotto.
Sicurezza fin dalla progettazione
Definite asset, confini di fiducia, minacce e abusi prevedibili. Collegate i requisiti applicabili dell’allegato I a controlli ed evidenze di test. Impiegate impostazioni sicure, controlli di accesso appropriati, minimizzazione dei dati e protezione di riservatezza e integrità. Motivate applicabilità e non applicabilità: una casella spuntata non sostituisce la valutazione dei rischi.
Controlli di sicurezza hardware
Secure boot, chiavi protette, restrizioni debug e misure anti-manomissione possono affrontare rischi identificati. Sono scelte implementative, non un obbligo universale di installare un TPM discreto o bloccare irreversibilmente ogni interfaccia debug. Validate catena di avvio, provisioning produttivo e recupero.
Comunicazioni sicure
Identificate interfacce e confini di fiducia. Scegliete autenticazione e protezione crittografica adeguate ai rischi. Testate validazione dei certificati, ciclo di vita delle credenziali e gestione degli errori. Il solo nome di una versione TLS non dimostra i requisiti essenziali.
Vulnerabilità e periodo di supporto
Assegnate responsabilità per ricezione, triage, correzione e divulgazione. Pubblicate un contatto di sicurezza e definite escalation ai fornitori. L’articolo 13 richiede di considerare l’uso atteso: normalmente almeno cinque anni, ma quando l’uso atteso è più breve il supporto corrisponde a tale durata. Un prodotto longevo può richiedere più anni. Comunicate la fine del supporto e pianificate le risorse.
Distinta software SBOM
L’allegato I, parte II, richiede una SBOM leggibile da macchina che copra almeno le dipendenze di primo livello. Un inventario interno più profondo aiuta il triage. Registrate versioni e aggiornate l’inventario delle release. Non equivale a pubblicare integralmente la SBOM: il CRA non impone tale pubblicazione in modo generalizzato.
Infrastruttura di aggiornamento
Predisponete un meccanismo sicuro e appropriato per distribuire aggiornamenti. Contano autenticità, integrità, recupero e usabilità. OTA, slot A/B e anti-rollback possono essere adatti, ma non sono tecnologie prescritte universalmente. Testate interruzioni e rotazione delle chiavi.
Segnalazione degli eventi
L’articolo 14 si applica dall’11 settembre 2026. Riguarda vulnerabilità attivamente sfruttate e gravi incidenti che incidono sulla sicurezza del prodotto, non ogni CVE di una dipendenza. Sia l’allarme entro 24 ore sia la notifica entro 72 ore decorrono dalla conoscenza dell’evento. La Single Reporting Platform indirizza la segnalazione al CSIRT coordinatore e all’ENISA, secondo le disposizioni di diffusione. Consultate il flusso di segnalazione per le relazioni finali.
Documentazione e conformità
I requisiti principali si applicano dall’11 dicembre 2027. Preparate rischi, documentazione tecnica, test, gestione delle vulnerabilità e dichiarazione UE per il percorso applicabile. La categoria predefinita può usare il controllo interno. In classe I l’autovalutazione dipende dalla copertura dei requisiti applicabili tramite norme armonizzate, specifiche comuni o certificazione pertinente; altrimenti occorre la valutazione di terza parte prevista. La classe II richiede i percorsi di terza parte specificati. Per i prodotti critici valgono l’articolo 32 ed eventuali atti di certificazione dell’articolo 8: l’allegato IV da solo non rende oggi obbligatorio EUCC.
Un certificato PSA/SESIP può sostenere proprietà valutate del componente, ma la conformità del prodotto integrato resta responsabilità del fabbricante.
Supporto conformità UE · Parliamo del percorso del vostro prodotto
Domande frequenti
Il CRA impone TPM e OTA in ogni prodotto?
No. Il CRA stabilisce requisiti essenziali basati sul rischio. TPM, secure boot, OTA o aggiornamenti A/B possono essere controlli adatti, ma non sono tecnologie obbligatorie universalmente.
Il supporto dura sempre cinque anni?
L’articolo 13 prevede normalmente almeno cinque anni considerando l’uso atteso. Se questo è più breve, il supporto corrisponde a tale durata; prodotti più longevi possono richiedere un periodo maggiore.
Ogni CVE scoperto va segnalato entro 24 ore?
No. L’articolo 14 riguarda vulnerabilità attivamente sfruttate e gravi incidenti che incidono sulla sicurezza del prodotto. Le altre vulnerabilità richiedono comunque gestione secondo gli obblighi pertinenti.
La classe I consente sempre l’autovalutazione?
No. Il controllo interno dipende dalla copertura dei requisiti applicabili con norme, specifiche o certificazione pertinenti. Altrimenti serve il percorso di terza parte previsto.
Fonti primarie
Riferimenti tecnici e normativi verificati il 1° ottobre 2026.