Il reparto prodotto ha appena finito di censire le dipendenze cloud del catalogo 2026: due dispositivi connessi, un termostato intelligente e un e-reader, condividono la stessa caratteristica. Senza il servizio cloud a cui sono agganciati, smettono entrambi di funzionare.
Il termostato perde la regolazione da remoto, l’e-reader perde l’accesso alla libreria che il cliente ha acquistato. Stessa criticità operativa, stessa dipendenza totale.
Eppure, secondo gli orientamenti che la Commissione ha pubblicato in versione definitiva il 27 luglio 2026 sull’applicazione del Cyber Resilience Act, solo uno dei due dispositivi resta dentro il perimetro degli obblighi che gravano sul prodotto nel suo complesso. L’altro no, per una ragione che non ha nulla a che fare con quanto quella dipendenza sia critica per l’utente.
Chi ha già mappato gli obblighi generali del CRA si trova ora davanti a una domanda pratica, ossia cosa succede quando il prodotto non è mai “solo”, ossia quando dipende da un pezzo di infrastruttura che qualcun altro possiede e gestisce.
Indice degli argomenti
La necessità del servizio non è il criterio che decide
Il Cyber Resilience Act, il regolamento (UE) 2024/2847, definisce il prodotto con elementi digitali includendo, insieme a hardware e software, le sue soluzioni di elaborazione dati remota (articolo 3, punto 1).
Chi progetta un dispositivo connesso deve quindi trattare come parte del prodotto stesso non solo il codice che gira sul dispositivo, ma anche l’elaborazione che avviene altrove, quando quella elaborazione rientra nella definizione di trattamento remoto dei dati, indicata nelle linee guida con l’acronimo RDPS.
L’articolo 3, punto 2, fissa questa definizione con precisione: si tratta di elaborazione dati a distanza per la quale il software è progettato e sviluppato dal fabbricante, o sotto la sua responsabilità, e la cui assenza impedirebbe al prodotto di svolgere una delle sue funzioni.
Da questa definizione gli orientamenti della Commissione ricavano un test in sequenza, riassunto in un diagramma di flusso all’interno del documento.
Il test pone tre domande, una dopo l’altra e ciascuna domanda si esamina solo se la precedente ha già avuto risposta positiva.
Le tre domande del test
La prima domanda chiede se quella elaborazione avviene a distanza. Se la risposta è no, il ragionamento si ferma: non c’è alcuna RDPS da valutare.
La seconda domanda chiede se quella elaborazione a distanza è necessaria per una funzione del prodotto, cioè se la sua assenza impedirebbe al prodotto di funzionare come previsto. Se tale impedimento non c’è, l’elaborazione resta una dipendenza esterna: il produttore deve comunque monitorarla nella valutazione del rischio, ma quella dipendenza non diventa parte del prodotto.
La terza domanda verifica se l’elaborazione remota è stata sviluppata dal produttore o sotto la sua responsabilità. Se il servizio è sviluppato da un terzo in autonomia, l’elaborazione è trattata come componente di terze parti, in caso contrario si qualifica come RDPS.
È in questa terza domanda, quella sulla paternità del progetto, che il termostato e l’e-reader, identici quanto alle prime due risposte, imboccano strade diverse.
Il termostato e l’e-reader rispondono in modo diverso alla stessa domanda
Gli orientamenti dedicano un caso d’uso a ciascuno dei due dispositivi e li costruiscono apposta perché la dipendenza tecnica risulti identica.
Il termostato intelligente e la RDPS
Nel termostato intelligente, l’applicazione mobile e il dispositivo scambiano informazioni e memorizzano le preferenze dell’utente attraverso un’elaborazione remota. Quelle funzioni sono state sviluppate e progettate sotto la responsabilità del produttore del termostato, anche se vengono eseguite su un’infrastruttura fisica e virtuale fornita da un terzo, un servizio di tipo IaaS. Poiché il termostato non potrebbe svolgere le sue funzioni smart senza quella elaborazione e poiché il software è stato progettato dal produttore o sotto la sua responsabilità, l’elaborazione remota si qualifica come RDPS. Il produttore deve documentarla nella documentazione tecnica del prodotto, includerla nella valutazione del rischio e garantire che il prodotto nel suo complesso, termostato più elaborazione remota, soddisfi i requisiti essenziali del regolamento.
L’e-reader e il servizio SaaS di terze parti
Nell’e-reader, il produttore del dispositivo si affida invece a un servizio di archiviazione SaaS di terze parti per conservare i libri elettronici acquistati dai clienti e consentirne l’accesso. Anche qui l’assenza del servizio impedirebbe al prodotto di svolgere una delle sue funzioni: senza quell’archiviazione, l’utente non accede più alla propria libreria. Ma il servizio SaaS non è stato sviluppato dal produttore dell’e-reader, né è sotto la sua responsabilità. Il fornitore lo progetta e lo mette a disposizione di chiunque voglia integrarlo, senza che il produttore dell’e-reader ne abbia definito la progettazione o le specifiche. La seconda domanda del test si supera, la terza no. L’elaborazione non si qualifica come RDPS. Il produttore dell’e-reader deve comunque trattarla come un componente di terze parti, valutarne i rischi di integrazione, mitigarli con controlli a livello di prodotto ed esercitare la dovuta diligenza verso il fornitore. Ma non deve estendere a quel servizio i requisiti essenziali del regolamento, perché quel servizio non è, in senso proprio, parte del prodotto.
Non è il cloud in sé, è quanto dello stack è stato progettato
La differenza tra i due casi non riguarda la natura esterna del fornitore, ma il livello dello stack architetturale in cui si inserisce la dipendenza esterna. Gli orientamenti chiariscono il punto distinguendo i modelli di servizio cloud più comuni.
Se il produttore utilizza un’infrastruttura di terzi, un servizio IaaS, per eseguire software che ha comunque progettato e sviluppato lui, quel software resta sotto la sua responsabilità e può qualificarsi come RDPS, esattamente come nel caso del termostato.
Lo stesso vale se il produttore sviluppa la propria applicazione su una piattaforma di terzi, un servizio PaaS: l’ambiente di esecuzione è comprato, ma la logica applicativa resta sua.
Cambia tutto, invece, quando il produttore acquista un’applicazione SaaS già completamente sviluppata da un fornitore terzo, con una capacità di configurazione limitata alle sole impostazioni per l’utente finale. In quel caso non è lui ad aver progettato il software, e la responsabilità dello sviluppo non è sua nemmeno indirettamente.
Si tratta di considerazioni che incidono già sull’architettura del sistema, ben prima che il prodotto affronti i controlli di compliance. Costruire la propria logica applicativa su un’infrastruttura o una piattaforma di terzi mantiene il produttore dentro il regime pieno del regolamento per quella componente, con tutto quello che comporta in termini di oneri di valutazione e documentazione. Comprare un servizio già pronto sposta quella componente verso il regime più leggero della dovuta diligenza, ma sposta anche il controllo sulla progettazione fuori dalle mani del produttore.
La scelta architetturale, quindi, non è mai neutra rispetto alla conformità che ne deriva.
La classificazione decide chi porta il peso degli obblighi
Le conseguenze pratiche della differenza sono notevoli.
Quando l’elaborazione remota si qualifica come RDPS, il produttore deve considerarla parte del prodotto ai fini di tutti gli obblighi del regolamento: la valutazione del rischio di cybersicurezza prevista dall’articolo 13, paragrafo 2, l’applicazione dei requisiti essenziali dell’allegato I al prodotto nel suo complesso, e gli obblighi di segnalazione dell’articolo 14 su vulnerabilità sfruttate attivamente e incidenti gravi. Questi ultimi obblighi meritano un’attenzione specifica sul piano temporale: si applicano dall’11 settembre 2026 a tutti i prodotti con elementi digitali che rientrano nell’ambito del regolamento, compresi quelli immessi sul mercato prima dell’11 dicembre 2027, data di piena applicazione del CRA. Chi ha un RDPS nel proprio prodotto e non lo ha ancora riconosciuto come tale rischia di scoprirlo quando l’obbligo di segnalazione sarà già decorso.
Quando l’elaborazione si qualifica invece come componente, il regime è quello della dovuta diligenza previsto dall’articolo 13, paragrafo 5: il produttore valuta i rischi derivanti dall’integrazione, li mitiga con controlli sul proprio prodotto e verifica che il fornitore terzo offra garanzie adeguate.
Gli orientamenti indicano anche gli strumenti concreti con cui questa verifica può essere documentata: la prova di conformità al regolamento di esecuzione (UE) 2024/2690, che specifica gli obblighi di gestione del rischio per i fornitori di servizi cloud ai sensi della direttiva NIS 2, la prova di conformità al regolamento (UE) 2022/2554, il cosiddetto DORA, se il fornitore serve il settore finanziario, una certificazione ottenuta nell’ambito di uno schema europeo di certificazione della sicurezza informatica, oppure la conformità alle norme ISO/IEC 27017 e 27001. Nessuno di questi obblighi si trasferisce automaticamente al fornitore: resta il produttore a doverne rispondere davanti all’autorità di vigilanza del mercato.
La scelta del fornitore cloud è già una scelta di perimetro di responsabilità
Gli effetti di tale ripartizione si traducono in obblighi immediati già in fase di contrattualizzazione dei fornitori (procurement). Decidere se costruire la logica applicativa su un’infrastruttura o una piattaforma di terzi, oppure acquistare un servizio SaaS già pronto, non è solo una decisione tecnica o di costo: è la decisione che determina quale regime di conformità si applicherà a quella componente e quindi quali clausole contrattuali servono davvero.
Per i fornitori trattati come componente, il capitolato dovrebbe prevedere garanzie verificabili: accordi sul livello di servizio con impegni specifici di sicurezza, la richiesta di prova di conformità al regolamento di esecuzione (UE) 2024/2690 quando il fornitore rientra nell’ambito della NIS 2 e le certificazioni indicate sopra.
Per le soluzioni che restano RDPS, il produttore deve poter dimostrare, con una documentazione tecnica aggiornata nel tempo, che lo sviluppo è avvenuto sotto la sua responsabilità, anche quando l’infrastruttura sottostante appartiene a un terzo. Coinvolgere legal e compliance nella fase di design dell’architettura cloud, e non a valle quando il fornitore è già scelto e il contratto firmato, evita di scoprire la classificazione a obblighi già decorsi.
Si ricordi che questi orientamenti non sono vincolanti: la Commissione lo dichiara esplicitamente nel documento e un’interpretazione del regolamento può venire solo dalla Corte di giustizia dell’Unione europea. Gli esempi che gli orientamenti offrono, termostato ed e-reader compresi, non sostituiscono una valutazione caso per caso, che resta necessaria per ogni prodotto reale, con le sue specificità di progettazione e di filiera contrattuale.
Partecipa alla community