Dove siamo nel calendario
Il Cyber Resilience Act è il Regolamento (UE) 2024/2847, in vigore dal dicembre 2024. Non si applica tutto in una volta: il regolamento scagliona l’entrata in vigore degli obblighi su un arco di tre anni, ed è utile fissare i tre momenti chiave perché vengono spesso confusi.
Sta per scattare la prima tappa operativa. Dall’11 giugno 2026 si applica il Capo IV, dedicato agli organismi di valutazione della conformità e alle autorità di notifica: entro questa data gli Stati membri designano le autorità nazionali e i notified bodies. È la prima milestone concreta, ormai imminente, e mette in piedi l’impalcatura istituzionale su cui poggerà tutto il resto.
La seconda tappa arriva a settembre, la terza a fine 2027. Tenere distinte le due cose è il punto centrale di questo articolo.
Il reporting parte a settembre
Dall’11 settembre 2026 diventano applicabili gli obblighi di reporting previsti dall’Art. 14: i fabbricanti devono segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi. L’obbligo vale anche per prodotti già immessi sul mercato, non solo per quelli nuovi.
Le scadenze sono stringenti. Per una vulnerabilità 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 passeranno per il CRA Single Reporting Platform gestito da ENISA, che sarà operativo per settembre 2026. La piattaforma non è ancora attiva: i fabbricanti che oggi mappano i propri prodotti devono prepararsi a un canale che entrerà in funzione contestualmente all’obbligo. Chi ha già impostato i flussi NIS2 parte avvantaggiato — il tema è lo stesso, come abbiamo discusso a proposito di NIS2 e PMI.
SBOM: l’obbligo pieno è a fine 2027
Il grosso del regolamento — requisiti essenziali, obblighi del fabbricante e documentazione tecnica — si applica dall’11 dicembre 2027. È qui che entra in scena l’SBOM.
L’Allegato I, Parte II, punto 1 richiede di documentare i componenti del prodotto in un software bill of materials in un formato comunemente usato e machine-readable, coprendo almeno le top-level dependencies. Il CRA non impone un formato specifico e a oggi non esistono standard EN armonizzati definitivi né atti delegati sul formato: in pratica si adottano CycloneDX o SPDX. Per chi cerca specifiche di dettaglio, la BSI TR-03183-2 fornisce indicazioni tecniche per SBOM conformi al CRA.
Un punto spesso frainteso: l’SBOM va inserito nella documentazione tecnica e fornito alle autorità di sorveglianza su richiesta motivata, senza obbligo di renderlo pubblico. Non è una disclosure di mercato, è un artefatto di conformità.
L’open source steward
Il CRA introduce all’Art. 24 una figura nuova: l’open source steward. Sono persone giuridiche che supportano in modo continuativo software libero/open source destinato ad attività commerciali — entità diverse dal fabbricante. I singoli sviluppatori volontari restano fuori scope.
Il regime è light-touch: policy di cybersecurity documentata, gestione e disclosure delle vulnerabilità, cooperazione con le autorità. Gli steward non sono soggetti a sanzioni amministrative. È un riconoscimento che la catena di fornitura del software poggia su progetti mantenuti da entità che non vendono il prodotto finito, e che vanno responsabilizzate senza essere trattate come fabbricanti. Il tema ci riguarda direttamente, ed è coerente con il nostro lavoro sull’open source.
Cosa significa in pratica
Per chi mette prodotti con componenti digitali sul mercato europeo, la sequenza è chiara: prima il reporting, poi l’SBOM. Da settembre serve un processo per riconoscere e notificare vulnerabilità sfruttate e incidenti entro finestre di ore; da fine 2027 serve un SBOM machine-readable nella documentazione tecnica, mantenuto aggiornato.
I due fronti sono operativamente collegati. Un inventario accurato delle dipendenze — l’SBOM — è anche ciò che rende possibile rispondere in 24 ore quando una di quelle dipendenze viene sfruttata. Costruirlo nel corso del 2026, prima della scadenza, significa arrivare al 2027 con il lavoro già fatto.
È su questo asse che lavorano i nostri prodotti: CyberScan per la gestione delle vulnerabilità e la generazione dell’SBOM, e DataGovern per la governance della documentazione di conformità. La scadenza è normativa; la preparazione è una scelta di tempistica.
Link: Regolamento (UE) 2024/2847 — EUR-Lex · Commissione UE — CRA reporting obligations · Commissione UE — CRA and open source