Cyber Resilience Act for machines and HMIs: how Oktima lightens your load

A stylized shield on a blue grid

You have delivered a machine with an HMI. A few months later, a vulnerability is discovered in a library included in the HMI. Which machines are affected? Is an update needed? Who tells the customer?

The Cyber Resilience Act (CRA) makes these checks part of the work on the product: software security has to be looked after even after delivery.

If you are a machine manufacturer, that is, you place machines on the market under your own name, the CRA obligations are yours, towards the authorities and towards your customers, for every digital component included in the product, even those developed by third parties.

If you build the HMI in-house by putting together your own code and third-party components, such as a graphics framework and assorted libraries, maintaining the HMI application to resolve vulnerabilities over time is entirely up to you: you have to monitor the vulnerabilities of each component, assess them and fix them where needed.
If you build the HMI with a vendor's development tool, it is in your interest to check that the vendor can guarantee you information on the vulnerability status and updates with the timing and completeness the CRA requires of you.

If you choose Oktima to develop your HMI applications, they also include the Oktima runtime and its libraries. We take care of monitoring, assessing and fixing the vulnerabilities in these components. You receive the analysis results, the documentation and the updates to integrate into your product. Oktima's support thus saves you a significant part of the work the CRA requires.

CRA: two dates, two different commitments

The CRA is Regulation (EU) 2024/2847. For those who develop or integrate an HMI, there are two dates to remember:

11 September 2026: reporting obligations. The manufacturer must report actively exploited vulnerabilities and severe incidents affecting the security of the product, even if it was placed on the market before this date.
11 December 2027: product requirements and vulnerability handling. Products subject to the CRA placed on the market from that day must meet its requirements to carry the CE marking. They need secure design, technical documentation and vulnerability handling for the support period.

For new products, the risk assessment must therefore start during design. For those already delivered, you need to be able to tell today whether an exploited vulnerability affects them.

From 11 December 2027, infringements of the essential cybersecurity requirements and of the manufacturer's obligations, reporting included, can lead to fines of up to €15 million or 2.5% of total worldwide annual turnover for the preceding financial year, whichever is higher.

The work continues after the product is delivered

The manufacturer is responsible for the security of the product as a whole, third-party components included. A vulnerability in the HMI can therefore affect the machine that integrates it.

An HMI application or application firmware contains libraries for graphics, communication, cryptography and hardware management. The CRA asks you to look after their security.

Know what every released version contains. The SBOM (Software Bill of Materials) lists the software components and their versions.
Monitor new vulnerabilities. Comparing the SBOM with public databases identifies the ones to examine.
Assess whether the vulnerabilities are exploitable in the product. This is triage: a library may be vulnerable, but the product may not use the affected function. The analysis results must be justified and documented, even when no fix is needed, in what is called a VEX (Vulnerability Exploitability eXchange): it states which vulnerabilities affect the product, which do not, and why.

So the SBOM lists the components, but then the vulnerabilities have to be assessed. The work that takes the most expertise is interpreting the results. When a vulnerability affects the product, you need a fix, guidance for users and, where required, a report to the authorities.

These activities continue for the support period, which is set based on the product's expected period of use: normally at least five years, but potentially longer for an industrial machine. The regulation makes an exception for products with an expected period of use shorter than five years.

There are therefore two scenarios that deserve particular attention:

If you develop your application or application firmware in code, for example in C or C++, and/or by integrating third-party libraries and components: you have to continuously monitor and assess vulnerabilities, run tests and release fixes.
If you use an HMI tool that the vendor does not update, or if the vendor does not guarantee, for vulnerabilities, information and response times that match the completeness and deadlines the CRA requires: the vendor's shortcomings become your shortcomings as the manufacturer, and you are responsible for them under the CRA.

Secure design and updates

Handling the vulnerabilities of the HMI is part of the broader cybersecurity risk assessment, as defined by the CRA.

Before placing a product on the EU market, the manufacturer has to carry out and document an assessment of the cybersecurity risks associated with the product, taking into account its intended purpose and the context in which it is used. The risk assessment therefore serves to identify vulnerabilities and to minimise the attack surface from the development phase of the product onwards. It defines measures such as protected access, secure configurations, data protection and reliable update mechanisms, based on how and where the product will be used.

The Modbus protocol, for example, in its commonly used forms offers neither authentication nor encryption: the risk has to be addressed in the design, with measures such as network segregation and access control. A vulnerability in a software library, on the other hand, requires assessing its impact and, when needed, updating the software. Both aspects must be documented.

The risk assessment is not a one-off activity: it has to be updated throughout the product's lifecycle, especially whenever a software update changes the risk profile.

When a vulnerability is actively exploited

