Cibersegurança para fabricantes de máquinas

As máquinas são hoje fornecidas com controladores, ecrãs, unidades telemáticas e aplicações complementares, a maioria construída por fornecedores. A partir de 2027, o Regulamento Máquinas e o Cyber Resilience Act esperam ambos que saiba que software está em cada máquina e que o mantenha seguro durante anos. O CRACI regista o que entra em cada build de software.

Marcar demo

Dois regulamentos, uma pergunta: que software está na máquina?

A partir de 2027, uma máquina com um controlador, um ecrã de operador ou uma ligação de dados responde a dois regulamentos da UE. Ambos partem da mesma pergunta: que software está nesta máquina, versão a versão, e o que contém?

11 de setembro de 2026Aplica-se o reporte de vulnerabilidades ativamente exploradas e de incidentes graves do Cyber Resilience Act.
20 de janeiro de 2027Aplica-se o Regulamento Máquinas, (UE) 2023/1230, que substitui a Diretiva Máquinas.
11 de dezembro de 2027O Cyber Resilience Act, (UE) 2024/2847, aplica-se na íntegra.

Regulamento Máquinas

Dois requisitos essenciais de saúde e de segurança do anexo III tratam da cibersegurança:

1.1.9, proteção contra a corrupção. A ligação de outro dispositivo à máquina, direta ou remota, não pode dar origem a uma situação perigosa. O software e os dados críticos para a conformidade da máquina com os requisitos essenciais de saúde e de segurança têm de ser identificados e protegidos contra a corrupção acidental ou intencional. A máquina tem de identificar o software nela instalado de que precisa para funcionar em segurança e disponibilizar essa informação a qualquer momento. Tem também de recolher provas de intervenções legítimas ou ilegítimas nesse software ou na sua configuração.
1.2.1, segurança e fiabilidade dos sistemas de comando. Os sistemas de comando têm de resistir a tentativas maliciosas razoavelmente previsíveis de terceiros que conduzam a uma situação perigosa. Ao abrigo de 1.2.1(f), têm de manter um registo de rastreio das intervenções e das versões do software de segurança carregadas depois de a máquina ter sido colocada no mercado, durante cinco anos após o carregamento.

Cyber Resilience Act

Uma máquina com ligação de dados, ou uma parte dela vendida separadamente, é um produto com elementos digitais. O fabricante tem de exercer a devida diligência sobre os componentes de terceiros que integra, elaborar uma SBOM que abranja pelo menos as dependências de nível superior, tratar as vulnerabilidades durante o período de suporte, que é de pelo menos cinco anos, salvo se se previr que o produto seja utilizado durante menos tempo, e conservar a documentação técnica durante pelo menos dez anos ou durante o período de suporte, consoante o que for mais longo.

Requisito	Regulamento Máquinas	Cyber Resilience Act	O que exige do lado do software
Conhecer o software instalado	1.1.9: a máquina identifica a qualquer momento o software de que precisa para funcionar em segurança	Uma SBOM que abranja pelo menos as dependências de nível superior	Um registo de cada componente em cada versão do software
Protegê-lo contra a corrupção	1.1.9 e 1.2.1: proteger o software de segurança e resistir a tentativas maliciosas	Requisitos essenciais de cibersegurança do produto	Componentes conhecidos e builds a que uma dependência envenenada não consegue chegar
Registar alterações e versões	1.2.1(f): registo das versões do software de segurança carregadas após a colocação no mercado	Documentação técnica do produto colocado no mercado	Histórico de versões por build e por release
Tratar as vulnerabilidades	Não referido como tal	Tratamento de vulnerabilidades durante o período de suporte; reporte desde 11 de setembro de 2026	Monitorização dos componentes distribuídos face a novos avisos de segurança
Conservar os registos	Registo de rastreio: cinco anos após cada carregamento	Documentação técnica: pelo menos dez anos ou o período de suporte	SBOM exportadas para a documentação técnica

Cumprir o CRA abrange o Regulamento Máquinas?

Não automaticamente. O Cyber Resilience Act não confere presunção de conformidade com o Regulamento Máquinas. O seu considerando 53 diz que cumprir os requisitos essenciais do CRA pode facilitar o cumprimento dos requisitos do Regulamento Máquinas relativos à proteção contra a corrupção e à segurança e fiabilidade dos sistemas de comando. Diz também que o fabricante tem de o demonstrar, por exemplo aplicando normas harmonizadas após uma avaliação de riscos, e que os procedimentos de avaliação da conformidade de ambos os regulamentos continuam a aplicar-se.

