Da oggi valgono gli obblighi di segnalazione del CRA: cosa fa chi pubblica plugin

Oggi è l'11 settembre 2026, e da questa data si applica l'articolo 14 del Cyber Resilience Act. Il titolo ufficiale è obblighi di segnalazione del fabbricante. Che si applichi esattamente da oggi è scritto nell'articolo 71 del regolamento (UE) 2024/2847.

Sul CRA si è già scritto molto, quasi tutto alla stessa altezza: esiste un obbligo di segnalazione, esistono scadenze, preparati per tempo. Manca la parte che conta quando arriva davvero una mail in cui qualcuno descrive una falla sfruttata nel tuo plugin. Quale organismo, quale scadenza a partire da quale momento, e cosa metti per iscritto nelle ore successive.

È di questo che si parla qui. È una lettura dello stato della ricerca al 21 agosto 2026 e non è consulenza legale. Dove un dato era incerto, il testo lo dice.

Di chi si parla davvero

Due definizioni reggono tutta la faccenda. Un prodotto con elementi digitali è, secondo l'articolo 3, punto 1, un prodotto software o hardware insieme al trattamento dei dati a distanza, inclusi espressamente i componenti immessi sul mercato separatamente. Un plugin distribuito per conto proprio rientra in quella formulazione. Fabbricante è, secondo l'articolo 3, punto 13, chi sviluppa tali prodotti o li fa sviluppare e li commercializza con il proprio nome o marchio, a pagamento, dietro monetizzazione o gratuitamente. Anche un plugin gratuito pubblicato con il tuo nome nella directory ti rende fabbricante secondo la lettera del testo.

La parte onesta: questa lettura si regge bene sulle definizioni primarie, ma a oggi non esiste alcuna presa di posizione di un'autorità o della Commissione che nomini espressamente i plugin di WordPress.

Tre date, e solo una è oggi

Il CRA arriva a scaglioni, ed è lì che nasce la confusione più frequente nelle discussioni. L'articolo 71 nomina tre date:

• 11 giugno 2026: si applica il capo IV, le norme sugli organismi notificati. Per chi pubblica plugin senza valutazione della conformità non cambia nulla.
• 11 settembre 2026: si applica l'articolo 14, gli obblighi di segnalazione. È oggi.
• 11 dicembre 2027: si applica il resto del regolamento. Rientrano marcatura CE, documentazione tecnica, valutazione della conformità e la distinta base del software dell'allegato I, parte II.

Quello che inizia oggi è l'obbligo di segnalare quando succede qualcosa. Quello che inizia nel 2027 è l'obbligo di dimostrare in modo permanente come sviluppi. Chi compra oggi strumenti per la SBOM compra per fra due anni.

Due percorsi di segnalazione con scadenze separate

La formula 24 ore, 72 ore, 14 giorni compare in quasi ogni articolo di sintesi. Descrive esattamente uno dei due casi che l'articolo 14 disciplina. Il secondo caso ha le stesse prime due tappe e termina su una scadenza diversa.

Percorso 1: vulnerabilità sfruttata attivamente

Percorso 2: incidente di sicurezza grave

Due cose spariscono nella formula breve. La prima: nell'incidente la relazione finale scade dopo un mese, e non dopo 14 giorni. L'autorità tedesca BSI cita questa scadenza di un mese sulle proprie pagine. La seconda: le scadenze non partono tutte dallo stesso punto. Le 24 e le 72 ore decorrono dal momento in cui si viene a conoscenza, i 14 giorni decorrono dal momento in cui una misura correttiva è disponibile, e il mese decorre dal momento in cui hai presentato la notifica delle 72 ore.

In pratica la relazione finale del percorso vulnerabilità può scadere settimane dopo l'allerta precoce. La sua voce in calendario nasce solo quando la correzione esiste.

Cosa fa scattare l'obbligo e cosa no

Una vulnerabilità sfruttata attivamente presuppone indizi solidi che un attaccante la stia sfruttando davvero. Un incidente di sicurezza grave è un evento che pregiudica o può pregiudicare la capacità del prodotto di proteggere la disponibilità, l'autenticità, l'integrità o la riservatezza dei dati.

Un errore ordinario non fa scattare alcuna segnalazione, e nemmeno un aggiornamento di routine. Una falla che un ricercatore di sicurezza ti comunica e che nessuno sfrutta va nel normale percorso di correzione. Chi invece riceve indizi di uno sfruttamento in corso e ci pensa su tre giorni ha già perso la prima scadenza. Questa distinzione è la prima domanda a cui si risponde quando il caso è reale.

Il secondo obbligo, quello che passa inosservato

L'articolo 14, paragrafo 8, obbliga il fabbricante a informare gli utenti del prodotto sulla vulnerabilità o sull'incidente e, se del caso, sulle misure che gli utenti stessi possono adottare, in formato leggibile da una macchina ove necessario.

