Sono un fabbricante? La domanda del CRA senza risposta.
Chi pubblica un plugin vuole sapere se il regolamento sulla ciberresilienza lo rende fabbricante. Le fonti disponibili danno due risposte diverse.
La domanda sta in una frase. Hai costruito un plugin per WordPress, sta nella directory aperta, chiunque può scaricarlo e accanto vendi una versione Pro. Questo ti rende fabbricante ai sensi del regolamento sulla ciberresilienza, il regolamento (UE) 2024/2847?
La risposta onesta è scomoda. Dipende, le fonti si contraddicono proprio su questo punto e una parte delle voci più forti sul mercato vende gli strumenti che dovrebbero risolvere la questione. Ad agosto 2026 abbiamo verificato in modo sistematico, contro le fonti disponibili, l'affermazione secondo cui i plugin gratuiti con versione Pro rientrano automaticamente nel CRA. Il risultato non è un sì netto e non è un no netto.
Per questo qui non trovi una risposta che non esiste. Trovi cosa dice il regolamento, cosa dice la Commissione a riguardo, dove le due cose divergono e con quali domande mettere in ordine la propria situazione. Questo è un inquadramento e non una consulenza legale.
La frase che fa sobbalzare quasi tutti
Si parte dalla definizione. L'eccezione viene dopo. L'articolo 3, punto 1 del CRA descrive il prodotto con elementi digitali come "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Portato sul nostro caso: un modulo software distribuito separatamente rientra. Un plugin è un modulo software distribuito separatamente.
L'articolo 3, punto 13 definisce poi il fabbricante: chi sviluppa o fa sviluppare prodotti con elementi digitali e li immette sul mercato con il proprio nome o marchio, "whether for payment, monetisation or free of charge". Quest'ultima formula è il punto in cui la discussione di solito finisce prima di cominciare. Dice che il prezzo non fa parte della nozione di fabbricante: far pagare, monetizzare in altro modo o regalare sono equivalenti. Conta l'immissione sul mercato con nome proprio.
Una riserva vale per tutto l'articolo: durante la ricerca EUR-Lex non ha restituito contenuti in nessuna delle forme di URL provate. Le citazioni degli articoli provengono da riproduzioni del testo integrale che coincidevano tra loro. Per questo restano in inglese e vengono spiegate accanto invece di essere tradotte: una traduzione nostra simulerebbe una precisione che non è documentata. Chi riusa una citazione letterale la verifichi prima su EUR-Lex.
Il contrappeso sta nella guida della Commissione
A fine luglio 2026 la Commissione europea ha pubblicato una guida applicativa sul CRA, riferimento C(2026) 5252, composta da una comunicazione e da un allegato con le istruzioni vere e proprie. Circa 80 pagine, 67 esempi pratici, diagrammi di flusso, con microimprese e PMI come destinatari dichiarati. Piccola nota sulla precisione: la Commissione data il documento Bruxelles, 27 luglio 2026, mentre heise online riferisce di una pubblicazione il 28 luglio 2026. Probabilmente data di emissione contro data di pubblicazione. Per questo scriviamo fine luglio e indichiamo il riferimento.
Nel merito la guida dice sull'open source il contrario di quello che molti si aspettano dopo aver letto l'articolo 3: il software open source liberamente disponibile resta in linea di principio fuori dall'ambito di applicazione del CRA finché non viene commercializzato. Come attività commerciale valgono secondo la guida, tra le altre cose, la vendita del software, le edizioni enterprise a pagamento, la monetizzazione di servizi tramite il programma, la richiesta di dati personali oltre le finalità di sicurezza e interoperabilità e le donazioni che di fatto sono condizione di accesso.
Espressamente non commerciali sono secondo la guida i contributi volontari, il finanziamento pubblico e la sponsorizzazione presi da soli. I servizi di supporto a pagamento non sottopongono automaticamente un progetto al CRA, finché il software stesso resta liberamente disponibile.
Va notato cosa manca nel regolamento: il CRA non definisce la nozione di attività commerciale in modo autonomo nell'articolato. I criteri vengono dai considerando e da questa guida. È esattamente da lì che nasce lo spazio in cui le letture divergono.
L'amministratore è un regime più leggero, non un lasciapassare
Tra il fabbricante e chi non è coinvolto esiste un terzo ruolo. L'articolo 3, punto 14 del CRA definisce l'amministratore di software open source (open-source software steward) come la persona giuridica che non è un fabbricante e il cui scopo consiste nel sostenere in modo duraturo e sistematico lo sviluppo di determinati prodotti con elementi digitali che sono software libero e open source e sono destinati ad attività commerciali.
Quello che ne deriva sta nell'articolo 24. Il paragrafo 1 richiede una politica di cibersicurezza documentata che favorisca lo sviluppo sicuro e la gestione delle vulnerabilità, compresa la segnalazione volontaria prevista dall'articolo 15. Il paragrafo 2 richiede la cooperazione con le autorità di vigilanza del mercato e, su richiesta motivata, la consegna della documentazione in una lingua facilmente comprensibile per l'autorità. Il paragrafo 3 rende applicabile agli amministratori l'articolo 14, paragrafo 1 per i prodotti al cui sviluppo partecipano, e l'articolo 14, paragrafi 3 e 8 nella misura in cui incidenti gravi riguardino la loro stessa infrastruttura di sviluppo.
Va tenuta a mente la combinazione: gli amministratori hanno un obbligo di segnalazione dall'11 settembre 2026, ma secondo l'articolo 64, paragrafo 10 nessuna sanzione pecuniaria. Chi sente "rientra nel CRA" e pensa alle multe ha l'immagine sbagliata per questo ruolo. Cosa vale per i fabbricanti dall'11 settembre 2026 e quali termini scattano è spiegato nell'articolo sugli obblighi di segnalazione del CRA.
Qui le fonti si dividono
Il caso centrale è il plugin gratuito nella directory aperta e accanto una versione Pro a pagamento dello stesso fornitore. Ci sono due letture e portano a risultati diversi.
Lettura A: la versione gratuita si valuta da sola
Secondo questa lettura la versione libera va esaminata a sé. Se non viene monetizzata essa stessa, quindi nessun acquisto necessario, nessun blocco di accesso o di aggiornamenti dietro pagamento, nessun trattamento di dati oltre le finalità di sicurezza e interoperabilità, allora non ricade automaticamente negli obblighi completi del fabbricante solo perché lo stesso fornitore vende accanto una versione Pro. L'Open Regulatory Compliance Working Group riporta la guida nel senso che una persona giuridica può assumere ruoli diversi allo stesso tempo, anche per versioni diverse dello stesso software, edizione community ed edizione monetizzata comprese. A sostegno c'è il considerando 18 del regolamento, secondo cui la fornitura di prodotti che sono software libero e open source e che non vengono monetizzati dai loro fabbricanti non dovrebbe essere considerata attività commerciale. Il considerando 18 registra inoltre che la mera esistenza di rilasci regolari e il mero sostegno finanziario da parte di fabbricanti non bastano di per sé a dare natura commerciale all'attività.
Lettura B: la versione Pro tinge quella gratuita
Diversi fornitori specializzati in conformità al CRA formulano in modo più ampio. Chi vende il plugin, offre una versione Pro, presta supporto a pagamento o lo monetizza in qualche modo fornirebbe nell'ambito di un'attività commerciale e rientrerebbe nell'ambito di applicazione, indipendentemente dalla licenza GPL. È interessante che uno di questi stessi fornitori altrove distingua di nuovo e guardi se il prodotto gratuito serva da strumento di vendita per un'offerta a pagamento.
E ora la dichiarazione che appartiene a questa posizione: questi fornitori vendono strumenti e consulenza di conformità al CRA a chi sviluppa plugin. Un interesse economico a una lettura il più ampia possibile dell'ambito di applicazione non si può escludere, perché più sviluppatori coinvolti significano più clienti. Non è un'insinuazione e non rende falsa l'affermazione. Significa soltanto che quella formulazione non viene dalla guida. È la sua interpretazione da parte di operatori di mercato con un interesse proprio. Chi pesa una fonte pesa anche il suo interesse.
Un'altra riserva che quasi nessuno consegna insieme al consiglio: l'allegato di C(2026) 5252 non è stato elaborabile in modo automatico. Tutte le affermazioni di merito sull'open source in questo articolo vengono dal comunicato stampa della Commissione, dalla stampa specializzata e da blog di organizzazioni. Non abbiamo riletto i 67 esempi né i criteri esatti di delimitazione. Chi ti dice di sapere con precisione cosa c'è a pagina 41 ha più accesso di noi oppure racconta più di quanto sa.
A questo si aggiunge che non esiste alcuna presa di posizione di un'autorità o della Commissione che nomini espressamente i plugin di WordPress. Inquadrare i plugin come prodotto con elementi digitali è ben argomentabile attraverso l'articolo 3, punti 1 e 13. Le fonti che nominano i plugin sono senza eccezione blog di fornitori che vendono strumenti di conformità.
Sette domande per collocare il proprio caso
Le domande che seguono non sostituiscono l'esame del caso da parte di chi è abilitato. Sono una griglia per fare ordine, costruita con i criteri che guida e considerando indicano secondo le fonti valutate. Più spesso la colonna di destra punta verso il commerciale, più ha senso comportarsi per prudenza come un fabbricante.
| Domanda sul proprio prodotto | Cosa significa la risposta |
|---|---|
| L'accesso alla versione gratuita è legato a un pagamento, anche in modo nascosto tramite una registrazione con obbligo di acquisto? | Chiedere un prezzo per il software o per i file precompilati conta come attività commerciale secondo la guida. Un download libero senza controprestazione no. |
| La versione gratuita riceve aggiornamenti di sicurezza solo dietro pagamento? | Bloccare gli aggiornamenti dietro pagamento è, secondo la lettura valutata, uno degli argomenti più forti per considerare monetizzata la versione libera stessa. |
| Vengono richiesti dati personali oltre le finalità di sicurezza e interoperabilità? | La guida indica esattamente questo come attività commerciale. Raccogliere un indirizzo e-mail per il download è quindi un fattore di rischio, non un dettaglio. |
| La versione gratuita è autonoma dal punto di vista funzionale oppure è un paywall davanti alla funzione vera? | Un prodotto utilizzabile da solo parla per la lettura A. Un guscio gratuito che senza acquisto non fa nulla parla per il legame funzionale con la vendita. |
| Vengono monetizzati altri servizi attraverso il programma, per esempio pubblicità o raccolta di dati? | Il software come piattaforma per monetizzare altri prodotti conta come attività commerciale secondo la guida, anche se il software stesso è gratuito. |
| Le donazioni sono di fatto condizione per accedere al software o agli aggiornamenti? | Le donazioni volontarie senza scopo di lucro non sono commerciali. Le donazioni che di fatto sono condizione di accesso lo sono. |
| L'immissione sul mercato avviene con nome o marchio proprio? | È l'elemento dell'articolo 3, punto 13 che opera indipendentemente dal prezzo. Da solo non risponde alla domanda sul fabbricante, ma è la porta da cui quella domanda entra. |
Se vuoi tradurre il risultato in qualcosa di utilizzabile: la parte che ha senso a prescindere dall'inquadramento è un file security.txt con i recapiti pubblici per le segnalazioni di vulnerabilità. Quello si può preparare oggi, senza aver risolto prima la domanda sul fabbricante.
Come ci collochiamo noi
hafenstudios è esattamente il caso di cui si discute. Abbiamo diversi plugin con versione gratuita e versione Pro a pagamento, tra cui Wellenbrecher, che dal 21 agosto 2026 è nella directory di WordPress. Con il tema Hafen abbiamo anche software senza alcuna edizione a pagamento. Tutto è sotto GPLv2 o successiva.
La nostra posizione: ci comportiamo come un fabbricante. È l'ipotesi prudente e ci costa meno di quanto costerebbe aver sbagliato nel caso serio. In pratica significa canali di contatto documentati per le segnalazioni di vulnerabilità, una procedura per i termini dell'articolo 14 e la preparazione al programma completo di obblighi dall'11 dicembre 2027, quando arrivano marcatura CE, documentazione tecnica, valutazione della conformità e la distinta base del software dell'allegato I, parte II.
Diciamo apertamente che la questione non è chiusa. Un appuntamento con un avvocato è in programma. È più onesto che affermare qui una certezza che le fonti non danno. Di nuovo, nel punto in cui conta: questo articolo è un inquadramento e non una consulenza legale. Per la valutazione vincolante del tuo caso serve qualcuno abilitato.
L'incertezza è il danno vero
Ora l'opinione per cui questo articolo è stato scritto. Il problema di questa situazione non è la regolazione in sé. Requisiti di sicurezza per software che gira su centinaia di migliaia di siti si giustificano senza fatica. Il problema è che nessuno può dire in modo affidabile chi è coinvolto.
Questa incertezza si distribuisce in modo diseguale. Un gruppo grande ha un ufficio legale che scrive una valutazione e un budget che sopravvive a una valutazione sbagliata. Un'attività di due persone ha una serata e una pagina di risultati in cui i primi cinque arrivano da fornitori che vogliono venderle un abbonamento. Il costo dell'incertezza lo paga il piccolo, anche se la guida è stata scritta espressamente per microimprese e PMI.
Il quadro nazionale non rende le cose più tranquille, e lì conviene guardare al proprio paese. La segnalazione va al CSIRT dello Stato membro dello stabilimento principale, e l'attuazione nazionale è stata risolta in modo diverso in ogni Stato membro. In Germania, dove siamo noi, il destinatario è il BSI con CERT-Bund, e la legge tedesca di attuazione del CRA al 21 agosto 2026 non era ancora in vigore: è depositata come documento del Bundestag 21/6134 del 26 maggio 2026, prima lettura l'11 giugno 2026. Non crea obblighi nuovi, indica le competenze. L'articolo 14 vale l'11 settembre 2026 a prescindere. Se il tuo stabilimento principale è in un altro Stato membro, autorità competente e calendario nazionale vanno verificati lì.
Quello che ne deriva è poco spettacolare. Comportati per prudenza come un fabbricante se più di una delle sette domande punta verso il commerciale. Documenta come sei arrivato al tuo inquadramento. E diffida di ogni fonte che risponde a questa domanda in due frasi, soprattutto se nella terza vende qualcosa.
Cosa pubblichiamo su sicurezza e canali di segnalazione
Sulla nostra pagina dedicata alla sicurezza è spiegato come segnalare una vulnerabilità in uno dei nostri plugin, come la trattiamo e in quali tempi. È la parte che un fornitore deve garantire a prescindere dalla domanda sul fabbricante.
Domande frequenti
Regalare il software mi rende davvero fabbricante?
Secondo l'articolo 3, punto 13 del CRA il prezzo non conta. È fabbricante chi sviluppa o fa sviluppare un prodotto con elementi digitali e lo immette sul mercato con il proprio nome o marchio, nella formula inglese "whether for payment, monetisation or free of charge", quindi a pagamento, con altra monetizzazione o gratis. Se questa immissione sul mercato avvenga nell'ambito di un'attività commerciale è la seconda domanda, quella controversa. Il CRA non definisce questa nozione nell'articolato.
Il mio plugin gratuito rientra automaticamente nel CRA perché esiste una versione Pro?
Secondo le fonti che si occupano della guida stessa, non automaticamente. Descrivono un esame caso per caso: una versione autonoma e non monetizzata resta nel regime più leggero o fuori ambito, a meno che sia monetizzata essa stessa o legata funzionalmente alla vendita. I fornitori commerciali di conformità sostengono la lettura ampia. La questione non è chiusa.
Che cos'è un amministratore di software open source?
L'articolo 3, punto 14 del CRA descrive una persona giuridica che non è un fabbricante e il cui scopo consiste nel sostenere in modo duraturo e sistematico lo sviluppo di determinati prodotti open source destinati ad attività commerciali. L'articolo 24 richiede una politica di cibersicurezza documentata, la cooperazione con le autorità e un obbligo di segnalazione limitato. Secondo l'articolo 64, paragrafo 10 gli amministratori sono esclusi dalle sanzioni pecuniarie previste da quella disposizione.
La guida della Commissione è vincolante?
No. La Commissione stessa chiarisce che solo la Corte di giustizia dell'Unione europea può interpretare il diritto dell'Unione in modo vincolante. C(2026) 5252 non cambia nessun obbligo e nessuna scadenza. Per le autorità di vigilanza del mercato resterà comunque un punto di riferimento pratico, per questo va conosciuta senza scambiarla per legge.
Da quando vale cosa?
Il capo IV sugli organismi notificati vale dall'11 giugno 2026. L'articolo 14 con gli obblighi di segnalazione dei fabbricanti vale dall'11 settembre 2026. Il resto del regolamento vale dall'11 dicembre 2027, e comprende marcatura CE, documentazione tecnica, valutazione della conformità e la distinta base del software dell'allegato I, parte II. La fonte delle tre date è l'articolo 71 del CRA.