A norma harmonizada em preparação para o ponto 1.1.9 é a EN 50742, Safety of machinery – Protection against corruption. Em novembro de 2026 era um projeto final, FprEN 50742, que abrange o ponto 1.1.9 e os pontos relacionados do 1.2.1, e enquanto a referência de uma versão definitiva não for publicada no Jornal Oficial da UE não confere presunção de conformidade. Combina a avaliação do risco da EN ISO 12100 com conceitos de segurança da IEC 62443 e aceita a aplicação coerente da IEC 62443-4-1, da IEC 62443-3-3 e da IEC 62443-4-2 como via equivalente para cumprir os seus objetivos de proteção. A IEC 62443-4-2 define os requisitos técnicos de segurança dos componentes de sistemas de controlo, graduados por nível de capacidade de segurança. Na Alemanha, os princípios de ensaio GS-IFA-M25, de julho de 2026, traduzem a proteção contra a corrupção em 66 critérios de ensaio, com a terminologia da prEN 50742. Um deles, o T46, pede que o produto possa fornecer, a pedido, a versão e a configuração do software instalado. Responder a isso para cada configuração exige um registo do que contém cada versão do software.

O Regulamento Máquinas tem uma presunção própria, que passa por outra via: os sistemas europeus de certificação da cibersegurança adotados ao abrigo do Regulamento Cibersegurança, Regulamento (UE) 2019/881. Um certificado ou uma declaração de conformidade emitidos no âmbito de um desses sistemas presumem a conformidade com 1.1.9 e 1.2.1, na medida em que abranjam esses requisitos.

Assim, uma avaliação de riscos e um conjunto de evidências podem servir ambos os regulamentos, mas a conformidade demonstra-se perante cada um. Se a sua máquina tiver uma ligação de dados, planeie para ambos. As evidências do software, ou seja, as SBOM, os registos de vulnerabilidades e o histórico de atualizações, são a parte que partilham.

Em janeiro de 2026, associações do setor das máquinas pediram o adiamento de 1.1.9 e 1.2.1(f) e, em março de 2026, que se aplicassem a partir da data do CRA, 11 de dezembro de 2027. É um pedido, não uma lei: em novembro de 2026 não tinha sido adotado nenhum adiamento. As datas desta página são as datas dos regulamentos.

Que máquinas e que software estão abrangidos

As máquinas de construção, de movimentação de materiais, de mineração e industriais estão abrangidas pelo Regulamento Máquinas, e também pelo CRA quando a máquina ou as suas partes têm uma ligação de dados.
Os tratores agrícolas e florestais abrangidos pelo Regulamento (UE) n.º 167/2013 estão excluídos do Regulamento Máquinas, exceto as máquinas neles montadas. A lista de exclusões do CRA não refere esse regulamento, pelo que um trator ligado pode estar no âmbito do CRA.
Os veículos rodoviários homologados ao abrigo do Regulamento (UE) 2019/2144 estão excluídos do CRA.
Componentes vendidos separadamente. O CRA aplica-se também aos componentes de software e hardware colocados separadamente no mercado. Um fornecedor que vende separadamente uma ECU ou uma unidade telemática é, por direito próprio, um fabricante ao abrigo do CRA. Quando a unidade é apenas integrada na máquina, o fabricante da máquina assume a obrigação pela máquina inteira e tem de exercer a devida diligência sobre o componente do fornecedor.

Esta é informação geral, não aconselhamento jurídico. Verifique a classificação do seu próprio produto.

Dentro de uma mesma máquina, o software vem de vários sítios, e só a equipa que constrói um software consegue dizer com fiabilidade o que contém. Pelo que ouvimos dos fabricantes de máquinas, as ECU bare-metal têm pouco open source, enquanto o software em Linux, Android e Windows tem muito.

Software	Origem típica	Peso do open source	Quem consegue produzir uma SBOM fiável	Onde o CRACI se encaixa
Aplicação do controlador da máquina	Interna ou de fornecedor	Variável	A equipa que a constrói	Quando é construída em GitHub Actions sobre Linux
Firmware de ECU (hidráulica, direção, potência)	Fornecedor	Normalmente baixo: código proprietário e gerado a partir de modelos	O fornecedor	Não diretamente: através da SBOM do fornecedor, adicionada ao CRACI
Imagem Linux do ecrã ou da HMI	Interna ou de fornecedor	Elevado	A equipa que constrói a imagem	Sim: builds Yocto e de outros Linux embebidos
Gateway telemático	Interna ou de fornecedor	Elevado	A equipa que o constrói	Sim, quando é construído em GitHub Actions
Aplicações de diagnóstico e complementares	Interna	Elevado	A equipa da aplicação	Builds npm, PyPI, Go e Cargo, sim; aplicações Android com Gradle, iOS e Windows, hoje não
Back end na cloud	Interna	Elevado	A equipa do serviço	Sim, para builds em GitHub Actions

