Dall’11 settembre 2026 è operativo il primo tassello concreto del Cyber Resilience Act: produttori e operatori interessati devono segnalare vulnerabilità attivamente sfruttate e incidenti gravi. La piena applicazione della normativa arriverà l’11 dicembre 2027. Ma il vero cambiamento è già iniziato: la sicurezza informatica entra formalmente nel ciclo di vita del prodotto digitale. E questo potrebbe avere conseguenze importanti anche per il mercato del software sviluppato senza adeguati processi tecnici e organizzativi.
Non è ancora il Cyber Resilience Act “completo”
Il Cyber Resilience Act, o CRA, è ormai uno dei principali strumenti con cui l’Unione Europea sta cercando di innalzare il livello di sicurezza dei prodotti digitali immessi sul mercato.
Il regolamento europeo 2024/2847 è entrato in vigore il 10 dicembre 2024, ma la sua applicazione è stata suddivisa in diverse fasi.
L’11 settembre 2026 rappresenta una delle prime date realmente operative: da quel giorno si applicano gli obblighi di comunicazione relativi alle vulnerabilità attivamente sfruttate e agli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali.
La maggior parte degli obblighi del regolamento entrerà invece in applicazione l’11 dicembre 2027.
È una distinzione importante, perché parlare genericamente di “CRA entrato in vigore l’11 settembre” sarebbe tecnicamente scorretto.
Il regolamento è già in vigore.
Quello che è iniziato l’11 settembre 2026 è una prima fase operativa particolarmente significativa.
Fonte: European Commission – Cyber Resilience Act
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Fonte: European Commission – CRA Implementation Timeline
https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
Che cosa cambia dall’11 settembre 2026
La novità immediatamente operativa riguarda il modo in cui devono essere gestite alcune categorie di vulnerabilità e incidenti.
Quando un produttore viene a conoscenza di una vulnerabilità attivamente sfruttata, deve effettuare una segnalazione attraverso la piattaforma europea gestita da ENISA.
Il sistema prevede una prima segnalazione entro 24 ore, una notifica completa entro 72 ore e successivi aggiornamenti secondo le tempistiche previste dal regolamento.
La stessa piattaforma viene utilizzata per la segnalazione degli incidenti gravi che hanno un impatto sulla sicurezza del prodotto.
L’obiettivo è evitare che lo stesso evento debba essere comunicato separatamente a una molteplicità di autorità nazionali.
ENISA ha infatti realizzato la CRA Single Reporting Platform, un punto unico attraverso il quale i produttori possono effettuare le comunicazioni previste dalla normativa.
Fonte: European Commission – CRA Reporting Obligations
https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
Fonte: ENISA – CRA Single Reporting Platform
https://www.enisa.europa.eu/topics/product-security/vulnerability-services/eu-incident-response-and-cyber-crisis-management/single-reporting-platform-srp
Ma il vero cambiamento arriva nel 2027
La parte più significativa del CRA non è però la procedura di segnalazione.
Il vero cambiamento riguarda il modo in cui il legislatore europeo considera il software.
Il regolamento introduce infatti requisiti di cybersecurity che devono essere presi in considerazione durante progettazione, sviluppo, produzione, distribuzione e manutenzione del prodotto.
Non basta quindi che un programma svolga correttamente la funzione per cui è stato sviluppato.
Il produttore deve affrontare anche il problema della sicurezza del prodotto, valutare i rischi, gestire le vulnerabilità e predisporre processi adeguati per intervenire quando emerge un problema.
È un cambio di paradigma significativo.
Per anni il mercato del software ha spesso separato la fase di sviluppo dalla fase di sicurezza, affidando quest’ultima a controlli successivi, penetration test occasionali o interventi effettuati dopo la scoperta di una vulnerabilità.
Il CRA porta invece la sicurezza dentro il processo di sviluppo.
Fonte: European Commission – CRA Summary
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Dal “funziona” al “è stato progettato per essere sicuro”
È probabilmente questa la frase che meglio descrive il cambiamento.
Un prodotto software professionale non dovrebbe essere valutato esclusivamente sulla base delle sue funzionalità.
Il CRA introduce requisiti che riguardano, tra le altre cose:
- valutazione dei rischi cybersecurity;
- gestione delle vulnerabilità;
- aggiornamenti di sicurezza;
- informazioni fornite agli utenti;
- documentazione tecnica;
- gestione del ciclo di vita del prodotto.
Il produttore deve inoltre mantenere aggiornata, quando necessario, la valutazione del rischio.
Questo significa che la cybersecurity non viene più considerata esclusivamente come una caratteristica aggiuntiva del prodotto.
Diventa una parte del prodotto stesso.
Fonte: EUR-Lex – Regulation (EU) 2024/2847
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
Una novità particolarmente importante: il periodo di supporto
Uno degli aspetti meno discussi del CRA potrebbe essere anche uno dei più rilevanti per il mercato.
Il produttore deve stabilire un support period, cioè il periodo durante il quale garantisce la gestione efficace delle vulnerabilità del prodotto.
Come regola generale, il regolamento prevede un periodo di supporto di almeno cinque anni, salvo che la vita utile prevista del prodotto sia inferiore. Se il prodotto è ragionevolmente destinato a rimanere in uso più a lungo, il periodo di supporto dovrebbe riflettere tale durata.
Questo cambia profondamente la logica di molti prodotti software.
Un software non può essere semplicemente consegnato e considerato concluso.
Occorre interrogarsi su cosa succederà quando verrà scoperta una vulnerabilità.
Chi la analizzerà?
Chi svilupperà la patch?
Come verrà distribuita?
Per quanto tempo?
Con quali procedure?
E chi sarà responsabile del processo?
Il concetto di “consegna del software” tende quindi a lasciare spazio a quello di ciclo di vita del prodotto.
Fonte: EUR-Lex – Regulation (EU) 2024/2847, support period
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
E qui entra in gioco il fenomeno del “vibe coding”
È impossibile parlare dell’attuale evoluzione del software senza parlare di intelligenza artificiale.
Strumenti di generazione automatica del codice, coding assistant e piattaforme di vibe coding hanno ridotto drasticamente la barriera di ingresso allo sviluppo.
Oggi una persona con competenze tecniche limitate può descrivere in linguaggio naturale ciò che vuole ottenere e ottenere in pochi minuti una web application, un plugin, un sistema di gestione dati o una piccola piattaforma software.
Il fenomeno è reale e non deve essere demonizzato.
L’intelligenza artificiale sta aumentando enormemente la produttività degli sviluppatori esperti e, contemporaneamente, sta permettendo a persone con competenze inferiori di realizzare applicazioni che fino a pochi anni fa avrebbero richiesto un team tecnico.
Il problema nasce quando questa facilità viene confusa con la capacità di progettare e mantenere un prodotto software professionale.
Scrivere codice non significa necessariamente saper progettare una soluzione sicura.
E soprattutto, ottenere un’applicazione funzionante non significa aver verificato:
- autenticazione e autorizzazioni;
- gestione delle sessioni;
- validazione degli input;
- esposizione delle API;
- gestione dei segreti;
- dipendenze software;
- vulnerabilità delle librerie;
- logging;
- gestione degli errori;
- aggiornamenti;
- backup e recovery;
- superfici di attacco;
- protezione dei dati;
- comportamento del sistema in condizioni anomale.
È qui che il CRA potrebbe produrre uno dei suoi effetti indiretti più interessanti.
Non perché vieti il vibe coding.
Non lo vieta.
E nemmeno perché stabilisca che un software debba essere necessariamente sviluppato da un programmatore con una determinata qualifica.
La normativa interviene invece sul prodotto immesso sul mercato e sull’operatore economico che ne assume la responsabilità.
Questa distinzione è fondamentale.
Il CRA non certifica il programmatore: responsabilizza il prodotto
Il rischio di una lettura superficiale del regolamento sarebbe pensare che l’Europa abbia introdotto una sorta di “patentino” per sviluppatori.
Non è così.
Il CRA non dice:
“Solo un professionista qualificato può scrivere software.”
Dice qualcosa di molto diverso:
se un prodotto digitale rientra nel suo campo di applicazione e viene immesso sul mercato, devono essere rispettati determinati requisiti di cybersecurity.
Il legislatore non sembra quindi interessato a stabilire chi ha scritto ogni singola riga di codice.
È interessato a stabilire chi è responsabile del prodotto e se quel prodotto è stato progettato, documentato, mantenuto e gestito secondo determinati requisiti di sicurezza.
Questa impostazione rende possibile anche l’utilizzo dell’intelligenza artificiale nello sviluppo.
Un’azienda può utilizzare AI per generare codice.
Può utilizzare strumenti automatici.
Può utilizzare agenti software.
Può persino automatizzare gran parte del processo di sviluppo.
Ma l’automazione dello sviluppo non elimina la responsabilità sul prodotto.
Ed è probabilmente questo uno dei punti più importanti da comprendere nell’era del vibe coding.
Fonte: EUR-Lex – Regulation (EU) 2024/2847, obblighi dei fabbricanti
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
Chi è davvero coinvolto dal CRA?
Il campo di applicazione è più ampio di quanto possa sembrare.
Il CRA riguarda i cosiddetti “products with digital elements”, cioè prodotti software o hardware e relative soluzioni di trattamento dati remoto, compresi componenti software o hardware immessi separatamente sul mercato, secondo la definizione contenuta nel regolamento.
Sono quindi potenzialmente interessati moltissimi prodotti:
- dispositivi connessi;
- software;
- applicazioni;
- componenti software distribuiti separatamente;
- prodotti IoT;
- altri prodotti digitali rientranti nel campo di applicazione del regolamento.
La Commissione ha pubblicato il 27 luglio 2026 una prima serie di orientamenti pratici per aiutare fabbricanti, sviluppatori e imprese di tutte le dimensioni a comprendere e applicare il CRA.
Fonte: EUR-Lex – Regulation (EU) 2024/2847, Article 3
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
Fonte: European Commission – CRA Implementation Guidance, 27 July 2026
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
Non tutto il software è automaticamente soggetto al CRA
Questo è un altro punto che merita attenzione.
Non sarebbe corretto affermare che:
“Dal 2027 ogni sito web dovrà essere certificato CRA.”
Oppure che:
“Ogni sviluppatore freelance dovrà diventare un’azienda cybersecurity.”
La realtà è molto più articolata.
Il regolamento distingue tra diverse situazioni e attribuisce obblighi differenti a produttori, importatori, distributori e altri soggetti.
Anche il software open source segue un regime particolare.
La Commissione ha introdotto infatti la figura degli open-source software stewards, soggetti giuridici che forniscono in modo continuativo supporto allo sviluppo di specifici software open source destinati ad attività commerciali e che ne garantiscono la sostenibilità.
Il CRA prevede per questi soggetti un regime specifico e proporzionato.
Fonte: European Commission – Cyber Resilience Act and Open Source
https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
Il punto critico per il mercato: la responsabilità
È proprio qui che il regolamento potrebbe produrre un cambiamento culturale.
Immaginiamo un’azienda che acquista un prodotto software sviluppato da un piccolo fornitore.
Fino a oggi, in molti contesti, il rapporto poteva essere estremamente semplice:
“Il software funziona?”
Sì.
“È stato consegnato?”
Sì.
“C’è un problema?”
Vediamo di risolverlo.
Il modello che il CRA tende a introdurre è diverso.
Il produttore deve avere una struttura per la gestione delle vulnerabilità.
Deve considerare la cybersecurity nella progettazione.
Deve documentare determinati aspetti.
Deve gestire gli aggiornamenti.
Deve indicare il periodo di supporto.
E, in determinate circostanze, deve notificare tempestivamente vulnerabilità e incidenti.
Il software diventa quindi sempre più simile a un prodotto industriale, almeno dal punto di vista della responsabilità sulla sicurezza.
Fonte: European Commission – CRA Summary
https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Anche le dipendenze diventano un problema di governance
Questo aspetto è particolarmente importante nello sviluppo moderno.
Un’applicazione raramente è composta soltanto dal codice scritto direttamente dal suo autore.
Può utilizzare:
- framework;
- librerie;
- package open source;
- API;
- componenti esterni;
- servizi cloud.
Una vulnerabilità presente in una dipendenza può diventare una vulnerabilità del prodotto finale.
Il CRA spinge quindi verso un approccio molto più strutturato alla gestione delle componenti e delle vulnerabilità.
Non basta più, in prospettiva, dire:
“Quel problema è nella libreria che utilizziamo.”
Dal punto di vista del prodotto, la domanda diventa:
Chi deve accorgersene, valutarne l’impatto e intervenire?
È un passaggio importante dalla responsabilità sul singolo codice alla responsabilità sulla catena tecnologica che compone il prodotto.
Fonte: EUR-Lex – Regulation (EU) 2024/2847, cybersecurity requirements and vulnerability management
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
E se il software è stato generato dall’intelligenza artificiale?
Questa è probabilmente una delle domande più interessanti dei prossimi anni.
Il CRA non introduce una distinzione tra codice scritto manualmente e codice generato dall’AI.
Dal punto di vista della sicurezza, il codice è codice.
Se un’applicazione contiene una vulnerabilità, sapere che quella parte è stata generata da ChatGPT, Claude, Copilot o da un altro sistema di AI non elimina la responsabilità del produttore.
Anzi, la crescente automazione potrebbe rendere ancora più importante la presenza di processi di verifica.
L’AI può generare migliaia di righe di codice in pochi minuti.
Ma questo non significa che quelle righe siano state necessariamente:
- sottoposte a threat modeling;
- testate contro vulnerabilità note;
- verificate nelle dipendenze;
- sottoposte a penetration test;
- integrate correttamente;
- documentate;
- progettate per essere mantenute nel tempo.
Il paradosso dell’AI coding è quindi evidente:
Più è facile produrre software, più diventa importante verificare la qualità e la sicurezza di ciò che viene prodotto.
Le conseguenze economiche possono essere rilevanti
Il CRA non è soltanto una norma tecnica.
Prevede anche un sistema sanzionatorio.
Per la non conformità ai requisiti essenziali di cybersecurity e per le violazioni degli articoli 13 e 14, il regolamento prevede sanzioni amministrative fino a 15 milioni di euro oppure, per le imprese, fino al 2,5% del fatturato mondiale annuo totale dell’esercizio precedente, se superiore.
Per altre categorie di violazioni sono previste soglie inferiori.
Naturalmente si tratta di massimali, non di una sanzione automatica.
Le sanzioni concrete saranno definite e applicate secondo le regole nazionali e tenendo conto delle circostanze del caso.
Il dato importante, però, è il principio:
la cybersecurity diventa una responsabilità con una rilevanza economica concreta.
Fonte: EUR-Lex – Regulation (EU) 2024/2847, Article 64
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
Non significa che spariranno gli sviluppatori improvvisati
Sarebbe sbagliato arrivare a questa conclusione.
Il mercato continuerà ad avere freelance, piccoli studi, startup, sviluppatori indipendenti e persone che utilizzano strumenti AI per costruire applicazioni.
Il CRA non elimina questa realtà.
Potrebbe però rendere progressivamente più difficile sostenere che la semplice capacità di produrre un software funzionante sia sufficiente per venderlo come prodotto professionale, quando il prodotto rientra nel campo di applicazione della normativa.
Ed è una differenza sostanziale.
La barriera non è più necessariamente:
“Quanto codice sai scrivere?”
Diventa sempre più:
“Quanto sei in grado di governare il prodotto che stai mettendo sul mercato?”
Questa è una barriera qualitativa molto diversa.
Una possibile selezione naturale del mercato
È probabilmente questo l’effetto più interessante da osservare nei prossimi anni.
Non è detto che il CRA faccia scomparire i piccoli sviluppatori.
Potrebbe però aumentare la distanza tra:
chi sviluppa software come attività professionale strutturata
e
chi produce applicazioni senza avere processi adeguati di sicurezza, manutenzione e gestione delle vulnerabilità.
Per un’azienda che acquista software, questo potrebbe diventare un elemento importante nella selezione dei fornitori.
Non basterà più chiedere:
“Quanto costa?”
Potrebbe diventare normale chiedere anche:
- Qual è il periodo di supporto?
- Come gestite le vulnerabilità?
- Come vengono gestiti gli aggiornamenti?
- Come monitorate le dipendenze?
- Esiste una procedura di vulnerability disclosure?
- Come viene effettuata la valutazione del rischio?
- Qual è la documentazione disponibile?
- Chi è responsabile della sicurezza del prodotto?
Sono domande che oggi vengono poste soprattutto nei contesti enterprise.
Il CRA potrebbe contribuire a portarle progressivamente anche in una fascia più ampia del mercato.
Il rapporto con NIS2
Il Cyber Resilience Act non vive isolato.
Fa parte di un ecosistema europeo più ampio di norme sulla cybersecurity, nel quale rientrano anche NIS2, il Cybersecurity Act e altre iniziative europee.
La differenza fondamentale è che NIS2 si concentra principalmente sulla cybersecurity delle organizzazioni e dei settori interessati, mentre il CRA interviene sulla sicurezza dei prodotti con elementi digitali.
Le due normative possono quindi interessare soggetti diversi e, in alcuni casi, sovrapporsi.
La direzione europea appare comunque abbastanza chiara:
la cybersecurity non viene più trattata esclusivamente come una questione interna all’IT aziendale.
Sta diventando un requisito che attraversa prodotti, organizzazioni, supply chain e ciclo di vita tecnologico.
Fonte: European Commission – Cyber Resilience Act
https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
Il vero banco di prova sarà il 2027
L’11 settembre 2026 è quindi un punto di partenza, non il traguardo.
La vera verifica arriverà l’11 dicembre 2027, quando entrerà in applicazione la parte principale del regolamento.
Nel frattempo saranno fondamentali:
- standardizzazione;
- linee guida della Commissione;
- attività di ENISA;
- organismi di valutazione della conformità;
- preparazione delle imprese.
La Commissione ha già pubblicato nel luglio 2026 una prima serie di orientamenti pratici per aiutare fabbricanti, sviluppatori e imprese di tutte le dimensioni.
Fonte: European Commission – CRA Implementation
https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
Fonte: European Commission – CRA Implementation Guidance, 27 July 2026
https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation
La domanda non è più “chi ha scritto il codice?”
L’evoluzione del settore sta portando a un punto interessante.
L’intelligenza artificiale sta progressivamente rendendo il codice una commodity.
Generare una funzione, un’interfaccia, un database o persino una piccola applicazione sta diventando sempre più semplice.
Il valore professionale potrebbe quindi spostarsi ulteriormente verso ciò che viene prima e dopo il codice:
analisi, architettura, sicurezza, integrazione, governance, test, manutenzione, responsabilità e capacità di gestire il ciclo di vita del prodotto.
In questo senso il Cyber Resilience Act potrebbe rappresentare un passaggio importante.
Non perché eliminerà il vibe coding.
Non perché impedirà a un non-programmatore di creare un’applicazione.
E nemmeno perché trasformerà automaticamente ogni sviluppatore in un esperto di cybersecurity.
Ma perché introduce una logica diversa:
Un prodotto digitale professionale non è soltanto qualcosa che funziona. È qualcosa di cui qualcuno deve essere in grado di governare anche il rischio.
Ed è proprio questo il punto che potrebbe cambiare il mercato.
Nel momento in cui il software diventa sempre più facile da produrre, la capacità di garantirne sicurezza, manutenzione e affidabilità potrebbe diventare una delle principali differenze tra un prototipo generato in poche ore e un vero prodotto tecnologico.
Il Cyber Resilience Act introduce un principio destinato ad avere conseguenze significative:
La cybersecurity non è più soltanto una caratteristica tecnica da aggiungere al prodotto. Diventa parte della responsabilità del prodotto stesso.
L’11 settembre 2026 è iniziato il primo passaggio operativo con gli obblighi di reporting.
L’11 dicembre 2027 arriverà la piena applicazione della maggior parte dei requisiti.
Per il mercato sarà un periodo interessante.
Perché nel frattempo l’AI continuerà a rendere il software sempre più facile da generare.
La domanda che rimane aperta è quindi molto semplice:
Quando chiunque può creare software, chi sarà realmente in grado di garantirne la sicurezza?
Ed è probabilmente questa, più che la capacità di scrivere codice, la competenza che il mercato tecnologico europeo sarà chiamato a valorizzare nei prossimi anni.