È un obbligo autonomo accanto alla segnalazione alle autorità, e per chi pubblica plugin è la parte più visibile del regolamento, perché la nota ogni cliente. Senza preparazione è anche la parte che fallisce per prima: se distribuisci il plugin gratis tramite wordpress.org, non conosci i tuoi utenti. Hai il canale di aggiornamento, le note di versione e il readme. Chi lascia gli aggiornamenti fermi non riceve l'informazione nemmeno se la mandi bene, e da lì si apre un altro tema, quello di tenere aggiornati i plugin di WordPress.

Dove va la segnalazione, e perché oggi ancora si inceppa

Si segnala contemporaneamente al CSIRT di coordinamento e all'ENISA, tramite la piattaforma unica di segnalazione dell'articolo 16, la Single Reporting Platform. Il CSIRT che riceve smista la segnalazione ai CSIRT degli altri Stati membri in cui il prodotto è distribuito.

Questo dice il regolamento. Lo stato reale al 21 agosto 2026 era questo:

• La piattaforma non era raggiungibile pubblicamente. L'ENISA lo formulava al futuro: dall'11 settembre 2026 sarà usata da CSIRT e fabbricanti per le segnalazioni obbligatorie.
• Non c'era alcun link pubblico di registrazione. L'indirizzo produttivo della piattaforma non era stato pubblicato.
• Esistevano documenti guida dell'ENISA per la registrazione e per la presentazione delle segnalazioni, aggiornati l'ultima volta a luglio e ad agosto 2026, e un indirizzo di assistenza: cra-srp-helpdesk@enisa.europa.eu.
• Secondo quelle guide l'accesso passa da EU Login. Al primo accesso vengono richiesti il ruolo, il CSIRT competente, un accordo giuridico e i dati del fabbricante.

Un aggiornamento dell'ENISA del 3 agosto 2026 toglie un po' di pressione. La convalida del tuo account da parte del CSIRT di coordinamento non è un presupposto perché l'obbligo di segnalazione sia soddisfatto; corre in parallelo, quindi un account non ancora abilitato non ti mette da solo in violazione. L'inoltro ai CSIRT di altri Stati membri avviene manualmente. E l'ENISA consiglia di creare in anticipo l'account EU Login, ma di registrarsi sulla piattaforma solo quando c'è una segnalazione concreta da presentare. Questi punti provengono da una fonte secondaria, i documenti guida dell'ENISA non erano liberamente consultabili.

La parte nazionale: a quale organismo si segnala

Si segnala al CSIRT dello Stato membro dello stabilimento principale. Quale sia quell'organismo cambia da paese a paese, perché lo designa ogni Stato membro. Conviene cercarlo prima di averne bisogno e annotarlo accanto al proprio indirizzo di sicurezza.

La Germania serve da esempio, perché lì la designazione è già pubblicata: il BSI con il CERT-Bund. Il BSI conferma sulle proprie pagine la scala delle scadenze, compresa la relazione finale a un mese, e rimanda all'ENISA per la piattaforma. La legge tedesca di attuazione non era ancora in vigore il 21 agosto 2026. Il disegno di legge risulta come documento del Bundestag 21/6134 del 26 maggio 2026, prima lettura l'11 giugno 2026, poi rinvio alla commissione interni, senza obiezioni del Bundesrat. Non crea obblighi nuovi, distribuisce competenze. In altri Stati membri l'attuazione nazionale segue un calendario proprio.

Il confronto con l'AI Act è istruttivo. Lì la legge tedesca di attuazione è in vigore dal 29 luglio 2026. Per il CRA è ancora in iter, mentre il regolamento si applica oggi in modo diretto. Un regolamento non aspetta la legge nazionale che lo accompagna, e questo vale in qualunque Stato membro tu sia stabilito.

Quanto costa la segnalazione che non parte

L'articolo 64, paragrafo 2, prevede per le violazioni dei requisiti essenziali dell'allegato I e degli obblighi degli articoli 13 e 14 sanzioni pecuniarie fino a 15.000.000 di euro oppure, per le imprese, fino al 2,5 per cento del fatturato mondiale totale annuo dell'esercizio precedente, a seconda di quale dei due importi sia più elevato. Quest'ultima precisazione viene spesso omessa, e la sua assenza rovescia il senso. Non è una possibilità di scegliere l'importo più basso.

Per collocarlo: l'articolo 64, paragrafo 3, prevede fino a 10.000.000 di euro o il 2 per cento per altri obblighi, e il paragrafo 4 fino a 5.000.000 di euro o l'1 per cento per informazioni inesatte, incomplete o fuorvianti fornite a organismi notificati e autorità di vigilanza del mercato.

E poi c'è l'articolo 64, paragrafo 10, con un'eccezione che quasi nessuno cita. Le sanzioni pecuniarie non si applicano ai fabbricanti che sono microimprese o piccole imprese, nella misura in cui si tratti del mancato rispetto del termine dell'articolo 14, paragrafo 2, lettera a, o dell'articolo 14, paragrafo 4, lettera a. Sono le due allerte precoci di 24 ore. Sono esclusi dalle sanzioni previste da quella disposizione anche gli amministratori di software libero, gli open-source software steward.

L'eccezione è stretta e viene letta troppo larga con regolarità. Riguarda il termine dell'allerta precoce. Non libera dall'obbligo di segnalazione in sé, non copre la notifica delle 72 ore e non copre la relazione finale. Un fornitore piccolo che semplicemente non segnala rientra nella stessa cornice sanzionatoria di uno grande.

