Cyber Resilience Act: cosa fare entro il 2027

In breve

• Il Cyber Resilience Act (CRA) è un regolamento europeo che entra in vigore in modo pieno l'11 dicembre 2027.
• Riguarda chiunque venda in Europa "prodotti con elementi digitali": software, hardware connesso, IoT, app, librerie open source usate commercialmente.
• Obblighi principali: progettare in sicurezza fin dall'inizio, gestire le vulnerabilità per tutto il ciclo di vita, notificare attivamente bug critici a ENISA.
• Le sanzioni arrivano fino al 2,5% del fatturato globale annuo.
• Per software house italiane, system integrator e produttori IoT, è il momento di partire: sistemare lo SDLC, l'aggiornamento prodotti, la documentazione tecnica.

Cosa è il Cyber Resilience Act

È il regolamento europeo che, per la prima volta, dice una cosa semplice: se vendi un prodotto digitale in Europa, sei responsabile della sua sicurezza per tutto il ciclo di vita.

Si applica praticamente a tutto:

• Software (gestionali, app web, app mobili).
• Hardware connesso (router, telecamere, stampanti, sensori IoT).
• Componenti software riutilizzati (librerie, framework).
• Macchine industriali connesse (cobot, PLC, scanner).

Sono esclusi: dispositivi medici (regolati dal MDR), auto (regolate da R155), aeronautica, software open source non commerciale.

Fonte ufficiale: Cyber Resilience Act — testo finale.

Le scadenze chiave

• 11 dicembre 2024: entrata in vigore formale.
• 11 settembre 2026: obbligo di notifica delle vulnerabilità sfruttate attivamente e degli incidenti gravi.
• 11 dicembre 2027: applicazione completa di tutti gli obblighi (security by design, documentazione, marcatura CE).

In pratica, avete circa 18 mesi per arrivare pronti.

Cosa cambia per chi sviluppa software

Il CRA richiede sei cose, in modo molto operativo:

1. Security by design: la sicurezza va pensata fin dalle prime fasi di progettazione, non aggiunta dopo.
2. Default sicuri: il prodotto, appena installato, deve essere sicuro senza configurazioni esoteriche (no password "admin/admin", no porte aperte inutili).
3. Aggiornamenti gratuiti per vulnerabilità di sicurezza, per tutta la durata di "supporto attesa" (di solito 5-10 anni).
4. Gestione vulnerabilità strutturata: procedure scritte, contatti pubblici per chi segnala bug, SBOM (Software Bill of Materials).
5. Notifica entro 24 ore di vulnerabilità sfruttate attivamente o incidenti gravi a ENISA.
6. Documentazione tecnica completa che dimostri come avete rispettato gli obblighi.

Tre categorie di rischio

Il CRA divide i prodotti in tre fasce:

• Default: la maggior parte dei software business e IoT consumer. Autocertificazione del produttore.
• Importanti (Classe I e II): gestori di password, antivirus, firewall, smart card reader, microcontroller industriali. Serve un audit più approfondito o, in alcuni casi, terza parte.
• Critici: smart meter, dispositivi sicurezza industriale critici. Certificazione obbligatoria da terza parte.

Per la maggior parte delle software house italiane, ricadrete nella prima categoria: gestione interna ma documentazione rigorosa.

Sanzioni

Multe fino a:

• 15 milioni di euro o 2,5% del fatturato globale (il maggiore dei due) per violazioni gravi.
• 10 milioni o 2% per violazioni meno gravi.
• 5 milioni o 1% per informazioni false alle autorità.

Ritiro dal mercato e blocco delle vendite per i casi più gravi.

Cosa fare nei prossimi 18 mesi

Ecco una roadmap pratica per una software house o un system integrator:

Mesi 1-3 — Mappatura

• Elencare tutti i prodotti che vendete in UE.
• Capire la categoria di rischio di ognuno.
• Identificare gap su SDLC, gestione vulnerabilità, documentazione.

Mesi 4-9 — Implementazione

• Adottare SDLC sicuro: code review, scansioni statiche (SAST), scansioni dipendenze (SCA), pen test annuali.
• Generare SBOM automatico ad ogni release (con strumenti come CycloneDX, Syft).
• Pubblicare una pagina "security disclosure" con contatti per ricercatori esterni.
• Definire procedura interna di triage e patch.

Mesi 10-18 — Certificazione e go-live

• Preparare la documentazione tecnica.
• Apporre marcatura CE (per prodotti hardware) o dichiarazione di conformità (software).
• Formare il team sulla gestione incidenti e notifica ENISA.

Open source: il punto delicato

Il CRA esclude gli sviluppatori open source individuali, ma include chi:

• Vende prodotti commerciali basati su open source.
• Usa open source come parte di una soluzione fatturata al cliente.

Tradotto: se la vostra software house usa React, Node.js, Postgres, siete voi i responsabili della sicurezza di queste componenti nel vostro prodotto. Non potete dire "il bug è di un altro".

Approfondimenti

• Regolamento (UE) 2024/2847
• ENISA — CRA implementation guidance
• OpenSSF — Best Practices

In sintesi

Il CRA non è un altro adempimento burocratico: è un cambio di mentalità. Chi sviluppa software diventa responsabile di tutta la vita del prodotto, non solo della prima vendita. Partite ora con SDLC, SBOM e procedure di patching. Tra 18 mesi sarete pronti, con calma. Aspettare l'autunno 2027 significa correre.