O Regulamento Máquinas da UE a partir de 20 de janeiro de 2027: o que exige ao software das suas máquinas

A 20 de janeiro de 2027, a Diretiva Máquinas é substituída pelo Regulamento (UE) 2023/1230, o Regulamento Máquinas. Quase tudo será familiar para quem constrói máquinas com marcação CE. Uma parte não será. Pela primeira vez, a legislação sobre máquinas impõe obrigações diretamente ao software: a máquina tem de dizer de que software precisa para funcionar em segurança, detetar quando esse software ou a sua configuração mudam, resistir à corrupção e guardar um rasto das atualizações do software de segurança durante cinco anos.

Este artigo foi escrito para os responsáveis de engenharia e de automação dos fabricantes de máquinas. Se coloca máquinas no mercado da UE depois dessa data, estes requisitos vão parar aos seus programas de PLC, à sua HMI, ao acesso remoto e ao backend de atualizações.

O que a lei diz de facto

A Comissão Europeia afirma que o Regulamento «se aplica obrigatoriamente a partir de 20 de janeiro de 2027» e que «integra disposições de cibersegurança para os dados de software relevantes para a conformidade e para os sistemas de comando de segurança». O texto publicado em 2023 indicava 14 de janeiro; uma retificação alterou a data.

As obrigações relativas ao software estão em dois requisitos essenciais de saúde e de segurança do anexo III do Regulamento.

Secção 1.1.9, proteção contra a corrupção. Em resumo:

• A ligação de outro dispositivo à máquina, diretamente ou à distância, não pode dar origem a uma situação perigosa.
• O software e os dados essenciais para o cumprimento dos requisitos de segurança «devem ser identificados como tal» e protegidos contra corrupção acidental ou intencional.
• O hardware que transmite sinais ou dados que dão acesso a esse software (pense numa porta de programação ou numa interface de rede para o controlador de segurança) também tem de estar protegido, e a máquina tem de recolher dados que evidenciem intervenções nesse hardware.
• A máquina «deve identificar o software nela instalado que seja necessário ao seu funcionamento em condições de segurança e deve estar apta a fornecer essas informações, em qualquer momento, num formato facilmente acessível».
• A máquina «deve recolher dados que evidenciem uma intervenção legítima ou ilegítima no software, bem como uma modificação do software nela instalado ou da sua configuração».

Secçã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, conducentes a uma situação perigosa levadas a cabo por terceiros». A alínea f) acrescenta a obrigação de registo: o registo de rastreamento dos dados gerados em relação a uma intervenção e das versões de software de segurança instaladas depois de a máquina ter sido colocada no mercado «seja ativado por um período de cinco anos após tal instalação». O registo existe para demonstrar a conformidade quando uma autoridade nacional apresenta um pedido fundamentado, e para mais nada.

Também na lista: a documentação técnica tem de poder incluir «o código-fonte ou a lógica de programação do software relacionado com segurança» se uma autoridade o pedir (anexo IV).

Que máquinas estão abrangidas

As regras aplicam-se às máquinas colocadas no mercado a partir de 20 de janeiro de 2027. As máquinas colocadas no mercado ao abrigo da antiga diretiva antes dessa data podem continuar a ser vendidas (artigo 52.º), e o parque já instalado não é abrangido pelas novas regras de software.

O senão está no que significa «colocado no mercado». O Guia Azul da Comissão diz que o conceito «refere-se a cada produto individual e não a um tipo de produto». Cada unidade que sai da sua fábrica para um cliente da UE a partir de 20 de janeiro de 2027 tem de cumprir os novos requisitos, software incluído. Uma família de produtos que é expedida de forma contínua precisa de ter o software de comando pronto antes da primeira unidade de 2027, não na próxima mudança de modelo.

As atualizações posteriores também merecem reflexão. Uma alteração feita «através de meios físicos ou digitais» que o fabricante não previu, e que cria um novo perigo ou aumenta um risco existente, pode ser uma alteração substancial. O considerando 32 diz que a avaliação dos riscos deve abordar as atualizações de software previstas no momento da colocação no mercado, por isso descreva já aí o seu percurso de atualizações.

O que significa em cada camada da máquina

Controlador de segurança e PLC

• Decida o que é relevante para a segurança. Normalmente é o programa de segurança, mas pode incluir código standard do PLC que alimenta uma função de segurança, parâmetros de segurança dos variadores e a configuração de scanners laser ou cortinas de luz. Deixe-o por escrito para cada família de máquinas; tudo o resto depende disto.
• Referência e comparação. Para cada configuração lançada, registe um checksum ou uma assinatura de cada elemento relevante para a segurança. No arranque e a intervalos regulares, a máquina compara o que está a correr com essa referência e regista qualquer diferença. Isto apanha a intervenção que contornou o seu controlo de acessos, como um portátil ligado diretamente ao controlador.
• Feche o acesso de engenharia. Palavras-passe no programa de segurança, portas e serviços não usados desativados, e acesso de engenharia apenas por um caminho que autentique a pessoa e registe o que ela fez.

