Torna al Blog

Cyber Resilience Act e app mobile: cosa deve fare una software house italiana entro il 2027

·5 min lettura
Cyber Resilience Act e app mobile - compliance per software house

Il Regolamento (UE) 2024/2847 — Cyber Resilience Act — si applica dall'11 dicembre 2027 a qualsiasi software immesso sul mercato dell'Unione. Un'app Android o iOS distribuita tramite App Store o Google Play rientra nella definizione. La maggior parte delle software house italiane non lo sa ancora.

Se la tua azienda sviluppa un gestionale mobile, un'app di field service, una app per prenotazioni o fidelizzazione che i clienti europei scaricano sullo smartphone, dal 2027 avrai obblighi nuovi: produrre una Software Bill of Materials (SBOM), gestire attivamente le vulnerabilità, garantire patch per cinque anni e — in caso di incidente — notificare l'ENISA entro 24 ore. Non sono obblighi del GDPR, che già conosci. Sono obblighi del Cyber Resilience Act, e la maggior parte delle software house italiane con fatturato tra €1M e €15M non ne ha ancora sentito parlare.

La mia app è un "prodotto con elementi digitali"?

La definizione dell'Art. 3 del Regolamento (UE) 2024/2847

L'Art. 3(1) definisce il prodotto con elementi digitali come «un prodotto software o hardware e le sue soluzioni di elaborazione dati remota, inclusi componenti software o hardware immessi sul mercato separatamente». Non esiste un elenco di categorie tecnologiche ammesse o escluse: il criterio è funzionale.

L'Art. 3(21) definisce "immissione sul mercato" come il «primo atto di messa a disposizione di un prodotto nel mercato dell'Unione». Distribuire un'app tramite App Store o Google Play a utenti europei è esattamente questo, indipendentemente dal canale. Il Considerando 15 del regolamento lo conferma: la distribuzione tramite marketplace digitali non modifica l'applicabilità della norma.

Casi che normalmente rientrano nel perimetro

Sono tipicamente soggette al CRA le seguenti tipologie:

  • App B2C distribuite al pubblico tramite store a utenti nell'UE
  • App aziendali installate sui dispositivi dei clienti (field service, prenotazioni, gestionali mobili)
  • App che controllano dispositivi IoT o interagiscono con hardware connesso
  • SDK e componenti software commercializzati separatamente

Il caso ambiguo: SaaS puro

Se il client mobile è sostanzialmente un terminale remoto — tutta la logica gira su cloud e l'app non ha funzioni autonome lato device — il perimetro è meno netto. Secondo la bozza di linee guida della Commissione (Ares(2026)2319816, marzo 2026, in attesa di adozione formale a giugno 2026), occorre applicare un test a tre criteri per valutare se il "remote data processing" costituisce parte integrante del prodotto. In assenza di un testo definitivo, è prudente assumere che il CRA si applichi e verificare il perimetro analizzando Art. 3 e Considerando 15-18.

Cosa cambia rispetto al GDPR che già conosci

Il GDPR ti ha abituato alla logica del data protection by design. Il CRA introduce qualcosa di diverso: sicurezza del prodotto by design, con obblighi tecnici che il GDPR non prevede.

  • SBOM (Software Bill of Materials): un inventario strutturato di tutte le dipendenze del software — librerie npm, pacchetti Gradle, pod CocoaPods. Per molte app mobile, le dipendenze di terze parti rappresentano la superficie di attacco principale.
  • Vulnerability management attivo: devi monitorare i CVE nei componenti che usi e rilasciare aggiornamenti. Il CRA vieta di abbandonare il prodotto senza patch per cinque anni dalla messa in commercio.
  • Coordinated vulnerability disclosure policy: un canale dichiarato attraverso cui i ricercatori di sicurezza possono segnalarti vulnerabilità. L'ENISA ha un template ufficiale.
  • Notifiche a 24h/72h/14 giorni: in caso di incidente di sicurezza attivamente sfruttato, entri in un regime di notifica all'ENISA con scadenze precise — obbligo che scatta già dall'11 settembre 2026 (per i dettagli, vedi il nostro articolo sulle notifiche Art. 14).
  • Documentazione tecnica e Dichiarazione UE di Conformità: devi produrre e conservare documentazione che dimostri la conformità ai requisiti essenziali dell'Allegato I.

Autodichiarazione o ente notificato?

La maggior parte delle app mobile standard rientra nella categoria "default" del CRA: è possibile l'autodichiarazione di conformità, senza enti notificati esterni, applicando le norme armonizzate quando disponibili.

Alcune categorie di app ricadono nell'Allegato III Classe I e possono richiedere una valutazione di terza parte in assenza di norma armonizzata: password manager, applicazioni VPN e sistemi di identity management / gestione accessi privilegiati (PAM). La Classe II (Allegato IV) — che include OS, hypervisor e browser — richiede sempre un ente notificato. Per le app mobile tipiche di una software house italiana, la Classe II è uno scenario raro.

Cosa fare adesso — roadmap 18 mesi

L'11 dicembre 2027 sembra lontano. Non lo è: costruire un processo CVE e produrre uno SBOM verificabile richiede mesi, non settimane. Un'azienda che inizia nel 2026 arriva al 2027 con un processo rodato; una che aspetta il 2027 arriva in emergenza.

  1. Verifica se sei nel perimetro: analizza Art. 3 e Considerando 15-18 del Regolamento (UE) 2024/2847. Se la tua app gira su device di clienti europei, la risposta è quasi certamente sì.
  2. Produci un inventario delle dipendenze: è il prerequisito per qualsiasi SBOM. Strumenti open source come Syft, CycloneDX o SPDX sono un punto di partenza concreto.
  3. Avvia un processo CVE interno: monitora i CVE nei componenti che usi. Non serve subito uno strumento commerciale — basta una procedura documentata.
  4. Redigi una coordinated vulnerability disclosure policy: usa il template ENISA e pubblica il canale di segnalazione nel tuo sito o store listing.
  5. Pianifica 5 anni di patch: rivedi la tua politica di end-of-life. Il CRA impone la disponibilità di aggiornamenti di sicurezza per l'intera vita supportata del prodotto.
  6. Contattaci per una valutazione dei tuoi prodotti digitali: Tomato Blue affianca le software house italiane nella mappatura del perimetro CRA e nella costruzione dei processi richiesti.

Le sanzioni che ricordano cosa è in gioco

L'Art. 64(2) del Regolamento (UE) 2024/2847 stabilisce per la non conformità ai requisiti essenziali (Allegato I) e agli obblighi dell'Art. 13-14 una sanzione fino a €15.000.000 o il 2,5% del fatturato annuale mondiale — si applica il valore più alto. Per una software house italiana con €5M di fatturato: €125.000. Con €10M: €250.000. Con €15M: €375.000.

Le microimprese non sono esenti dai requisiti; alcune modalità di enforcement legate alle notifiche dell'Art. 14 prevedono agevolazioni, non esenzioni. La dimensione aziendale non è un salvacondotto.

Fonti