A known vulnerability and an actively exploited vulnerability call for different actions. In the second case, the manufacturer must report it, according to the deadlines below, to ENISA (European Union Agency for Cybersecurity) and to the national CSIRT (Computer Security Incident Response Team) through the single European SRP (Single Reporting Platform).

Within 24 hours: a first alert, or early warning.
Within 72 hours: a notification with information on the vulnerability and the measures taken.
Within 14 days of a fix or a mitigation becoming available: a final report.

For severe incidents, the final report is due within one month of the incident notification.

Affected users must be informed promptly, without undue delay, with guidance on how to contain the risk even when the update is not ready yet.

To meet these deadlines, you need a process that lets you quickly work out which products are affected and who has to act.

The work we take on

At Oktima we have a team dedicated to the CRA. For the runtime integrated into your HMIs, we track the dependencies and provide you with the analysis results (SBOM, VEX).

The process starts before release and continues on published versions:

Before the stable release, we generate the SBOM and check it against vulnerability databases. Every finding goes through triage, and we release the stable version only when no known exploitable vulnerabilities remain.
After the stable release, we continuously re-analyze the published versions. When a vulnerability emerges, we assess whether and how it affects the runtime.
If action is needed, we notify you with measures to contain the risk and prepare the fix. When it is available, you receive the update and the information to apply it.

In your reserved area you will find the SBOM of every version, the VEX updated daily and a status page:

SBOM and VEX are in CycloneDX format. You can import them into your analysis tools and integrate our analysis data into your product's documentation. The VEX keeps the results of our analyses carried out during triage, with their justifications.
The status page mirrors the VEX: you can see at any time which vulnerabilities are being triaged and which already have an outcome from our assessment. Security notifications are also sent to the email address you specify.

Us
Every day we match the SBOMs of the published versions against vulnerability databases. Reports can also come in from researchers or customers.
You
When a vulnerability emerges, the status page shows it as "in triage".

Every dayRe-scan or report

Every day we match the SBOMs of the published versions against vulnerability databases. Reports can also come in from researchers or customers.

When a vulnerability emerges, the status page shows it as "in triage".

From the fix to the machine, with Oktima

When we publish a runtime fix, you update Oktima, generate the application again, test it and install it on the affected devices. Testing the application and rolling it out to the machines remain activities you have to plan.

As manufacturers, you remain responsible for the risk assessment of the whole product, including software components outside the Oktima application, the technical documentation, conformity and CE marking, the reports due to the authorities and informing your customers.

What to do now

Responsibility cannot be delegated. If the machine carries your name, you answer for the software it contains, third-party libraries and the vendor's runtime included. A vendor can take work off your hands, not responsibility. The reporting obligations are already in force, also for machines already delivered. From December 2027, vulnerability handling becomes a condition for CE marking. Who keeps track of what is installed, who assesses the reports and what each supplier guarantees has to be settled and verified beforehand, not when an answer is needed within a few hours.

With Oktima, the part of this work that concerns your HMI's runtime is on us. If you are developing a new HMI or evaluating an alternative to your current workflow or development tool, contact us.

Further reading: the text of the regulation and the European Commission guidance for manufacturers.

Cyber Resilience Act per macchine e HMI: come Oktima vi alleggerisce il lavoro

Uno scudo stilizzato su una griglia blu

Avete consegnato una macchina con un HMI. Dopo qualche mese viene scoperta una vulnerabilità in una libreria inclusa nell'HMI. Quali macchine sono coinvolte? Serve un aggiornamento? Chi avvisa il cliente?

Il Cyber Resilience Act (CRA) rende questi controlli parte del lavoro sul prodotto: la sicurezza del software va seguita anche dopo la consegna.

Se siete fabbricanti di macchine, cioè le immettete sul mercato con il vostro nome, gli obblighi del CRA sono vostri, verso le autorità e verso i vostri clienti, per tutti i componenti digitali inclusi nel prodotto, anche se sviluppati da terze parti.

Se realizzate l'HMI in casa mettendo insieme codice vostro e componenti di terze parti, come un framework grafico e svariate librerie, la manutenzione dell'applicazione HMI per risolvere le vulnerabilità nel tempo resta completamente in carico a voi: dovete monitorare le vulnerabilità di ciascun componente, valutarle ed eventualmente correggerle.
Se realizzate l'HMI con un tool di sviluppo di un fornitore, è vostro interesse verificare che quel fornitore possa garantirvi informazioni sullo stato delle vulnerabilità e aggiornamenti secondo i tempi e con la completezza che il CRA vi richiede.

Se scegliete Oktima per sviluppare le vostre applicazioni HMI, queste includono anche il runtime di Oktima e le sue librerie. Il monitoraggio, la valutazione e la correzione delle vulnerabilità di questi componenti li facciamo noi. Ricevete i risultati delle analisi, la documentazione e gli aggiornamenti da integrare nel vostro prodotto. Il supporto di Oktima vi risparmia così una parte importante del lavoro richiesto dal CRA.

