CRA Articolo 14: 24 ore per segnalare, e la piattaforma non è ancora attiva

La maggior parte dei team GRC ha archiviato il Cyber Resilience Act sotto due parole: "prodotto" e "2027".

Entrambe sono sbagliate.

L'obbligo di notifica previsto dall'Articolo 14 si applica a partire dall'11 settembre 2026. Non dal dicembre 2027. Quella è la data che tutti ricordano, ed è quella sbagliata.

Tre settimane.

E non riguarda soltanto ciò che commercializzerete il prossimo anno. Riguarda ciò che avete già commercializzato. Un prodotto immesso sul mercato UE nel 2018 e ancora disponibile oggi rientra nell'ambito di applicazione dell'obbligo di notifica dal giorno in cui questo entra in vigore.

Se la vostra organizzazione vende nell'UE qualsiasi prodotto con elementi digitali, questo è il vostro processo di gestione degli incidenti, non la documentazione del team di prodotto.

Cosa prevede effettivamente l'Articolo 14

Due trigger, tre scadenze, un canale.

I trigger:

• una vulnerabilità attivamente sfruttata nel vostro prodotto
• un incidente grave che ha un impatto sulla sicurezza del vostro prodotto

Le scadenze:

• 24 ore: allerta precoce, dal momento in cui si viene a conoscenza del fatto
• 72 ore: notifica completa, incluse le misure correttive o di mitigazione adottate
• 14 giorni: relazione finale, una volta disponibile una misura correttiva per una vulnerabilità attivamente sfruttata
• un mese: relazione finale per un incidente grave, una volta gestito

Il canale:

Un'unica segnalazione tramite la Single Reporting Platform di ENISA, indirizzata al CSIRT del luogo in cui si ha la sede principale, resa disponibile a ENISA contestualmente.

Si noti cosa non è incluso. Non si tratta di "notificare ogni CVE". Il trigger è lo sfruttamento attivo in rete, oppure un incidente grave. Questa distinzione è la differenza tra un processo gestibile e un team che affoga alla seconda settimana.

Analizziamo nel dettaglio cosa è necessario fare correttamente.

1. La data è il 2026. Quella che avete memorizzato è il 2027.

Il CRA (Regolamento (UE) 2024/2847) è entrato in vigore il 10 dicembre 2024. La maggior parte degli obblighi (security by design, documentazione tecnica, valutazione della conformità, marcatura CE) si applica dall'11 dicembre 2027.

L'Articolo 71(2) isola gli obblighi di notifica e li anticipa di quindici mesi.

Poi l'Articolo 69(3) chiude la via d'uscita. Le disposizioni transitorie che consentono ai prodotti già esistenti di restare sul mercato fino al dicembre 2027 senza piena conformità non si estendono alla notifica.

Pertanto, il perimetro in scope l'11 settembre non è la roadmap 2027. È l'intera base installata.

Suggerimento: Se il vostro inventario di prodotti elenca solo ciò che è in sviluppo attivo, non avete un inventario di prodotti. Avete un backlog.

2. Il contatore parte dal momento in cui si è "a conoscenza". Nessuno ha definito questo termine.

È qui che tutto regge o crolla, e non è una questione legale.

Ventiquattro ore non sono un tempo lungo. Sono un giorno lavorativo, o una notte di sabato. Il contatore non parte quando il team legale concorda che esiste un problema. Parte nel momento in cui l'organizzazione ne viene a conoscenza.

Chi è dunque "l'organizzazione"?

• un ingegnere del supporto che vede un ticket anomalo alle 19:00
• un ricercatore che scrive all'indirizzo generico security@
• un feed di threat intelligence che segnala il nome del vostro prodotto
• il SOC di un cliente che chiama il vostro account manager

Ognuno di questi può essere il momento della conoscenza. Se nessuno sa cosa fare dopo, le vostre 24 ore bruciano mentre un'email resta non letta.

Prima di settembre è necessario avere scritto tre cose:

