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

Al 30 maggio 2026, nessun organismo notificato risulta designato ai sensi del CRA. Nessuna norma armonizzata è stata pubblicata nella Gazzetta Ufficiale. La piattaforma di segnalazione ENISA non esiste ancora. Mancano circa 3,4 mesi all'applicazione dell'Articolo 14, l'11 settembre 2026.

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.

Tre ostacoli non aggirabili

Nessuna norma armonizzata

L'Articolo 32(2) prevede tre percorsi di conformità per la Classe I importante: autovalutazione, valutazione di terze parti basata su norme armonizzate o specifiche comuni, oppure valutazione da parte di un organismo notificato. Il percorso intermedio richiede norme armonizzate CRA. Ma nessuna norma armonizzata CRA è stata pubblicata nella Gazzetta Ufficiale. Al 30 maggio 2026:

• 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'Articolo 27(2).
• Nessun atto delegato ex Articolo 27(9) designa alcuno schema europeo di certificazione della cibersicurezza come percorso di presunzione di conformità al CRA.

Dove le norme non esistono, l'Articolo 32(2) richiede 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 attiva l'11 giugno 2026. L'obiettivo della Commissione è disporre di una capacità sufficiente di organismi notificati entro l'11 dicembre 2026 (Articolo 35(2), impegno di diligenza). Al 30 maggio 2026 nessun organismo notificato designato ai sensi del CRA è elencato nello Spazio unico di conformità del mercato interno.

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 fino all'apertura della designazione formale dopo giugno 2026.

Contatti subito gli organismi di valutazione della conformità. Il meccanismo formale non apre prima della metà del 2026. Aspettare fino ad allora rende improbabile completare la valutazione entro dicembre 2027.

Nessuna piattaforma di segnalazione ENISA

La Piattaforma unica di segnalazione prevista dall'Articolo 16 non è disponibile al 30 maggio 2026. ENISA ha assegnato l'appalto a un fornitore. La piattaforma è prevista in apertura prima dell'11 settembre 2026. Non sono stati pubblicati né URL di registrazione né istruzioni per i fabbricanti.

Cosa può fare adesso:

• Redigere i modelli di notifica in base ai requisiti di formato dell'Articolo 14: notifiche a 24 ore e 72 ore, una relazione finale di vulnerabilità a 14 giorni e una 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à.

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

Cosa deve essere pronto prima dell'11 settembre 2026

Mancano circa 3,4 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 o Modulo H.
• 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 designazione degli ON non apre prima di giugno 2026; aspettare significa
    superare dicembre 2027
[ ] Periodo di supporto dichiarato in base alla durata prevista del prodotto (Art. 13(8))

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 in base all'Art. 14
[ ] 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

Articolo 14: 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 (Articolo 16).

Esenzione per le PMI: l'Articolo 64(10)(a) esenta le microimprese e le piccole imprese dalle sanzioni per il mancato rispetto dei requisiti temporali dell'Articolo 14(2)(a) e 14(4)(a). L'esenzione riguarda solo le tempistiche. L'obbligo di segnalazione in sé continua ad applicarsi.

Cosa significa «attivamente sfruttata»

L'Articolo 14(2)(a) si applica 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 dell'Art. 14 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 dell'Articolo 14 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à (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.

Articolo 13(8): 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.

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

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 viola l'Articolo 13(9), 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 (Art. 13(8))

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

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

Sanzioni

L'Articolo 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 cibersicurezza dell'Allegato I e agli obblighi dell'Articolo 13.
• Il mancato rispetto degli obblighi dell'Articolo 14 (segnalazione di vulnerabilità e incidenti).

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

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

Esenzione per le PMI: l'Articolo 64(10)(a) esenta le microimprese e le piccole imprese dalle sanzioni per il mancato rispetto di specifici requisiti temporali di cui all'Articolo 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 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 (Articolo 13(9)). 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 cicli di vita lunghi (da 10 a 20 anni) interagiscono direttamente con il limite minimo di cinque anni del periodo di supporto (Articolo 13(8)) e con il requisito di disponibilità degli aggiornamenti di 10 anni per rilascio (Articolo 13(9)). Un prodotto con una durata prevista di 20 anni può richiedere un impegno di supporto di 20 anni.

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à. Il processo formale di designazione degli ON 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)). 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.