Sommario
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
CyberAgent
Vulnerability assessment continuo e generazione dell’SBOM: scansione, mappatura sui requisiti, evidenze documentali pronte.
Scopri CyberAgent →
DataGovern
Governance della documentazione di conformità: politiche, evidenze e registri tenuti insieme e aggiornati.
Scopri DataGovern →
Cosa è uscito il 27 luglio
La Commissione europea ha pubblicato la prima guida ufficiale all’applicazione del Cyber Resilience Act. Sono due atti: la comunicazione C(2026) 5252 e il suo allegato, che contiene la guida vera e propria. Accanto viaggia un documento separato di FAQ sull’implementazione.
La base giuridica è l’articolo 26 del Regolamento (UE) 2024/2847, che incarica la Commissione di pubblicare orientamenti per aiutare gli operatori economici ad applicare il regolamento. Una prima versione era stata messa in consultazione a marzo per raccogliere osservazioni; questa è il testo adottato.
Due caratteristiche contano più del contenuto stesso. La guida non è vincolante: è l’interpretazione della Commissione e in caso di contestazione restano decisivi il testo del regolamento e gli standard armonizzati. E dichiara esplicitamente di rivolgersi anche a microimprese e PMI, con 67 esempi pratici e diagrammi di flusso pensati per chi non ha un ufficio legale interno.
I cinque nodi che scioglie
1. Ambito: quali prodotti rientrano
Il CRA copre i prodotti con elementi digitali connessi a un dispositivo o a una rete: router, modem, prodotti per la casa connessa, smartwatch, sistemi operativi, firewall, VPN, browser, antivirus, password manager. La guida entra nei due casi che generavano più domande, le soluzioni di elaborazione dati remota e il software open source.
Sul software chiarisce un punto che vale la pena tenere a mente perché cambia il calendario di ogni team di sviluppo: il regolamento si applica quando una versione è messa a disposizione per la prima volta sul mercato dell’Unione. Installazioni multiple della stessa versione contano come una sola immissione sul mercato.
2. Modifica sostanziale: quando la conformità riparte
È il concetto che decide se una nuova release è un aggiornamento o un prodotto nuovo agli occhi del regolamento. Una modifica è sostanziale quando incide sulla conformità ai requisiti di cybersicurezza, quando altera il livello di rischio oppure quando cambia la destinazione d’uso originaria.
Gli esempi che la guida porta sono concreti: aggiungere una funzione di connettività remota introduce nuovi vettori di attacco, quindi è sostanziale; cambiare i protocolli di cifratura in modo che incida sulla conformità, idem. Una correzione di sicurezza che non tocca nessuna delle tre condizioni, no.
3. Periodo di supporto: il minimo non è la regola
Qui la lettura corrente va corretta. Il periodo di supporto è di almeno cinque anni, ma la guida chiarisce che va allineato alla vita attesa del prodotto: cinque anni sono il pavimento, non il valore da dichiarare per default. Se un prodotto ha un ciclo di vita ragionevolmente più lungo, il supporto lo segue. Se ne ha uno documentabilmente più breve, il periodo può essere inferiore.
Il corollario operativo pesa: per ogni versione sostanzialmente modificata va dichiarato un nuovo periodo di supporto. Chi rilascia spesso deve tenere un registro di quale versione è supportata fino a quando e deve saperlo dire a un’autorità.
4. Reporting: cosa si notifica e in quanto tempo
Le finestre erano già nel regolamento e restano quelle: per una vulnerabilità attivamente sfruttata, early warning entro 24 ore, notifica entro 72 ore, report finale entro 14 giorni dalla disponibilità di una misura correttiva. Per gli incidenti gravi il report finale è dovuto entro un mese. Le notifiche vanno al CSIRT nazionale e a ENISA.
Il punto che si tende a sottovalutare: l’obbligo vale anche per i prodotti già immessi sul mercato, non solo per quelli nuovi.
5. Valutazione del rischio: cosa va documentato
Il fabbricante deve condurre una valutazione del rischio di cybersicurezza, identificare i vincoli applicabili e implementare misure adeguate. La guida dettaglia cosa ci si aspetta di trovare scritto, che è la parte che in pratica separa un’azienda pronta da una che dovrà ricostruire tutto a ritroso.
Il calendario aggiornato
Il regolamento è in vigore dal dicembre 2024 e si applica per gradi. Le tappe già passate e quelle davanti:
- 28 novembre 2025: atto di esecuzione sulle descrizioni tecniche dei prodotti importanti e critici.
- 11 dicembre 2025: atto delegato sulle notifiche ai CSIRT.
- 11 giugno 2026: si applicano le norme su organismi di valutazione della conformità e autorità di notifica. Già passata.
- 27 luglio 2026: primo set di linee guida della Commissione. È il fatto da cui parte questo pezzo.
- Q3 2026: primi deliverable di standardizzazione, orizzontali e verticali.
- 11 settembre 2026: scattano gli obblighi di segnalazione. È la prossima scadenza vera, fra sei settimane.
- Q4 2026: atto delegato sulla presunzione di conformità EUCC.
- 11 dicembre 2026: gli Stati membri devono avere notificato organismi in numero sufficiente.
- 30 ottobre 2027: ulteriori deliverable di standardizzazione.
- 11 dicembre 2027: applicazione piena, requisiti essenziali e documentazione tecnica compresi.
Cosa fare adesso
Per un’azienda che mette prodotti con componenti digitali sul mercato europeo, la sequenza utile nelle prossime sei settimane è questa.
1. Stabilire se rientrate e per quali prodotti. Non è una domanda retorica: la guida esiste perché la risposta non era ovvia, soprattutto per software e servizi con elaborazione remota. Il risultato va messo per iscritto, prodotto per prodotto, perché è il presupposto di tutto il resto.
2. Attivare il canale di segnalazione entro l’11 settembre. Servono un processo, dei ruoli nominati e un runbook, perché le finestre di 24 e 72 ore non si improvvisano di venerdì sera. Chi ha già i flussi NIS2 parte avvantaggiato: il meccanismo è lo stesso, come abbiamo visto per NIS2 e PMI.
3. Dichiarare i periodi di supporto e tenerne il registro. Prodotto per prodotto e versione per versione, con la data di fine supporto e il criterio con cui è stata scelta.
4. Definire cosa conta come modifica sostanziale da voi. Tre criteri applicati al vostro ciclo di rilascio, scritti una volta, così la decisione non si rigioca a ogni release.
5. Cominciare l’SBOM adesso, anche se scade a fine 2027. L’inventario delle dipendenze è ciò che rende possibile rispondere in 24 ore quando una di quelle dipendenze viene sfruttata davvero: serve al punto 2 molto prima di servire alla documentazione tecnica. Il perché lo abbiamo argomentato in SBOM e reporting del CRA e i numeri sul carico di vulnerabilità che sta arrivando stanno in 432 CVE del kernel Linux in due giorni.
Se sviluppate o usate open source
Il CRA introduce all’articolo 24 la figura dell’open source steward: persone giuridiche che sostengono in modo continuativo software libero destinato ad attività commerciali. Il regime è leggero (policy di cybersicurezza documentata, gestione e disclosure delle vulnerabilità, cooperazione con le autorità) e gli steward non sono soggetti a sanzioni amministrative. I singoli sviluppatori volontari restano fuori ambito.
La guida di luglio torna sull’open source fra i casi di ambito da chiarire ed è il segnale che la questione resta la più delicata del regolamento. Chi costruisce prodotti su componenti open source, cioè quasi tutti, ha comunque gli obblighi del fabbricante sul prodotto finito, indipendentemente da dove viene il codice.
Cosa ne pensiamo
Una guida non vincolante con 67 esempi è più utile di quanto il suo status faccia pensare. In un regolamento dove la violazione dei requisiti essenziali costa fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, il maggiore dei due (art. 64), il valore di un documento della Commissione che dice “questo caso rientra, questo no” è che sposta la discussione da un’interpretazione difendibile a una posizione allineata a chi il regolamento lo ha scritto. Non è una garanzia, è un vantaggio in caso di contestazione.
Il punto che ci sembra sottovalutato è il periodo di supporto. La lettura diffusa è “cinque anni e via”; la guida dice di allinearlo alla vita attesa del prodotto e di ridichiararlo a ogni modifica sostanziale. Per chi vende dispositivi con vita lunga, questo è un impegno di manutenzione pluriennale che va messo a bilancio, non una casella da spuntare.
La parte che nessun documento risolve al posto vostro resta l’inventario. Senza sapere cosa gira e con quali dipendenze, il reporting a 24 ore non è eseguibile e l’SBOM del 2027 sarà un lavoro archeologico. È il terreno dove lavorano i nostri strumenti: CyberAgent per la scansione continua e la generazione dell’SBOM, DataGovern per tenere insieme le evidenze documentali. Come diciamo sempre, nessuno dei due produce conformità automatica: riducono il lavoro manuale e rendono ripetibile la parte che va dimostrata, mentre la responsabilità formale resta vostra.
Sei settimane alla prima scadenza con obblighi veri. Chi comincia a settembre arriva tardi di sei settimane: la consulenza CISO serve soprattutto a non scoprirlo il 12 settembre.
Fonti
- Commissione UE: Commission publishes new guidance to support businesses’ implementation of the Cyber Resilience Act
- Commissione UE: i documenti C(2026) 5252 e allegato
- Commissione UE: Cyber Resilience Act, pagina di implementazione e calendario
- Regolamento (UE) 2024/2847 su EUR-Lex
- Punto Informatico: Cyber Resilience Act, la Commissione UE pubblica le linee guida