Cybersecurity e Regolamento 2023/1230: guida pratica per la corretta gestione

L'integrazione della cybersecurity nelle macchine non è più un'opzione, ma un requisito cogente imposto dal Regolamento (UE) 2023/1230. Con l'avvicinarsi della scadenza del 20 gennaio 2027, i consulenti devono evolvere il proprio approccio metodologico per gestire l'intersezione tra sicurezza funzionale e protezione digitale.

Integrazione tra rischio meccanico e cyber

La valutazione dei rischi non può più limitarsi agli aspetti fisici. Secondo il REss 1.1.9 del Regolamento, la macchina deve essere progettata in modo tale che le connessioni non portino a situazioni pericolose. L'approccio vincente consiste nell'estendere la EN ISO 12100 incorporando l'analisi delle minacce digitali all'interno della valutazione dei rischi.

Metodologia operativa

1. Identificazione dei vettori di attacco (porte di comunicazione, accessi remoti, interfacce utente).
2. Valutazione dell'impatto di un eventuale attacco sulle funzioni di sicurezza (es. manomissione di un PLC di sicurezza).
3. Definizione di misure di protezione (segmentazione della rete, autenticazione, crittografia).

Quali software sono componenti di sicurezza?

Non tutto il codice è un 'componente di sicurezza'. Il Regolamento definisce tali componenti come elementi destinati a garantire una funzione di sicurezza il cui guasto mette in pericolo la sicurezza delle persone. Se un software gestisce, ad esempio, le logiche di un Performance Level (PL) richiesto secondo EN ISO 13849-1, esso ricade a pieno titolo nella definizione.

La distinzione è cruciale: il software che controlla esclusivamente la produttività non è un componente di sicurezza, mentre quello che elabora i segnali provenienti dai ripari o dai dispositivi di arresto di emergenza lo è. La documentazione tecnica deve riflettere chiaramente questa distinzione, evitando di appesantire inutilmente il fascicolo con componenti software irrilevanti ai fini della sicurezza.

Aggiornamenti software e modifiche sostanziali

Uno dei dubbi più frequenti riguarda l'aggiornamento software post-immissione. Il nuovo Regolamento chiarisce che gli aggiornamenti non devono essere considerati modifiche sostanziali se non alterano le prestazioni di sicurezza in modo tale da richiedere una nuova valutazione.

ATTENZIONE: Se un aggiornamento software introduce nuove funzionalità che espandono il perimetro operativo della macchina o modificano le logiche di sicurezza esistenti, si configura una modifica sostanziale. In questo caso, il fabbricante deve procedere a una nuova valutazione dei rischi e, se necessario, a una nuova procedura di marcatura CE.

Responsabilità post-vendita e vulnerabilità

Il Regolamento impone al fabbricante l'obbligo di monitorare e correggere le vulnerabilità di sicurezza. In caso di scoperta di una falla che compromette la sicurezza (es. un exploit che permette il superamento delle barriere immateriali), il fabbricante ha l'obbligo di informare gli utilizzatori e fornire le necessarie patch di sicurezza.

Il mancato intervento espone il fabbricante a responsabilità civili e penali dirette, rendendo fondamentale la creazione di un processo strutturato di Product Security Incident Response (PSIRT). La tracciabilità delle versioni software nel fascicolo tecnico diventa quindi un obbligo non solo normativo, ma di gestione del rischio d'impresa.

Come farlo con CEPilot

La gestione della complessità documentale legata ai requisiti cyber richiede uno strumento centralizzato. La Dashboard multi-progetto di CEPilot ti consente di tracciare lo stato di conformità di ogni macchina, inclusa la gestione delle versioni software e delle scadenze per le revisioni periodiche richieste dal nuovo regolamento.

In sintesi

• Integra la cybersecurity nella valutazione EN ISO 12100 fin dalla fase di design.
• Identifica chiaramente quali moduli software costituiscono componenti di sicurezza.
• Mantieni un registro aggiornato delle versioni software nel fascicolo tecnico.
• Distingui tra patch di sicurezza (manutenzione) e nuove funzionalità (modifiche sostanziali).
• Predisponi un piano di notifica per gli utilizzatori in caso di vulnerabilità critiche scoperte post-vendita.