EU Cyber Resilience Act: Calendario di attuazione 2024-2027

Ad aprile 2026, nessun organismo notificato è designato sotto il CRA. Nessuna norma armonizzata è stata pubblicata nella Gazzetta Ufficiale. La piattaforma di segnalazione ENISA non esiste ancora. Mancano cinque mesi all'applicazione dell'Art. 14 l'11 settembre 2026.

Se immettete prodotti con elementi digitali sul mercato UE, questa è la situazione reale: cosa dovete costruire prima di settembre, cosa è bloccato oggi e perché l'autovalutazione per la Classe I importante non funziona in questo momento.

Tre ostacoli che non potete aggirare

Tre elementi che la conformità al CRA richiede non esistono ancora. Conosceteli prima di definire il vostro calendario.

Nessuna norma armonizzata

L'Art. 32(2) prevede tre percorsi per la valutazione della conformità della Classe I importante: autovalutazione, valutazione di terze parti in base a norme armonizzate o specifiche comuni, oppure valutazione da parte di un organismo notificato. Il secondo percorso richiede l'esistenza di norme armonizzate CRA. Ma ad aprile 2026 nessuna norma armonizzata CRA è stata pubblicata nella Gazzetta Ufficiale:

• La pagina delle norme armonizzate della Commissione non contiene alcuna voce per il Regolamento (UE) 2024/2847.
• Nessuna specifica comune è stata adottata ai sensi dell'Art. 27(2).
• Nessun atto delegato ex Art. 27(9) designa alcuno schema europeo di certificazione della cybersicurezza come percorso di presunzione di conformità al CRA.

Dove le norme non esistono, l'Art. 32(2) richiede il Modulo B+C (esame UE del tipo) o il Modulo H (garanzia della qualità totale). Entrambi richiedono un organismo notificato.

Se producete un prodotto di Classe I importante, l'autovalutazione non funziona oggi. La valutazione da parte di un organismo notificato è l'unico percorso conforme disponibile.

CEN-CLC/JTC 13/WG 9 sta sviluppando la serie EN 40000:

• prEN 40000-1-1 (Vocabolario): consultazione pubblica completata, non ancora alla Votazione formale
• prEN 40000-1-2 (Principi): consultazione pubblica completata, non ancora alla Votazione formale
• prEN 40000-1-3 (Gestione delle vulnerabilità): consultazione pubblica da dicembre 2025 a febbraio 2026, attualmente in risoluzione dei commenti
• prEN 40000-1-4 (Requisiti generici di sicurezza): ancora in fase di redazione
• Verticali di tipo C (browser, VPN, SIEM, ecc.): bozze mature, non ancora in consultazione pubblica

Prima citazione in GU realistica: Q4 2026. Diversi standard verticali slitteranno probabilmente al 2027.

Nessun organismo notificato

Il Capitolo IV si applica dall'11 giugno 2026. L'obiettivo della Commissione è disporre di una capacità sufficiente entro l'11 dicembre 2026 (Art. 35(2), impegno di diligenza). Ad aprile 2026, nessun organismo notificato designato ai sensi del CRA è elencato nello Spazio unico di conformità del mercato interno (SMCS).

Se avete bisogno di completare una valutazione per la Classe I importante prima di dicembre 2027, calcolate:

• Preparazione del fascicolo tecnico: da 3 a 6 mesi
• Valutazione Modulo B+C: da 2 a 4 mesi per prodotto
• Disponibilità degli organismi notificati: incerta fino all'apertura della designazione formale dopo giugno 2026

Contattate subito i potenziali organismi di valutazione della conformità. Il meccanismo formale non apre prima della metà del 2026. Chi aspetta fino ad allora difficilmente completerà la valutazione entro dicembre 2027.

Nessuna piattaforma di segnalazione ENISA

La Piattaforma unica di segnalazione (SRP) prevista dall'Art. 16 non è disponibile ad aprile 2026. ENISA ha assegnato l'appalto a un fornitore. La piattaforma è prevista prima dell'11 settembre 2026. Non esiste ancora un URL di registrazione. Non sono state pubblicate istruzioni per i fabbricanti.

Il coordinatore CSIRT per l'Italia è il CSIRT Italia, operativo presso l'ACN (Agenzia per la Cybersicurezza Nazionale). Identificate il vostro punto di contatto nazionale ora, prima che la piattaforma ENISA sia disponibile.

Cosa potete fare adesso:

