---
title: "Cyber Resilience Act: senza SBOM niente CE dall’11 dicembre 2027"
description: "Dall’11 dicembre 2027 il Reg. (UE) 2024/2847 impone fascicolo tecnico e distinta base del software: senza, niente dichiarazione di conformità né CE."
url: https://csidia.com/note-operative/cyber-resilience-act-sbom-fascicolo-tecnico-2027/
lang: it
date: 2026-07-25
label: "Normativa"
publisher: CSIDIA S.r.l. (https://csidia.com/)
english: https://csidia.com/en/notes/cyber-resilience-act-sbom-fascicolo-tecnico-2027/
---

# Cyber Resilience Act: senza SBOM niente CE dall’11 dicembre 2027

L'11 dicembre 2027 il Regolamento (UE) 2024/2847 — il Cyber Resilience Act — si applica per intero: lo fissa l'art. 71, § 2. Da quel giorno un prodotto con elementi digitali si immette sul mercato dell'Unione soltanto se il fabbricante, **prima**, ha redatto la documentazione tecnica dell'art. 31, ha svolto la valutazione di conformità dell'art. 32, ha firmato la dichiarazione di conformità UE dell'art. 28 e ha apposto la marcatura CE secondo l'art. 30. È la sequenza dell'art. 13, § 12: se manca il primo anello, non esiste l'ultimo. E dentro quel fascicolo c'è una voce nuova — la **distinta base del software**. Da oggi, 25 luglio 2026, mancano poco più di sedici mesi.

## Non è l'obbligo di settembre

Il CRA entra a tappe, ed è facile confonderle. L'art. 14 — [segnalazione delle vulnerabilità sfruttate e degli incidenti gravi](https://csidia.com/note-operative/cyber-resilience-act-segnalazione-settembre-2026), preallarme in 24 ore e notifica in 72 — si applica dall'11 settembre 2026, fra meno di sette settimane; il capo IV sugli organismi notificati è in vigore dall'11 giugno 2026. Ma settembre è un obbligo di **comportamento**: cosa fate quando succede qualcosa, e si regge su una casella di posta, una policy e un responsabile nominato. L'11 dicembre 2027 è un obbligo di **prodotto e di carta**: un fascicolo per famiglia di prodotto, aggiornato versione per versione, che dovete avere già scritto per poter vendere. Non si recupera nelle ultime settimane.

## Cosa deve contenere il fascicolo

L'art. 31, § 1 rimanda all'Allegato VII, che elenca il contenuto minimo:

1. descrizione generale del prodotto: finalità prevista, **versioni del software** rilevanti per la conformità, disposizione interna se c'è hardware, istruzioni per l'utilizzatore dell'Allegato II;
2. progettazione, sviluppo, produzione e gestione delle vulnerabilità — disegni e schemi, **una descrizione dell'architettura che spieghi come i componenti software si alimentano a vicenda**, la distinta base del software, la politica di divulgazione coordinata, il canale di segnalazione, i meccanismi di distribuzione sicura degli aggiornamenti;
3. la valutazione dei rischi di cibersicurezza dell'art. 13;
4. le informazioni usate per determinare il **periodo di assistenza**, che l'art. 13, § 8 fissa in almeno cinque anni;
5. norme armonizzate e certificazioni applicate — o, in mancanza, le soluzioni adottate al loro posto;
6. le relazioni delle prove eseguite;
7. copia della dichiarazione di conformità UE;
8. «se del caso, la distinta base del software, a seguito di una richiesta motivata di un'autorità di vigilanza del mercato».

L'art. 13, § 13 chiude il cerchio: fascicolo e dichiarazione restano a disposizione delle autorità **per almeno dieci anni** dall'immissione sul mercato, o per il periodo di assistenza se più lungo. Non un modulo da archiviare: un archivio vivo.

## Una riga di regolamento, una radiografia

L'obbligo sostanziale sta nell'Allegato I, parte II, punto 1: i fabbricanti «identificano e documentano le vulnerabilità e i componenti contenuti nel prodotto con elementi digitali, redigendo anche una distinta base del software in un formato di uso comune e leggibile da un dispositivo automatico, che includa almeno le dipendenze di primo livello del prodotto». L'art. 3, punto 39) la definisce «un registro formale contenente i dettagli e le relazioni della catena di approvvigionamento dei componenti inclusi negli elementi software». Non è un foglio di calcolo compilato a fine progetto: è un artefatto macchina-leggibile che si rigenera a ogni release.

E dice molto più di «cosa c'è dentro»: quali librerie open source usate e in quale versione esatta, quali componenti commerciali avete comprato e da chi, come i moduli dipendono l'uno dall'altro. Da lì si ricostruiscono scelte architetturali, fornitori, costo di sostituire un pezzo. Incrociata con i database pubblici delle vulnerabilità, permette a chi la possiede di sapere **prima del fabbricante** quali versioni sono esposte e a cosa. È la stessa informazione che serve a difendersi e ad attaccare.

## Il regolamento lo sa, e lascia il problema a voi

Il testo non nasconde la tensione, la gestisce. Il considerando 77 è esplicito: «I fabbricanti non dovrebbero essere obbligati a rendere pubblica la distinta base del software». L'Allegato II, punto 9 chiede l'indirizzo dove reperirla **solo se** il fabbricante decide di metterla a disposizione dell'utilizzatore; l'Allegato VII, punto 8 la subordina a una richiesta motivata dell'autorità; persino la valutazione europea delle dipendenze software dell'art. 13, § 25 arriva all'ADCO **anonimizzata e aggregata**. E l'art. 63 impone a tutte le parti coinvolte di tutelare i segreti commerciali «compreso il codice sorgente».

Il legislatore ha costruito il proprio perimetro; il vostro dovete costruirlo voi. Vale la condizione che tutela già i manuali tecnici: la Direttiva (UE) 2016/943, recepita col D.Lgs. 11 maggio 2018, n. 63 sugli artt. 98-99 del Codice della Proprietà Industriale, protegge un'informazione come segreto commerciale solo se è segreta, ha valore economico in quanto tale ed è sottoposta a **misure ragionevolmente adeguate a mantenerla segreta**. Una SBOM caricata su un assistente cloud generico per «farla sistemare in fretta» smette silenziosamente di soddisfare la terza condizione. È un modello ricorrente, non l'accusa a qualcuno: quando il documento è difficile e la scadenza vicina, la scorciatoia più comoda porta sempre il file fuori dall'azienda.

## Chi dovrà mostrarlo a un terzo

Non tutti i prodotti si autocertificano. L'Allegato III elenca quelli «importanti» — classe I: sistemi operativi, router e switch, VPN, SIEM, microcontrollori e FPGA con funzionalità di sicurezza, telecamere e serrature intelligenti, indossabili per il monitoraggio della salute; classe II: ipervisori e runtime di container, firewall e IDS/IPS, microprocessori a prova di manomissione. L'Allegato IV elenca i «critici»: gateway dei contatori intelligenti, carte intelligenti ed elementi sicuri. Per la classe I, se non si applicano integralmente norme armonizzate, scatta l'esame UE del tipo (modulo B+C) o la garanzia della qualità totale (modulo H); per la classe II uno dei due, sempre; per l'Allegato IV serve un sistema europeo di certificazione (art. 32, §§ 2-4). In tutti questi casi il fascicolo esce dall'azienda e finisce sul tavolo di un organismo notificato. L'art. 12 aggiunge un ponte: un prodotto che è anche sistema di IA ad alto rischio (art. 6 del Regolamento (UE) 2024/1689) si presume conforme ai requisiti di cibersicurezza dell'art. 15 dell'AI Act se rispetta l'Allegato I del CRA e lo dimostra nella dichiarazione UE. Un solo fascicolo, due regolamenti.

## Quanto costa non averlo

L'art. 64 mette cifre, non ammonimenti. Non conformità ai requisiti essenziali dell'Allegato I e agli obblighi degli artt. 13 e 14: fino a **15 milioni di euro o il 2,5% del fatturato mondiale annuo**, se superiore. Documentazione tecnica (art. 31, §§ 1-4), dichiarazione di conformità (art. 28), marcatura CE (art. 30, §§ 1-4): fino a **10 milioni o il 2%**. Informazioni inesatte, incomplete o fuorvianti agli organismi notificati e alle autorità di vigilanza — cioè un fascicolo compilato male — fino a **5 milioni o l'1%**. Ma prima delle sanzioni c'è il blocco: niente fascicolo, niente dichiarazione; niente dichiarazione, niente CE; niente CE, niente mercato unico. Lo stesso schema del [Regolamento Macchine, dove è il manuale a decidere la marcatura](https://csidia.com/note-operative/regolamento-macchine-manuali-istruzioni-2027) dal 20 gennaio 2027.

## Cosa fare adesso

1. **Classificate ogni prodotto**: ordinario, Allegato III classe I o II, Allegato IV. È questo che determina se il fascicolo lo leggerà solo la vigilanza del mercato o anche un organismo notificato.
2. **Generate la SBOM per prodotto e per versione**, leggibile da un dispositivo automatico, almeno con le dipendenze di primo livello, e legatela alla pipeline di rilascio: compilata a mano, alla terza release è già falsa.
3. **Decidete e motivate il periodo di assistenza**: le ragioni della scelta sono un elemento richiesto dall'Allegato VII, punto 4, non una nota interna.
4. **Classificate la SBOM come documento riservato oggi**, non alla prima richiesta motivata: chi la vede, con quale canale la trasmettete, dove è archiviata. È la prova delle «misure ragionevolmente adeguate».
5. **Unificate il fascicolo**: l'art. 31, § 3 impone una documentazione tecnica unica per i prodotti soggetti anche ad altri atti dell'Unione. Chi sta già riscrivendo manuali per il gennaio 2027 lavora sullo stesso raccoglitore.

## Fonti

- [Regolamento (UE) 2024/2847 (Cyber Resilience Act) — testo ufficiale in italiano (EUR-Lex)](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/ita)
- [Commissione europea — Cyber Resilience Act, date di applicazione](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)
- [D.Lgs. 11 maggio 2018, n. 63 — attuazione della direttiva (UE) 2016/943 sui segreti commerciali (Normattiva)](https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:2018-05-11;63)

Nota di CSIDIA S.r.l. (Vignola, MO): https://csidia.com/note-operative/cyber-resilience-act-sbom-fascicolo-tecnico-2027/ · Chi siamo e che cosa facciamo: https://csidia.com/in-breve/ · engagement@csidia.com