Cyber Resilience Act: le tre date che contano e il transitorio che nessuno racconta

Il Cyber Resilience Act è il regolamento europeo sulla sicurezza informatica dei «prodotti con elementi digitali»: software compreso. È un regolamento, non una direttiva: si applica direttamente, senza recepimento nazionale (Reg. UE 2024/2847). La data che tutti citano — dicembre 2027 — è solo una delle tre previste, e per chi ha già software sul mercato non è nemmeno la prima che conta.

• Tre date di applicazione (art. 71): organismi di valutazione dall'11 giugno 2026, obblighi di segnalazione dei fabbricanti dall'11 settembre 2026, tutto il resto dall'11 dicembre 2027.
• Il software già sul mercato resta fuori dai requisiti tecnici finché non subisce una «modifica sostanziale» — ma gli obblighi di segnalazione delle vulnerabilità valgono per tutti i prodotti in ambito (art. 69).
• Il SaaS puro è fuori ambito: il cloud rientra solo quando è parte funzionale di un prodotto (art. 3).
• Il software gratuito non è esente se fornito nel corso di un'attività commerciale (art. 3).

La domanda che ogni azienda con software già sul mercato si fa è: «devo rifare tutto?». L'art. 69 dà una risposta in due metà, e quasi tutti raccontano solo la prima.

Tradotto in decisioni: il software esistente sfugge ai requisiti tecnici finché non viene modificato sostanzialmente, ma non sfugge all'obbligo di segnalare le vulnerabilità attivamente sfruttate. Chi ha prodotti in ambito già sul mercato non deve chiedersi «cosa faccio entro il 2027?»: deve chiedersi chi, in azienda, si accorge di una vulnerabilità sfruttata e la segnala — da settembre 2026. È un problema di processo e di monitoraggio, non di riscrittura del codice. E per chi sta pianificando una modifica importante a un prodotto esistente, la data della modifica diventa la data in cui i requisiti si accendono: va messa nel piano di progetto, non scoperta dopo.

Il confine è nelle definizioni dell'art. 3: il regolamento copre il software e «le relative soluzioni di elaborazione dati da remoto», definite come l'elaborazione la cui assenza impedirebbe al prodotto di svolgere una delle sue funzioni. In pratica: il cloud entra nel perimetro quando è parte funzionale di un prodotto — il backend senza cui l'app non funziona — mentre un SaaS puro venduto come servizio autonomo non soddisfa la definizione (per quello il riferimento è semmai la NIS2). È una distinzione da maneggiare con precisione, perché la stessa architettura può stare da una parte o dall'altra a seconda di come il prodotto è confezionato e venduto.

Attenzione anche al software gratuito: la messa a disposizione sul mercato copre la fornitura «a titolo oneroso o gratuito [...] nel corso di un'attività commerciale» (art. 3). Un componente free distribuito come leva commerciale di un servizio a pagamento rientra nell'attività commerciale — il prezzo zero non è una scorciatoia per uscire dal perimetro.

Come ci posizioniamo noi rispetto a queste norme, prodotto per prodotto, lo abbiamo scritto nero su bianco nella pagina Sicurezza e conformità.

Molti articoli sul Cyber Resilience Act aprono con le multe. Noi non le citiamo, per una ragione semplice: non abbiamo ancora verificato il capo VII sul testo del regolamento, e la nostra regola è non pubblicare numeri normativi letti di seconda mano. Lo stesso vale per due punti che meritano una lettura dedicata: la qualificazione del software sviluppato su commessa singola e gli atti di esecuzione sulle classi di prodotti importanti e critici. Quando li avremo verificati, aggiorneremo questo articolo.

Nel frattempo, la motivazione giusta per occuparsi del CRA non è la paura di una multa: è che i suoi requisiti, gestione delle vulnerabilità, aggiornamenti garantiti, trasparenza sui componenti — stanno diventando il criterio con cui i clienti scelgono i fornitori, prima ancora che la legge li imponga. Chi compra software ha già iniziato a chiedere «chi lo mantiene, e come».