• Redigete i modelli di notifica in base ai requisiti dell'Art. 14(2): formati a 24h, 72h, 14 giorni e 30 giorni
• Definite chi internamente è autorizzato ad attivare una notifica a 24 ore nel fine settimana o durante le festività
• Stabilite percorsi di escalation e contatti di riserva

Pagina SRP di ENISA: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

Cosa deve essere in atto prima dell'11 settembre 2026

Mancano cinque mesi. Se le voci seguenti non sono completate, non siete in ritardo su singoli compiti. Siete in ritardo sull'infrastruttura, e l'infrastruttura richiede mesi.

Inventario e classificazione dei prodotti

Dovete disporre di un elenco completo di ogni prodotto con elementi digitali (PED) che immettete sul mercato UE, con la classificazione CRA confermata per ciascun prodotto:

• Classe predefinita: percorso di autovalutazione disponibile
• Classe I importante: valutazione da parte di un organismo notificato richiesta oggi (v. sezione sopra)
• Classe II importante: organismo notificato obbligatorio. Modulo B+C o Modulo H
• Critica: Modulo B+C o garanzia della qualità totale. Può applicarsi la certificazione europea della cybersicurezza

Riferimento per la classificazione: il Regolamento di esecuzione (UE) 2025/2392 (GU 1 dicembre 2025, in vigore dal 21 dicembre 2025) fornisce le descrizioni tecniche delle categorie di prodotti degli Allegati III e IV. Usatelo per risolvere i casi limite.

Infrastruttura SBOM

Non potete segnalare una vulnerabilità attivamente sfruttata entro 24 ore se non sapete quali componenti contiene il vostro prodotto. La generazione di SBOM deve essere operativa prima di settembre 2026.

• Formato: CycloneDX o SPDX. Entrambi sono accettati ai sensi del CRA. Scegliete uno e standardizzate su tutti i prodotti.
• Ambito: dipendenze transitive, non solo dipendenze dirette. La visibilità completa dei componenti è richiesta per la valutazione del rischio dell'Allegato VII.
• Archiviazione: con controllo di versione, collegata alle release del prodotto. Ogni SBOM deve corrispondere a una build specifica.
• Integrazione: nella pipeline CI/CD. Un'esportazione una tantum non soddisfa l'obbligo continuativo.

Monitoraggio delle vulnerabilità

Il conteggio delle 24 ore inizia dalla consapevolezza: certezza ragionevole a seguito di una valutazione iniziale. La conferma forense non è richiesta per far scattare il conteggio. Dovete disporre di un monitoraggio in grado di produrre quella valutazione iniziale prima che la scadenza scorra.

• Iscrivetevi a NVD, OSV e agli advisory rilevanti dei fornitori per lo stack di componenti utilizzato
• Automatizzate la scansione sui componenti SBOM
• Documentate il percorso interno di escalation e testatelo end-to-end
• Redigete i modelli di notifica ora, prima che la piattaforma ENISA sia disponibile

Checklist di stato prima dell'11 settembre 2026

INVENTARIO PRODOTTI (inizia da qui — la classificazione determina il percorso di conformità):
[ ] Elenco completo dei PED venduti nell'UE con classificazione CRA confermata per ciascun prodotto
[ ] Classe I importante: contatto con un organismo di valutazione della conformità avviato ora;
    la designazione formale degli ON non apre fino a giugno 2026; attendere mette a rischio
    il completamento della valutazione entro dicembre 2027
[ ] Periodo di supporto dichiarato in base alla durata prevista (Art. 13(8))

BASE SBOM (inizia qui — alimenta il monitoraggio, il fascicolo tecnico e la segnalazione a 24 ore):
[ ] Generazione SBOM integrata nella CI/CD — un'esportazione una tantum non è sufficiente
[ ] Formato standardizzato: CycloneDX o SPDX
[ ] Copertura delle dipendenze transitive verificata — le sole dipendenze dirette non bastano
[ ] SBOM con controllo di versione e collegati a release specifiche del prodotto

