Il Cyber Resilience Act per le PMI non è più una scadenza lontana. Dall’11 settembre 2026 sono già applicabili gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi che interessano la sicurezza dei prodotti con elementi digitali. Il resto della disciplina diventerà pienamente applicabile dall’11 dicembre 2027
Per software house, fornitori SaaS, produttori di dispositivi connessi e imprese che commercializzano applicazioni con il proprio marchio, questo significa rivedere non soltanto la sicurezza del codice, ma l’intero ciclo di vita del prodotto: progettazione, sviluppo, dipendenze, aggiornamenti, documentazione, gestione delle vulnerabilità e risposta agli incidenti.
Aspettare il 2027 sarebbe rischioso. La conformità al CRA richiede processi, responsabilità ed evidenze che non possono essere costruiti nelle ultime settimane prima della scadenza.
Che cos’è il Cyber Resilience Act
Il Cyber Resilience Act, formalmente Regolamento UE 2024/2847, introduce requisiti orizzontali di cybersecurity per i prodotti con elementi digitali messi a disposizione sul mercato dell’Unione Europea. Il regolamento riguarda prodotti hardware e software il cui uso previsto o ragionevolmente prevedibile include una connessione logica o fisica, diretta o indiretta, a un dispositivo o a una rete.
L’obiettivo è fare in modo che hardware e software arrivino sul mercato con meno vulnerabilità e che i produttori ne gestiscano la sicurezza durante il periodo di utilizzo previsto. La responsabilità, quindi, non termina quando il prodotto viene venduto o consegnato al cliente.
Il CRA introduce un cambiamento importante: la cybersecurity diventa una caratteristica verificabile del prodotto, da considerare durante pianificazione, progettazione, sviluppo, produzione, distribuzione e manutenzione.
A quali imprese si applica
Il regolamento interessa principalmente i produttori che immettono sul mercato europeo un prodotto con elementi digitali con il proprio nome o marchio. Gli obblighi possono coinvolgere anche importatori e distributori, con responsabilità differenti lungo la catena del valore.
Per capire se una PMI rientra nel perimetro, non basta chiedersi se realizza “prodotti informatici”. Occorre verificare se sviluppa, modifica sostanzialmente, distribuisce o commercializza:
- Applicazioni desktop o mobile.
- Software installato presso il cliente.
- Componenti e librerie software commerciali.
- Dispositivi IoT e apparati connessi.
- Sistemi hardware con software incorporato.
- Soluzioni che includono elaborazione remota necessaria al funzionamento del prodotto.
- Prodotti digitali commercializzati con il proprio marchio.
La qualificazione va effettuata sul prodotto e sul ruolo effettivamente assunto dall’impresa. La Commissione europea ha pubblicato indicazioni operative dedicate anche alle soluzioni di elaborazione remota, all’open source, alle modifiche sostanziali e ai periodi di supporto.
Cosa è cambiato nel 2026
Dall’11 settembre 2026, i produttori devono comunicare attraverso la Single Reporting Platform di ENISA le vulnerabilità attivamente sfruttate e gli incidenti gravi che incidono sulla sicurezza dei prodotti con elementi digitali.
Il processo prevede più fasi:
- Entro 24 ore: invio di un early warning dal momento in cui il produttore viene a conoscenza dell’evento.
- Entro 72 ore: trasmissione della notifica con informazioni generali e una valutazione iniziale.
- Vulnerabilità attivamente sfruttata: report finale non oltre 14 giorni dalla disponibilità di una misura correttiva o mitigativa, come una patch.
- Incidente grave: report finale entro un mese dalla notifica delle 72 ore.
La piattaforma consente di effettuare un’unica segnalazione, indirizzata al CSIRT competente e resa disponibile a ENISA secondo il meccanismo previsto dal CRA.
Questi tempi richiedono una macchina organizzativa già pronta. Se l’impresa non sa chi deve classificare l’evento, recuperare i log, valutare i prodotti coinvolti e autorizzare la notifica, rispettare una finestra di 24 ore diventa difficile.
Cosa cambierà nel 2027
Dall’11 dicembre 2027 troveranno piena applicazione gli obblighi principali del CRA. I produttori dovranno dimostrare che i prodotti con elementi digitali rispettano i requisiti essenziali di cybersecurity e che il rischio è stato valutato durante l’intero ciclo di vita.
Tra le attività centrali rientrano:
- Valutazione del rischio di cybersecurity del prodotto.
- Progettazione e sviluppo secondo principi di security by design e by default.
- Gestione efficace delle vulnerabilità, comprese quelle presenti nei componenti di terze parti.
- Predisposizione della documentazione tecnica.
- Definizione e comunicazione del periodo di supporto.
- Esecuzione della procedura di valutazione della conformità applicabile.
- Dichiarazione UE di conformità e marcatura CE, quando previste.
Per alcuni prodotti di particolare rilevanza per la cybersecurity potrebbe essere necessaria una valutazione da parte di un organismo notificato prima dell’immissione sul mercato.
Attenzione ai prodotti esistenti
Un punto spesso sottovalutato riguarda i prodotti già distribuiti. Gli obblighi di reporting si applicano anche ai prodotti con elementi digitali messi a disposizione sul mercato prima dell’11 dicembre 2027.
Per le altre disposizioni, un prodotto immesso sul mercato prima della piena applicazione ricade nel CRA se viene sottoposto, da quella data, a una modifica sostanziale.
Una software house non dovrebbe quindi limitarsi a controllare i nuovi progetti. È opportuno censire anche le soluzioni già installate presso i clienti, identificando versioni ancora supportate, componenti utilizzati, owner tecnici e modalità di distribuzione delle patch.
SBOM e dipendenze software
Gran parte del software moderno contiene librerie open source, package, framework e componenti sviluppati da terzi. Una vulnerabilità in una dipendenza può propagarsi a più applicazioni senza essere immediatamente visibile.
Il CRA richiede di identificare e documentare i componenti del prodotto; una Software Bill of Materials, o SBOM, aiuta a conoscere la composizione del software e a collegare rapidamente una vulnerabilità nota ai prodotti interessati.
Per essere realmente utile, la SBOM non deve essere un documento creato una sola volta. Dovrebbe essere:
- Generata automaticamente durante la pipeline di build.
- Associata a una versione precisa del prodotto.
- Aggiornata quando cambiano componenti o dipendenze.
- Collegata a sistemi di vulnerability scanning.
- Conservata insieme alle evidenze tecniche della release.
La SBOM non risolve da sola il problema della sicurezza della supply chain. Permette però di rispondere rapidamente a una domanda fondamentale: “Quali nostri prodotti contengono il componente vulnerabile?”.
Secure SDLC e CRA
Per prepararsi al Cyber Resilience Act, le PMI che sviluppano software dovrebbero integrare la sicurezza nel **Software Development Life Cycle**, invece di affidarsi soltanto a un penetration test finale.
Un Secure SDLC proporzionato alle dimensioni dell’organizzazione può includere:
1. Definizione dei requisiti di sicurezza nella fase di analisi.
2. Threat modeling per individuare minacce, asset e superfici di attacco.
3. Regole di secure coding e code review.
4. Scansione SAST del codice sorgente.
5. Software Composition Analysis per le dipendenze.
6. Gestione sicura di secret e credenziali.
7. Test DAST o penetration test sulle release più critiche.
8. Produzione automatica della SBOM.
9. Firma e protezione degli artefatti di rilascio.
10. Monitoraggio delle vulnerabilità dopo la distribuzione.
Il CRA richiede che la valutazione del rischio influenzi pianificazione, progettazione, sviluppo, produzione, consegna e manutenzione. Non è quindi sufficiente conservare un report di sicurezza isolato: servono controlli ripetibili e prove del loro funzionamento.
Vulnerability management
La gestione delle vulnerabilità è uno dei punti più impegnativi per le imprese con prodotti già in uso. Il produttore deve predisporre politiche e procedure adeguate, comprese modalità coordinate di divulgazione delle vulnerabilità, per ricevere, analizzare e correggere segnalazioni provenienti da fonti interne ed esterne.
Un processo minimo dovrebbe definire:
– Un canale pubblico per le segnalazioni di sicurezza.
– Un responsabile per la presa in carico.
– Criteri di classificazione per gravità, sfruttabilità e impatto.
– Tempi interni di triage, correzione e rilascio.
– Procedure di coordinated vulnerability disclosure.
– Modalità di comunicazione ai clienti.
– Regole per verificare se una vulnerabilità è attivamente sfruttata.
– Collegamento con il processo di incident response e con la notifica ENISA.
Durante il periodo di supporto, il produttore deve gestire efficacemente le vulnerabilità del prodotto e dei suoi componenti. In linea generale, il supporto non può essere inferiore a cinque anni, salvo che la vita utile prevista del prodotto sia più breve; quando la durata d’uso attesa supera cinque anni, il periodo deve rifletterla.
CRA, NIS2 e GDPR
Cyber Resilience Act, NIS2 e GDPR non sono intercambiabili. Il CRA riguarda soprattutto la sicurezza dei prodotti con elementi digitali; NIS2 disciplina la gestione del rischio cyber e gli incidenti per i soggetti inclusi nel suo ambito; il GDPR tutela i dati personali.
Una stessa vulnerabilità può però attivare più processi. Un difetto in un’applicazione potrebbe rappresentare contemporaneamente:
– Una vulnerabilità di prodotto da valutare ai sensi del CRA.
– Un incidente significativo per un soggetto NIS2.
– Una violazione di dati personali rilevante per il GDPR.
Anche NIS2 utilizza una struttura di notifica con early warning entro 24 ore e notifica entro 72 ore, ma presupposti, destinatari e contenuti non coincidono necessariamente con quelli del CRA.
La soluzione pratica è costruire un unico processo interno di incident classification, capace di attivare percorsi regolatori distinti senza duplicare raccolta delle evidenze, analisi tecnica e gestione delle responsabilità.
Checklist CRA per PMI
Una prima verifica può partire da queste dieci domande:
– L’impresa conosce tutti i prodotti digitali commercializzati e le versioni ancora supportate?
– Per ogni prodotto è stato identificato il ruolo dell’impresa nella catena del valore?
– Esiste un owner responsabile della cybersecurity del prodotto?
– È disponibile una valutazione documentata del rischio?
– Le dipendenze software sono inventariate attraverso una SBOM aggiornata?
– Esiste un processo strutturato di vulnerability management?
– È disponibile un canale per la segnalazione responsabile delle vulnerabilità?
– L’incident response contempla le scadenze CRA di 24 e 72 ore?
– L’impresa sa chi può accedere e operare sulla piattaforma ENISA?
– Il ciclo di sviluppo produce evidenze utili alla documentazione tecnica e alla conformità?
Più risposte negative emergono, maggiore è il rischio di trovarsi impreparati davanti a una vulnerabilità attivamente sfruttata o alla scadenza del 2027.
Come prepararsi
Per una PMI, il percorso può essere organizzato in quattro fasi:
- Scoping: censire prodotti, versioni, mercati, componenti e ruoli nella supply chain.
- Gap assessment: confrontare processi e controlli attuali con i requisiti CRA.
- Remediation: introdurre Secure SDLC, SBOM, vulnerability management, reporting e documentazione.
- Verifica: eseguire audit interni ed esercitazioni su vulnerabilità e incidenti simulati.
La priorità immediata è rendere operativo il reporting già in vigore. In parallelo, occorre pianificare gli interventi necessari per arrivare al dicembre 2027 con processi consolidati e non soltanto con documenti redatti a ridosso della scadenza.
Conclusione
Il Cyber Resilience Act per PMI e software house trasforma la sicurezza del software da buona pratica tecnica a responsabilità verificabile lungo il ciclo di vita del prodotto. Le imprese dovranno conoscere ciò che distribuiscono, governare le dipendenze, correggere le vulnerabilità, mantenere evidenze e rispettare tempi di notifica molto brevi.
Prepararsi ora significa ridurre il rischio normativo, ma anche migliorare qualità del software, affidabilità dei rilasci e fiducia dei clienti.