• quale evento costituisce la conoscenza, in linguaggio chiaro
• chi è autorizzato a dichiararlo, con un sostituto nominato
• dove viene registrato il contatore, in modo da poter dimostrare quando è partito

Quest'ultimo punto conta più di quanto ci si aspetti. Se un'autorità di vigilanza chiede perché l'allerta precoce è arrivata all'ora 31, "siamo venuti a conoscenza del fatto più tardi di quanto si pensi" è una risposta valida solo se lo si può dimostrare.

Aneddoto: Lo abbiamo visto accadere con il GDPR. Una violazione viene dichiarata con tre settimane di ritardo, non perché qualcuno stesse nascondendo qualcosa. Il supporto l'aveva registrata come un bug. L'IT l'aveva chiamata un problema di configurazione. Nessuno nella catena aveva mai concordato su cosa costituisse effettivamente una violazione di dati personali, quindi il contatore non era mai partito. Il team legale l'ha scoperto quando un cliente ha fatto una domanda.

Stesso meccanismo nel CRA, con una finestra più stretta. Le definizioni sono la parte noiosa. Sono anche la parte che determina se si è stati in ritardo.

3. Il CRA vi chiede di notificare prima ancora di chiedervi di ascoltare

Ecco il problema di sequenza che nessuno segnala, e che coglierà di sorpresa i team più attenti.

L'Articolo 13(8) richiede ai produttori di disporre di politiche e procedure, inclusa la politica di divulgazione coordinata delle vulnerabilità prevista dall'Allegato I, Parte II, punto (5), per gestire e rimediare alle vulnerabilità segnalate da fonti interne o esterne.

In realtà ci sono tre obblighi giuridicamente distinti, e nella maggior parte delle aziende un'unica casella di posta li serve tutti e tre:

• una politica CVD, redatta, pubblicata e applicata
• un indirizzo di contatto per la segnalazione di vulnerabilità nei vostri prodotti e nei componenti di terze parti che distribuite
• un punto di contatto unico attraverso cui gli utenti possono raggiungere direttamente una persona

Ora, i tempi. Questi obblighi rientrano nell'Allegato I, Parte II. L'Allegato I diventa giuridicamente vincolante l'11 dicembre 2027. La notifica ai sensi dell'Articolo 14 diventa vincolante l'11 settembre 2026.

Rileggete. Per quindici mesi, la legge vi richiede di notificare vulnerabilità attivamente sfruttate nei vostri prodotti, senza ancora richiedere che operiate il canale attraverso cui verreste a saperlo.

Un team che segue le date alla lettera trascorrerà quei quindici mesi con un contatore di 24 ore attivo e nessun modo affidabile per sapere che il contatore è partito. Perché la risposta onesta alla domanda "come scoprono i produttori lo sfruttamento attivo dei propri prodotti?" è: qualcuno glielo dice.

C'è un secondo motivo per farlo subito. Di tutto ciò che il CRA prevede, la politica CVD e l'indirizzo di contatto sono le due cose visibili dall'esterno della vostra organizzazione. Un'autorità di sorveglianza del mercato che si forma una prima impressione della vostra postura guarderà il vostro sito web prima ancora di chiedervi un documento.

Come si presenta una buona implementazione:

• la politica a un URL stabile e pubblico, non sepolta in una pagina legale
• un file security.txt sul vostro dominio
• una casella di posta monitorata con un responsabile nominato e un sostituto, non un alias che nessuno legge
• ambito dichiarato, tempi di risposta attesi, cosa è compreso o escluso dall'attività di testing, come si gestiscono i riconoscimenti e la pubblicazione
• ogni segnalazione registrata, perché applicare la politica è di per sé l'obbligo

Suggerimento: Non è necessario inventare nulla. ISO/IEC 29147 e ISO/IEC 30111 sono gli standard di riferimento per la divulgazione e la gestione delle vulnerabilità, e il vulnerability disclosure toolkit dell'NCSC è un ottimo punto di partenza gratuito. Pubblicare qualcosa di funzionale in tre settimane vale più di pubblicare qualcosa di perfetto nel dicembre 2027.

