Guardian360
Inizia la prova gratuitaDiventa partner
← Tutti i post

Opinione

Tutti guardano la NIS2. Il Cyber Resilience Act è quello che può togliere il tuo prodotto dal mercato.

Di Jan Martijn Broekhof ·

Il 9 luglio ho partecipato a CRA Connect, un evento sul Cyber Resilience Act organizzato da CyberVeilig Nederland, FME e il Ministero degli Affari Economici, ospitato da Tesorion a Nieuwegein. Ci sono andato pensando di conoscere già l’essenziale. Guardian360 sviluppa software, quindi ovviamente il CRA ci riguarda; quella parte non è mai stata in dubbio. Ciò che mi ha colto di sorpresa è stata la velocità. Non la data di punta del dicembre 2027, che quasi tutti nella sala sapevano recitare, ma quella che le sta silenziosamente davanti: 11 settembre 2026. Non è un obbligo lontano. È tempo di preparazione che ha già iniziato a correre.

Sospetto di non essere l’unico ad avere avuto la timeline leggermente sbagliata in testa. E il motivo per cui questo conta è semplice: in questo momento, quasi tutti nella cybersecurity guardano la NIS2. Il CRA sta arrivando nella sua ombra, e dei due, il CRA è quello che alla fine può impedirti del tutto di vendere il tuo prodotto.

Cos’è esattamente il Cyber Resilience Act?

Il Cyber Resilience Act è un regolamento europeo che punta alla sicurezza dei prodotti con elementi digitali. È entrato in vigore il 10 dicembre 2024 e, poiché è un regolamento e non una direttiva, si applica direttamente in tutta l’UE senza essere recepito nelle leggi nazionali.

Il suo ambito è ampio. Copre non solo i dispositivi fisici connessi come hardware IoT, firewall e apparati di rete, ma anche il software: sistemi operativi, app mobili, firmware e componenti software commercializzati separatamente. Se un prodotto con elementi digitali è immesso sul mercato dell’UE nell’ambito di un’attività commerciale, è molto probabile che rientri nell’ambito. Questa portata si estende anche oltre l’Europa; un produttore con sede fuori dall’UE è vincolato dal CRA nel momento in cui i suoi prodotti sono messi a disposizione sul mercato dell’UE.

C’è un’eccezione che vale la pena nominare, perché è ampiamente fraintesa. Il software open-source non commerciale ricade fuori dal CRA. Ma nel momento in cui integri componenti open-source in un prodotto commerciale, quei componenti fanno parte del tuo prodotto, e gli obblighi del CRA si applicano al tutto. Non puoi esternalizzare la responsabilità a un progetto upstream che non hai mai pagato.

Quando devi effettivamente conformarti?

È qui che si nasconde la sorpresa. Ci sono due date, e la seconda si prende tutta l’attenzione mentre la prima fa il danno.

L’11 settembre 2026 inizia l’obbligo di segnalazione. Da quella data, i produttori che vengono a conoscenza di una vulnerabilità attivamente sfruttata o di un incidente grave nel loro prodotto devono segnalarlo, con una prima notifica entro 24 ore, attraverso il canale nazionale su mijn.NCSC.nl. L’11 dicembre 2027 il resto del regolamento si applica per intero: i requisiti essenziali di cybersecurity, la valutazione della conformità, la marcatura CE, la documentazione tecnica. Da quella data, solo i prodotti conformi al CRA possono essere immessi sul mercato dell’UE.

Ora ribalta quelle date. Guardale non come scadenze ma come il momento in cui la tua preparazione deve essere finita. Un processo funzionante di segnalazione degli incidenti e delle vulnerabilità, testato e presidiato, deve esistere prima del settembre 2026. Una valutazione completa della conformità, con tutta la documentazione a supporto, deve essere fatta prima del dicembre 2027. Sottrai il tempo che ciascuna di queste richiede davvero, ed entrambe le date rimandano allo stesso posto scomodo: adesso.

Tutti guardano la NIS2. È questa la parte pericolosa.

Il settore della cybersecurity ha passato gli ultimi due anni assorbito dalla NIS2 e dalla sua attuazione olandese. Quell’attenzione non è sbagliata, ma ha creato un punto cieco, e il punto cieco è pericoloso proprio perché le due leggi non sono in competizione per la tua attenzione. Si incastrano.

Il CRA è, di fatto, lo strumento sulla catena di fornitura sotto la NIS2. Un’organizzazione che ricade sotto la NIS2 può essere sicura solo se i prodotti che acquista sono a loro volta sicuri. Un ospedale, un’utility, un operatore logistico; ognuno è resiliente solo quanto i prodotti connessi e il software che acquista. È esattamente ciò che il CRA regola a livello di prodotto. Guarda solo alla NIS2 e stai gestendo metà del problema mentre dai per scontato che l’altra metà si risolva da sola.