CRA: due date, due impegni diversi

Il CRA è il Regolamento (UE) 2024/2847. Per chi sviluppa o integra un HMI, le date da ricordare sono due:

11 settembre 2026: obblighi di segnalazione. Il fabbricante deve segnalare le vulnerabilità sfruttate attivamente e gli incidenti gravi che incidono sulla sicurezza del prodotto, anche se immesso sul mercato prima di questa data.
11 dicembre 2027: requisiti di prodotto e gestione delle vulnerabilità. I prodotti soggetti al CRA immessi sul mercato da quel giorno devono rispettarne i requisiti per la marcatura CE. Servono progettazione sicura, documentazione tecnica e gestione delle vulnerabilità per il periodo di supporto.

Per i nuovi prodotti, la valutazione dei rischi deve quindi iniziare durante la progettazione. Per quelli già consegnati, serve già oggi sapere se una vulnerabilità sfruttata li riguarda.

Dall'11 dicembre 2027, le violazioni dei requisiti essenziali di sicurezza e degli obblighi del fabbricante, incluse le segnalazioni, possono comportare sanzioni fino a 15 milioni di euro o al 2,5% del fatturato mondiale annuo dell'esercizio precedente se maggiore.

Il lavoro continua dopo la consegna del prodotto

Il fabbricante risponde della sicurezza del prodotto nel suo insieme, componenti di terzi compresi. Una vulnerabilità dell'HMI può quindi riguardare la macchina che lo integra.

Un'applicazione o firmware applicativo HMI contiene librerie per grafica, comunicazione, crittografia e gestione dell'hardware. Il CRA chiede di seguirne la sicurezza.

Sapere cosa contiene ogni versione rilasciata. La SBOM (Software Bill of Materials) elenca i componenti software e le loro versioni.
Monitorare le nuove vulnerabilità. Il confronto della SBOM con i database pubblici permette di individuare quelle da esaminare.
Valutare se le vulnerabilità sono sfruttabili nel prodotto. È il triage: una libreria può essere vulnerabile, ma il prodotto potrebbe non usare la funzione interessata. I risultati delle analisi vanno motivati e documentati, anche quando non serve una correzione, in un cosiddetto VEX (Vulnerability Exploitability eXchange): riporta quali vulnerabilità interessano il prodotto, quali no e perché.

La SBOM quindi elenca i componenti, ma poi bisogna valutare le vulnerabilità. Il lavoro che richiede più competenza è interpretare i risultati. Quando una vulnerabilità riguarda il prodotto, servono una correzione, indicazioni agli utenti e, nei casi previsti, una segnalazione alle autorità.

Queste attività proseguono per il periodo di supporto, stabilito in base alla durata d'uso prevista per il prodotto: di norma almeno cinque anni, ma potenzialmente più a lungo per una macchina industriale. Il regolamento prevede un'eccezione per i prodotti con una durata d'uso prevista inferiore a cinque anni.

Sono quindi due gli scenari che meritano particolare attenzione:

Se sviluppate la vostra applicazione o firmware applicativo a livello di codice, ad esempio in C o C++, e/o integrando librerie/componenti di terze parti: dovete monitorare e valutare continuamente le vulnerabilità, effettuare test e rilasciare correzioni.
Se usate un tool HMI che il fornitore non aggiorna, o se il fornitore non garantisce, rispetto alle vulnerabilità, informazioni e tempi di risposta compatibili con la completezza e le scadenze richieste dal CRA: le mancanze del fornitore diventano vostre mancanze come fabbricanti e ne siete responsabili rispetto al CRA.

Progettazione sicura e aggiornamenti

La gestione delle vulnerabilità dell'HMI si inserisce nel più ampio contesto del cybersecurity risk assessment, come lo definisce il CRA.

Prima di immettere un prodotto sul mercato UE, il fabbricante deve effettuare e documentare una valutazione dei rischi di sicurezza informatica legati al prodotto, considerandone l'uso previsto e il contesto d'uso. Il risk assessment serve quindi a individuare le vulnerabilità e a minimizzare la superficie di attacco sin dalla fase di sviluppo del prodotto. Si definiscono misure come accessi protetti, configurazioni sicure, tutela dei dati e modalità di aggiornamento affidabili, in base a come e dove sarà usato il prodotto.

Il protocollo Modbus, per esempio, nelle forme comunemente usate non offre autenticazione e cifratura: il rischio va affrontato nella progettazione, con misure come la separazione della rete e il controllo degli accessi. Una vulnerabilità in una libreria software richiede invece di valutarne l'impatto e, quando necessario, aggiornare il software. Entrambi gli aspetti devono essere documentati.