4. Non si può notificare ciò che non si sa denominare

La fase delle 72 ore richiede il tipo di prodotto e la sua classificazione. Ciò significa che, prima di un incidente e non durante, è necessario avere:

• l'elenco dei prodotti con elementi digitali immessi sul mercato UE
• per ciascuno, se sia standard, importante (Allegato III, Classe I o II) o critico (Allegato IV)
• un SBOM in un formato comunemente utilizzato e leggibile da macchina

La classificazione segue la funzione principale del prodotto e, laddove si applichi più di una classe, prevale quella più restrittiva.

L'SBOM è la parte che i team sottovalutano. L'Articolo 14 chiede di notificare una vulnerabilità nel vostro prodotto. Se il vostro prodotto incorpora un framework a fine vita che non avete inventariato, non apprenderete che è sotto sfruttamento dalla vostra telemetria. Lo apprenderete da un cliente, o dalle notizie, che è un modo molto costoso per far partire un contatore di 24 ore.

Suggerimento: Fate l'esercizio al contrario. Scegliete un componente che sapete essere presente in tre dei vostri prodotti. Riuscite a produrre quell'elenco in meno di un'ora, oggi, senza chiedere all'ingegneria? Se no, questo è il vostro primo gap.

5. La piattaforma non è operativa. Registratevi comunque.

Ecco la parte che rende questo un articolo e non un memo di compliance.

La Single Reporting Platform, istituita dall'Articolo 16 e gestita da ENISA, è prevista operativa l'11 settembre 2026. Non prima. A metà agosto, l'URL di accesso pubblico non era ancora stato pubblicato. Brevi video e un webinar sono stati promessi due settimane prima del lancio.

L'obbligo è fisso. Lo strumento non lo è. Quel divario è a vostro carico, non del regolatore.

Tre cose non dipendono dall'esistenza della piattaforma:

Create subito gli account EU Login. La registrazione avviene tramite EU Login su ecas.ec.europa.eu. L'account può essere creato oggi. Farlo durante un incidente, con un contatore di 24 ore in corso, è un ritardo autoindotto.

Create due profili, non uno. Esiste un Primary Assigned Representative che si registra selezionando il ruolo, scegliendo il CSIRT coordinatore, accettando l'accordo e inserendo i dati del produttore. Il sostituto, o Secondary AR, viene invitato via email, e tale invito scade dopo sette giorni. Inviatelo e confermatene l'accettazione. Un invito non accettato non è un sostituto.

Non aspettate la validazione del CSIRT. La validazione dell'AR da parte del CSIRT coordinatore avviene dopo la registrazione. Procede in parallelo e non vi impedisce di notificare. I team che ritengono di dover attendere il via libera prima di poter presentare una segnalazione perderanno ore che non si possono permettere.

Le linee guida di ENISA sono cambiate due volte in questo mese. Le guide alla registrazione e alla notifica sono state ridatate il 3 agosto; la guida all'interfaccia è comparsa il 14 agosto. Tutto è contrassegnato come soggetto a modifiche. Costruite il vostro processo interno sui campi obbligatori, non sugli screenshot.

6. Non esistono ancora standard armonizzati

Il 13 agosto 2026, ETSI ha sottoposto 17 bozze finali di standard di prodotto CRA a Public Enquiry. Nessuno di essi è uno standard armonizzato. I commenti si chiudono a partire da metà settembre, con l'approvazione che si estende fino a novembre a seconda del settore.

Gli organismi notificati arriveranno nel dicembre 2026.

La posizione onesta è quindi questa: l'infrastruttura di conformità del CRA è ancora in costruzione, e l'obbligo di notifica arriva comunque per primo.

Se il vostro piano era "inizieremo una volta pubblicati gli standard", avete già perso la finestra di notifica. Gli standard vi dicono come dimostrare che il vostro prodotto soddisfa i requisiti essenziali. Non vi dicono chi presenta l'allerta precoce di domenica.