MONITORAGGIO VULNERABILITÀ (deve essere attivo prima dell'11 settembre):
[ ] Monitoraggio attivo per tutti i prodotti: NVD, OSV, advisory dei fornitori
[ ] Scansione automatizzata sui componenti SBOM attiva
[ ] Percorso interno di escalation documentato e testato end-to-end
[ ] Copertura 24/7 confermata, inclusi festività e fine settimana

PREPARAZIONE ALLA SEGNALAZIONE (piattaforma ENISA non ancora disponibile — preparate tutto il resto ora):
[ ] Modelli di notifica a 24h, 72h, 14 giorni e 30 giorni redatti in base all'Art. 14(2)
[ ] Coordinatore CSIRT dello Stato membro identificato (per l'Italia: CSIRT Italia / ACN)
[ ] Persona autorizzata ad attivare una notifica a 24 ore designata e raggiungibile a qualsiasi ora

DOCUMENTAZIONE:
[ ] Documentazione tecnica verificata rispetto all'Allegato VII
[ ] Analisi delle lacune completata
[ ] Valutazione del rischio in corso

Art. 14: cosa richiede la segnalazione dall'11 settembre 2026

Dall'11 settembre 2026, dovete segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi a due destinatari simultaneamente: il coordinatore CSIRT designato nel vostro Stato membro e ENISA tramite la Piattaforma unica di segnalazione (Art. 16).

Quando inizia il conteggio delle 24 ore? Le linee guida provvisorie della Commissione (3 marzo 2026) precisano: al momento della consapevolezza, intesa come certezza ragionevole a seguito di una valutazione iniziale. La conferma forense non è richiesta. La presenza di prove credibili di uno sfruttamento attivo è sufficiente ad attivare la finestra di 24 ore.

Esenzione per le PMI: l'Art. 64(10)(a) esenta le microimprese e le piccole imprese dalle sanzioni per il mancato rispetto dei termini di 24 ore e di prima notifica di cui all'Art. 14(2)(a) e 14(4)(a). L'esenzione riguarda solo i requisiti temporali, non l'obbligo di segnalazione in sé.

Cosa significa "attivamente sfruttata"

L'Art. 14(2)(a) si applica quando vi sono prove credibili che un attore malevolo abbia sfruttato la vulnerabilità in un sistema senza il consenso del proprietario. Gli indicatori includono:

• Attacchi confermati in circolazione
• Sfruttamento segnalato in feed di threat intelligence o da ricercatori di sicurezza
• Rilevamento in honeypot con prove di impiego attivo

Le linee guida provvisorie della Commissione (Ares(2026)2319816) usano come standard "prove credibili di sfruttamento attivo". La soglia è più bassa rispetto alla conferma forense.

Checklist di prontezza alla segnalazione

INFRASTRUTTURA DI SEGNALAZIONE (prima dell'11 settembre 2026):
[ ] Modelli di notifica predisposti: formati a 24h, 72h, 14 giorni e 30 giorni
[ ] Coordinatore CSIRT dello Stato membro identificato — è il punto di invio principale
    insieme a ENISA (per l'Italia: CSIRT Italia operativo presso ACN)
[ ] Percorso di escalation 24/7 attivo, inclusa la copertura festiva e i contatti di riserva
[ ] Revisione legale degli obblighi dell'Art. 14 completata

GESTIONE DELLE VULNERABILITÀ:
[ ] Monitoraggio attivo operativo per tutti i prodotti
[ ] Integrazione CVE/NVD attiva
[ ] Modelli di notifica ai clienti pronti

COORDINAMENTO DEL TEAM:
[ ] Team di sicurezza formato sugli obblighi dell'Art. 14 e sulla sequenza a quattro livelli
[ ] Escalation verso il management documentata
[ ] Team legale informato sugli obblighi di segnalazione
[ ] Comunicazione PR predisposta per le divulgazioni pubbliche

Conformità piena entro l'11 dicembre 2027

Requisiti essenziali di cybersicurezza (Allegato I)

Ogni PED conforme deve dimostrare:

Sicurezza by design

• Livello di sicurezza proporzionato al rischio (Allegato I, Parte I, §1)
• Protezione contro l'accesso non autorizzato
• Riservatezza, integrità e disponibilità di dati e funzioni essenziali
• Superficie di attacco minima, impostazioni predefinite sicure, assenza di credenziali hard-coded o predefinite

Processo di gestione delle vulnerabilità

• Processo documentato per l'identificazione e la gestione delle vulnerabilità
• Aggiornamenti di sicurezza tempestivi e gratuiti per tutta la durata del periodo di supporto
• Politica di divulgazione coordinata delle vulnerabilità (Art. 13(6))

Capacità di aggiornamento

• Meccanismo di aggiornamento sicuro e affidabile
• Possibilità di separare gli aggiornamenti di sicurezza dagli aggiornamenti di funzionalità

Documentazione tecnica (Allegato VII)

Periodo di supporto: due obblighi distinti

Il CRA impone due obblighi distinti in materia di aggiornamenti di sicurezza.

Art. 13(8): dovete rilasciare aggiornamenti di sicurezza per un minimo di 5 anni dalla data di immissione del prodotto sul mercato, oppure per la durata prevista del prodotto se inferiore. I 5 anni sono un minimo. Un prodotto con una durata prevista di 10 anni richiede un periodo di supporto di 10 anni.

Art. 13(9): ogni aggiornamento di sicurezza rilasciato deve rimanere disponibile per il download per un minimo di 10 anni dalla data di rilascio, o per la durata residua del periodo di supporto, a seconda di quale sia maggiore.

Questi sono obblighi indipendenti. Un aggiornamento rilasciato nel quarto anno di un periodo di supporto di 5 anni deve rimanere scaricabile fino al quattordicesimo anno dal rilascio. Chi elimina i pacchetti di aggiornamento precedenti o lascia scadere l'infrastruttura di distribuzione viola l'Art. 13(9) anche rilasciando nuovi aggiornamenti nei tempi previsti. Pianificate l'infrastruttura di archiviazione e distribuzione per il lungo periodo prima di rilasciare il primo aggiornamento ai sensi del CRA.

Checklist della conformità piena

CONFORMITÀ DEL PRODOTTO:
[ ] Tutti i prodotti soddisfano i requisiti dell'Allegato I: sicurezza by design,
    gestione delle vulnerabilità e capacità di aggiornamento
[ ] Valutazioni della conformità completate: processo ON concluso per Classe I/II importante
[ ] Marcatura CE applicata
[ ] Dichiarazione di conformità UE predisposta ai sensi dell'Art. 28

FASCICOLO TECNICO (Allegato VII):
[ ] Valutazione del rischio completa e documentata
[ ] SBOM aggiornato e validato
[ ] Prove di conformità organizzate e accessibili
[ ] Periodo di supporto dichiarato ai sensi dell'Art. 13(8) e della durata prevista

CATENA DI MERCATO:
[ ] Importatori e distributori informati dei propri obblighi CRA
[ ] Documentazione rivolta ai clienti aggiornata

OBBLIGHI CONTINUATIVI:
[ ] Art. 13(8): processo di aggiornamenti di sicurezza attivo per tutta la durata del periodo di supporto
[ ] Art. 13(9): infrastruttura di disponibilità degli aggiornamenti in essere (10 anni da ciascun rilascio)
[ ] Monitoraggio delle vulnerabilità attivo e testato
[ ] Risposta agli incidenti verificata almeno ogni trimestre

Linee guida della Commissione: bozza di marzo 2026

La Commissione ha pubblicato una bozza di comunicazione di circa 70 pagine (Ares(2026)2319816) il 3 marzo 2026. La consultazione con le parti interessate si è chiusa il 31 marzo 2026. Il documento non è ancora definitivo. La versione finale è in attesa di tutte le versioni linguistiche dell'UE. Per un'analisi completa, v. la nostra guida alle linee guida della Commissione sul CRA.

Decisioni chiave rilevanti per il calendario:

Test RDPS per l'ambito SaaS: il software per l'elaborazione remota dei dati rientra nell'ambito del CRA solo se supera un test in tre parti. Il software esegue l'elaborazione remota dei dati. Tale elaborazione è necessaria per la funzione principale del prodotto. Il fabbricante controlla l'elaborazione remota. Il SaaS che non supera questo test è escluso dall'ambito.

Prodotti esistenti: la ricostruzione della documentazione storica non è richiesta. Dovete effettuare una valutazione del rischio attuale. Le famiglie di prodotti possono essere raggruppate ai fini della valutazione del rischio.

Aggiornamenti software: un aggiornamento non costituisce una "modifica sostanziale" che comporta una nuova valutazione della conformità, a meno che non introduca nuovi vettori di minaccia o modifichi la finalità prevista del prodotto. Le linee guida forniscono un test in quattro domande.

Conteggio delle 24 ore: inizia dalla consapevolezza, intesa come certezza ragionevole a seguito di una valutazione iniziale. La conferma forense non è richiesta.

Minimo del periodo di supporto: 5 anni è un minimo, non un valore predefinito. Il periodo di supporto deve riflettere la durata prevista del prodotto. Un prodotto con durata prevista di 10 anni richiede un periodo di supporto di 10 anni.

Open source: la pubblicazione del codice sorgente non costituisce immissione di un prodotto sul mercato. I contributori che non controllano il rilascio di un prodotto finito non sono fabbricanti ai sensi del CRA.

Annuncio ufficiale: https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act

Sanzioni

L'Art. 64(2) del Regolamento (UE) 2024/2847 fissa la sanzione massima a 15 milioni di euro o al 2,5% del fatturato mondiale annuo totale, se superiore, per:

• La non conformità ai requisiti essenziali di cybersicurezza dell'Allegato I e agli obblighi dell'Art. 13
• Il mancato rispetto degli obblighi dell'Art. 14 (segnalazione di vulnerabilità e incidenti)

Entrambe le violazioni, ossia immettere sul mercato un prodotto non conforme e non segnalare una vulnerabilità attivamente sfruttata, si collocano nello stesso livello sanzionatorio. Non esiste un livello inferiore per le violazioni di segnalazione.

L'Art. 64(3) (10 milioni di euro o 2%) riguarda un insieme separato di obblighi: Artt. 18-23, 28, 30-33, 39, 41, 47, 49, 53, principalmente obblighi di importatori, distributori e organismi notificati. L'Art. 14 non è in questo elenco.

Esenzione per le PMI: l'Art. 64(10)(a) esenta le microimprese e le piccole imprese dalle sanzioni per il mancato rispetto di specifici requisiti temporali di cui all'Art. 14(2)(a) e 14(4)(a). L'esenzione riguarda le tempistiche, non la sostanza dell'obbligo di segnalazione.

Note per settore

Elettronica di consumo

L'automazione SBOM è l'investimento iniziale con il miglior rapporto costo/beneficio. Alimenta direttamente il monitoraggio delle vulnerabilità e la generazione del fascicolo tecnico. I prodotti di consumo hanno tipicamente catene di fornitura complesse con più fornitori di componenti.

La gestione degli aggiornamenti firmware su grandi parchi di dispositivi richiede un'infrastruttura OTA. Un aggiornamento rilasciato nel terzo anno di vita di un prodotto deve rimanere scaricabile per 10 anni dalla data di rilascio (Art. 13(9)). Pianificate l'infrastruttura di distribuzione ora, non al momento del rilascio.

Editori di software

Segnalare le vulnerabilità è l'obbligo operativamente più oneroso per i prodotti software. I tassi di individuazione sono più elevati e tracciare le dipendenze a livello transitivo negli stack moderni non è banale. Integrate la generazione SBOM nelle pipeline CI/CD esistenti: alimenta direttamente il flusso di monitoraggio e risposta.

Apparecchiature industriali

I cicli di vita del prodotto lunghi, da 10 a 20 anni, interagiscono direttamente con il minimo di 5 anni per il periodo di supporto (Art. 13(8)) e con il requisito di disponibilità degli aggiornamenti per 10 anni per rilascio (Art. 13(9)). Un prodotto con una durata prevista di 20 anni richiede un impegno di supporto ventennale.

I prodotti industriali rientrano spesso nella Classe I o II importante, il che comporta oggi la valutazione da parte di un organismo notificato. Contattate subito gli organismi di valutazione della conformità. Il processo formale di designazione degli ON si apre dopo giugno 2026 e la capacità sarà limitata almeno fino a dicembre 2026.

Dispositivi IoT

L'eliminazione delle credenziali predefinite è un requisito vincolante (Allegato I, Parte I, §2(e)). Affrontatelo per primo: è una violazione evidente dell'Allegato I ed è relativamente contenuta da correggere. I meccanismi di aggiornamento sicuro per dispositivi con risorse limitate richiedono un intervento architetturale. Partite dalle credenziali, poi affrontate gli aggiornamenti.

Prossimi passi

Gestite la conformità CRA su più prodotti? CRA Evidence traccia la prontezza all'Articolo 14, la copertura SBOM e lo stato di valutazione della conformità su tutto il vostro portafoglio.

Dopo aver confermato la classificazione dei prodotti, costruite l'infrastruttura SBOM con la nostra guida ai requisiti SBOM. Consultate la nostra guida alla segnalazione delle vulnerabilità a ENISA per il processo di notifica a 24 ore da avere operativo prima di settembre 2026.

Questo articolo ha scopo puramente informativo e non costituisce consulenza legale. Per una guida specifica in materia di conformità, consultare un legale qualificato.