Dall’11 settembre 2026 entrano in vigore i primi obblighi del Cyber Resilience Act UE: chi commercializza o fornisce componenti digitali (software e hardware) deve notificare tempestivamente vulnerabilità critiche sfruttate attivamente — tipicamente entro 24 ore alle autorità e poi ai clienti. Le aziende acquirenti devono chiedere ai fornitori conformità, canali di notifica e piani di patch management.

Il Cyber Resilience Act riguarda solo i produttori di software?

Gli obblighi principali di notifica pesano su chi commercializza/fornisce componenti digitali; le aziende acquirenti devono comunque governare la supply chain e chiedere evidenze.

Cosa chiedere subito a un fornitore CRM/gestionale?

Conformità CRA, canali e tempistiche di notifica vulnerabilità, frequenza e processo di patch management.

Hardening infrastrutturale basta per il CRA?

No. Protegge server e perimetro, ma non sostituisce la conformità e le procedure di notifica del software di terzi.

Cyber Resilience Act: dall’11 settembre 2026 cosa chiedere ai fornitori software

Dal 11 settembre 2026 entrano formalmente in vigore i primi obblighi del Cyber Resilience Act (CRA) europeo. Non è solo un tema «da vendor software»: se usi CRM, gestionali o moduli di automazione in azienda, la supply chain digitale diventa parte del rischio operativo.

Contenuto informativo tecnico/normativo. Non sostituisce una consulenza legale personalizzata sull’ambito soggettivo del CRA.

Cosa cambia in pratica

Il CRA introduce obblighi di notifica tempestiva e reporting delle vulnerabilità per chi commercializza o fornisce componenti digitali (software e hardware) nell’Unione Europea.

In particolare, i produttori di software non possono più gestire falle critiche attivamente sfruttate in modalità solo riservata o differita: scatta l’obbligo di segnalarle rapidamente alle autorità competenti e, in seguito, ai clienti — con tempistiche tipiche dell’ordine delle 24 ore verso le autorità.

Perché interessa anche chi «compra» software

Hardening di server, firewall e hypervisor riduce la superficie infrastrutturale. Ma se l’applicativo che gira sopra (CRM, ERP, portali, automazioni) non ha canali di aggiornamento e notifica chiari, resta l’anello debole.

Chi si occupa di infrastruttura può proteggere rete e sistemi; non risponde del codice di terze parti di cui non ha paternità. Per questo il CRA rende esplicito un passaggio commerciale: chiedere evidenze ai fornitori.

Tre domande da inviare ai fornitori (oggi)

  • Conformità al CRA — I prodotti e i canali di aggiornamento sono allineati ai requisiti di tracciamento/notifica a partire dall’11 settembre 2026?
  • Procedura di notifica — Quali canali ufficiali e quali tempistiche userete per comunicarci patch di sicurezza critiche sul pacchetto che abbiamo in produzione?
  • Patch management — Con quale frequenza rilasciate fix di sicurezza sul codice, e come gestite le vulnerabilità sfruttate attivamente?

Conserva le risposte scritte: diventano evidenza utile anche per questionari clienti, polizze cyber e percorsi tipo NIS2.

Infrastruttura e software: due pezzi dello stesso rischio

  • Infrastruttura — inventory, patch hypervisor/OS, hardening, monitoring (Hardening, 003 Intelligence).
  • Applicativi di terzi — conformità CRA, SLA di notifica, frequenza patch, ownership del codice.
  • Fotografia iniziale — se non sapete cosa avete in produzione: Security Status Report.

Sul pezzo normativo correlato per molte PMI: anche NIS2 per PMI e il gap analysis NIS2.

Cosa fare questa settimana

  • Elenca i software critici (CRM, gestionale, VPN appliance, email, backup).
  • Invia le tre domande CRA ai fornitori con scadenza di risposta.
  • Allinea IT e procurement: chi riceve le advisory e chi decide il downtime di patch.

Prossimo passo

Se vuoi affiancare la richiesta ai fornitori con una verifica tecnica dell’infrastruttura: Contatti ITSOS · hub Cybersecurity.