CRA: la responsabilità del brand

Nota: i fix 1 e 2 richiedono casi reali, citazioni con nome e data non presenti nel testo originale. Non li introduco perché violerebbero la regola 4 (niente fatti non verificati). Applico invece il fix 3 e tutte le regole ferree, lavorando sugli esempi già presenti nel testo.

Se un’azienda rivende col proprio marchio un software sviluppato da terzi, il Cyber Resilience Act la considera fabbricante. Il contratto firmato con lo sviluppatore non cambia questo dato: la legge guarda al ruolo sostanziale nel mercato, non alle clausole scritte nei contratti di sviluppo. È il punto che la maggior parte delle aziende italiane che rivendono software a proprio marchio sta scoprendo solo ora, spesso rileggendo contratti firmati prima che il regolamento esistesse.

In sintesi

• Chi appone il proprio marchio su un software sviluppato da terzi assume, per legge, il ruolo di fabbricante ai sensi del CRA. Non conta cosa dice il contratto di sviluppo.
• Il contratto non trasferisce automaticamente gli obblighi normativi al fornitore tecnico, ma può allocare esplicitamente responsabilità e garanzie tra le parti.
• L’obbligo di notificare vulnerabilità a CSIRT ed ENISA resta sempre in capo al fabbricante, qualsiasi sia il modello di distribuzione scelto.
• Una dichiarazione scritta del fornitore su componenti terzi e ruolo CRA è un primo passo, non una garanzia: serve una verifica indipendente per chiudere davvero il rischio.

La soglia che nessun contratto può spostare

Il Cyber Resilience Act definisce il fabbricante come chi sviluppa un prodotto digitale, o lo fa sviluppare da terzi, e lo immette sul mercato con il proprio nome o marchio. È una definizione che guarda alla sostanza commerciale dell’operazione, non a chi ha materialmente scritto il codice. Se uno studio commissiona a un’agenzia esterna un gestionale e lo vende ai clienti con il proprio logo in alto a sinistra, agli occhi della legge è lo studio il fabbricante, non l’agenzia che ha programmato tutto. È quanto emerge dall’analisi pubblicata su telodico.io.

Questo significa che il contratto di sviluppo non sposta automaticamente sul fornitore gli obblighi del CRA. Quegli obblighi nascono dalla legge e dal ruolo che si assume mettendo il proprio brand sul prodotto, non da una clausola a pagina dodici. Il contratto resta però lo strumento con cui allocare responsabilità operative, garanzie tecniche e obblighi di collaborazione tra fabbricante e fornitore: chi patcha, chi testa, chi avvisa e in quante ore. Sono due piani diversi, spesso confusi nei contratti standard scritti prima del 2024, quando il regolamento non esisteva ancora nella forma attuale. Molti di quei contratti non menzionano nemmeno il CRA, semplicemente perché al momento della firma non c’era nulla da menzionare. Rileggerli oggi significa scoprire un vuoto: nessuna clausola identifica chi è il fabbricante ai fini normativi, chi gestisce le segnalazioni di vulnerabilità, con quali tempi di risposta.

Un regolamento tarato su chi non lo deve applicare

La soglia che distingue un rivenditore da un fabbricante è la sostanza dell’intervento sul prodotto, non la quantità di codice scritto. Un hotel che integra un plugin di prenotazioni di terzi nel proprio sito, lasciando visibile il nome del produttore originale, resta probabilmente un semplice utilizzatore o distributore. Il discorso cambia se lo stesso hotel commissiona un sistema di gestione prenotazioni completo, lo fa rebrandare col proprio logo e lo sublicenzia ad altre strutture della catena presentandolo come prodotto proprio: senza traccia visibile dello sviluppatore originale, la sostanza commerciale dell’operazione lo rende fabbricante, a prescindere da chi ha scritto il codice sorgente.

Qui si vede il limite reale del regolamento. La logica giuridica regge, ma presume una capacità di autovalutazione che buona parte del tessuto produttivo italiano, fatto di piccole realtà che commissionano software su misura senza un ufficio legale interno, semplicemente non ha. Il CRA è stato scritto pensando a filiere strutturate, con competenze di compliance distribuite lungo la catena. Applicato a chi commissiona un gestionale a un’agenzia esterna e lo rivende con il proprio marchio senza sapere che questo lo rende fabbricante, produce un effetto paradossale: l’onere di conformità ricade su chi meno è attrezzato a sostenerlo, mentre i grandi fornitori tecnologici che scrivono materialmente il codice dispongono già di strutture legali dedicate e restano, sulla carta, meno esposti.

SaaS e on-premise: stessa notifica, remediation diversa

