Cyber Resilience Act:
marcatura CE per il software,
scadenze e impatti per le PMI

Cos’è il Cyber Resilience Act

Il Cyber Resilience Act è il Regolamento (UE) 2024/2847, pubblicato in Gazzetta Ufficiale dell’Unione Europea il 20 novembre 2024 ed entrato formalmente in vigore il 10 dicembre 2024. Per la prima volta l’UE introduce requisiti di sicurezza obbligatori per tutti i «prodotti con elementi digitali» (PED) immessi sul mercato europeo: software stand-alone, sistemi operativi, firmware, dispositivi IoT consumer e industriali, apparati di rete, hardware crittografico, soluzioni di sicurezza. È il pezzo mancante del mosaico normativo cyber UE: si affianca alla Direttiva NIS2 (sicurezza dei soggetti che erogano servizi essenziali) e all’AI Act (intelligenza artificiale), chiudendo il cerchio sull’altro lato dell’equazione: la sicurezza dei prodotti che quei soggetti usano per erogare i propri servizi.

La logica è la stessa che ha trasformato negli anni la marcatura CE su lavatrici, giocattoli e dispositivi medicali: chi immette un prodotto sul mercato UE è tenuto a dimostrare, sotto la propria responsabilità, che il prodotto rispetta requisiti essenziali fissati dalla normativa. Con il CRA, per la prima volta, il bollino CE comprende anche la cybersecurity. Per chi acquista, il bollino diventa il prerequisito di accesso al mercato — esattamente come oggi per un giocattolo o per un alimentatore.

Le due scadenze critiche da tenere in agenda

Il CRA non scatta tutto insieme: l’UE ha previsto un’applicazione progressiva, con due tappe operative che vanno segnate adesso nel piano IT delle PMI italiane.

• 111 settembre 2026 — notifica vulnerabilità a ENISA in 24 ore. I produttori di prodotti con elementi digitali devono notificare a ENISA, attraverso una single reporting platform europea, le vulnerabilità del proprio prodotto attivamente sfruttate, entro 24 ore dalla scoperta o dalla conferma di sfruttamento. È un sistema simile, per logica, alla notifica incidenti NIS2, ma applicato al ciclo di vita del prodotto e gestito centralmente dall’UE.
• 211 dicembre 2027 — applicazione piena del CRA. Da quella data, ogni prodotto con elementi digitali immesso sul mercato UE deve essere conforme ai requisiti del regolamento e recare la marcatura CE che lo attesta. Niente marcatura CE, niente messa in commercio. Per chi acquista, da quella data ogni nuovo software o dispositivo connesso che entra in azienda deve arrivare con la documentazione CRA.

In mezzo, fra la prima e la seconda scadenza, c’è una finestra di 15 mesi in cui il mercato si adegua. È in questa finestra che si gioca la partita per le PMI italiane: i fornitori IT più strutturati stanno già allineando i propri prodotti, gli altri arriveranno in extremis o non arriveranno affatto. Avere consapevolezza di chi è in che punto della curva è già un’azione concreta di vendor risk management.

Le tre categorie di prodotto previste dal CRA

Non tutti i prodotti seguono lo stesso percorso di valutazione. Il CRA introduce una classificazione in tre livelli, con regole di conformità più severe man mano che cresce il rischio sistemico:

• Categoria standard (default) — la grande maggioranza dei prodotti rientra qui: applicazioni gestionali, utility, software di produttività, dispositivi IoT consumer non critici. La conformità è dimostrata dal produttore tramite autovalutazione (self-assessment) e dichiarazione di conformità sotto la propria responsabilità.
• Classe I — prodotti importanti — categoria intermedia che comprende prodotti il cui malfunzionamento può avere effetti significativi: gestori di password, antivirus, soluzioni VPN consumer, dispositivi smart-home con funzioni di sicurezza, microcontrollori per IoT. La valutazione di conformità può ancora avvenire tramite autovalutazione, ma il produttore deve aderire a procedure più stringenti di documentazione e gestione delle vulnerabilità.
• Classe II — prodotti importanti critici — la categoria più esigente, che richiede una valutazione di conformità da parte di un organismo notificato di terza parte. Vi rientrano, fra l’altro: sistemi operativi general-purpose, hypervisor, firewall industriali e di rete, infrastrutture a chiave pubblica (PKI), hardware crittografico, smart card. Sono i prodotti che costituiscono il «substrato di fiducia» dell’infrastruttura digitale: per loro l’autovalutazione non basta.

Per chi acquista, conoscere la categoria di un prodotto è il primo passo per leggerne la documentazione: capisce quanto è stringente la verifica che ha superato e quanto è ragionevole fidarsi della dichiarazione di conformità.

Gli obblighi tecnici del CRA in cinque punti

Sotto l’etichetta «marcatura CE» il CRA chiede ai produttori cinque cose concrete, che cambiano in modo permanente la qualità del software che entra nelle aziende:

• 1Security by design e by default — il prodotto deve essere progettato per essere sicuro nelle sue configurazioni iniziali. Niente più password di default condivise, porte aperte inutilmente, servizi attivi che non servono. La sicurezza non è una funzionalità opzionale.
• 2SBOM (Software Bill of Materials) — il produttore deve mantenere e rendere disponibile la distinta strutturata di tutti i componenti software del prodotto, in formato standard interoperabile. I due formati di riferimento sono SPDX (standardizzato come ISO/IEC 5962:2021) e CycloneDX (di OWASP). L’SBOM permette di rispondere in poche ore — non in settimane — alla domanda «questo prodotto contiene la libreria X affetta dalla nuova vulnerabilità Y?».
• 3Supporto alla sicurezza per minimo 5 anni — il produttore deve garantire patch e aggiornamenti di sicurezza per almeno 5 anni o per la vita utile attesa del prodotto, se più lunga. È la fine del software end-of-life venduto come fosse ancora supportato. Per chi acquista, l’orizzonte contrattuale di supporto diventa un dato chiaro e verificabile.
• 4Coordinated Vulnerability Disclosure — il produttore deve avere un canale pubblico e documentato per ricevere segnalazioni di vulnerabilità da ricercatori e clienti, processi strutturati per gestirle e tempi definiti per il rilascio della patch. La trasparenza sulle vulnerabilità diventa la regola, non l’eccezione.
• 5Notifica delle vulnerabilità attivamente sfruttate a ENISA in 24 ore — quando una vulnerabilità del prodotto risulta attivamente sfruttata in incidenti reali, il produttore ha 24 ore per notificarla alla single reporting platform europea gestita da ENISA. È lo stesso cronometro della pre-notifica NIS2, applicato però al ciclo di vita del prodotto.

Cosa devono fare le PMI italiane che acquistano software

Per la PMI italiana media — manifatturiera, di servizi, studio professionale strutturato — il CRA non chiede di diventare un produttore di software. Chiede di gestire diversamente il software che si acquista. Quattro azioni concrete da mettere in roadmap nei prossimi 18 mesi:

• 1Audit del portafoglio software in uso — costruire un inventario aggiornato dei prodotti digitali in azienda, per ciascuno annotando: fornitore, versione, categoria CRA prevista, data prevista di adeguamento, scadenza del supporto attuale. È il «catasto» del software, oggi spesso assente nelle PMI. Senza questo passaggio, le tre azioni successive non sono possibili.
• 2Clausole contrattuali nei rinnovi 2026-2027 — ogni nuovo contratto o rinnovo software deve includere quattro elementi: dichiarazione di conformità CRA con la categoria del prodotto, consegna dell’SBOM in formato SPDX o CycloneDX, SLA esplicita sui tempi di rilascio delle patch di sicurezza, durata garantita del supporto di sicurezza (≥ 5 anni), procedura di vulnerability disclosure verso il fornitore. Le PMI che li chiedono in anticipo si trovano un mercato che risponde meglio di quanto sembri.
• 3Vendor risk management arricchito — il CRA si somma alla NIS2 (articolo 21, sicurezza della supply chain ICT) e al controllo A.5.21 di ISO/IEC 27001:2022 sulla gestione della sicurezza nella catena di approvvigionamento. Per le PMI già impegnate sul percorso NIS2, il CRA non aggiunge un secondo binario parallelo: arricchisce lo stesso processo di valutazione fornitori con criteri più puntuali sui prodotti acquistati. Per le PMI non NIS2, è l’occasione per introdurre un primo, semplice processo strutturato.
• 4Formazione del procurement — chi negozia i contratti software deve sapere riconoscere SBOM, marcatura CE, classi di prodotto, clausole di supporto. È un lavoro di breve durata ma ad alto impatto: una mezza giornata di formazione mirata su tre o quattro persone, una volta sola, evita anni di acquisti mal coperti contrattualmente.

Come AtWorkStudio supporta il percorso CRA

AtWorkStudio affianca le PMI italiane sul percorso di adeguamento alle normative cyber UE — NIS2, DORA, AI Act e ora CRA — con un approccio operativo. Partiamo dall’audit del portafoglio software del cliente, proseguiamo con la mappatura dei fornitori e la revisione delle clausole contrattuali (in coordinamento con il legale dell’azienda), e accompagniamo nel tempo l’adeguamento man mano che il mercato si riallinea. La nostra esperienza maturata sull’implementazione del controllo A.5.21 di ISO/IEC 27001:2022 — sicurezza della catena di approvvigionamento ICT — è il presupposto naturale per affrontare la parte CRA del lavoro.

Operiamo da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, qualificati ACN per servizi cloud SaaS (qualifica QC1 per Email Security Gateway e Backup Microsoft 365), membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT. Per le PMI che valutano l’investimento, gli interventi di assessment e adeguamento possono rientrare tra le spese ammissibili del voucher MIMIT cloud e cybersecurity.