La valutazione dei rischi non è un'attività una tantum: va aggiornata lungo tutto il ciclo di vita del prodotto, specialmente ogni volta che un aggiornamento software modifica il profilo di rischio.

Quando una vulnerabilità è sfruttata attivamente

Una vulnerabilità nota e una vulnerabilità sfruttata attivamente richiedono azioni diverse. Nel secondo caso, il fabbricante deve segnalarla, secondo le scadenze di seguito, all'ENISA (European Union Agency for Cybersecurity) e al CSIRT (Computer Security Incident Response Team) nazionale attraverso la piattaforma unica europea SRP (Single Reporting Platform).

Entro 24 ore: primo avviso, o early warning.
Entro 72 ore: notifica con informazioni sulla vulnerabilità e sulle misure adottate.
Entro 14 giorni dalla disponibilità di una correzione o di una mitigazione: relazione finale.

Per gli incidenti gravi, la relazione finale è dovuta entro un mese dalla notifica dell'incidente.

Gli utenti interessati vanno informati tempestivamente, senza ritardi ingiustificati, indicando come contenere il rischio anche quando l'aggiornamento non è ancora pronto.

Per rispettare questi tempi, serve un processo che permetta di capire rapidamente quali prodotti sono coinvolti e chi deve intervenire.

Il lavoro che prendiamo in carico

In Oktima abbiamo un team dedicato al CRA. Per il runtime integrato nei vostri HMI, seguiamo le dipendenze e vi forniamo i risultati delle analisi (SBOM, VEX).

Il processo parte prima del rilascio e continua sulle versioni pubblicate:

Prima del rilascio stabile, generiamo la SBOM e la confrontiamo con i database delle vulnerabilità. Ogni risultato passa dal triage, e rilasciamo la versione stabile solo quando non restano vulnerabilità sfruttabili note.
Dopo il rilascio stabile, rianalizziamo costantemente le versioni pubblicate. Quando emerge una vulnerabilità, valutiamo se e come interessa il runtime.
Se occorre intervenire, vi avvisiamo con le misure per contenere il rischio e prepariamo la correzione. Quando è disponibile, ricevete l'aggiornamento e le informazioni per applicarlo.

Nella vostra area riservata troverete la SBOM di ogni versione, il VEX aggiornato quotidianamente e una pagina di stato:

SBOM e VEX sono in formato CycloneDX. Potete importarli negli strumenti di analisi e integrare i nostri dati di analisi nella documentazione del vostro prodotto. Il VEX conserva i risultati delle nostre analisi svolte durante il triage, con le relative motivazioni.
La pagina di stato è lo specchio del VEX: potete vedere in ogni momento quali vulnerabilità sono in fase di triage e su quali esiste già un esito frutto della nostra valutazione. Le notifiche di sicurezza arrivano anche all'indirizzo email che indicate.

Noi
Confrontiamo ogni giorno le SBOM delle versioni pubblicate con i database delle vulnerabilità. Segnalazioni possono arrivare anche da ricercatori o clienti.
Voi
Quando emerge una vulnerabilità, la pagina di stato la mostra come «in triage».

Ogni giornoRianalisi o segnalazione

Confrontiamo ogni giorno le SBOM delle versioni pubblicate con i database delle vulnerabilità. Segnalazioni possono arrivare anche da ricercatori o clienti.

Quando emerge una vulnerabilità, la pagina di stato la mostra come «in triage».

Dalla correzione alla macchina, con Oktima

Quando pubblichiamo una correzione del runtime, aggiornate Oktima, generate nuovamente l'applicazione, la verificate e la installate sui dispositivi interessati. Il collaudo dell'applicazione e la distribuzione sulle macchine restano attività che dovete pianificare.

A voi fabbricanti restano la valutazione dei rischi del prodotto intero, compresi componenti software esterni all'applicazione Oktima, la documentazione tecnica, la conformità e la marcatura CE, le segnalazioni dovute alle autorità e l'informazione ai vostri clienti.

Cosa fare ora

La responsabilità non si delega. Se la macchina porta il vostro nome, del software che contiene rispondete voi, librerie di terzi e runtime del fornitore compresi. Un fornitore può togliervi lavoro, non responsabilità. Gli obblighi di segnalazione sono già in vigore, anche per le macchine già consegnate. Dal dicembre 2027 la gestione delle vulnerabilità diventa condizione per la marcatura CE. Chi tiene traccia di cosa è installato, chi valuta le segnalazioni e cosa garantisce ogni fornitore va stabilito e verificato prima, non quando servirà una risposta in poche ore.

La parte di questo lavoro che riguarda il runtime del vostro HMI, con Oktima, la facciamo noi. Se state sviluppando un nuovo HMI o valutando un'alternativa al vostro attuale workflow o tool di sviluppo, contattateci.

Per approfondire: il testo del regolamento e le indicazioni della Commissione europea per i fabbricanti.