Il Cyber Resilience Act UE: 77 giorni per prepararsi alla scadenza di settembre 2026

Il conto alla rovescia è già iniziato

Il Cyber Resilience Act UE (CRA) non è più un orizzonte normativo lontano — è un conto alla rovescia. L'11 settembre 2026, la prima scadenza vincolante del CRA entra in vigore: i fabbricanti e sviluppatori di prodotti con elementi digitali devono iniziare a segnalare all'ENISA e ai CSIRT nazionali le vulnerabilità attivamente sfruttate. Mancano 77 giorni.

Se la vostra organizzazione sviluppa software, commercializza hardware connesso o integra componenti digitali di terze parti in prodotti distribuiti nei mercati UE, questa scadenza vi riguarda. Il CRA introduce obblighi che si estendono alla vostra pipeline di sviluppo, alle relazioni con i fornitori, al processo di risposta agli incidenti e alla governance esecutiva.

Questa guida spiega cosa richiede la scadenza di settembre, chi è nell'ambito di applicazione, quali sanzioni si applicano e i passi pratici da compiere adesso — prima che le autorità di regolamentazione inizino a fare domande.

Cos'è il Cyber Resilience Act UE?

Il CRA è entrato in vigore nel dicembre 2024 dopo anni di lavoro legislativo, innescato da una serie di incidenti — SolarWinds, Log4Shell, MOVEit — che hanno evidenziato il rischio sistemico delle catene di fornitura software insicure. A differenza del GDPR (che disciplina i dati) o di NIS2 (che disciplina le operazioni), il CRA prende di mira i prodotti stessi: impone requisiti obbligatori di cybersicurezza a qualsiasi prodotto con elementi digitali (PED) immesso sul mercato UE, coprendo l'intero ciclo di vita del prodotto dalla progettazione alla fine vita.

Il principio centrale del CRA è la sicurezza per impostazione predefinita: i prodotti devono essere consegnati sicuri, senza che il cliente debba configurare separatamente la sicurezza. Questo sposta la responsabilità a monte — verso sviluppatori e fabbricanti — anziché lasciarla all'utente finale.

Distinzione fondamentale: Il GDPR protegge i dati. NIS2 protegge le operazioni. Il CRA protegge i prodotti software e hardware stessi, dal momento della loro progettazione fino alla dismissione.

La scadenza dell'11 settembre 2026: cosa cambia

Il CRA è introdotto per fasi. L'11 settembre 2026 attiva gli obblighi di segnalazione delle vulnerabilità — il requisito operativamente più urgente per la maggior parte delle organizzazioni oggi. Da quella data, qualsiasi vulnerabilità attivamente sfruttata che riguarda il vostro prodotto innesca una rigorosa cascata di notifiche.

Due aspetti di questa tempistica meritano particolare attenzione. In primo luogo, la finestra di 24 ore inizia dal momento in cui la vostra organizzazione viene a conoscenza dello sfruttamento attivo — non dall'assegnazione di un CVE o dalla divulgazione pubblica. Il rilevamento delle minacce e l'allerta interna diventano quindi controlli di conformità diretti. I ritardi nel rilevamento si traducono direttamente in esposizione legale.

In secondo luogo, questo si applica a qualsiasi vulnerabilità attivamente sfruttata — senza soglie di gravità. Un bug a bassa gravità attivamente sfruttato deve essere segnalato entro 24 ore. Una vulnerabilità critica non ancora sfruttata non avvia l'orologio. Il fattore scatenante è lo sfruttamento, non la gravità.

Chi è nell'ambito di applicazione?

L'ambito di applicazione del CRA è intenzionalmente ampio. Le seguenti categorie di organizzazioni sono direttamente interessate:

Fabbricanti

Qualsiasi organizzazione che progetta, sviluppa o produce prodotti con elementi digitali e li immette sul mercato UE. Ciò include software aziendale, applicazioni consumer, hardware connesso, sistemi di controllo industriale, firmware incorporato e apparecchiature di rete.

Fornitori di Software-as-a-Service

Il CRA affronta esplicitamente i prodotti digitali forniti da remoto. I fornitori SaaS rientrano nell'ambito quando i loro servizi includono componenti che si qualificano come prodotti con elementi digitali — in particolare quando tali componenti possono essere scaricati, installati o aggiornati sui sistemi del cliente. Se la vostra offerta SaaS include un agente desktop, un'applicazione mobile, un connettore on-premise o un SDK, tali componenti ricadono nel quadro CRA.

Importatori e distributori

Le organizzazioni che importano o distribuiscono prodotti con elementi digitali nei mercati UE devono verificare che i fabbricanti con cui lavorano abbiano soddisfatto i requisiti CRA. Se un fabbricante non adempie, distributori e importatori hanno obblighi residui.

