EU Cyber Resilience Act: cosa devono costruire i produttori di dispositivi
L'EU Cyber Resilience Act (CRA) (Regolamento UE 2024/2847) è in vigore. La maggior parte dei requisiti di prodotto si applica dall'11 dicembre 2027, con un'applicazione parziale anticipata all'11 giugno 2026 (disposizioni di governance e applicazione) e all'11 settembre 2026 (organismi notificati). La scadenza dell'11 dicembre 2027 è quella critica per i produttori che stanno costruendo o aggiornando prodotti connessi.
Il CRA introduce requisiti di cybersecurity obbligatori per qualsiasi prodotto con elementi digitali venduto nell'Unione Europea, il che include praticamente ogni dispositivo IoT connesso. La non conformità blocca l'accesso al mercato e comporta sanzioni fino a 15 milioni di euro o il 2,5% del fatturato annuo globale, a seconda di quale sia maggiore.
La maggior parte dei contenuti sul CRA è scritta da studi legali. Questa pagina si concentra su ciò che i produttori devono concretamente costruire e gestire per soddisfare i requisiti tecnici, e su cosa copre Connhex.
Tra tutti i requisiti del CRA, l'infrastruttura OTA e la gestione delle credenziali per singolo dispositivo sono i più complessi da progettare e deployare, soprattutto per i prodotti già in campo. La scadenza per i prodotti è l'11 dicembre 2027.
Fonti ufficiali: Testo completo del CRA (EUR-Lex) · Sintesi del CRA (EUR-Lex)
Cosa richiede il CRA, tecnicamente
Il CRA è organizzato intorno agli obblighi dei produttori lungo l'intero ciclo di vita del prodotto. I requisiti con l'impatto più diretto su ciò che i produttori devono costruire sono:
1. Capacità di aggiornamento OTA (Art. 13.8)
I produttori devono garantire che le vulnerabilità possano essere corrette tramite aggiornamenti di sicurezza, inclusi gli aggiornamenti remoti, per la durata di vita prevista del prodotto o per un minimo di cinque anni.
Questo significa che ogni prodotto connesso venduto nell'UE dall'11 dicembre 2027 deve disporre di un meccanismo di aggiornamento over-the-air funzionante: firmato, autenticato e in grado di distribuire patch ai dispositivi in campo.
2. Identità univoche per dispositivo (Art. 13.3 e Allegato I)
I prodotti devono implementare principi di secure-by-design, incluse credenziali di autenticazione univoche per singolo dispositivo. Segreti condivisi, password hardcoded e credenziali predefinite generiche non soddisfano questo requisito.
Ogni dispositivo deve ricevere un'identità univoca (ad esempio un certificato X.509 o equivalente) durante la produzione, e quell'identità deve essere usata per tutte le comunicazioni con i sistemi backend.
3. Nessuna vulnerabilità sfruttabile nota al momento della vendita (Art. 13.1)
I prodotti devono essere immessi sul mercato senza vulnerabilità sfruttabili note. Questo richiede un processo di security testing documentato e un meccanismo per tracciare e rispondere alle vulnerabilità scoperte dopo la vendita.
4. Disclosure e gestione delle vulnerabilità (Art. 13.6, 13.7)
I produttori devono avere un processo per:
- Ricevere segnalazioni di vulnerabilità (un punto di contatto pubblico)
- Triageare e affrontare le vulnerabilità segnalate entro le tempistiche definite
- Notificare all'autorità UE competente (ENISA) le vulnerabilità attivamente sfruttate entro 24 ore, e fornire una notifica dettagliata entro 72 ore
Questo è principalmente un requisito organizzativo e di processo, non di piattaforma.
5. Software Bill of Materials (SBOM) (Art. 13.9)
I produttori devono mantenere un SBOM (un inventario leggibile da macchina di tutti i componenti software del prodotto) per facilitare il tracciamento delle vulnerabilità lungo la supply chain.
La generazione di SBOM è un requisito della pipeline di build e della toolchain. Strumenti come Syft, CycloneDX o sistemi di build con integrazione SPDX producono questo output; non è qualcosa che fornisce una piattaforma di connettività IoT.
6. Protezione e minimizzazione dei dati (Art. 13.4)
I prodotti devono trattare solo i dati necessari per il loro scopo previsto e proteggerli da accessi non autorizzati. Per i produttori con sede nell'UE o prodotti che si rivolgono a clienti UE, questo si interseca con gli obblighi del GDPR.
Cosa devi avere in essere
Mappa dei requisiti CRA ai compiti di implementazione:
| Requisito CRA | Cosa devi costruire |
|---|---|
| Aggiornamenti OTA (Art. 13.8) | Distribuzione firmware firmata, rilasci graduali, rollback in caso di errore, client di aggiornamento sul dispositivo |
| Identità univoche per dispositivo (Art. 13.3) | Emissione di certificati per singolo dispositivo durante la produzione, catena di trust X.509 |
| Pipeline di patching delle vulnerabilità | SDLC sicuro, processo di build e firma delle patch, meccanismo di consegna OTA |
| Processo di disclosure delle vulnerabilità | Punto di contatto pubblico, workflow interno di triage, procedura di notifica ENISA |
| SBOM | Generazione automatica nella pipeline di build (responsabilità della toolchain), storage e versioning |
| Minimizzazione dei dati | Revisione di API e modello dati, policy di retention, controlli di accesso |
Come Connhex affronta ogni requisito
Le sezioni seguenti sono esplicite su ciò che Connhex copre direttamente, ciò che supporta e ciò che è fuori scope dalla piattaforma.
Aggiornamenti OTA: coperti direttamente
Connhex Edge fornisce il client di aggiornamento sul dispositivo. Connhex Control gestisce le campagne firmware dal cloud: le immagini firmware vengono firmate al caricamento, e l'agente sul dispositivo verifica la firma prima di applicare qualsiasi aggiornamento. I rilasci graduali e il rollback automatico in caso di errore sono integrati. Vedi Aggiornamenti firmware OTA.
Identità univoche per dispositivo: coperte direttamente
Connhex Provisioning e Connhex Manufacturing automatizzano l'emissione di certificati X.509 per singolo dispositivo durante la produzione. Connhex Remote Init gestisce i dispositivi già in campo che devono essere migrati a credenziali per singolo dispositivo. Vedi Provisioning sicuro dei dispositivi.
Monitoraggio e rilevamento anomalie: supportato
Connhex Monitoring fornisce l'infrastruttura di telemetria per rilevare comportamenti anomali dei dispositivi che potrebbero indicare un exploit attivo. Questo supporta il tuo processo di rilevamento degli incidenti ma non sostituisce un programma formale di security monitoring.
Protezione dei dati e GDPR: supportato
Connhex fornisce una documentazione sulla conformità GDPR che copre flussi di dati, residenza, policy di retention e controlli di accesso, direttamente utile per le valutazioni di conformità sia al CRA che al GDPR.
Disclosure delle vulnerabilità: fuori scope di Connhex
Stabilire un contatto pubblico per la segnalazione delle vulnerabilità, definire le procedure interne di triage e configurare i workflow di notifica ENISA sono requisiti organizzativi. Connhex mantiene il proprio processo di segnalazione delle vulnerabilità per la piattaforma stessa; il tuo prodotto ha bisogno di un processo separato per il tuo firmware e hardware. Se vuoi definire questo perimetro per il tuo deployment, contattaci.
SBOM: fuori scope di Connhex
La generazione di SBOM è una questione di pipeline di build gestita da integrazioni nella toolchain, non da una piattaforma di connettività IoT. Connhex Manufacturing traccia le versioni firmware al momento della produzione (utile per risalire a quale versione SBOM è stata spedita con quale dispositivo) ma non genera SBOM.
Conformità CRA nei diversi settori
Il CRA si applica a tutti i prodotti connessi, indipendentemente dal settore. I requisiti per gli aggiornamenti OTA e le identità univoche dei dispositivi sono particolarmente rilevanti per:
Connhex per HVAC · Connhex per la smart home · Connhex per le lavatrici industriali
Cosa fare adesso
La conformità al CRA tocca più workstream. L'infrastruttura OTA e la gestione delle credenziali per singolo dispositivo sono tra i più impegnativi da implementare e deployare, in particolare per i prodotti già in campo. Partire da questi consente al resto del lavoro di conformità di costruirsi su una base solida prima della scadenza dell'11 dicembre 2027.
Se vuoi capire quali funzionalità di Connhex si mappano al tuo prodotto specifico e alla tua timeline di conformità, contattaci: lavoriamo con produttori in tutta l'UE esattamente su questo.