Anche la posta in gioco è diversa, ed è la parte che dovrebbe far drizzare le orecchie. La non conformità alla NIS2 comporta vigilanza e sanzioni. Sono cose serie. Ma il CRA funziona come la marcatura CE per la sicurezza fisica: dal dicembre 2027, un prodotto senza una valutazione di conformità valida semplicemente non può essere immesso sul mercato dell’UE. Il caso peggiore sotto la NIS2 è una sanzione. Il caso peggiore sotto il CRA è che il tuo prodotto non può essere venduto. Per un fornitore di software, questo non è un costo di compliance. È un costo esistenziale.

L’abbiamo testato su noi stessi

Voglio essere onesto su dove si colloca Guardian360 in tutto questo, perché è il modo più chiaro per mostrare perché “ci arriveremo” è il riflesso sbagliato.

Siamo certificati ISO 27001. Manteniamo già una Software Bill of Materials per i nostri prodotti. Sulla carta, eravamo preparati meglio della maggior parte. E la conclusione a cui siamo comunque arrivati è stata sobria: quella preparazione ci dà un vantaggio di partenza, non un’esenzione. La ISO 27001 governa il nostro sistema di gestione della sicurezza delle informazioni, la nostra organizzazione e i suoi processi. Il CRA governa la sicurezza del prodotto stesso. I due sono complementari, ma non intercambiabili, e un certificato ISO 27001 appeso al muro non rende un prodotto conforme al CRA.

Poi abbiamo iniziato a mappare i nostri prodotti rispetto alle categorie del CRA, ed è diventato ancora più interessante. Il regolamento suddivide i prodotti con elementi digitali in prodotti ordinari, prodotti importanti di classe I e classe II, e prodotti critici, con la valutazione che diventa più pesante man mano che il rischio sale. La classe II, che include i sistemi di rilevamento e prevenzione delle intrusioni, richiede una valutazione da parte di un organismo notificato esterno; l’autovalutazione non basta. Parte di ciò che facciamo si colloca proprio in quello spazio del rilevamento delle intrusioni. In altre parole, alcuni dei nostri prodotti puntano verso il regime più pesante, non quello più leggero. Capire esattamente quale prodotto ricade in quale categoria, e documentarne il ragionamento, è proprio il tipo di compito che richiede mesi. Non è qualcosa che si fa di fretta nella tarda estate del 2026.

Perché non puoi aspettare, nemmeno per il “solo” obbligo di segnalazione

Ecco l’obiezione legittima, e merita una risposta diretta. Qualcuno dirà: settembre 2026 è solo l’obbligo di segnalazione, non la piena conformità del prodotto. La conformità completa è al 2027. Quindi non stiamo esagerando l’urgenza?

No, ed ecco perché. L’obbligo di segnalazione non è un interruttore che accendi. Non puoi segnalare ciò che non monitori, il che significa che il processo di rilevamento e segnalazione deve essere operativo, e provato, prima che la data arrivi. Non puoi segnalare con precisione su un prodotto le cui dipendenze da terze parti non hai mai mappato, ed è qui che entra in gioco la Software Bill of Materials; costruirne una su un portafoglio prodotti reale è un lavoro di mesi, non di un pomeriggio. E per chiunque costruisca prodotti fisici, la timeline è ancora meno clemente. All’evento, Ferry Mulders di VDL Agrobotics ha parlato del ciclo di vita di una macchina, del dimostrare che una macchina non può essere violata lungo gli anni in cui resta in servizio. Un costruttore di macchine con un ciclo di sviluppo pluriennale sta progettando oggi i prodotti che arriveranno sul mercato dopo il 2027. Per loro, il 2027 non è il futuro. È il brief di progettazione attuale.

Erik de Jong di Tesorion, la cui azienda ha ospitato l’evento, ha messo la versione onesta di tutto ciò in modo diretto: aiutano gli altri a diventare conformi e si ritrovano con un cospicuo lavoro CRA tutto loro. È la realtà in tutto il nostro settore. Le persone che danno consulenza su questo tema ne sono soggette anch’esse.

Cosa significa questo per i partner

Se sei un partner, un MSP, un integratore, un rivenditore o uno specialista di cybersecurity, questo ti arriva sulla scrivania due volte.

Primo, per te stesso. Se sviluppi, importi o distribuisci un qualsiasi prodotto con elementi digitali, vai a verificare se il CRA ti riguarda, e a quale categoria appartiene ciascun prodotto. Non dare per scontato che un’attività di servizi sia fuori ambito; moltissimi fornitori di servizi distribuiscono anche software, appliance o prodotti integrati senza pensarli in quei termini.

Secondo, per i tuoi clienti. Ti chiederanno cosa significa il CRA per loro, e i partner che sanno rispondere bene, con calma, in modo specifico, con la timeline e le categorie chiare, sono quelli che si guadagneranno la fiducia che ne consegue. La conversazione arriverà comunque. L’unica domanda è se avrai fatto il lavoro prima che il tuo cliente chieda, o dopo.

Quindi ecco la domanda con cui ti lascio. Hai già messo i tuoi prodotti a confronto con gli allegati del CRA, oppure stai silenziosamente dando per scontato che il 2027 sia ancora comodamente lontano? Perché quando ribalti le date, non lo è.

Fonti