Progetti open source

I progetti open source puramente senza scopo di lucro senza attività commerciale sono generalmente esenti. Tuttavia, se la vostra organizzazione commercializza software open source — tramite contratti di supporto, servizi ospitati, prodotti integrati o SaaS costruiti su componenti open source — non siete esenti.

Test pratico: Se la vostra organizzazione genera ricavi da un prodotto che include o è costruito su elementi digitali, e tale prodotto è accessibile a clienti UE, il CRA si applica.

I requisiti di dicembre 2027: pianificare in anticipo

L'11 settembre 2026 è la prima ondata. Il peso completo degli obblighi CRA arriva l'11 dicembre 2027. I 18 mesi tra le due scadenze devono essere utilizzati per i requisiti strutturalmente più complessi.

Distinta base del software (SBOM)

I fabbricanti devono mantenere e mettere a disposizione una distinta base del software — un inventario leggibile da macchina di ogni componente software, libreria, dipendenza e versione inclusa in un prodotto. La SBOM deve essere tenuta aggiornata per tutta la durata di vita supportata del prodotto.

Sicurezza nella progettazione

I prodotti devono essere progettati con la superficie di attacco minima necessaria, configurazioni sicure per impostazione predefinita, controlli di accesso appropriati, crittografia dei dati in transito e a riposo e la capacità di ricevere aggiornamenti di sicurezza per tutta la loro durata di vita supportata.

Programma di gestione delle vulnerabilità

I fabbricanti devono gestire un programma formale di gestione delle vulnerabilità: politiche di identificazione, valutazione e rimediazione; processi di divulgazione coordinata delle vulnerabilità; e registrazioni che dimostrino una gestione continua per tutta la durata di vita del prodotto.

Le sanzioni: cosa è in gioco

I meccanismi di applicazione del CRA sono calibrati per essere significativi:

• Fino a 15 milioni di euro o il 2,5% del fatturato annuo mondiale — per mancato rispetto dei requisiti essenziali di cybersicurezza o degli obblighi di gestione delle vulnerabilità
• Fino a 10 milioni di euro o il 2% del fatturato annuo mondiale — per mancato adempimento degli obblighi di segnalazione delle vulnerabilità attivamente sfruttate
• Fino a 5 milioni di euro o l'1% del fatturato annuo mondiale — per fornitura di informazioni false o fuorvianti alle autorità di vigilanza del mercato

Oltre alle sanzioni finanziarie, le autorità nazionali di vigilanza del mercato possono ordinare il ritiro o il richiamo di prodotti non conformi dai mercati UE. Per le organizzazioni il cui fatturato dipende dall'accesso al mercato UE, questo è un rischio esistenziale per la continuità operativa.

Implicazione di governance: Come per NIS2 e DORA, le violazioni del CRA possono innescare un esame delle decisioni esecutive. I consigli di amministrazione devono trattare la conformità al CRA come una responsabilità fiduciaria.

Il CRA nel quadro normativo più ampio

Il CRA non opera in isolamento. È uno dei tre principali regolamenti digitali UE che entrano in fase di applicazione attiva nel 2026, insieme a NIS2 (che sta già emettendo sanzioni amministrative) e DORA (applicato al settore finanziario dal 17 gennaio 2025). Un singolo incidente può innescare obblighi simultanei sotto più quadri normativi.

• Gli stessi CSIRT nazionali ricevono sia le segnalazioni di vulnerabilità CRA che le notifiche di incidenti NIS2. Per le organizzazioni nell'ambito di entrambi i quadri, lo stesso evento di sfruttamento potrebbe innescare scadenze di notifica parallele.
• I requisiti DORA di gestione del rischio ICT di terze parti creano obblighi per le entità finanziarie di valutare lo stato di conformità CRA dei loro fornitori. Se fornite software o servizi tecnologici a clienti del settore finanziario, la vostra maturità CRA fa ora parte della loro due diligence fornitori DORA.
• I requisiti di cybersicurezza della legge sull'IA per i sistemi di IA ad alto rischio fanno riferimento ai requisiti essenziali del CRA. Un prodotto di IA che non soddisfa la conformità CRA potrebbe anche non soddisfare la conformità della legge sull'IA.

La vostra checklist di preparazione al CRA in 10 passi

