Condividere l'articolo
Nel Secure by Design and Default Playbook, l’ENISA, l’Agenzia dell’Unione europea per la cibersicurezza, illustra per la prima volta in modo concreto come i fabbricanti di prodotti con elementi digitali possano attuare, dal punto di vista tecnico e organizzativo, i requisiti del Cyber Resilience Act (CRA).
Con la versione 1.0 del Secure by Design and Default Playbook, pubblicata nel luglio 2026, l’ENISA ha reso disponibile la versione definitiva della propria guida pratica. Il documento tiene conto dei risultati della consultazione pubblica svoltasi nella primavera del 2026, che ha raccolto 28 contributi provenienti dall’industria, dalle autorità pubbliche e dalla comunità open source, e contiene numerose precisazioni tecniche nonché nuove raccomandazioni per l’attuazione.
La guida è rivolta in particolare ai produttori di software e dispositivi IoT e mira a integrare sistematicamente la cibersicurezza lungo l’intero ciclo di vita del prodotto. In questa breve panoramica abbiamo riassunto gli aspetti più importanti del documento.
Quali obiettivi persegue il Playbook dell’ENISA e come è strutturato?
L’approccio dell’ENISA si basa sull’integrazione sistematica della sicurezza fin dalle prime fasi dello sviluppo, secondo il principio comunemente definito «Shift Left». I requisiti di sicurezza non vengono quindi considerati soltanto durante le attività di test o nella fase operativa, ma già nella definizione dei requisiti, nella progettazione dell’architettura e nella scelta delle tecnologie.
Questo approccio orientato al ciclo di vita comprende le fasi Requirements, Design, Implementation, Verification, Deployment, Maintenance e Disposal, anch’esse riviste e precisate nella versione 1.0.
L’ENISA chiarisce inoltre che tali processi devono essere intesi come raggruppamenti di attività e non come un modello necessariamente sequenziale. Possono sovrapporsi, essere svolti in modo iterativo e ripetersi durante il ciclo di vita del prodotto. Negli ambienti agili, ad esempio, i requisiti di sicurezza possono essere raccolti e progressivamente affinati attraverso elementi del backlog, user story, criteri di accettazione e la Definition of Done.
La terminologia adottata risulta così maggiormente allineata ai tradizionali processi di sviluppo e a riferimenti quali IEC 62443 e IEC 61508.
La versione finale definisce inoltre per la prima volta in modo esplicito gli «Intended Outcomes», che non erano ancora presenti nella bozza sottoposta a consultazione:
Il Playbook struttura i requisiti in 22 principi, suddivisi nelle categorie Secure by Design e Secure by Default. I principi sono accompagnati da misure tecniche concrete, requisiti relativi alle evidenze e criteri di rilascio.
Tra gli aspetti tecnici principali figurano la modellazione strutturata delle minacce, architetture software sicure basate su principi consolidati come Least Privilege e Defense in Depth, configurazioni predefinite sicure e una gestione continua delle vulnerabilità. A questi si aggiungono requisiti relativi al monitoraggio, all’Incident Response e alla capacità di ripristino. La resilienza viene così considerata una componente integrante dell’esercizio operativo.
Un elemento innovativo riguarda il concetto inizialmente definito «Machine-Readable Security Manifest», che nella versione 1.0 è stato rielaborato nel concetto più ampio di «Machine-processable Attestation». L’obiettivo è consentire una documentazione strutturata e trattabile automaticamente delle misure e delle evidenze di sicurezza. In questo modo anche le verifiche di conformità possono essere maggiormente automatizzate e scalate.
Oltre agli aspetti tecnici, l’ENISA sottolinea anche elementi organizzativi quali la chiara attribuzione delle responsabilità, l’integrazione della sicurezza nelle decisioni relative al prodotto e la protezione della catena di approvvigionamento. La sicurezza diventa quindi un compito interdisciplinare che coinvolge sviluppo, esercizio e management.
Nel complesso, il Playbook rappresenta un cambiamento di paradigma: la cibersicurezza non viene più considerata una funzione aggiuntiva introdotta a valle, ma una componente integrante e verificabile dell’intero ciclo di vita del prodotto. Per i fabbricanti ciò comporta non soltanto requisiti normativi più stringenti, ma anche la necessità di adeguare in modo sostanziale i propri processi di sviluppo.
Il messaggio fondamentale è chiaro: la cibersicurezza è un processo continuo, non una funzionalità una tantum.
Qual è la finalità dei 22 principi di sicurezza?
Il Playbook definisce 22 principi concreti, suddivisi in Secure by Design (14 principi) e Secure by Default (otto principi).
Ciascuno dei 22 principi è illustrato in dettaglio nel capitolo 4 del documento ENISA, intitolato Playbook, sulla base di criteri quali obiettivo, elementi tecnici di attuazione, evidenze richieste e criteri di rilascio.
L’obiettivo è trasformare i principi di sicurezza da concetti astratti in pratiche concrete di ingegneria e di esercizio. Per ogni principio vengono descritti passaggi di attuazione e criteri verificabili, in modo da rendere la sicurezza una componente misurabile e auditabile del processo di sviluppo.
I 22 principi seguono una struttura uniforme:
Quali requisiti specifici possono essere ricavati per i sistemi OT?
Nella progettazione dell’architettura e delle reti OT assume un ruolo centrale la segmentazione coerente dei sistemi industriali. La base è costituita da un modello a zone e conduit, ispirato alla serie di norme IEC 62443, che suddivide gli impianti in aree di sicurezza chiaramente delimitate e controlla in modo mirato le comunicazioni tra tali aree.
È inoltre necessaria una netta separazione tra reti IT e OT, al fine di ostacolare i movimenti laterali degli attaccanti e limitare le conseguenze degli incidenti di sicurezza.
La separazione fisica comunemente definita «air gap» non deve tuttavia essere considerata di per sé una garanzia di sicurezza. Le connessioni realmente necessarie, ad esempio per manutenzione, monitoraggio o integrazione dei dati, devono essere identificate esplicitamente e protette mediante punti di transizione controllati. Tra le misure possibili figurano firewall, gateway di protocollo e interfacce monitorate.
Particolare attenzione deve inoltre essere dedicata alla protezione degli accessi remoti, spesso indispensabili negli ambienti industriali. Tali accessi dovrebbero avvenire esclusivamente tramite meccanismi adeguatamente protetti, ad esempio connessioni VPN combinate con autenticazione a più fattori e jump host dedicati, in modo da evitare accessi diretti ai sistemi critici.
*Un jump host è un sistema appositamente protetto che funge da punto di accesso centrale e controllato per collegarsi in modo sicuro da una rete esterna, ad esempio Internet, a sistemi interni protetti.
Perché la modellazione delle minacce è un processo fondamentale negli ambienti OT?
Negli ambienti OT, la modellazione delle minacce deve essere integrata stabilmente nel processo di engineering. Devono essere considerate in modo sistematico le tipiche modalità di attacco specifiche dei sistemi industriali.
Tra queste rientra, ad esempio, la manipolazione mirata della logica di un PLC, mediante la quale possono essere influenzati direttamente i processi fisici.
Devono inoltre essere considerati i rischi derivanti da protocolli di comunicazione industriale non sicuri o configurati in modo errato, come Modbus o OPC UA, qualora i relativi meccanismi di sicurezza non siano adeguatamente implementati.
Un ulteriore scenario significativo è rappresentato dal movimento laterale attraverso le workstation di engineering, che spesso costituiscono sistemi di collegamento tra reti IT e OT e possono quindi rappresentare obiettivi particolarmente interessanti per un attaccante. Aumenta inoltre l’importanza degli attacchi alla catena di fornitura, ad esempio attraverso firmware compromessi o meccanismi di aggiornamento manipolati.
La modellazione delle minacce negli ambienti OT deve quindi andare oltre la tradizionale analisi della sicurezza IT e considerare necessariamente anche gli effetti sui processi fisici e sulle funzioni di sicurezza (Safety). Solo in questo modo è possibile valutare realisticamente il profilo di rischio dei sistemi industriali e adottare misure adeguate.
Quale ruolo svolgono la gestione dei rischi e la sicurezza operativa?
Il Playbook definisce otto attività principali nell’ambito della gestione dei rischi e della sicurezza operativa, che devono essere implementate come processi continuativi.
Tra queste figurano in particolare:
Il concetto di resilienza assume qui un ruolo centrale. Essa non viene considerata soltanto come un obiettivo dell’architettura del sistema, ma come una capacità operativa che deve essere attuata, verificata e migliorata continuamente durante l’esercizio.
Progressive Adoption: come possono le aziende introdurre gradualmente il Secure by Design?
Una delle principali novità della versione 1.0 è il capitolo «Progressive Adoption of the Playbooks». L’ENISA descrive così un approccio pragmatico che consente alle aziende, in particolare alle piccole e medie imprese (PMI), di integrare progressivamente nei propri processi di sviluppo i 22 principi Secure by Design e Secure by Default.
L’ENISA chiarisce tuttavia che questa introduzione progressiva riguarda esclusivamente l’attuazione pratica delle misure. Gli obblighi di legge, ad esempio quelli derivanti dal Cyber Resilience Act, non possono essere posticipati. La sequenza proposta serve unicamente come orientamento per introdurre le misure in modo strutturato e compatibile con le risorse disponibili.
L’ENISA propone un percorso articolato in tre fasi.
1. Definire il contesto e le priorità
In una prima fase, i fabbricanti dovrebbero analizzare il contesto del prodotto, le condizioni di utilizzo previste e i principali rischi di cibersicurezza.
Attraverso l’analisi dei rischi e il Threat Modelling vengono identificate le minacce rilevanti, i Trust Boundaries e gli obiettivi di sicurezza. Su questa base è possibile stabilire le priorità delle misure necessarie e definire in modo adeguato l’ambito dell’attuazione.
2. Creare una base tecnica di sicurezza
Nella seconda fase, l’ENISA raccomanda di creare una base tecnica di engineering che comprenda in particolare:
A seconda del tipo di prodotto, dovrebbero inoltre essere implementate importanti funzionalità Secure by Default, come accessi predefiniti restrittivi, protocolli di comunicazione sicuri, identità univoche dei dispositivi e aggiornamenti di sicurezza automatizzati.
Gli ulteriori principi del Playbook vengono quindi prioritizzati in funzione dei rischi individuati e del contesto del prodotto.
3. Ampliare continuamente il livello di sicurezza
Una volta creata una solida base, possono essere introdotti progressivamente ulteriori principi Secure by Design e Secure by Default.
L’obiettivo è aumentare continuamente la maturità delle misure di sicurezza, migliorarne la coerenza e automatizzare il maggior numero possibile di processi. Parallelamente, l’ENISA raccomanda di valutare regolarmente i progressi mediante indicatori e evidenze adeguati.
In sintesi, con il concetto di Progressive Adoption, l’ENISA fornisce per la prima volta una guida pratica per introdurre gradualmente il Secure by Design. Le aziende non devono necessariamente implementare tutte le misure nello stesso momento, ma possono procedere secondo un approccio basato sul rischio e sviluppare progressivamente i propri processi di sicurezza.
Per le PMI, questo approccio rappresenta una possibilità concreta per integrare sistematicamente e in modo sostenibile i requisiti del Cyber Resilience Act nel processo di sviluppo dei prodotti, senza ridurre l’obiettivo della piena conformità.
La versione 1.0 raccomanda inoltre espressamente l’utilizzo dell’OWASP Software Assurance Maturity Model (SAMM) come possibile modello di maturità per l’attuazione organizzativa del Secure by Design.
Il modello consente di strutturare e sviluppare progressivamente le attività di sicurezza lungo l’intero ciclo di vita dello sviluppo software. In particolare, aree quali Threat Assessment e Security Requirements mostrano come le minacce identificate possano essere tradotte in requisiti di sicurezza verificabili.
Che cos’è la Machine-processable Attestation e come viene utilizzata per fornire evidenze?
Nella versione 1.0 il concetto inizialmente denominato Machine-Readable Security Manifest (MRSM) è stato rielaborato e ampliato verso la Machine-processable Attestation.
Nella versione finale, l’ENISA si discosta quindi in parte dal concetto specifico di MRSM e descrive in modo più generale attestazioni di sicurezza trattabili automaticamente. In questo modo il concetto diventa tecnologicamente più aperto e può comprendere anche formati diversi da un unico Security Manifest.
Si tratta di un approccio volto a rappresentare le evidenze di sicurezza in forma strutturata e trattabile da sistemi automatici. L’obiettivo è documentare in modo sistematico e tracciabile il soddisfacimento dei requisiti di sicurezza.
Il concetto collega dichiarazioni di sicurezza (Security Claims) a evidenze tecniche concrete, quali dati di configurazione, risultati di test o log. Si crea così una base solida e automatizzabile per valutare il livello di sicurezza di un prodotto.
Un vantaggio particolarmente importante consiste nella possibilità di supportare verifiche di conformità automatizzate, ad esempio nell’ambito di audit. La Machine-processable Attestation affronta quindi un problema centrale dei requisiti normativi: fornire una documentazione di conformità verificabile e al contempo scalabile, che vada oltre evidenze puramente statiche o manuali.
Come vengono concretamente attuati nel Playbook i requisiti del Cyber Resilience Act?
Nell’allegato C del Playbook è riportata una correlazione diretta tra i 22 principi di sicurezza e i requisiti dell’allegato I del Cyber Resilience Act.
Per i fabbricanti ne deriva la necessità di attuare e documentare le misure di sicurezza lungo l’intero ciclo di vita del prodotto, gestire attivamente le vulnerabilità e mettere a disposizione gli aggiornamenti di sicurezza richiesti.
La cibersicurezza diventa così un requisito normativo vincolante e non può più essere considerata un elemento opzionale.
Il Secure by Design and Default Playbook dell’ENISA fornisce un quadro pratico e strutturato per integrare sistematicamente la cibersicurezza nell’intero ciclo di vita del prodotto.
Particolarmente rilevante è l’orientamento verso l’attuazione concreta dei requisiti di sicurezza. Al posto di linee guida esclusivamente astratte, il documento pone l’accento su misure pratiche, evidenze verificabili e criteri di rilascio chiaramente definiti.
Per i fabbricanti, in particolare nel contesto del Cyber Resilience Act, ciò rappresenta un significativo cambiamento di paradigma. La sicurezza non è più una misura complementare, ma una componente integrante dello sviluppo, dell’esercizio e dell’organizzazione.
L’introduzione di processi strutturati come la modellazione delle minacce, la gestione continua delle vulnerabilità e le evidenze di conformità automatizzabili può migliorare sia il livello di sicurezza sia la tracciabilità delle misure adottate.
In particolare negli ambienti industriali e OT, il Playbook offre un importante quadro di riferimento perché collega i requisiti normativi alle reali condizioni operative. Allo stesso tempo, la sua attuazione richiede una stretta integrazione tra engineering, esercizio e organizzazione, nonché un adeguamento dei processi di sviluppo e operativi esistenti.
Nel complesso, il Playbook dell’ENISA costituisce quindi una solida base per attuare e integrare la cibersicurezza in modo efficiente, sostenibile e verificabile.
La versione finale sviluppa ulteriormente la bozza sottoposta a consultazione. Mentre quest’ultima forniva già una guida pratica al Secure by Design, la versione 1.0 aggiunge obiettivi concreti, un modello di introduzione progressiva (Progressive Adoption), processi del ciclo di vita più precisi e un orientamento molto più marcato verso evidenze di sicurezza verificabili.
Il Playbook si configura così sempre più come un modello pratico di riferimento per l’attuazione tecnica dei requisiti del Cyber Resilience Act.
Download del Playbook
La versione 1.0 dell’ENISA Secure by Design and Default Playbook può essere consultata e scaricata tramite il link seguente.
Playbook «Security by Design and Default» dell’ENISA
Pubblicato il: 04/08/2026 (ultimo aggiornamento)
Wolfgang ReichDiploma HTL in Elettrotecnica, indirizzo Tecnica energetica (Dipl.-HTL-Ing.), 20 anni di esperienza nei settori della marcatura CE, della sicurezza delle macchine, della modifica di macchine, dell’elettrotecnica e della protezione contro le esplosioni, di cui 10 presso TÜV Austria e Intertek Deutschland GmbH. Presidente della commissione d’esame per il titolo di maestro artigiano presso la Camera di Commercio della Stiria per la meccatronica (tecnica di automazione ed elettronica).
E-Mail: wolfgang.reich@ibf-solutions.com | www.ibf-solutions.com
Software CE per l'ingegneria della sicurezza sistematica e professionale
Seminari pratici sulla sicurezza dei prodotti (in inglese)
Il CE-InfoService vi tiene informati sugli sviluppi importanti nel campo della sicurezza dei prodotti (in inglese).