7. La vostra notifica NIS2 e DORA non copre questo caso

Vedo questa convinzione continuamente, ed è pericolosa perché è quasi giusta.

Potreste già avere un processo rodato di notifica 24/72 ore da NIS2 o DORA. Bene. Non è lo stesso obbligo.

Un unico evento può attivare entrambi gli obblighi. Un incidente grave in un prodotto che producete e al tempo stesso operate genera due segnalazioni, due destinatari, due tracce documentali.

Il riflesso da costruire ora non è un nuovo processo. È un punto di decisione all'inizio del vostro processo esistente: quali regimi tocca questo evento? Rispondete al minuto cinque, non all'ora venti.

Aneddoto: Sarò diretto sulla situazione del mercato. Quasi nessuno dei miei clienti sta chiedendo del CRA in questo momento, perché non stanno ancora prendendo NIS2 abbastanza sul serio da arrivare a questo punto. Tre settimane. Questo è il quadro reale.

L'esempio che posso offrire è quindi il mio. A Mobilexpense, dove ricopro il ruolo di CISO, è esattamente questo che stiamo costruendo: un unico processo di gestione degli incidenti con due rami. Stesso intake, stesse prime domande, e poi un bivio nel punto in cui si decide se l'evento riguarda l'entità, il prodotto, o entrambi. Il bivio è economico da progettare ora. È molto costoso da improvvisare all'ora tre.

8. Cosa si può effettivamente completare prima dell'11 settembre

Tre settimane non sono sufficienti per costruire un programma. Sono sufficienti per costruire la parte che si attiva per prima.

Prima settimana:

• creare gli account EU Login, primario e di sostituzione
• inviare e confermare l'invito per il Secondary AR prima che scada
• identificare il vostro CSIRT coordinatore
• avviare la revisione legale della politica CVD, perché è l'elemento con il lead time più lungo

Seconda settimana:

• pubblicare la politica CVD, l'indirizzo di contatto e il security.txt
• congelare l'elenco dei prodotti in scope, inclusi quelli legacy
• assegnare a ciascuno una classificazione
• redigere la definizione di "conoscenza del fatto" e nominare le due persone autorizzate a dichiararla

Terza settimana:

• costruire l'allerta precoce delle 24 ore come un breve modulo interno che corrisponda ai campi obbligatori
• aggiungere la domanda di routing per regime all'inizio del vostro processo di gestione degli incidenti
• provarlo su carta. Un scenario, una sera di sabato, un cronometro

Quest'ultimo passaggio è quello che tutti saltano ed è l'unico che vi dice se gli altri undici hanno funzionato.

Considerazione finale

La verità scomoda dell'11 settembre è che il regolatore arriva prima dei propri strumenti, e questo non cambia nulla alla vostra posizione.

Non è possibile presentare un'allerta precoce con un certificato ISO 27001. Non è possibile classificare un prodotto con una policy. E non è possibile far partire un contatore di 24 ore con un processo che esiste solo in un documento che nessuno ha mai eseguito.

I produttori che gestiranno bene la situazione a settembre non saranno quelli con la migliore gap analysis CRA. Saranno quelli che, quando il ticket arriva alle 19:00 di un sabato, hanno una persona nominata che sa di essere autorizzata a premere il pulsante.

Tutto il resto è preparazione per quel singolo momento.

Le sanzioni per violazioni dei requisiti essenziali e degli obblighi del produttore raggiungono 15 milioni di euro o il 2,5% del fatturato mondiale annuo totale, se superiore. Ma la sanzione non è il rischio. Il rischio è scoprire, nel momento decisivo, che la conoscenza del fatto non era responsabilità di nessuno.

Se volete costruire correttamente il processo 24/72 ore (trigger, escalation, prove e il routing regolatorio che determina quali regimi tocca un evento), è esattamente ciò che affrontiamo nell'ISO/IEC 27035 Lead Incident Manager. Cinque giorni, allineato a DORA e NIS2, e ora anche all'Articolo 14 del CRA. Certificato o rimborsato.