1. Mappatura dell'ambito. Identificate ogni prodotto che la vostra organizzazione progetta, sviluppa, importa o distribuisce che potrebbe qualificarsi come prodotto con elementi digitali. Includete hardware connesso, software, sistemi embedded, SDK e componenti SaaS installati sui sistemi dei clienti.
2. Rilevamento delle minacce e allertamento. Implementate o rafforzate il monitoraggio per rilevare lo sfruttamento attivo di vulnerabilità note che riguardano i vostri prodotti. La finestra di segnalazione di 24 ore inizia nel momento in cui venite a conoscenza dello sfruttamento — la vostra infrastruttura di rilevamento è quindi un controllo di conformità.
3. Registrazione CSIRT e contatti. Identificate e documentate formalmente i canali di notifica del CSIRT nazionale e dell'ENISA per ogni giurisdizione in cui i vostri prodotti sono immessi sul mercato. In Lussemburgo, l'autorità principale è il CIRCL (Computer Incident Response Center Luxembourg).
4. Aggiornamento del piano di risposta agli incidenti. Rivedete le vostre procedure di risposta agli incidenti per includere i passi di notifica CRA. Definite chi avvia l'allerta precoce di 24 ore, chi approva la notifica di 72 ore e chi firma la relazione finale di 14 giorni.
5. Inventario dei componenti. Iniziate a catalogare tutti i componenti software, le librerie e le dipendenze nei vostri prodotti. Questa è la base della vostra SBOM.
6. Revisione dei contratti con i fornitori. Esaminate i contratti con tutti i fornitori di software e tecnologia i cui componenti compaiono nei vostri prodotti. Aggiungete clausole allineate al CRA che richiedano la divulgazione tempestiva delle vulnerabilità e l'impegno sulle scadenze di patching.
7. Base di documentazione tecnica. Iniziate a raccogliere la documentazione tecnica richiesta dal CRA: descrizioni dell'architettura, modelli di minaccia, risultati dei test di sicurezza e registrazioni della gestione delle vulnerabilità.
8. Formalizzazione del programma di gestione delle vulnerabilità. Stabilite o formalizzate la vostra politica di gestione delle vulnerabilità con processi di rilevamento chiari, triage, scadenze di rimediazione e procedure di divulgazione coordinata.
9. Selezione e sperimentazione degli strumenti SBOM. Valutate gli strumenti di generazione e gestione SBOM adatti al vostro stack tecnologico. Sperimentate l'integrazione nella pipeline CI/CD di almeno un prodotto entro fine anno.
10. Formazione di sviluppatori e dirigenti. Assicuratevi che i team di sviluppo comprendano i principi di sicurezza nella progettazione e che i dirigenti comprendano il quadro normativo e le dimensioni della responsabilità personale.

Come ObsidianCorps può aiutarvi

I nostri team lavorano con organizzazioni in Lussemburgo e nella Grande Regione su programmi di conformità normativa dall'entrata in vigore di NIS2. La preparazione al CRA è un'estensione naturale di questo lavoro — e per molti dei nostri clienti, le basi sono già parzialmente in atto.

Ecco come possiamo accelerare il vostro programma entro l'11 settembre:

• Mappatura dell'ambito CRA e analisi dei gap. Esaminiamo il vostro portafoglio prodotti, le pratiche di sviluppo, le relazioni con i fornitori e l'attuale documentazione di sicurezza rispetto ai requisiti CRA. Ricevete un rapporto di maturità prioritario che identifica i gap da colmare prima di settembre e una roadmap verso dicembre 2027.
• Progettazione del programma di gestione delle vulnerabilità. Vi aiutiamo a costruire o formalizzare le politiche, i processi e gli strumenti per il rilevamento, il triage, la divulgazione e la notifica delle vulnerabilità — inclusa l'integrazione con i workflow di notifica al CSIRT.
• Test di penetrazione e validazione della sicurezza. I test di sicurezza indipendenti dei vostri prodotti forniscono sia le prove tecniche necessarie per la documentazione di conformità sia la visibilità anticipata sulle vulnerabilità.
• Implementazione SBOM e integrazione DevSecOps. I nostri team di sviluppo software e DevSecOps aiutano a integrare la generazione di SBOM nella vostra pipeline CI/CD.
• Preparazione della documentazione tecnica. Vi aiutiamo a raccogliere le descrizioni dell'architettura, i modelli di minaccia e le registrazioni di sicurezza richiesti per la valutazione di conformità al CRA.
• Formazione di sviluppatori e dirigenti. Offriamo programmi di formazione adattati agli obblighi CRA per i team tecnici e il management, inclusi esercizi di simulazione di uno scenario di divulgazione di vulnerabilità nelle scadenze di notifica CRA.

Se non siete sicuri che i vostri prodotti rientrino nell'ambito, o se avete identificato un gap da colmare prima dell'11 settembre, offriamo una consulenza iniziale gratuita. Settantasette giorni sono sufficienti per fare progressi significativi — ma non abbastanza da sprecarli.

Contattate ObsidianCorps per avviare la vostra valutazione di maturità CRA.