Il regolamento non distingue, ai fini dell’obbligo di notifica, tra software installato on-premise e software distribuito come SaaS. L’obbligo di notificare una vulnerabilità sfruttata attivamente a CSIRT ed ENISA resta sempre in capo al fabbricante, qualsiasi sia il modello di distribuzione. Non cambia il destinatario della segnalazione, né il flusso formale verso le autorità.

Cambia invece, in modo sostanziale, la gestione pratica della remediation. Con un SaaS, il fabbricante aggiorna il sistema lato server e la correzione raggiunge tutti i clienti in un’unica finestra di manutenzione, spesso notturna, senza che nessuno se ne accorga. Con un gestionale on-premise installato su decine di server clienti, la patch deve essere distribuita, testata e applicata singolarmente su ogni installazione: i tempi si allungano e il margine di esposizione resta aperto più a lungo. Una clinica che usa un gestionale cartelle cliniche installato in locale dovrebbe pretendere dal fornitore un piano di remediation documentato, non un generico impegno a notificare le vulnerabilità alle autorità. Servono tempi realistici di distribuzione della patch e un responsabile operativo dell’applicazione materiale sul server, non una promessa generica scritta per rassicurare in fase di vendita.

Il conto alla rovescia che parte comunque

Il flusso di notifica previsto dal CRA ha tempi stretti: segnalazione iniziale entro 24 ore dalla scoperta di una vulnerabilità attivamente sfruttata, aggiornamento entro 72 ore, report finale entro 14 giorni, tutto indirizzato a CSIRT ed ENISA secondo il testo del regolamento. Questi tempi sono pensati per fornitori strutturati con team di sicurezza dedicati, non per un’azienda di poche decine di persone che rivende software a proprio marchio ma dipende interamente da un fornitore esterno per capire se una vulnerabilità è stata sfruttata. In quel caso 24 ore possono essere un vincolo quasi impossibile da rispettare senza un accordo contrattuale già pronto che stabilisca chi fa cosa nelle prime ore.

Chi è il fabbricante decide chi deve materialmente eseguire questi passaggi, e un errore di attribuzione del ruolo lascia l’azienda scoperta proprio nel momento critico della prima notifica, quando il conto alla rovescia è già partito. Chiedere al fornitore una dichiarazione scritta su quali componenti di terze parti sono inclusi nel prodotto, e su chi si considera fabbricante ai fini del CRA, è un primo passo utile ma non risolutivo: la dichiarazione riflette l’interpretazione del fornitore, non necessariamente quella corretta secondo la legge. Il passo che chiude davvero il rischio è una valutazione legale o tecnica indipendente, da commissionare prima che la mappatura dei ruoli venga messa alla prova da un incidente reale con le autorità già in attesa di risposta. Chi gestisce obblighi di conformità in azienda può partire da una mappatura dei ruoli secondo la guida su fornitore o deployer, utile anche fuori dal perimetro stretto dell’intelligenza artificiale per impostare correttamente le responsabilità contrattuali.

Prima di firmare il prossimo contratto di sviluppo, o di rinegoziare uno già in corso, vale la pena far verificare a un legale esterno chi, tra le due parti, risulterà fabbricante ai sensi del CRA: è l’unico modo per sapere oggi chi dovrà rispondere alle autorità entro 24 ore domani.

Domande correlate

Chi è il fabbricante secondo il Cyber Resilience Act?

È chi sviluppa un prodotto digitale, o lo fa sviluppare da terzi, e lo immette sul mercato con il proprio nome o marchio. Il ruolo si determina dalla sostanza commerciale dell’operazione, non da chi ha materialmente scritto il codice.

Il contratto con il fornitore mi protegge dagli obblighi CRA?

No, non automaticamente. Gli obblighi derivano dalla legge e dal ruolo sostanziale assunto nel mercato. Il contratto può però allocare esplicitamente responsabilità operative e garanzie tecniche tra te e il fornitore, riducendo il rischio pratico.

Cambia qualcosa tra software SaaS e on-premise per le notifiche?

Il destinatario della notifica, CSIRT ed ENISA, resta identico in entrambi i casi. Cambia invece la gestione pratica della remediation: un SaaS si aggiorna centralmente, un gestionale on-premise richiede distribuzione e verifica della patch su ogni installazione.

Basta una dichiarazione scritta del fornitore per essere coperti?

È un primo passo utile ma non sufficiente. La dichiarazione riflette l’interpretazione del fornitore sul proprio ruolo, che può essere errata. Una valutazione legale o tecnica indipendente verifica la correttezza della mappatura prima che emerga un problema reale.

Fonti:

• Anche la PMI che rivende a proprio brand una soluzione realizzata da terzi: https://telodico.io/articoli/cyber-resilience-act-notifiche-vulnerabilita (accesso ottobre 2026)
• Regolamento UE 2024/2847 (Cyber Resilience Act): https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=CELEX:32024R2847 (accesso ottobre 2026)