Cyber Resilience Act software: la tua web app deve segnalare le vulnerabilità dall'11 settembre 2026? Dipende da dove gira

Se la tua web app vive su un server e la gente la usa dal browser senza installare niente, in generale no: il Cyber Resilience Act la tratta come un servizio, non come un prodotto. Se invece è un'app scaricata da uno store, un programma installato sul computer o un dispositivo che parla con un tuo backend, sì: dall'11 settembre 2026 le vulnerabilità sfruttate e gli incidenti gravi vanno segnalati a ENISA, e il preallarme va dato entro 24 ore.

Questa è la risposta corta. Quella lunga sta nella riga che separa i due casi, e la riga non passa dove la mette il senso comune. Non conta se hai fatto scrivere del codice: conta come quel codice arriva a chi lo usa. Sotto ci sono i criteri con cui guardo i progetti che ho in mano, e le domande da portare a un legale prima di firmare il prossimo contratto.

Dall'11 settembre 2026 vale solo la segnalazione, il resto dal dicembre 2027

Il regolamento (UE) 2024/2847 è in vigore dal dicembre 2024, ma si applica a scaglioni. Dall'11 settembre 2026 scatta l'articolo 14: chi fabbrica un prodotto con elementi digitali deve segnalare le vulnerabilità attivamente sfruttate e gli incidenti gravi che toccano la sicurezza del prodotto. Tutto il resto, cioè i requisiti di progettazione sicura, la documentazione tecnica, la marcatura CE e la gestione delle vulnerabilità per l'intero ciclo di vita, arriva l'11 dicembre 2027.

I tempi della segnalazione sono questi:

• preallarme entro 24 ore da quando ti accorgi della vulnerabilità sfruttata o dell'incidente;
• notifica con i dettagli entro 72 ore;
• relazione finale entro 14 giorni da quando esiste una correzione, per le vulnerabilità, ed entro un mese dalla notifica per gli incidenti.

Si fa tutto da un unico portale gestito da ENISA, attivo dall'11 settembre, che inoltra la segnalazione anche allo CSIRT nazionale. Non serve registrarsi prima di avere qualcosa da segnalare: lo dice ENISA stessa. Vanno avvisati anche gli utenti colpiti, con le misure da prendere. E per chi manca gli obblighi di segnalazione le sanzioni arrivano fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo, se più alto.

Un dettaglio che cambia i conti: l'obbligo di segnalazione vale anche per i prodotti già sul mercato prima del dicembre 2027. Il regolamento esonera i prodotti vecchi da quasi tutto, ma non dall'articolo 14.

Il SaaS puro è fuori, quello che si installa è dentro

Un «prodotto con elementi digitali» è un software o un hardware messo sul mercato, insieme alle sue soluzioni di trattamento dei dati a distanza. Un servizio cloud progettato fuori dalla responsabilità del fabbricante di un prodotto non è un prodotto: lo dice un considerando del regolamento, lo stesso in cui si legge che un sito web che non supporta le funzioni di un prodotto è fuori.

Tradotto sui progetti che passano da uno studio come il nostro:

• Sito istituzionale, blog, landing page: fuori.
• Gestionale o piattaforma usata dal browser, ospitata su un server, senza niente da installare: in generale fuori, perché è un servizio e non un prodotto messo sul mercato.
• App per iOS o Android scaricata dallo store: dentro. È software messo a disposizione sul mercato.
• Programma desktop, plugin, agente installato su una macchina del cliente: dentro.
• Backend che serve un'app o un dispositivo: dentro insieme al prodotto, se senza quel backend il prodotto non farebbe una delle sue funzioni. È la «soluzione di trattamento dei dati a distanza» della definizione.

L'ultimo caso è quello che inganna. «Il server è nostro, quindi è un servizio» non regge se il server esiste per far funzionare un'app che sta sul telefono del cliente. La domanda da farsi è una: se spengo il backend, l'app continua a fare quello per cui è stata venduta? Se la risposta è no, i due pezzi sono un prodotto solo.

Chi è il fabbricante quando il software è su misura

Il regolamento chiama fabbricante chi sviluppa il prodotto, o lo fa sviluppare, e lo mette sul mercato con il proprio nome o marchio. Sono due condizioni insieme, e la seconda pesa più della prima. Nei progetti su misura le combinazioni che vedo sono tre.

• L'app esce con il marchio del cliente e a scriverla siamo noi: il fabbricante è il cliente. Ha fatto sviluppare il prodotto e lo mette sul mercato a nome suo.
• Il prodotto è nostro, lo diamo in licenza sotto il nostro nome: fabbricanti siamo noi, con tutto quello che segue.
• Software sviluppato per il cliente e usato solo al suo interno, mai messo a disposizione di terzi: qui la questione è se sia mai stato «messo a disposizione sul mercato», e questo è un punto da chiarire con un legale caso per caso.

Il software libero e open source non monetizzato è fuori, e anche questo sta nel regolamento. Ma la libreria open source dentro un prodotto commerciale non tira fuori il prodotto: di quello che c'è dentro risponde chi lo mette sul mercato.

Le 24 ore sono un problema di contratto, non di codice

Un preallarme entro 24 ore presuppone tre cose che nella maggior parte dei contratti di sviluppo non ci sono: qualcuno che guarda i log, un modo per capire che una vulnerabilità è stata sfruttata e non solo scoperta, e un nome che decide di segnalare. Mi è capitato di ereditare progetti dove nessuno sapeva dove fossero i log, figuriamoci chi dovesse leggerli.

Per chi commissiona il problema è questo. Se il fabbricante sei tu, la segnalazione sul portale ENISA la firmi tu, ma le informazioni per compilarla (che cosa è successo, in quale versione, con quale correzione) le ha chi ha scritto il codice. Se quel passaggio non è scritto da nessuna parte, le 24 ore passano a cercarsi al telefono.

Le voci che oggi metterei in qualunque contratto di sviluppo o di manutenzione di un prodotto che rientra:

• chi è il fabbricante ai fini del regolamento, cioè con quale nome e marchio esce il prodotto;
• chi monitora, con quali strumenti, e come arriva l'avviso a chi deve segnalare;
• entro quante ore lo sviluppatore consegna i dettagli tecnici, visto che per la notifica completa ne restano 72;
• chi avvisa gli utenti, e come;
• cosa succede quando il contratto di manutenzione finisce e il prodotto resta in uso.

L'ultima voce è quella che nessuno vuole discutere al momento della firma. Ed è la più concreta: l'obbligo di segnalare sta sul fabbricante finché il prodotto è in giro, non finché paga un canone a chi lo ha scritto.

Il lavoro per stare a norma è lo stesso che serve per non farsi male

Secondo me la riga fra SaaS e prodotto durerà poco nella pratica. Chi compra software chiederà le stesse garanzie anche a chi sta fuori dal regolamento. E quello che serve per rispettare l'articolo 14, cioè log leggibili, versioni tracciate, un canale per ricevere segnalazioni e un referente con un numero di telefono, è lo stesso che serve per un prodotto che non si rompe. Quindi lo faccio anche sulla web app dal browser che il regolamento ignora.

Se hai un software in giro con il tuo nome sopra, le domande da farti sono tre: dove gira, con che marchio esce, chi lo guarda dopo la consegna. Se a una di queste rispondi «non lo so», si parte da lì. Per il confine, cioè per capire se il tuo caso è dentro o fuori, il parere va chiesto a un legale che il regolamento lo ha letto tutto: qui ho messo i criteri, non il verdetto.