HMI

• Um ecrã de identificação do software que liste o software relevante para a segurança, com versões e checksums. Leia os valores diretamente dos dispositivos, em tempo real. Uma página escrita à mão no momento do lançamento afasta-se da realidade, e o requisito diz «em qualquer momento».
• Ecrãs de parâmetros. A alínea d) do ponto 1.2.1 proíbe alterações das definições ou regras que possam conduzir a situações perigosas. Os parâmetros relacionados com a segurança devem ficar atrás de níveis de acesso, com limites impostos no controlador e não apenas na HMI, e cada alteração registada com quem, quando, o valor antigo e o novo.

Acesso remoto

A secção 1.1.9 refere expressamente os dispositivos remotos. Na prática:

• As funções de segurança ficam no local. Uma sessão remota pode ler, diagnosticar e preparar uma alteração. Não pode anular uma paragem, um resguardo ou um dispositivo de validação.
• As sessões são autenticadas pessoa a pessoa, não através de uma conta de serviço partilhada, e o cliente consegue ver quando há uma aberta.
• Cada início de sessão, fim de sessão e alteração entra no mesmo registo de evidências que as intervenções locais.

Backend e pipeline de atualizações

Se entrega atualizações depois da expedição, o seu servidor de atualizações entra no âmbito do trabalho. Para cada número de série, precisa de saber que versão do software de segurança foi instalada, quando e por quem. Assine as atualizações e faça com que a máquina verifique a assinatura antes de instalar o que quer que seja.

O próprio registo de rastreamento

O Regulamento não diz onde fica o registo. A nossa opinião: a cópia que conta fica na máquina, porque muitos clientes não vão permitir uma ligação permanente. Uma cópia espelhada na cloud é útil, mas não pode ser a única.

O volume é pequeno: intervenções e instalações de software de segurança, não dados de processo. Cinco anos cabem no armazenamento local se o dimensionar com esse objetivo. Proteja-o contra a eliminação e garanta que sobrevive à troca de um controlador. Se as entradas identificarem um técnico, isso são dados pessoais nas instalações do cliente: registe o que o requisito exige e mais nada.

O que o fornecedor do controlador lhe dá, e o que não dá

A sua plataforma de controladores vai fornecer parte disto. Antes de construir seja o que for, veja o que ela oferece: uma assinatura ou um checksum sobre o programa de segurança, proteção por palavra-passe, gestão de utilizadores, um registo de alterações, leitura de versões. Use o que lá estiver.

Estas são peças de construção. O fornecedor não sabe quais dos seus variadores e scanners são relevantes para a segurança, não vê o seu gateway remoto nem o seu servidor de atualizações, e não pode decidir como as evidências sobrevivem a cinco anos e à substituição de um controlador. Configurar essas funcionalidades, ligá-las em toda a máquina e documentar o resultado é trabalho do fabricante da máquina, e é o fabricante que assina a declaração de conformidade.

A relação com o Regulamento de Ciber-Resiliência

O Regulamento de Ciber-Resiliência (Cyber Resilience Act, CRA) tem o seu próprio calendário. As obrigações de notificação aplicam-se desde 11 de setembro de 2026, e os requisitos completos aplicam-se a partir de 11 de dezembro de 2027. O Regulamento Máquinas chega entre as duas datas.

O CRA reconhece a sobreposição. O considerando 53 do Regulamento (UE) 2024/2847 diz que os fabricantes de máquinas que sejam também produtos com elementos digitais devem cumprir os dois, e que a conformidade com o CRA «pode facilitar» o cumprimento das secções 1.1.9 e 1.2.1. Cabe ao fabricante demonstrar essa sinergia. O anexo I do CRA exige a proteção da integridade «dos comandos, dos programas e da configuração» e a comunicação de informações sobre as corrupções, o que está próximo do que a secção 1.1.9 pede.

Há uma diferença que pesa no desenho do seu registo. A exigência do CRA de registar e controlar a atividade interna vem acompanhada de «um mecanismo de autoexclusão para o utilizador». O registo de rastreamento do Regulamento Máquinas tem de se manter ativado durante cinco anos. Pode construir um único mecanismo de registo, se quiser, mas não deixe que a autoexclusão do CRA desligue o registo exigido para as máquinas.

Construa já para o Regulamento Máquinas, porque chega primeiro, e desenhe-o de modo que o mesmo repositório de evidências, a mesma assinatura e os mesmos registos de atualizações sirvam o CRA em dezembro de 2027.

Normas e o adiamento que não aconteceu

Não conte com a citação, até 20 de janeiro de 2027, de uma norma harmonizada que cubra estes requisitos. A página das normas harmonizadas da Comissão, na versão atualizada em setembro de 2026, diz que a primeira lista ao abrigo do Regulamento Máquinas está em preparação. Vai transpor a maior parte das normas citadas ao abrigo da diretiva e clarificá-las onde estas «ainda não abordam totalmente» os novos requisitos, e «pode ser esperada antes do final deste ano».