Porque é que as máquinas são mais difíceis do que a eletrónica de consumo

Baixo volume, grande variedade. Um fabricante de máquinas pode ter centenas de plataformas no mercado, vender meia dúzia de unidades de cada por ano e configurar muitas máquinas por encomenda. Cada configuração é um conjunto de software diferente, por isso uma SBOM por cada build importa mais do que uma SBOM por cada linha de produto.

Vidas úteis longas. As máquinas ficam em serviço durante uma década ou mais, enquanto os fornecedores mudam ou deixam de existir. O registo do que entrou numa versão de software tem de ser feito quando é construída, porque não pode ser reconstruído anos depois.

O software de fornecedores domina, e as SBOM dos fornecedores são muitas vezes fracas. Ouvimos falar de SBOM de fornecedores com componentes em falta, sem package URLs nem CPE, sem licenças e sem hashes, algumas escritas à mão e que falham a validação do esquema. A análise binária de uma ECU já programada é um remedeio: adivinha o conteúdo em vez de o registar.

O risco está nas camadas ligadas. Grande parte da lógica das ECU é gerada a partir de modelos e contém pouco open source. O open source, e a exposição à rede, concentram-se nas camadas de Linux, conectividade e aplicações, por isso concentre aí o seu esforço primeiro.

Um exemplo ilustrativo: a stack de software de uma plataforma fictícia de pá carregadora de rodas, da cloud até às ECU.

Back end na cloud e aplicação complementarInternos. Sobretudo open source e expostos à rede. Cyber Resilience Act.
Gateway telemáticoLinux embebido, sobretudo open source, ligado à rede móvel. Cyber Resilience Act, e 1.1.9 pela ligação remota.
Ecrã do operadorImagem de Linux embebido com uma framework de interface, sobretudo open source, ligada ao barramento da máquina e às ferramentas de assistência. Cyber Resilience Act e 1.1.9.
Controlador da máquinaAplicação interna sobre uma plataforma de fornecedor, relevante para a segurança. 1.1.9 e 1.2.1, e o Cyber Resilience Act quando pode ser alcançado através de uma ligação.
ECU hidráulica, de direção e do motorFirmware de fornecedores, proprietário e gerado a partir de modelos, com pouco open source, relevante para a segurança. 1.1.9 e 1.2.1; o Cyber Resilience Act através da máquina.

O open source e a exposição à rede estão nas três camadas de cima, que é também onde costumam estar os seus próprios pipelines de build. Comece por aí.

Como se preparar, passo a passo

Funcionalidades da máquina como a identificação do software na máquina e os registos de intervenções fazem parte do design da máquina. Os passos abaixo cobrem o software que entra nela.

Inventarie o software de cada plataforma de máquina. Liste cada software de cada plataforma e configuração, e assinale o que é relevante para a segurança. É o ponto de partida para 1.1.9, que pede à máquina que identifique o software de que precisa para funcionar em segurança.
Separe o que constrói do que integra. O software que as suas equipas constroem e o software que chega dos fornecedores precisam de vias de evidência diferentes. No primeiro caso, produz o registo; no segundo, define requisitos e verifica o que recebe.
Registe cada build de release do seu próprio software. Produza uma SBOM a partir de cada build de release, guarde-a por versão e monitorize-a quanto a novas vulnerabilidades durante todo o período de suporte.
Defina um padrão mínimo para as SBOM de fornecedores. Acorde o formato e os campos de que precisa, como package URLs ou CPE, licenças e hashes, valide cada entrega e devolva-a quando falhar. Veja como os fornecedores respondem a pedidos de SBOM de clientes.
Planeie a conservação para a vida da máquina. Conserve a documentação técnica do CRA durante pelo menos dez anos ou o período de suporte, consoante o que for mais longo, e o registo do software de segurança de 1.2.1(f) durante cinco anos após cada carregamento. Planeie-o para a vida da máquina, não para a duração do projeto.
Ponha em prática o tratamento e o reporte de vulnerabilidades. O reporte de vulnerabilidades ativamente exploradas e de incidentes graves ao abrigo do CRA aplica-se desde 11 de setembro de 2026. Decida quem faz a triagem das conclusões, quem é responsável por cada correção e quem reporta.
Proteja o próprio build. Execute cada build num ambiente isolado que só alcance as fontes de que precisa, para que uma dependência comprometida não consiga chegar ao seu código-fonte, aos seus segredos ou à sua release.