Le prime 24 ore, in pratica

Quello che segue è un modello di lavoro, non la riproduzione di un modulo di legge. Il regolamento nomina scadenze e destinatari. Quali campi il modulo della piattaforma richieda davvero non era consultabile pubblicamente il 21 agosto 2026. Qui c'è il materiale che comunque va raccolto per segnalare.

Ora zero. La segnalazione arriva, per mail al tuo indirizzo di sicurezza, dal forum di assistenza o da una piattaforma di divulgazione. Annota data e ora al minuto. Lì inizia la scadenza, ed è l'unico dato che dopo non si ricostruisce.

Prima ora. Una persona decide quale percorso. Ci sono indizi di sfruttamento reale, voci di log, installazioni compromesse, un exploit pubblico? Allora percorso 1. È successo qualcosa che intacca la funzione protettiva del prodotto, un aggiornamento manomesso o un'intrusione nell'infrastruttura di build? Allora percorso 2. Entrambi insieme sono possibili, e nel dubbio vale il percorso più severo. La decisione viene messa per iscritto.

Entro la quarta ora. Determinare l'ambito: quale prodotto, quali versioni, da quando, quale configurazione è interessata, se esiste una contromisura senza aggiornamento. In parallelo, tenere il contatto con chi ha segnalato perché non pubblichi nel frattempo.

Entro la ventiquattresima ora. Presentare l'allerta precoce. Si chiama allerta precoce e non analisi, e può contenere punti aperti.

Cosa serve per l'allerta precoce

• Nome del prodotto, versioni interessate, dati del fabbricante.
• Momento e fonte della conoscenza.
• Breve descrizione di cosa è successo e di cosa fa concludere che ci sia sfruttamento.
• Prima valutazione dell'impatto e della diffusione delle versioni interessate.
• Gli Stati membri in cui il prodotto è disponibile. Per un plugin nella directory aperta è tutta l'Unione.
• Cosa è già in corso e quando si prevede una correzione.

Cosa va nel registro interno

Il registro è la metà meno vistosa e più utile del lavoro. È quello che dopo risponde alla domanda se le scadenze sono state rispettate. Basta un file di testo nel repository, purché qualcuno lo tenga.

• Momento e fonte della conoscenza.
• La decisione sul percorso, con due frasi di motivazione.
• Momento dell'allerta precoce, della notifica delle 72 ore e della relazione finale, ciascuno con il destinatario.
• Momento a partire dal quale una misura correttiva era disponibile. Da lì si contano i 14 giorni nel percorso vulnerabilità.
• La versione dell'informativa ai clienti così come è uscita, e quando.
• Versioni interessate e versione che contiene la correzione.

Come si scrive l'informativa ai clienti

Breve, oggettiva, senza rassicurazioni di comodo. Nominare le versioni interessate, dire cosa deve fare adesso un utente, dire da quale versione il problema è risolto. Se esiste una misura provvisoria, sta in cima. In un plugin WordPress il posto è il readme con la voce di changelog e l'aggiornamento stesso, più la pagina sulla sicurezza e, se esiste una lista clienti, una mail. La parte leggibile da una macchina dell'articolo 14, paragrafo 8, in un plugin è di fatto l'indicazione di versione nel canale di aggiornamento.

Cosa deve esserci prima, per non cercarlo nell'emergenza

• Un contatto di sicurezza pubblicato, meglio una casella dedicata che il forum di assistenza.
• Un /.well-known/security.txt secondo la RFC 9116, così chi segnala trova la strada senza indovinare.
• Una politica di divulgazione coordinata: cosa prometti, cosa chiedi, qual è l'ambito.
• Un modo per raggiungere tutti gli utenti interessati. Per i plugin gratuiti della directory è il canale di aggiornamento con il readme, per i prodotti a pagamento la lista clienti.
• Un posto fisso per il registro, creato prima di averne bisogno.

Tutto questo non richiede un fine settimana. In mezzo a un incidente richiede troppo tempo. Quali strumenti aiutano a tenere d'occhio le installazioni è materia di un altro confronto fra plugin di sicurezza.

A che punto siamo noi

Perché una guida che si limita a pretendere vale poco: da noi c'è una pagina sulla sicurezza con contatto di sicurezza pubblicato, tempi di risposta promessi, ambito definito e la politica di divulgazione coordinata, più un /.well-known/security.txt secondo la RFC 9116 che rimanda a quella pagina. Dietro c'è la dichiarazione del fabbricante, scritta perché chi segnala non debba chiedere da dove si entra.

Anche quello che da noi non c'è ancora appartiene a questo paragrafo. Dei nostri plugin gratuiti nella directory di WordPress, per esempio Wellenbrecher, non conosciamo le installazioni. La nostra strada verso quegli utenti è il canale di aggiornamento e il readme, nient'altro. La registrazione sulla piattaforma di segnalazione non è ancora possibile, si può preparare solo l'account EU Login. E il nostro registro degli incidenti resta interno, non è una pagina pubblica.

Domande frequenti