Em janeiro de 2026, a CEMA, a CECE, a CECIMO, a EGMF e a FEM pediram, numa posição conjunta da indústria, que as secções 1.1.9 e 1.2.1, alínea f), fossem adiadas para 11 de dezembro de 2027, em linha com o CRA. Estimaram os custos de conformidade em «mais de 1 milhão de euros por arquitetura de plataforma» e afirmaram que as normas esperadas continuam muito genéricas quanto ao registo de dados da alínea f) do ponto 1.2.1.

O pedido não foi aceite. O Regulamento Máquinas foi alterado em julho de 2026 pelo Regulamento (UE) 2026/1744, mas essa alteração trata dos sistemas de IA de risco elevado em máquinas e não mexe na data de aplicação. Planeie para 20 de janeiro de 2027.

Por isso, pode não haver, no primeiro dia, nenhuma norma que confira presunção de conformidade para estes dois requisitos. O seu processo técnico terá então de descrever a solução que aplicou para cada um (anexo IV). Escreva isso enquanto constrói, não depois. Para as máquinas enumeradas no anexo I, parte B, há mais um passo: a autoavaliação só é possível se as normas harmonizadas ou as especificações comuns cobrirem todos os requisitos pertinentes; caso contrário, intervém um organismo notificado (artigo 25.º). As máquinas não enumeradas no anexo I fazem a autoavaliação em qualquer dos casos.

Um plano de 15 semanas

De segunda-feira, 5 de outubro de 2026, até ao prazo vão pouco mais de 15 semanas, com as festas pelo meio. É apertado, mas exequível se definir prioridades pela data de expedição: as famílias com unidades para a UE a sair em janeiro vêm primeiro.

1. Semanas 1 e 2 (5 a 16 de outubro): âmbito. Liste todas as famílias de máquinas que vão expedir unidades para a UE depois de 20 de janeiro de 2027. Para cada uma, liste o software e os dados relevantes para a segurança: programa de segurança, código standard crítico para a conformidade, parâmetros de segurança de variadores e sensores, HMI, firmware, gateway remoto. Nomeie um responsável por família.
2. Semanas 3 e 4 (19 a 30 de outubro): avaliação dos riscos e lacunas. Atualize a avaliação dos riscos para as ligações, o acesso remoto, as tentativas maliciosas e o percurso das atualizações. Veja o que a sua plataforma de controladores oferece e o que está ativado.
3. Semanas 5 a 9 (2 de novembro a 4 de dezembro): construção. Ecrã de identificação do software, comparação com a referência, controlo de acessos na engenharia e no acesso remoto, o registo de rastreamento com capacidade para cinco anos, atualizações assinadas e registos por número de série no backend.
4. Semanas 10 e 11 (7 a 18 de dezembro): testar como um técnico e como um atacante o fariam. Altere um parâmetro de segurança diretamente com a ferramenta do fornecedor e confirme que a máquina o regista. Troque um controlador e verifique se o registo sobrevive. Corte a alimentação a meio de uma atualização.
5. Semanas 12 e 13 (21 de dezembro a 1 de janeiro): festas. Não planeie trabalho de engenharia; deixe um teste de longa duração a encher o registo até ao tamanho de cinco anos.
6. Semanas 14 e 15 (4 a 15 de janeiro): documentação e lançamento. Entradas do processo técnico para as secções 1.1.9 e 1.2.1, instruções de utilização que expliquem como o cliente lê a identificação do software e o que o acesso remoto pode e não pode fazer, e um passo de produção que carrega a referência lançada e a regista por número de série.

Se houver mais arquiteturas de plataforma a precisar disto do que cabem nessa janela, avise já o departamento comercial: uma unidade que não esteja pronta não pode ser legalmente colocada no mercado da UE.

Para quem isto não é

As máquinas colocadas no mercado antes de 20 de janeiro de 2027 não são abrangidas por estas regras de software, a menos que alguém as altere substancialmente mais tarde. Se compra máquinas em vez de as construir, a obrigação é do seu fornecedor; a sua parte é exigir nas especificações a identificação do software e o acesso ao registo.

Onde obter ajuda

Somos uma empresa de software, não um organismo notificado nem uma sociedade de advogados. Construímos e alteramos o software onde estes requisitos vão parar: aplicações de HMI e de backend, gateways de acesso remoto, pipelines de atualização e registo de evidências, em conjunto com os engenheiros de automação responsáveis pelo programa de segurança. As plataformas mais antigas, com anos de código acumulado, são o caso mais difícil, e é aí que costuma começar o nosso trabalho de manutenção de sistemas legados; o lado do CRA é tratado no nosso guia do Regulamento de Ciber-Resiliência. Se a sua equipa tem o plano mas não tem mãos para o concluir até janeiro, escreva para office@c9group.dev.