--- title: "Cyber Resilience Act (CRA): ambito, scadenze, obblighi" description: "Cyber Resilience Act (Regolamento UE 2024/2847): ambito, scadenze 2026-2027, obblighi, notifiche, marcatura CE e coordinamento NIS 2." canonical: https://www.aegister.com/it/cms/insights/cyber-resilience-act-cra-obblighi-fabbricanti/ url: /it/cms/insights/cyber-resilience-act-cra-obblighi-fabbricanti/ lang: it --- ![](/static/images/header-contact.webp) # Cyber Resilience Act (CRA): obblighi per fabbricanti di software e hardware --- ![Cyber Resilience Act (CRA): obblighi per fabbricanti di software e hardware](/static/images/cms/cyber-resilience-act-cra-obligations-manufacturers.webp) ## Cyber Resilience Act (CRA): obblighi per fabbricanti di software e hardware 25 Aprile 2026 [CRA](/it/cms/keyword/cra/) [Cyber Resilience Act](/it/cms/keyword/cyber-resilience-act/) [cybersecurity UE](/it/cms/keyword/cybersecurity-ue/) [Regolamento 2024/2847](/it/cms/keyword/regolamento-20242847/) +6 Il Cyber Resilience Act (CRA) è il Regolamento (UE) 2024/2847. Introduce requisiti orizzontali di cybersecurity per prodotti con elementi digitali immessi sul mercato UE. Per fabbricanti software e hardware, la sicurezza prodotto diventa un obbligo di compliance lungo il ciclo di vita. Fonti: [Regolamento (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj), [sintesi Commissione europea sul CRA](https://digital-strategy.ec.europa.eu/en/policies/cra-summary), [pagina Commissione europea sul CRA](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act), [materiali ENISA sul CRA](https://www.enisa.europa.eu/topics/cyber-resilience-act). ## Punti chiave - Il CRA è entrato in vigore il 10 dicembre 2024. - Gli obblighi principali si applicano dall’11 dicembre 2027. - Gli obblighi di reporting dell’articolo 14 si applicano prima, dall’11 settembre 2026. - Il CRA copre prodotti hardware e software con elementi digitali messi a disposizione sul mercato UE, salvo esclusioni definite. - I fabbricanti devono gestire sicurezza in fase di progettazione, vulnerabilità, valutazione di conformità, documentazione tecnica e marcatura CE. - La non conformità ai requisiti essenziali e agli articoli 13 e 14 può portare a sanzioni fino a 15 milioni di euro o 2,5% del fatturato mondiale. ## Ambito di questo articolo Questo articolo spiega gli obblighi CRA per fabbricanti, importatori, distributori e team software. Non sostituisce un’analisi legale o un piano di valutazione di conformità specifico per prodotto. ## Cos’è il Cyber Resilience Act Il CRA è una normativa di product security. Si applica in modo trasversale ai prodotti con elementi digitali, inclusi software, hardware e soluzioni di remote data processing necessarie per una funzione del prodotto. La Commissione lo descrive come framework orizzontale per hardware e software sicuri nel mercato UE. ## Quando si applica: calendario | Data | Milestone | Conseguenza operativa | | --- | --- | --- | | 10 dicembre 2024 | Entrata in vigore | Inizia il periodo di preparazione. | | 11 giugno 2026 | Applicazione Capitolo IV | Si applicano le regole sugli organismi notificati. | | 11 settembre 2026 | Applicazione articolo 14 | Partono gli obblighi di reporting su vulnerabilità sfruttate e incidenti severi. | | 11 dicembre 2027 | Applicazione principale | Si applicano gli obblighi core CRA. | ## Chi è soggetto al CRA Il CRA riguarda operatori economici come fabbricanti, rappresentanti autorizzati, importatori e distributori. Gli obblighi più intensi ricadono sul fabbricante, perché controlla progettazione, sviluppo, documentazione, gestione vulnerabilità e conformità. Il software open source richiede analisi specifica. Il regolamento distingue attività non commerciali, attività commerciali e ruolo di open-source software steward. Non si deve presumere che ogni repository sia fuori ambito. ## Le categorie di prodotti | Categoria | Lettura pratica | Impatto compliance | | --- | --- | --- | | Prodotti standard | Prodotti non elencati come importanti o critici. | Obblighi fabbricante e valutazione di conformità. | | Importanti classe I | Prodotti in Allegato III con rilevanza cybersecurity. | Aspettative di conformità più strutturate. | | Importanti classe II | Prodotti a rischio superiore in Allegato III. | Onere di valutazione più forte. | | Critici | Prodotti in Allegato IV. | Possibile rilevanza certificazione e garanzie più alte. | ## Obblighi principali per i fabbricanti - Progettare, sviluppare e produrre secondo requisiti essenziali di cybersecurity. - Documentare risk assessment cyber e controlli tecnici. - Gestire vulnerabilità durante il periodo di supporto. - Fornire informazioni e istruzioni di sicurezza agli utenti. - Eseguire la valutazione di conformità appropriata. - Applicare la marcatura CE quando i requisiti sono soddisfatti. ## Notifica vulnerabilità e incidenti L’articolo 14 introduce obblighi di reporting per vulnerabilità attivamente sfruttate e incidenti severi che impattano la sicurezza del prodotto. La sintesi della Commissione indica applicazione dall’11 settembre 2026. I team prodotto dovrebbero preparare intake, triage, evidenze e disclosure prima di quella data. ## Coordinamento con NIS 2 e altre normative UE La NIS 2 riguarda soggetti e misure di gestione del rischio. Il CRA riguarda prodotti con elementi digitali. Un vendor software può essere impattato da entrambi: NIS 2 come soggetto e CRA come fabbricante. Per contesto, vedi [NIS 2](/it/cms/insights/impatto-nis-2-conformita/), [revisione del Cybersecurity Act UE](/it/cms/insights/revisione-cybersecurity-act-ue-2026/), [Cyber Solidarity Act](/it/cms/insights/cyber-solidarity-act-2025/) e [finanziamenti per readiness CRA](/it/cms/insights/secure-first-open-call-cra-readiness-2026-it/). ## Checklist operativa 1. Inventariare prodotti e componenti digitali sul mercato UE. 2. Classificare categoria prodotto e ruolo di operatore economico. 3. Mappare controlli secure-by-design al ciclo di vita prodotto. 4. Definire intake, triage, remediation e disclosure vulnerabilità. 5. Preparare documentazione tecnica e repository evidenze. 6. Valutare percorso di conformità e piano marcatura CE. 7. Coordinare reporting CRA con processi NIS 2, DORA o settoriali. ## Ciclo di sviluppo sicuro nel CRA I fabbricanti dovrebbero tradurre gli obblighi CRA nel ciclo di vita prodotto. Il ciclo pratico include classificazione, threat modeling, review di design, controllo dipendenze, test sicurezza, approvazione release, aggiornamenti di sicurezza e comunicazione fine supporto. Ogni passaggio deve lasciare evidenza. | Fase ciclo di vita | Evidenza da conservare | | --- | --- | | Classificazione prodotto | Analisi ambito, decisione categoria, ruolo operatore. | | Design sicuro | Threat model, review architettura, requisiti sicurezza. | | Build e dipendenze | SBOM, review dipendenze, record firma. | | Testing | Risultati test sicurezza, note remediation vulnerabilità. | | Release | Evidenze conformità, istruzioni sicurezza, documentazione CE. | | Post-market | Intake vulnerabilità, patch, evidenze notifica. | ## Checkpoint per importatori e distributori Importatori e distributori non dovrebbero considerare il CRA un problema solo del fabbricante. Servono evidenze che i prodotti siano identificati, accompagnati dalla documentazione richiesta e gestiti senza compromettere la conformità. Il procurement dovrebbe richiedere documentazione product security prima della distribuzione. ## Workflow di gestione vulnerabilità 1. Ricevere segnalazioni tramite un canale presidiato. 2. Valutare exploitability, versioni impattate e impatto sicurezza prodotto. 3. Assegnare owner remediation e data target. 4. Preparare comunicazione utenti e istruzioni aggiornamento. 5. Valutare se scattano obblighi di reporting articolo 14. 6. Conservare log decisionali ed evidenze tecniche. ## Implicazioni sanzioni e governance Il massimale sanzionatorio CRA per requisiti essenziali e articoli 13 e 14 è sufficiente a rendere la sicurezza prodotto un rischio da governance. La compliance deve quindi entrare nella product governance, non restare solo nei team engineering. ## Pianificazione del periodo di supporto La gestione vulnerabilità CRA non è un’attività una tantum di release. I fabbricanti devono pianificare per quanto tempo aggiornamenti di sicurezza, intake vulnerabilità e comunicazioni utenti saranno supportati. Il testo regolatorio va verificato per categoria prodotto, ma il punto operativo è chiaro: il periodo di supporto deve essere definito, comunicato e finanziato. ## Pacchetto documentazione tecnica - Descrizione prodotto e uso previsto. - Risk assessment cyber e decisioni di design. - Mapping requisiti essenziali. - SBOM o inventario componenti dove applicabile. - Test e note remediation vulnerabilità. - Evidenze di valutazione conformità. - Istruzioni sicurezza utenti e informazioni sul supporto. ## Modello operativo del team prodotto La readiness CRA richiede collaborazione tra product, engineering, sicurezza, legale e supporto. Engineering possiede implementazione sicura. Security possiede threat modeling e validazione. Legale e compliance possiedono interpretazione conformità. Support gestisce comunicazioni e intake vulnerabilità. Product management governa lifecycle e impegni di supporto. ## Rischio legacy e modifica sostanziale I prodotti già sul mercato prima della data principale richiedono analisi quando subiscono modifiche sostanziali. I team prodotto dovrebbero definire cosa conta come cambio rilevante per la sicurezza, chi lo approva e quando aggiornare documentazione tecnica. Questo deve entrare nella release governance. I fabbricanti che costruiscono o aggiornano il programma CRA spesso traggono vantaggio dal supporto di un CISO esterno per fare da ponte tra ingegneria di prodotto, cybersecurity e legale. Il [servizio Virtual CISO di Aegister](https://aegister.com/it/solutions/virtual-ciso/) copre governance della sicurezza prodotto, disegno della gestione vulnerabilità, prontezza per la valutazione di conformità e coordinamento con gli obblighi NIS 2 quando entrambi i regimi si applicano. ## FAQ ### Quando si applica il CRA? Il CRA è entrato in vigore il 10 dicembre 2024. L’articolo 14 si applica dall’11 settembre 2026. Gli obblighi principali si applicano dall’11 dicembre 2027. ### Il CRA si applica al software? Sì, quando il software è un prodotto con elementi digitali messo a disposizione sul mercato UE, secondo ambito ed esclusioni del regolamento. ### La marcatura CE basta? No. La marcatura CE è l’esito visibile della conformità. Contano evidenze, risk assessment, gestione vulnerabilità e documentazione. ## Fonti ufficiali - [Regolamento (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj) - [Sintesi Commissione europea sul CRA](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) - [Pagina Commissione europea sul CRA](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) - [Materiali ENISA sul CRA](https://www.enisa.europa.eu/topics/cyber-resilience-act) - [Direttiva (UE) 2022/2555](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) Condividi questo articolo: ## Notizie Correlate [![SECURE First Open Call 2026: Cosa Devono Fare le mPMI Prima del 29 Marzo 2026](/static/images/cms/secure-cra-open-call.webp)](/it/cms/insights/secure-first-open-call-cra-readiness-2026-it/) [SECURE First Open Call 2026: Cosa Devono Fare le mPMI Prima del 29 Marzo 2026](/it/cms/insights/secure-first-open-call-cra-readiness-2026-it/) [La SECURE First Open Call (28 gen – 29 mar 2026) offre fino a EUR 30.000 per progetto con co-finanziamento al 50% per supportare le mPMI nella readiness al Cyber Resilience Act. Guida completa su eleggibilità, valutazione e checklist operativa.](/it/cms/insights/secure-first-open-call-cra-readiness-2026-it/) [ACN](/it/cms/keyword/acn/) [SECURE](/it/cms/keyword/secure/) +8 [![AI Act UE: implicazioni di cybersecurity per i team di conformità](/static/images/cms/eu-ai-act-cybersecurity-implications.webp)](/it/cms/insights/ai-act-implicazioni-cybersecurity/) [AI Act UE: implicazioni di cybersecurity per i team di conformità](/it/cms/insights/ai-act-implicazioni-cybersecurity/) [Guida alle implicazioni cybersecurity dell’AI Act UE per team compliance: date, controlli per sistemi IA ad alto rischio e coordinamento con NIS 2 e CRA.](/it/cms/insights/ai-act-implicazioni-cybersecurity/) [Cyber Resilience Act](/it/cms/keyword/cyber-resilience-act/) [AI Act UE](/it/cms/keyword/ai-act-ue/) +8 [![Comprendere la NIS 2: Guida Completa alla Nuova Direttiva UE sulla Cybersecurity](/static/images/cms/nis-2-guide.webp)](/it/cms/insights/guida-aegister-nis-2/) [Comprendere la NIS 2: Guida Completa alla Nuova Direttiva UE sulla Cybersecurity](/it/cms/insights/guida-aegister-nis-2/) [Padroneggia la Direttiva NIS 2 con la nostra guida completa che copre strategie di implementazione, requisiti di conformità e passi pratici per rafforzare il framework di cybersecurity della tua organizzazione.](/it/cms/insights/guida-aegister-nis-2/) [conformità cybersecurity](/it/cms/keyword/conformita-cybersecurity/) [gestione del rischio](/it/cms/keyword/gestione-del-rischio/) +13