Onde o CRACI se encaixa

O CRACI executa os seus builds de GitHub Actions nos seus próprios runners e regista o que entra em cada um. Para um fabricante de máquinas, isso cobre o software que as suas equipas constroem e as SBOM de fornecedores que recolhe.

Registos de build para o software de máquina que constrói

Execute os seus serviços de controlador e as suas imagens Linux de ecrã e telemática, incluindo builds Yocto e de outros Linux embebidos, nos runners de GitHub Actions do CRACI, até 32 vCPU, em x86-64 ou ARM64 nativo. Durante o build, o CRACI regista todos os pacotes e ficheiros que obtém, incluindo as dependências ocultas que nenhuma receita ou lockfile lista, e marca a SBOM de cada job com um estado de completude. Num build core-image-sato, a SBOM do CRACI tinha todos os componentes da própria SBOM do Yocto, mais 88 que esta não incluía, com um package URL para cada uma das 653 versões de crates Rust. Saiba mais sobre builds Yocto no CRACI.

SBOM de fornecedores a par das suas

Adicione SBOM dos seus fornecedores de ECU, ecrãs e unidades telemáticas, e os componentes adquiridos são monitorizados a par do software que constrói. Quando surge uma nova vulnerabilidade na stack Linux de um fornecedor, aparece no mesmo registo que a sua.

Que máquinas estão afetadas, e desde quando

O CRACI continua a reavaliar as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades. O histórico de builds mostra que builds continham a dependência vulnerável, direta ou transitiva, dentro do período de retenção do seu plano, e a vista de inventário mostra que versões de software estão implementadas em que produtos. As equipas de segurança fazem a triagem de cada conclusão e encaminham-na para a equipa responsável pela correção, e um policy gate pode manter uma CVE específica fora de todos os builds posteriores.

Evidências para o processo técnico

O CRACI fornece as evidências da cadeia de abastecimento de software de que a sua documentação técnica precisa: SBOM registadas durante o build e exportadas em CycloneDX ou SPDX, com dependências transitivas, licenças declaradas e as vulnerabilidades encontradas nos seus componentes, além de registos de vulnerabilidades e histórico de builds. Para máquinas abrangidas pelo CRA, o CRACI prepara o conteúdo das notificações do CRA, e uma pessoa da sua empresa submete-as através da Single Reporting Platform. A avaliação da conformidade, a declaração UE de conformidade e a marcação CE continuam a seu cargo, enquanto fabricante.

Um build que só alcança aquilo de que precisa

Cada job é executado na sua própria máquina virtual isolada, sob uma política de egress validada antes de o job arrancar e com falha em modo fechado. Com uma política de negação por predefinição, o build alcança as suas fontes de pacotes e mais nada, e uma ligação a qualquer outro host é bloqueada e gera um alerta.

Para fornecedores de ECU, ecrãs e unidades telemáticas

Os fabricantes de máquinas definem agora requisitos de SBOM para o software que compram, como package URLs ou CPE, licenças, hashes e um formato que passe a validação, e devolvem os ficheiros que falham. Se construir em GitHub Actions, o CRACI produz a SBOM a partir do próprio build, por isso lista o que realmente entrou na versão, incluindo os componentes que nenhum lockfile refere, com um package URL e a licença declarada de cada componente. Verifique a exportação face à lista completa de campos que o seu cliente pede. Saiba mais sobre como responder a pedidos de SBOM de clientes.

Quando o CRACI não é a resposta

O CRACI serve para o software que constrói. Não serve para estes casos:

Não para um fabricante de máquinas que apenas integra ECU de fornecedores e não constrói software próprio. O CRACI regista builds; não consegue produzir uma SBOM para um binário construído por outra pessoa. Se quase todo o seu software chega já programado em hardware de fornecedores, as suas ferramentas são os requisitos de SBOM para fornecedores, a validação de SBOM e, como remedeio, a análise binária, que o CRACI não faz (veja a análise binária comparada com um registo do build). O CRACI ajuda-o através dos builds dos seus fornecedores e monitorizando as SBOM que lhe entregam.
Não para firmware bare-metal ou RTOS construído fora do GitHub Actions, ou construído em Windows ou macOS. Hoje o CRACI executa jobs de GitHub Actions em runners Linux. Outros sistemas de CI, como o GitLab CI e o Jenkins, e os runners Windows e macOS estão no roadmap.
Não para aplicações Android complementares construídas com Gradle, nem para serviços Java. Maven e Java estão no roadmap, não são suportados hoje. As aplicações iOS precisam de runners macOS, que também estão no roadmap.
Não para máquinas já em serviço cujo software foi construído há anos. O CRACI regista os builds à medida que são executados.
Não os controlos na máquina. Identificar o software instalado na máquina, recolher provas de intervenções e manter o registo de rastreio são funcionalidades da máquina ao abrigo de 1.1.9 e 1.2.1. O CRACI não as fornece, não assina firmware e não realiza a avaliação da conformidade.
Não é, por si só, um arquivo de longo prazo. Os registos de build são guardados durante o período de retenção do seu plano. Exporte as SBOM para a sua documentação técnica para o horizonte de dez anos.

