Scadenze CRA 2026 e 2027: cosa è dovuto e cosa è bloccato

Al 12 luglio 2026, NANDO non mostra alcun organismo notificato designato ai sensi del CRA. Nessuna norma armonizzata CRA è stata pubblicata nella Gazzetta Ufficiale. La piattaforma di segnalazione ENISA deve essere operativa l'11 settembre 2026. Restano circa due mesi all'obbligo di segnalazione di vulnerabilità e incidenti.

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

Calendario in sintesi

Stato di fatto al 12 luglio 2026, rispetto alle due date cardine che vincolano i fabbricanti.

Riferimento date

Tre ostacoli non aggirabili

Nessuna norma armonizzata

I fabbricanti di Classe I importante hanno tre percorsi di conformità: autovalutazione, valutazione di terze parti basata su norme armonizzate o specifiche comuni, oppure valutazione da parte di un organismo notificato. I primi due dipendono da norme o specifiche non ancora disponibili. Al 12 luglio 2026:

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

Dove le norme non esistono, la via di riserva è il Modulo B+C (esame UE del tipo) o il Modulo H (garanzia della qualità totale). Entrambi richiedono un organismo notificato.

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

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 e altri): bozze mature, non ancora in consultazione pubblica.

Prima citazione realistica nella Gazzetta Ufficiale: 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 di organismi notificati entro l'11 dicembre 2026, ma è un obiettivo di migliori sforzi, non una garanzia per categoria di prodotto. Al 12 luglio 2026 nessun organismo notificato designato ai sensi del CRA è elencato nello NANDO.

Se ha bisogno di completare una valutazione di Classe I importante prima di dicembre 2027, calcoli:

• 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 ora che la designazione formale è aperta.

Contatti subito gli organismi di valutazione della conformità. Il meccanismo formale è aperto, anche se la capacità CRA non risulta ancora in NANDO. Aspettare fino ad allora rende improbabile completare la valutazione entro dicembre 2027.

Nessuna piattaforma di segnalazione ENISA

La Piattaforma unica di segnalazione non è disponibile al 12 luglio 2026. ENISA ha assegnato l'appalto a un fornitore. La piattaforma deve essere operativa entro l'11 settembre 2026. ENISA sta pubblicando istruzioni operative e materiale di formazione nel giugno 2026.

Cosa può fare adesso:

• Redigere i modelli di notifica per le quattro fasi: 24 ore, 72 ore, relazione finale di vulnerabilità a 14 giorni e relazione finale di incidente grave a un mese.
• Identificare il coordinatore CSIRT designato del proprio Stato membro.
• Definire chi internamente è autorizzato ad attivare una notifica a 24 ore nel fine settimana o durante una festività.

Apri la pagina della Piattaforma unica di segnalazione di ENISA.

Cosa deve essere pronto prima dell'11 settembre 2026

Restano circa due mesi. Se le voci seguenti non sono completate, non è in ritardo su singoli compiti. È in ritardo sull'infrastruttura, e l'infrastruttura richiede mesi.

Inventario e classificazione dei prodotti

Le serve un elenco completo di ogni prodotto con elementi digitali (PED) che immette 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 (vedi sopra).
• Classe II importante: organismo notificato obbligatorio. Modulo B+C, Modulo H o uno schema di certificazione applicabile con livello di affidabilità almeno sostanziale.
• Critica: Modulo B+C o garanzia della qualità totale. Può applicarsi anche la certificazione europea della cibersicurezza.

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. Lo utilizzi per risolvere i casi limite.

Infrastruttura SBOM

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

• Formato: CycloneDX o SPDX. Entrambi sono accettati ai sensi del CRA. Ne scelga uno e standardizzi 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. Le serve un monitoraggio in grado di produrre quella valutazione iniziale prima che la scadenza scorra.

• Si iscriva a NVD, OSV e agli advisory rilevanti dei fornitori per il suo stack di componenti.
• Automatizzi la scansione sui componenti SBOM.
• Documenti il percorso interno di escalation e lo testi end-to-end.
• Rediga ora i modelli di notifica, prima del lancio della piattaforma ENISA.

Checklist pre-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 prodotto
[ ] Prodotti di Classe I importante: organismo di valutazione della conformità contattato
    ora. La notifica formale CRA è aperta, ma NANDO non elenca ancora organismi designati;
    aspettare che la capacità maturi significa superare dicembre 2027
[ ] Periodo di supporto dichiarato in base alla durata prevista del prodotto

SBOM (inizia da qui: alimenta monitoraggio, fascicolo tecnico e segnalazione a 24 ore):
[ ] Generazione SBOM integrata nella pipeline CI/CD: un'esportazione una tantum non basta
[ ] 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 percorsi per festività e fine settimana

PREPARAZIONE ALLA SEGNALAZIONE (piattaforma ENISA non ancora disponibile: predisporre tutto il resto ora):
[ ] Modelli a 24 ore, 72 ore, vulnerabilità a 14 giorni e incidente a un mese redatti
[ ] Coordinatore CSIRT dello Stato membro identificato
[ ] 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

Cosa richiede la segnalazione dall'11 settembre 2026

Dall'11 settembre 2026, deve segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi a due destinatari simultaneamente: il coordinatore CSIRT designato del suo Stato membro ed ENISA tramite la Piattaforma unica di segnalazione.

Cosa significa «attivamente sfruttata»

