Stai sviluppando un'applicazione o producendo un dispositivo connesso? Dal 2025, il Cyber Resilience Act (CRA) dell'Unione Europea ti impone obblighi precisi. Non è un'opzione, non è un'etichetta volontaria: è legge. E le sanzioni arrivano fino al 2,5% del fatturato globale annuo.
Noi di Meteora Web lo viviamo ogni giorno con i nostri clienti: aziende che scoprono solo ora che il loro software embedded o il loro servizio SaaS deve rispettare requisiti stringenti di cybersecurity. E non parliamo solo di password più lunghe o di un aggiornamento ogni tanto. Parliamo di gestione delle vulnerabilità, comunicazione trasparente, documentazione tecnica, e un processo di vulnerability disclosure ben definito.
In questa guida ti portiamo dritto al punto: cosa deve fare un produttore (software o hardware) per essere conforme al CRA, senza giri di parole, con esempi concreti e azioni che puoi avviare subito.
Cos'è il Cyber Resilience Act e perché ti riguarda
Il Cyber Resilience Act (Regolamento UE 2024/2847) è il primo quadro normativo europeo che impone requisiti di cybersicurezza per prodotti con elementi digitali – software, hardware, firmware – immessi sul mercato. Non importa se vendi B2B o B2C, se sei una startup o una PMI: se il tuo prodotto ha una componente digitale e viene commercializzato nell'UE, sei coperto.
Obiettivo? Ridurre le vulnerabilità sfruttabili, obbligare i produttori a rilasciare patch tempestive e garantire che i consumatori siano informati sui rischi. Il CRA si applica a tutto il ciclo di vita del prodotto: dalla progettazione alla dismissione.
Sponsored Protocol
Chi è considerato produttore secondo il CRA
Il regolamento definisce produttore chiunque sviluppi, fabbrichi o faccia sviluppare/fabbricare un prodotto con elementi digitali e lo commercializzi con il proprio nome o marchio. Questo include:
- Produttori di dispositivi IoT (smart home, sensori industriali, wearable)
- Sviluppatori di applicazioni software desktop, mobile o cloud
- Fornitori di sistemi embedded (firmware su microcontrollori)
- Piattaforme SaaS che offrono funzionalità software – attenzione: il CRA copre anche i software standalone (es. app mobile, software gestionale)
- Chi assembla componenti hardware con software integrato (es. vendor di router, telecamere IP, termostati)
Attenzione: se il tuo prodotto include componenti open source, l'obbligo di conformità rimane tuo. Non puoi scaricare la responsabilità sul fornitore della libreria.
Obblighi chiave per i produttori: una checklist operativa
Il CRA non è un singolo adempimento, ma un insieme di requisiti che vanno integrati nel tuo processo di sviluppo. Ecco i punti essenziali.
1. Progettazione sicura (security by design)
Devi adottare un approccio di sicurezza fin dalla fase di progettazione. Non basta “aggiungere sicurezza dopo”. Significa:
- Analisi dei rischi iniziale (minacce, superfici di attacco)
- Scelta di componenti e librerie sicure (nessuna dipendenza obsoleta)
- Implementazione di principi come least privilege, validazione input, cifratura dati sensibili
- Documentazione delle scelte di sicurezza (da conservare per eventuali audit)
Esempio pratico: un client che produce termostati connessi utilizzava un modulo WiFi con firmware fermo a versioni del 2019. Noi abbiamo imposto un upgrade alla release più recente e abilitato gli aggiornamenti OTA (over-the-air) protetti da firma crittografica.
Sponsored Protocol
2. Gestione delle vulnerabilità
Il produttore deve istituire un processo continuo per identificare, segnalare e correggere le vulnerabilità. Questo include:
- Un canale pubblico per ricevere segnalazioni di vulnerabilità (es. security@azienda.it o una pagina dedicata)
- Un tempo massimo per rilasciare patch (il CRA non fissa una scadenza fissa, ma richiede che sia “tempestivo” e documentato)
- Aggiornamenti di sicurezza gratuiti per almeno 5 anni dal momento dell'immissione sul mercato (o per tutta la durata prevista del prodotto, se superiore)
Obbligo di vulnerability disclosure: devi pubblicare advisory sulle vulnerabilità note e informare gli utenti. Ecco un modello minimo di pagina di divulgazione:
<h2>Security Advisories</h2>
<p>We encourage responsible disclosure. Report vulnerabilities to security@myproduct.com.</p>
<ul>
<li><strong>CVE-2025-1234</strong> – RCE in module X (fixed in v2.1.3, release date 2025-08-01)</li>
<li><strong>CVE-2025-5678</strong> – XSS in admin panel (fixed in v3.0.0, release date 2025-09-15)</li>
</ul>3. Software Bill of Materials (SBOM)
Il CRA impone la trasparenza sulle componenti software del prodotto. Devi essere in grado di fornire una lista dei materiali software (SBOM) che elenchi tutte le dipendenze, versioni e licenze. Non è necessario rilasciarlo pubblicamente (salvo richiesta dell'autorità), ma devi averlo pronto.
Sponsored Protocol
Formati standard accettati: CycloneDX (raccomandato), SPDX. Esempio di un frammento di SBOM in CycloneDX:
{
"bomFormat": "CycloneDX",
"specVersion": "1.5",
"version": 1,
"components": [
{
"type": "library",
"name": "openssl",
"version": "3.0.12",
"purl": "pkg:generic/openssl@3.0.12",
"licenses": [{"license": {"id": "Apache-2.0"}}]
}
]
}Azioni immediate: usa strumenti come syft (Anchore) o trivy per generare SBOM automaticamente durante la build. Integra nel CI/CD.
4. Documentazione tecnica e dichiarazione di conformità
Prima di immettere il prodotto sul mercato, devi predisporre una documentazione tecnica che dimostri la conformità ai requisiti del CRA. Include analisi dei rischi, specifiche di sicurezza, test effettuati. Inoltre, devi redigere una Dichiarazione UE di Conformità e apporre la marcatura CE (con il nuovo simbolo “CE” aggiornato per il CRA).
Sponsored Protocol
Scarica un template: la Commissione Europea ha pubblicato modelli – cercali su ec.europa.eu.
5. Notifica di vulnerabilità sfruttate attivamente
Se una vulnerabilità del tuo prodotto viene sfruttata attivamente, devi notificarla entro 24 ore all'ENISA (Agenzia dell'UE per la cybersicurezza) e, entro 72 ore, fornire una valutazione dell'impatto. Un obbligo oneroso, ma fondamentale per la trasparenza.
Quali prodotti sono esentati? (Spoiler: pochi)
Il CRA esclude solo:
- Software libero non commercializzato (es. progetti open source personali senza scopo di lucro)
- Dispositivi medici soggetti a regolamentazione specifica (MDR)
- Componenti aeronautici (coperti da EASA)
Attenzione: il software open source distribuito a scopo commerciale (anche indiretto, come un CMS con supporto a pagamento) è incluso. Se il tuo prodotto è un semplice plugin WordPress venduto su marketplace, ricadi nel CRA.
Sanzioni e tempistiche
Il CRA è già in vigore dal 11 dicembre 2024, ma la maggior parte degli obblighi diventa applicabile dal 11 dicembre 2027. Tuttavia, alcune disposizioni (notifica di vulnerabilità) sono già attive. Non aspettare il 2027: adeguarsi richiede mesi di lavoro tecnico e organizzativo.
Sanzioni: fino a 15 milioni di euro o al 2,5% del fatturato annuale mondiale, a seconda di quale sia maggiore.
Come ci stiamo muovendo noi di Meteora Web
Supportiamo i nostri clienti (dalla startup al PMI manifatturiero) nel percorso di conformità al CRA. Partiamo sempre da un gap analysis: confrontiamo i loro processi attuali con i requisiti del regolamento. Poi interveniamo su:
Sponsored Protocol
- Integrazione di SBOM nei pipeline CI/CD
- Impostazione di una vulnerability disclosure policy
- Security audit del firmware/software con scansione SAST/DAST
- Documentazione tecnica e dichiarazione di conformità
Un esempio concreto: un cliente che produce sensori per agricoltura di precisione non aveva alcun processo di aggiornamento automatico. Abbiamo implementato un sistema OTA firmato con chiave hardware, e redatto la procedura di notifica all'ENISA. Ora è in linea con il CRA.
In sintesi – Cosa fare adesso
- Fai un inventory dei prodotti: elenca tutti i tuoi software e dispositivi con elementi digitali commercializzati nell'UE.
- Analizza i rischi: identifica le vulnerabilità più probabili per ogni prodotto.
- Genera il SBOM: usa syft o trivy su ogni build; integra nel CI/CD.
- Istituisci una vulnerability disclosure policy: crea una pagina pubblica e un indirizzo email dedicato.
- Pianifica gli aggiornamenti: definisci un ciclo di rilascio patch per almeno 5 anni.
- Consulta la guida pillar: per una visione d'insieme su NIS2 e CRA, leggi la nostra Guida Pillar Definitiva su NIS2 e Normativa Cybersecurity EU.
Non aspettare che arrivi una multa. Il Cyber Resilience Act non è solo un obbligo: è l'occasione per rendere i tuoi prodotti più sicuri e competitivi. Noi siamo qui per aiutarti.