A cibersegurança das máquinas explicada

Perguntas comuns sobre o Regulamento Máquinas, o CRA e o software de uma máquina

Quando se aplica o Regulamento Máquinas da UE?

A partir de 20 de janeiro de 2027. O Regulamento (UE) 2023/1230 substitui a Diretiva Máquinas nessa data. O texto inicialmente publicado indicava 14 de janeiro de 2027; uma retificação corrigiu-o para 20 de janeiro de 2027. As máquinas colocadas no mercado da UE a partir dessa data têm de cumprir os seus requisitos essenciais de saúde e de segurança, incluindo os relacionados com a cibersegurança do anexo III, 1.1.9 e 1.2.1.

Quais são os requisitos de cibersegurança do Regulamento Máquinas?

Anexo III 1.1.9, proteção contra a corrupção: a ligação de outro dispositivo não pode criar um perigo, o software e os dados críticos para a segurança têm de estar protegidos, e a máquina tem de identificar a qualquer momento o seu software relevante para a segurança e recolher provas de intervenções. Anexo III 1.2.1: os sistemas de comando têm de resistir a tentativas maliciosas razoavelmente previsíveis e manter um registo de rastreio das versões do software de segurança carregadas depois de a máquina ter sido colocada no mercado.

O Cyber Resilience Act aplica-se às máquinas?

Sim, quando a máquina ou uma parte dela é um produto com elementos digitais, o que na prática significa que tem uma ligação de dados. O CRA não exclui as máquinas. As suas obrigações de reporte aplicam-se desde 11 de setembro de 2026, e aplica-se na íntegra a partir de 11 de dezembro de 2027, onze meses depois do Regulamento Máquinas.

Se uma máquina cumprir o CRA, também cumpre o Regulamento Máquinas?

Não automaticamente. Não há presunção de conformidade entre os dois. O CRA diz que cumprir os seus requisitos pode facilitar o cumprimento de 1.1.9 e 1.2.1, mas o fabricante tem de o demonstrar, e aplicam-se ambos os procedimentos de avaliação da conformidade. A presunção própria do Regulamento Máquinas passa pelos sistemas europeus de certificação da cibersegurança. Um mesmo conjunto de evidências pode servir ambos.

Um fabricante de máquinas precisa de uma SBOM?

Para uma máquina no âmbito do CRA, sim: o CRA exige que o fabricante elabore uma SBOM que abranja pelo menos as dependências de nível superior. O Regulamento Máquinas não refere SBOM, mas 1.1.9 pede à máquina que identifique o software de que precisa para funcionar em segurança, o que é difícil de manter exato em muitas configurações sem um registo de cada versão de software.

Quem é responsável pelo software da ECU de um fornecedor?

Ambos, em papéis diferentes. Um fornecedor que coloca separadamente uma ECU no mercado é fabricante ao abrigo do CRA para esse componente. O fabricante da máquina é responsável pela máquina inteira e tem de exercer a devida diligência sobre os componentes que integra, e é por isso que os fabricantes de máquinas pedem agora aos fornecedores SBOM que cumpram um padrão definido.

Os tratores estão abrangidos pelo Regulamento Máquinas ou pelo CRA?

Os tratores agrícolas e florestais abrangidos pelo Regulamento (UE) n.º 167/2013 estão excluídos do Regulamento Máquinas, exceto as máquinas neles montadas. As exclusões do CRA não referem esse regulamento, pelo que um trator ligado pode estar no âmbito do CRA. Verifique a classificação do seu próprio produto; esta é informação geral, não aconselhamento jurídico.

Que sistemas de CI e máquinas de build suporta o CRACI?

O CRACI executa jobs de GitHub Actions em runners Linux, x86-64 e ARM64, de 1 a 32 vCPU. Outros sistemas de CI, como o GitLab CI e o Jenkins, estão no roadmap, tal como os runners Windows e macOS.

Veja o que entra nos builds do software das suas máquinas

Marque uma demo e mostraremos todos os componentes que os seus builds de controlador, ecrã e telemática obtêm, e quais deles são vulneráveis

Marcar demo