Il termine di 24 ore si attiva quando vi sono prove credibili che un attore di minaccia abbia sfruttato la vulnerabilità in un sistema senza il consenso del proprietario. Gli indicatori includono:

• Attacchi confermati osservati 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, 3 marzo 2026) usano come standard «prove credibili di sfruttamento attivo». La soglia è inferiore alla conferma forense.

Checklist di prontezza Fase 2

INFRASTRUTTURA DI SEGNALAZIONE (prima dell'11 settembre 2026):
[ ] Modelli di notifica predisposti: formati a 24 ore, 72 ore, vulnerabilità a 14 giorni e incidente a un mese
[ ] Coordinatore CSIRT dello Stato membro identificato: è il punto di invio principale
    insieme a ENISA
[ ] Percorso di escalation 24/7 confermato, inclusa la copertura festiva e i contatti di riserva
[ ] Revisione legale degli obblighi di segnalazione completata

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

PRONTEZZA DEL TEAM:
[ ] Team di sicurezza formato sugli obblighi di segnalazione e sulla sequenza a quattro livelli
[ ] Escalation verso il management documentata
[ ] Team legale informato sugli obblighi di segnalazione
[ ] Comunicazione predisposta per le divulgazioni pubbliche

Conformità piena entro l'11 dicembre 2027

Requisiti essenziali di cibersicurezza (Allegato I)

Ogni PED conforme deve soddisfare questi requisiti:

Sicurezza by design

• Livello di sicurezza proporzionato ai rischi del prodotto (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.

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à.

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.

Durata del supporto: deve rilasciare aggiornamenti di sicurezza per un minimo di cinque anni dalla data di immissione del prodotto sul mercato, oppure per la durata prevista del prodotto se inferiore. Cinque anni sono il limite minimo, non il valore predefinito. Un prodotto con una durata prevista di 10 anni richiede un periodo di supporto di 10 anni.

Disponibilità degli aggiornamenti: 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.

Sono obblighi indipendenti. Un aggiornamento rilasciato nel quarto anno di un periodo di supporto di cinque anni deve rimanere scaricabile fino al quattordicesimo anno dal rilascio. Eliminare i pacchetti di aggiornamento precedenti o lasciare scadere l'infrastruttura di distribuzione può violare la regola di disponibilità, anche rilasciando nuovi aggiornamenti nei tempi previsti. Pianifichi l'infrastruttura di archiviazione e distribuzione per il lungo periodo prima di rilasciare il primo aggiornamento ai sensi del CRA.

Checklist dicembre 2027

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 e Classe II importante
[ ] Marcatura CE applicata
[ ] Dichiarazione UE di conformità 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 in base alla durata prevista del prodotto

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

OBBLIGHI CONTINUATIVI:
[ ] Processo di aggiornamenti di sicurezza attivo per tutta la durata del periodo di supporto
[ ] 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 (Ares(2026)2319816) il 3 marzo 2026, di circa 70 pagine. La consultazione con le parti interessate si è chiusa il 31 marzo 2026. Il documento non è ancora finale. Le versioni linguistiche definitive sono in attesa. Per un'analisi completa, vedi 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 tre condizioni. Il software esegue l'elaborazione remota dei dati. L'elaborazione remota è necessaria per la funzione principale del prodotto. E il fabbricante controlla l'elaborazione remota. Il SaaS che non supera questo test è fuori dall'ambito.

Prodotti esistenti: la ricostruzione della documentazione storica non è richiesta. Serve 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 attiva 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. La certezza ragionevole a seguito di una valutazione iniziale è sufficiente. La conferma forense non è richiesta.

Limite minimo del periodo di supporto: cinque anni sono un minimo, non un valore predefinito. Il periodo di supporto deve riflettere la durata prevista del prodotto.

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.

Leggi l'annuncio della Commissione.

Sanzioni

Il livello sanzionatorio massimo del CRA è 15 milioni di euro o il 2,5% del fatturato mondiale annuo totale, se superiore. Si applica a:

• La non conformità ai requisiti essenziali di cibersicurezza e agli obblighi del fabbricante.
• Il mancato rispetto degli obblighi di segnalazione di vulnerabilità e incidenti.

Entrambe le violazioni si collocano nello stesso livello sanzionatorio. Non esiste un livello inferiore per le violazioni di segnalazione.

Note per settore

Elettronica di consumo

L'automazione SBOM è l'investimento iniziale con il miglior rapporto valore/costo. 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. Pianifichi l'infrastruttura di distribuzione ora, non al momento del rilascio.

Editori di software

La segnalazione di 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 è semplice. Integri la generazione SBOM nelle pipeline CI/CD esistenti. Alimenta direttamente il monitoraggio e il flusso di risposta.

Apparecchiature industriali

I prodotti industriali rientrano spesso nella Classe I o II importante, il che oggi comporta la valutazione da parte di un organismo notificato. Contatti subito gli organismi di valutazione della conformità. La notifica formale CRA è aperta, ma NANDO non elenca ancora organismi designati; la capacità resterà limitata almeno fino a dicembre 2026.

Dispositivi IoT

L'eliminazione delle credenziali predefinite è un requisito vincolante (Allegato I, Parte I, §2(e)). Lo affronti per primo. È una violazione evidente dell'Allegato I e relativamente contenuta da correggere rispetto a modifiche architetturali. I meccanismi di aggiornamento sicuro per dispositivi con risorse limitate richiedono più lavoro. Inizi dalle credenziali, poi affronti gli aggiornamenti.