Che cos'è il Cyber Resilience Act UE (CRA)?

Lo scope del CRA è intenzionalmente ampio. Qualsiasi prodotto il cui uso previsto o ragionevolmente prevedibile include connessione dati — diretta o indiretta — verso un dispositivo o una rete è in scope. Include:

• IoT consumer (smart speaker, telecamere, serrature, termostati).
• Sistemi di controllo industriali e IIoT.
• Apparati di rete (router, switch, firewall).
• Sistemi operativi, middleware, librerie, browser, software di produttività, app mobile.
• Prodotti di identità/autenticazione.
• Smartcard, moduli HSM, sensori smart.
• La maggior parte del software enterprise inclusi i tool di cybersecurity.

Fuori scope (coperti da altri regimi): dispositivi medici sotto MDR/IVDR, veicoli sotto type-approval, aviazione, prodotti sotto Civil Aviation Authority, offerte solo servizi (coperte invece da NIS2).

Sfumatura open-source: i contributor open-source non commerciali non sono "produttori" sotto il CRA. Ma chiunque monetizzi open-source — tramite supporto a pagamento, SaaS hosted o distribuzione commerciale — diventa produttore per i prodotti monetizzati. La categoria "open-source steward" dell'art. 24 crea obblighi più leggeri per fondazioni e steward non-profit di componenti largamente usati.

L'art. 7 + Allegato III divide i prodotti in tre classi di rischio che guidano la profondità della valutazione di conformità.

Classe default — la maggior parte dei prodotti. Auto-valutazione contro i requisiti essenziali dell'Allegato I è sufficiente; il produttore firma la Dichiarazione UE di Conformità.

Classe importante (Classe I e Classe II, Allegato III) — tipologie di prodotto a rischio più alto. La Classe I include prodotti di identity management, browser, password manager, antivirus, VPN, network management, SIEM/SOAR, smart-home con funzioni di sicurezza, videosorveglianza. La Classe II include hypervisor e container runtime per uso industriale, firewall/IDS industriali, microprocessori tamper-resistant. Classe I e II richiedono o conformità a standard armonizzati (auto-dichiarata ma standardizzata) o valutazione di conformità di terza parte.

Classe critica (Allegato IV) — al momento un elenco ristretto: dispositivi hardware con security box, secure element smartcard-like, smart-meter gateway. La Commissione può spostare prodotti dentro e fuori dalla critica via atti delegati. I prodotti critici richiedono valutazione di conformità di terza parte obbligatoria da organismo notificato, più possibile schema europeo di certificazione cybersecurity.

Per i vendor di cybersecurity specificamente, l'elenco Allegato III(I) è dove ricade la maggior parte del tooling security enterprise — inclusi endpoint, network detection, vulnerability scanning, IAM e SIEM. L'infrastruttura di valutazione di conformità per questa classe non sarà opzionale da dicembre 2027.

L'Allegato I si divide in Parte 1 (proprietà di sicurezza del prodotto) e Parte 2 (processo di gestione vulnerabilità). Entrambe sono essenziali — fallire una blocca la marcatura CE.

Parte 1 — sicurezza del prodotto: - Consegnato senza vulnerabilità note sfruttabili. - Consegnato con configurazione secure-by-default. - Confidenzialità, integrità, autenticità, disponibilità protette con mezzi appropriati. - Attack surface minimizzata (nessuna interfaccia esterna, servizio, account, funzionalità debug non necessari abilitati per default). - Resilienza contro denial-of-service. - Logging eventi di sicurezza per l'utente. - Meccanismo di update sicuro, inclusi security update automatici dove appropriato. - Dati processati solo per lo scopo previsto.

Parte 2 — gestione vulnerabilità: - Identificare e documentare vulnerabilità e relativi componenti (SBOM machine-readable). - Indirizzare le vulnerabilità senza ritardo tramite security update. - Disclosure pubblica delle vulnerabilità risolte una volta disponibile l'update — e una policy di coordinated disclosure pubblicata. - Security update gratuiti per il periodo di supporto dichiarato. - Verifica degli update (firmati, integrity-checked).

Il requisito SBOM è il perno operativo che la maggior parte dei team prodotto sottovaluta. L'SBOM dev'essere machine-readable (CycloneDX o SPDX), mantenuto aggiornato, e fornito alle autorità di sorveglianza del mercato su richiesta. Gli SBOM assemblati a mano al momento dell'audit falliscono il test "mantenuto aggiornato".

L'art. 14 — in vigore dall'11 settembre 2026, prima del resto del regolamento — crea due notifiche obbligatorie per i produttori.

Notifica di vulnerabilità attivamente sfruttata (art. 14(1)): entro 24 ore dalla awareness, early warning al CSIRT designato coordinatore sotto NIS2 *e* a ENISA, con nome, tipo di vulnerabilità e (quando noto) misure correttive o di mitigazione disponibili. Entro 72 ore, report più dettagliato. Report finale entro 14 giorni dalla disponibilità di una misura correttiva.

Notifica di incidente grave (art. 14(2)): entro 24 ore dalla awareness di un incidente grave che impatta la sicurezza di un prodotto con elementi digitali, early warning agli stessi destinatari. Definizione di grave: impatto significativo sulla capacità di fornire una funzionalità chiave, sulla confidenzialità/integrità/disponibilità di quantità significative di dati o su qualsiasi funzione ritenuta di interesse pubblico.

Il reporting è via la piattaforma di reporting unica ENISA (in costruzione al momento; specifiche negli atti di esecuzione in preparazione). È una notifica regulator-grade, non comunicazione cliente. Il countdown parte dalla awareness — significa che la capacità di detection è essa stessa un tema di conformità CRA.

Per i prodotti che resteranno sul mercato UE oltre dicembre 2027:

Adesso (2026): - Mappa il portfolio prodotti contro l'Allegato III per identificare le voci Classe I / Classe II / Critica. Le code degli organismi notificati saturano lungo il 2027. - Avvia il processo di gestione vulnerabilità (policy di coordinated disclosure, tooling SBOM, infrastruttura di firma update, registrazione CVE Numbering Authority se appropriato). - Cabla il workflow di reporting di settembre 2026 — chi è il lead di incidenti CRA, qual è il template di notifica a 24 ore, dov'è il canale ENISA. - Dry-run di valutazione di conformità contro le draft di standard armonizzati attuali (ETSI EN 303 645 per IoT consumer, allineamento ISO/IEC 27001 per processi generali).

Lungo il 2027: - Cambi di engineering per soddisfare l'Allegato I Parte 1 per default sulle nuove build. - Copertura SBOM di ogni artefatto spedito, mantenuta aggiornata build-on-build. - Cadenza di update e dichiarazione del periodo di supporto nella documentazione prodotto e nella Dichiarazione UE di Conformità.

L'errore costoso che i team prodotto stanno facendo è trattare il CRA come "un problema di documentazione da risolvere in Q3 2027". L'infrastruttura di valutazione di conformità (organismi notificati, standard armonizzati, piattaforma ENISA) viene costruita lungo il 2026-2027 con vincoli di capacità; i prodotti che arrivano in coda tardi non spediranno nell'UE il 12 dicembre 2027.

Per i vendor di tool cybersecurity specificamente — incluse le piattaforme security AI-powered — il CRA si somma all'AI Act quando il tool rientra nelle categorie dell'Allegato III. Produrre due pacchetti di conformità dalla stessa base di evidenze è drammaticamente più facile che costruire ognuno separatamente; l'implicazione operativa è che il modello Trust Center / continuous evidence diventa un abilitatore CRA, non solo un nice-to-have di audit.