CRA para fabricantes de máquinas após as orientações da Comissão de 27 de julho de 2026. O que é realmente necessário implementar?

Durante anos, a cibersegurança de uma máquina podia resumir-se a três passos: controlador de marca, VPN “porque é assim que se faz” e o clássico “o cliente trata da segurança da rede”. E, se alguém ainda acrescentasse uma firewall no armário, o assunto muitas vezes dava-se por encerrado — pelo menos até alguém tentar verificar o que acontece num ataque real, e não numa apresentação.

Só que a cibersegurança não circula pelo PROFINET. Os componentes podem ter certificados, declarações e “secure by design” no folheto de marketing, mas a máquina, como um todo, pode continuar a ser previsível de uma forma que nada tem a ver com segurança. Tal como um relé de segurança não torna o sistema seguro se a lógica de controlo permitir contorná-lo, também um HMI “seguro” não resolve o problema da arquitetura, da integração, das permissões, das atualizações e do que acontece quando alguém deixa de pedir autorização.

CRA (Cyber Resilience Act, Regulamento do Parlamento Europeu e do Conselho (UE) 2024/2847) não é um complemento para a área de TI. É uma regulamentação de produto que entra no ciclo de vida da máquina sem pedir autorização ao departamento de automação. Abrange o projeto do controlo, a análise de risco, a cadeia de abastecimento, a configuração, as atualizações, bem como a manutenção do produto muito depois de o FAT ter sido assinado e de a máquina ter saído da fábrica. E não, o argumento “não a ligamos à internet” não encerra o assunto. Na prática, basta um portátil de assistência, uma pen USB, um diagnóstico remoto “só por um momento” ou a integração com o sistema da fábrica para que a fronteira entre isolamento e exposição deixe de existir.

As orientações da Comissão de 27 de julho de 2026 não alteraram o próprio regulamento, mas reduziram de forma eficaz a margem de interpretação que antes permitia tratar a cibersegurança como uma camada opcional. Foi clarificado, entre outros aspetos, o limite do produto, o papel do processamento remoto, a responsabilidade pelas alterações após a entrega e o facto de “isso já não é problema nosso depois do FAT” deixar de ser um pressuposto seguro.

A mudança mais importante, porém, é mais fundamental: o ciberataque deixa de ser apenas um evento de TI e passa a ser um cenário com impacto na segurança funcional da máquina. Se uma alteração não autorizada do programa puder provocar o movimento de um eixo, o contorno de um bloqueio, a alteração dos parâmetros do processo ou a perda de funções de segurança, então já não estamos a falar de um “incidente de rede”. Estamos a falar de um comportamento potencialmente não controlado da máquina — independentemente de a origem ter sido um erro de configuração, uma vulnerabilidade de software ou uma intervenção deliberada.

Neste contexto, um pentest pontual antes do FAT deixa de ser prova de conformidade e passa a ser apenas uma fotografia do estado do sistema num momento concreto. O CRA exige uma abordagem contínua: desde o projeto, passando pela produção e colocação em funcionamento, até às atualizações, gestão de vulnerabilidades, resposta a incidentes e manutenção durante o período de suporte declarado.

Na prática, isto significa abandonar a lógica de “feito = seguro” em favor de “mantido = controlado”. Sem a ilusão de que uma firewall no armário, uma VPN e o certificado de um componente encerram o assunto. E sem assumir que a cibersegurança termina no momento em que é assinado o auto de receção.

Neste artigo, analisamos o que as orientações do CRA realmente mudam para fabricantes, integradores e empresas de modernização de máquinas — sem reduzir todo o tema ao slogan “vamos mudar a palavra-passe e acrescentar uma checkbox de cybersecurity”.

1. Para uma máquina ficar fora do CRA, teria de ser quase toda à base de contactores

Em muitos projetos, o âmbito do CRA é verificado com uma única pergunta:

A máquina vai estar ligada à internet?

Não vai.

Então o assunto está encerrado.

No esquema há um PLC, um HMI, vários acionamentos, entradas e saídas distribuídas, uma ilha de válvulas, um scanner de segurança e uma porta para carregar o programa. O controlador comunica com o painel via PROFINET, troca palavras de controlo e de estado com os acionamentos, e os sensores transmitem dados por IO-Link.

Mas não há router com cartão SIM.

Como se sabe, os dados só passam a ser dados quando saem da nave de produção.

Só que o CRA não pergunta se a máquina tem acesso à internet.

Pergunta se a sua finalidade ou a utilização razoavelmente previsível inclui uma ligação de dados direta ou indireta, lógica ou física, a um dispositivo ou a uma rede. Não tem de ser uma ligação à cloud, ao servidor do fabricante ou à internet pública. Pode ser por cabo, por ondas de rádio, por interface de software ou como parte de um sistema maior.

E agora a pergunta-chave: o que é que, numa máquina típica, efetivamente transmite dados?

O HMI lê estados do PLC e grava parâmetros de ajuste?

O PLC envia ao acionamento uma palavra de controlo e recebe em resposta a velocidade, o estado e o código de erro?

A ilha de entradas e saídas transmite a imagem do processo?

O sensor IO-Link envia o valor de medição, o identificador do dispositivo e os dados de diagnóstico?

O safety PLC comunica com os módulos através de PROFIsafe?

O programa, a configuração de hardware ou o firmware são carregados a partir de um portátil de assistência?

As receitas, os relatórios ou as atualizações podem ser transferidos por USB?

Se a resposta for “sim” nem que seja uma única vez, então muito provavelmente estamos perante uma ligação de dados.

E isso não muda pelo facto de:

• a máquina funciona numa rede local,
• não tem endereço IP público,
• a porta Ethernet é utilizada apenas durante o arranque,
• o portátil é ligado exclusivamente pela assistência técnica,
• a comunicação ocorre apenas no interior do sistema de controlo,
• o cliente garantiu que nunca ligará a máquina à internet.

O CRA abrange não só a utilização descrita no manual como utilização prevista, mas também a utilização razoavelmente previsível. Por isso, uma porta de serviço não deixa de transmitir dados só porque no esquema lhe foi acrescentada a indicação “SERVICE ONLY”.

As orientações da Comissão de 27 de julho de 2026 introduzem, no entanto, uma distinção importante.

Nem todos os cabos e nem todos os sinais elétricos constituem uma ligação de dados.

Se o sinal servir exclusivamente para ligar, desligar ou alimentar uma determinada função e não transmitir informação codificada digitalmente, a simples existência de dois estados elétricos ainda não basta para o considerar uma ligação de dados.

Um botão que aplica tensão à bobina de um contactor não passa a ser uma interface digital só porque o seu estado pode ser descrito como zero ou um.

Da mesma forma, um fim de curso clássico ligado a um circuito de relés e contactores pode apenas interromper ou fechar o circuito. Não transmite o número do dispositivo, um valor de processo, um código de diagnóstico, a versão do firmware nem um telegrama com várias informações.

Mas, quando esse mesmo estado chega a um dispositivo inteligente, é codificado, transmitido por barramento, associado ao diagnóstico e interpretado pelo recetor como informação, a situação já é diferente.

Assim, a fronteira não está entre uma máquina “online” e “offline”.

Está entre um simples sinal de comando e a troca de informação codificada digitalmente.

Por isso, na prática, uma máquina que devesse ficar fora do âmbito do CRA apenas por não ter ligação de dados teria de se assemelhar mais a um sistema clássico com botões, fins de curso, relés e contactores do que a um projeto moderno aberto no TIA Portal.

Naturalmente, isto não constitui uma exclusão legal para contactores.

É possível construir uma máquina simples com PLC que, após uma análise detalhada, não cumpra o critério de âmbito. E também é possível acrescentar a um sistema com contactores um regulador digital, uma interface de serviço ou um módulo de comunicação e passar exatamente para o outro lado dessa fronteira.

O nome do componente não decide a questão.

O que decide é aquilo que o produto efetivamente faz e com o que troca dados.

Por isso, antes de responder à pergunta sobre se uma determinada máquina está sujeita ao CRA, é necessário determinar:

• onde se situa a fronteira do produto avaliado,
• que dispositivos e elementos de software o compõem,
• que interfaces físicas e lógicas possui,
• que informações são transmitidas por essas interfaces,
• quais as ligações diretas e quais as que ocorrem através de um sistema maior,
• quais delas ocorrem durante o funcionamento normal, o arranque, o diagnóstico, a atualização ou a assistência técnica,
• que formas de utilização são razoavelmente previsíveis, mesmo que o fabricante preferisse não as prever.

Enquanto não respondermos a estas perguntas, não sabemos se a máquina fica fora do âmbito do CRA.

No máximo, temos uma frase conveniente:

“A máquina não está ligada à internet”.

Só que isso responde a uma pergunta que o CRA não faz.

PROFINET não é a internet. E, para o CRA, nem precisa de o ser.

2. A cibersegurança não se propaga pela PROFINET

Em muitos projetos, o tema da conformidade da máquina começa logo na fase de compras.

PLC de um fabricante reconhecido.
HMI com firmware atualizado.
Switch gerível.
Router industrial com VPN.
Acionamentos com funções de segurança.
Safety PLC com o certificado adequado.

Para cada dispositivo, uma declaração de conformidade, um manual e vários documentos com expressões como “secure”, “encrypted” e “defence in depth”.

No esquema, tudo parece profissional.

Mas continua sem se saber se a máquina completa é cibersegura.

Porque a cibersegurança não “passa” pela PROFINET.

É um pouco como uma fechadura numa porta:
pode ter uma fechadura muito boa em cada divisão, certificada, testada, com documentação impecável e um holograma “secure”, mas isso continua sem garantir segurança se alguém deixou a porta de entrada escancarada “porque assim foi mais rápido no arranque”.

E aqui acontece exatamente o mesmo: os componentes podem ser exemplares e, ainda assim, o sistema pode estar… criativamente aberto.

O PLC não “transmite” segurança ao HMI.
O firewall não “corrige” a lógica da aplicação.
O switch não “organiza” os acessos dos utilizadores.
E o facto de cada elemento ter certificado não significa, por si só, que a máquina inteira não seja uma enorme vulnerabilidade, cuidadosamente documentada.

A PROFINET transmite dados.

Não transmite responsabilidade.
E, infelizmente, também não transmite bom senso.

O CRA abrange tanto produtos completos como componentes colocados no mercado separadamente. Isto significa que o controlador, o painel de operador ou o módulo de comunicação podem ser avaliados em separado. Mas o fabricante da máquina continua a ter de demonstrar que o conjunto funciona de forma segura na configuração real do cliente — ou seja, naquela versão em que alguém “de certeza que já não alterou mais nada… certo?”.

E é aqui que surge o erro mais frequente.

É exatamente o mesmo mecanismo que conhecemos há anos no âmbito da segurança de máquinas.

A cortina tem PL e.
O Safety PLC tem SIL 3.
O acionamento tem STO.

Isso significa que a máquina inteira fica automaticamente nesse nível?

É como no caso de um andaime: o facto de cada componente cumprir as normas de segurança não garante, por si só, que a estrutura completa seja estável.

Não.

Porque ainda é preciso verificar como tudo funciona em conjunto — ou seja, aquela etapa pouco popular do “pensamento sistémico”, que infelizmente não tem um botão “auto-certify”.

Na cibersegurança, é exatamente a mesma coisa.

Pode ter componentes “seguros”, mas, na prática:

• o operador vê e pode alterar mais dados do que realmente precisa, porque “assim era mais prático”,
• uma única palavra-passe de serviço funciona em todas as máquinas, porque “a assistência técnica sabe o que está a fazer”,
• a porta de serviço está acessível “por precaução”, ou seja, para qualquer eventualidade,
• o acesso remoto abrange toda a rede, porque alguém disse um dia “isto é só para diagnóstico”,
• as atualizações podem ser carregadas sem controlo, porque “nunca correu mal”,
• os dispositivos “confiam uns nos outros” sem limitações, porque a confiança sai mais barata do que a segmentação,
• e a integração parte do princípio de que ninguém alguma vez vai cometer um erro, o que é — como a história mostra — o pressuposto mais otimista da engenharia.

Cada elemento, isoladamente, pode estar correto.

Mas o sistema, como um todo, consegue pegar nesses elementos corretos e construir algo que funciona… só que não necessariamente da forma prevista.

E isto é importante: o risco não está nos dispositivos, mas sim na forma como estão ligados, na configuração e naquele acesso “temporariamente deixado” que toda a gente conhece.

O CRA exige ao fabricante da máquina algo mais do que colecionar declarações como se fossem troféus. Exige verificar se aquilo que foi montado a partir de componentes continua a ser seguro como um todo — e não apenas se “fica bem na tabela de conformidade”.

Na prática, isso traduz-se em perguntas simples, do ponto de vista do negócio:

• cada utilizador tem apenas o acesso de que realmente precisa, ou também aquilo que “pode vir a dar jeito um dia”,
• o acesso remoto está reduzido ao mínimo, ou antes ajustado ao máximo da conveniência,
• a assistência técnica não tem “permissões totais em todo o lado” só porque alguém achou que isso facilitava a vida,
• a rede não é uma única superfície comum só porque a segmentação “complica o projeto”,
• as atualizações são controladas, ou antes “carregadas e depois logo se vê”,
• é possível identificar rapidamente quais as máquinas expostas, ou a abordagem é antes “verificamos depois do incidente”,
• a falha de um único elemento não deixa o sistema inteiro exposto só porque “foi assim que saiu na integração”.

Estas não são perguntas técnicas “para os engenheiros das coisas difíceis”.

São perguntas sobre risco de negócio: paragens, custos, responsabilidade e aquele pequeno detalhe de que a produção tem mesmo de funcionar.

Por isso, não basta dizer:

“todos os componentes estão conformes”

Porque isso continua sem responder à pergunta:

a máquina inteira é segura em utilização real, ou apenas no PowerPoint da revisão de projeto?

A declaração do fornecedor é importante.

Mas diz respeito apenas a um único elemento — aquele que foi efetivamente ensaiado em condições de laboratório, e não num ambiente “algures na fábrica, com VPN, USB e pressão de tempo”.

Não abrange a forma como foi utilizado.
Não abrange a configuração.
Não abrange a integração.
Não abrange as decisões tomadas “à pressa durante o arranque, porque o cliente estava à espera”.
Não abrange o que acontece após anos de exploração, quando já ninguém se lembra por que motivo algo ficou “temporariamente aberto”.

Por isso, a avaliação não pode terminar numa lista de dispositivos.

É preciso olhar para o sistema como um todo:

• quem tem acesso e porquê (e não “porque sempre teve”),
• o que é realmente necessário e o que apenas “ficou porque não incomodava”,
• onde os dados podem escapar ao controlo porque alguém considerou que “isto é só diagnóstico”,
• o que acontece quando alguém usa um acesso legítimo de forma ilegítima (ou seja, exatamente como fazem os ataques),
• com que rapidez se consegue reagir quando surge um problema, e não apenas “na revisão trimestral”.

Enquanto não houver resposta a estas perguntas, temos apenas um conjunto de componentes muito bem feitos.

Ainda não temos uma máquina segura.

A conformidade dos componentes não cria automaticamente a conformidade do sistema. A conformidade da máquina tem de ser concebida, verificada e — o mais difícil de tudo — mantida apesar da tentação de “já não mexer em nada, porque está a funcionar”.

3. Não acrescente o ciberataque à lista de perigos. Junte as duas análises no ponto certo

No mercado das máquinas, uma análise formal do risco de cibersegurança continua a ser mais a exceção do que um elemento normal do projeto.

Normalmente, há um router industrial.

Há VPN.

Há uma palavra-passe para o PLC.

Às vezes há um switch gerível, que depois ninguém gere.

Numa versão mais ambiciosa, o fabricante recebe do fornecedor uma apresentação sobre “defence in depth” e conclui que acabou de fechar a análise de risco de cibersegurança da máquina inteira.

Não fechou.

Comprou algumas medidas técnicas.

Isso ainda não é uma análise.

Por isso, não faz sentido descrever o problema como se em cada projeto fossem produzidas duas avaliações profissionais — uma de acordo com a ISO 12100, outra relativa à cibersegurança — que apenas por acaso não foram ligadas entre si.

Na maioria dos casos, é elaborada apenas uma.

Avaliação de risco da máquina.

E a análise de cibersegurança do produto nem sequer é feita.

A avaliação de risco da máquina de acordo com a ISO 12100 não consiste em registar numa tabela:

falha do sensor → movimento inesperado → esmagamento.

Isto pode ser um fragmento de um cenário concreto, mas não o ponto de partida.

Primeiro, é necessário definir os limites da máquina.

Qual é a sua utilização prevista?

Quais são as fases do ciclo de vida?

Quem a vai utilizar?

Que tarefas serão executadas durante o transporte, a montagem, o arranque, a produção, o ajuste, a limpeza, a remoção de encravamentos, a manutenção, o diagnóstico e a desmontagem?

Em que modos de funcionamento a máquina pode operar?

Onde se encontra a pessoa durante cada uma dessas operações?

Que partes da máquina permanecem, nessa altura, sob tensão, pressão, carga ou em movimento?

Que utilização não está em conformidade com as instruções, mas continua a ser razoavelmente previsível?

Só depois, para uma tarefa ou operação concreta, se identificam, entre outros, os seguintes elementos:

• fonte de perigo,
• tipo de perigo,
• zona de perigo,
• pessoa exposta,
• situação perigosa,
• acontecimento perigoso, se ocorrer nesse cenário,
• possíveis consequências e tipo de dano.

É assim que se faz a análise de risco de uma máquina.

Não começamos pelo componente.

Começamos pela pessoa que executa uma determinada tarefa numa máquina que se encontra num determinado estado. É precisamente esta a metodologia que a ISO 12100 estabelece para a identificação de perigos, bem como para a estimativa e avaliação do risco durante as fases relevantes do ciclo de vida da máquina.

Vejamos um exemplo simples.

O operador remove uma peça encravada do interior de uma célula de paletização.

Temos então:

Tarefa: remoção do encravamento.

Fase de utilização: operação, intervenção após a paragem do processo.

Modo de funcionamento: manual ou de serviço.

Pessoa exposta: operador ou técnico de manutenção.

Zona de perigo: interior da célula, em particular o espaço entre a garra, a peça e a estrutura da máquina.

Fonte de perigo: energia mecânica do robô, do eixo linear ou da garra pneumática.

Situação perigosa: a pessoa encontra-se na zona enquanto a execução de um movimento continua a ser possível.

Acontecimento perigoso: movimento inesperado do eixo, fecho da garra ou libertação de energia acumulada.

Possível consequência: impacto, esmagamento, fratura ou amputação.

Só agora é possível avaliar o risco e definir as medidas para a sua redução.

Pode ser necessário um interbloqueio da proteção.

Pode ser necessária uma paragem segura.

Pode ser necessário evitar o arranque inesperado.

Pode ser necessário descarregar a energia pneumática.

Talvez o movimento em modo manual só possa ocorrer com um dispositivo de autorização e com velocidade limitada de forma segura.

Isto continua a ser uma avaliação de risco clássica da máquina.

Onde entra a cibersegurança?

Não como um novo item ao lado do perigo mecânico, elétrico e térmico.

“Hacker” não é fonte de perigo mecânico

Acrescentar à tabela da ISO 12100 a entrada:

Perigo: ciberataque

acrescenta muito pouco.

Um ciberataque não é um veio em rotação, uma aresta cortante, uma temperatura elevada nem energia pneumática.

Também não é uma zona de perigo autónoma.

O operador não sofre esmagamento por causa de uma vulnerabilidade CVE.

Sofre-o por causa de um elemento da máquina que executou um movimento quando a pessoa se encontrava no local errado.

Um ciberataque pode, no entanto, alterar o estado do sistema de controlo, os dados, o programa, a configuração ou o modo de atuação de uma medida de proteção.

Assim, pode tornar-se:

• a causa de um acontecimento perigoso,
• uma via adicional que conduz a uma situação perigosa,
• a causa da perda de eficácia de uma medida de redução do risco,
• ou uma forma de contornar os pressupostos adotados durante o projeto das funções de segurança.

E é aqui que está o verdadeiro ponto de contacto.

Não na lista de perigos.

Mas no comportamento da máquina.

A análise de cibersegurança deve ser elaborada em separado

Para uma máquina ou um sistema de automação industrial, a análise de cibersegurança terá uma estrutura diferente da avaliação de risco segundo a ISO 12100.

A estrutura mais natural para um sistema de automação industrial é fornecida pela IEC 62443-3-2.

A norma exige, entre outros aspetos:

• a definição do sistema sujeito à análise, ou seja, o SUC,
• a divisão do sistema em zonas e canais de comunicação,
• a avaliação do risco para cada zona e canal,
• a definição dos níveis de segurança-alvo SL-T,
• a documentação dos requisitos de segurança.

Trata-se de um ponto de partida completamente diferente do da ISO 12100.

Na IEC 62443, perguntamos, entre outras coisas:

O que pertence exatamente ao sistema analisado?

Que ativos precisam de ser protegidos?

Que dispositivos, aplicações e interfaces existem no sistema?

Que elementos devem pertencer à mesma zona?

Como decorre a comunicação entre zonas?

Quem pode obter acesso?

A partir de que local?

Com recurso a que interface?

Que vulnerabilidades podem ser exploradas?

Que dados, funções ou componentes podem ser alterados?

Por que caminho um atacante pode passar do router de serviço para o PLC, o HMI, o acionamento ou a estação de engenharia?

Que consequências terá a perda de confidencialidade, integridade ou disponibilidade?

Que medidas de proteção são necessárias?

Para o processo de desenvolvimento seguro do produto e para os requisitos aplicáveis aos próprios componentes, também serão relevantes outras partes da série, em particular a IEC 62443-4-1 e a IEC 62443-4-2. Já a IEC 62443-3-3 organiza os requisitos técnicos de segurança ao nível do sistema.

Atualmente, o CRA não obriga o fabricante a indicar na capa da análise “realizado em conformidade com a IEC 62443”.

A IEC 62443 também não substitui a demonstração de conformidade com os requisitos do CRA.

No entanto, para um sistema de automação industrial, constitui um referencial muito mais lógico do que tentar acrescentar alguns cenários de ataque informático a uma tabela da ISO 12100.

Porque ambas as metodologias respondem a perguntas diferentes.

ISO 12100:

Durante que tarefa, em que local, a partir de que fonte e em resultado de que evento uma pessoa pode sofrer danos?

IEC 62443:

Quem, por que via e explorando que vulnerabilidade pode influenciar o sistema, os seus dados ou as suas funções?

Só depois é necessário verificar se a resposta da segunda análise altera o cenário da primeira.

O mesmo cenário, duas análises diferentes

Voltemos ao operador que remove uma peça encravada.

A análise segundo a ISO 12100 mostrou que a pessoa entra numa zona onde pode ser esmagada pelo movimento do robô ou da garra.

A medida de redução do risco é um resguardo com bloqueio, uma função de paragem segura e um reset local colocado fora da zona de perigo.

Agora realizamos a análise de cibersegurança do sistema.

Identificamos:

• o router utilizado para assistência remota,
• a conta de serviço,
• o portátil de engenharia,
• o HMI,
• o PLC standard,
• o safety PLC,
• os acionamentos,
• a interface de programação,
• a rede PROFINET e a comunicação PROFIsafe,
• os mecanismos de carregamento do programa e da configuração.

Consideramos o seguinte cenário:

A tomada de controlo da conta de serviço permite o acesso remoto ao PLC standard e o envio de um comando de movimento enquanto uma pessoa está presente na célula.

Este cenário conduz a um evento perigoso?

Não é possível responder apenas com base no facto de o PLC ter sido comprometido.

É necessário verificar a arquitetura das funções de segurança.

Se a abertura do resguardo for monitorizada pelo safety PLC, se a função desligar em segurança o binário dos acionamentos, se o reset for exclusivamente local e se o PLC standard não puder restabelecer o movimento independentemente do estado da função de segurança, então a tomada de controlo do controlador standard pode parar a produção ou danificar o processo.

Mas não deverá provocar movimento com o resguardo aberto.

Nesse caso, a análise de cibersegurança demonstra o ataque.

A avaliação de risco da máquina demonstra o perigo mecânico.

No entanto, uma função de segurança corretamente concebida corta a ligação entre ambos.

E agora a segunda variante.

O modo de serviço é selecionado a partir de um HMI comum.

O valor da velocidade limitada vem do PLC standard.

O técnico remoto pode executar o reset.

A mesma conta de engenharia permite alterar o programa standard e a configuração de safety.

A cópia do programa de safety não está associada a uma versão específica da máquina.

Ninguém verifica a soma de controlo após a intervenção.

Os parâmetros do acionamento podem ser alterados remotamente.

Nesta arquitetura, a tomada de controlo da conta já não significa apenas perda de confidencialidade ou uma breve paragem.

Pode alterar as condições em que se baseava a redução do risco.

Pode conduzir a:

• seleção do modo incorreto,
• alteração do parâmetro de movimento seguro,
• reset não autorizado,
• carregamento de uma configuração não aprovada,
• ou enfraquecimento da função que deveria impedir o arranque inesperado.

E então o cenário de cibersegurança tem de ser associado a um cenário concreto de segurança da máquina:

tarefa de remoção do encravamento → pessoa na zona de perigo → alteração não autorizada do sistema de comando ou da função de proteção → movimento inesperado → esmagamento.

A fonte do perigo não mudou.

Continua a ser a energia mecânica da máquina.

A zona de perigo não mudou.

Continua a situar-se no interior da célula.

A consequência possível não mudou.

Continua a ser a lesão do operador.

O que mudou foi o caminho que conduz ao evento perigoso.

Nem toda a vulnerabilidade entra na ISO 12100

Esta distinção é igualmente importante.

Suponhamos que uma vulnerabilidade no HMI permite ler dados históricos de produção.

Isso pode ser um problema relevante do ponto de vista do CRA.

Pode violar a confidencialidade dos dados.

Pode exigir uma atualização, uma avaliação de impacto, medidas dirigidas aos utilizadores e, em determinadas circunstâncias, também a comunicação da ocorrência.

Mas, se não afetar o comportamento da máquina, não alterar uma medida de proteção e não puder conduzir a uma situação perigosa, não faz sentido forçá-la a entrar na avaliação de risco segundo a ISO 12100.

Da mesma forma, um ataque que provoque apenas a indisponibilidade dos relatórios de produção pode representar um problema de negócio e um problema de conformidade com o CRA.

No entanto, isso não significa necessariamente um risco para o operador.

Por outro lado, uma possibilidade aparentemente inofensiva de alterar um único valor de referência pode ter pouca relevância para a confidencialidade dos dados, mas um impacto enorme na segurança física.

Por exemplo, quando esse valor define:

• a velocidade máxima do eixo,
• a força de aperto,
• a temperatura do processo,
• a pressão,
• a posição de paragem,
• o tempo de abertura da válvula,
• ou o limite admissível durante o funcionamento com a proteção aberta.

Por isso, não classificamos uma ameaça cibernética com base no quão técnica ela soa.

Analisamos o que ela pode efetivamente fazer à máquina.

O regulamento relativo às máquinas exige esta ligação

Esta ligação não é apenas uma boa prática de engenharia.

O ponto 1.2.1 do anexo III do regulamento relativo às máquinas exige que os sistemas de comando sejam concebidos e construídos de forma a evitar a ocorrência de situações perigosas, incluindo as resultantes de tentativas maliciosas de terceiros que sejam razoavelmente previsíveis.

Por sua vez, o CRA indica que os seus requisitos essenciais de cibersegurança podem apoiar a demonstração de conformidade, entre outros, com os requisitos 1.1.9 e 1.2.1 do regulamento relativo às máquinas.

Mas isso não acontece automaticamente.

O fabricante tem de demonstrar essa relação com base na avaliação de risco. A avaliação da conformidade ao abrigo do CRA e a avaliação da conformidade ao abrigo do regulamento relativo às máquinas continuam a ser processos distintos.

Ou seja, não basta preparar:

• a avaliação de risco ISO 12100,
• a análise IEC 62443,
• dois relatórios separados,
• e esperar que a semelhança entre os números das normas crie, por si só, um rasto de auditoria entre ambos.

É necessário estabelecer uma ligação entre eles.

Para cada cenário cibernético relevante, é necessário determinar:

1. que elemento ou função pode ser comprometido ou alterado,
2. que comportamento da máquina isso pode provocar,
3. se esse comportamento conduz a uma situação perigosa ou a um acontecimento perigoso,
4. a que tarefa e a que zona de perigo diz respeito,
5. que consequência possível foi identificada na avaliação ISO 12100,
6. que medida de redução do risco deve interromper o desenvolvimento do cenário,
7. se essa medida continua a ser eficaz após o comprometimento do elemento atacado.

Este último ponto é o mais importante.

Porque, se o ataque e a proteção dependerem:

• do mesmo controlador,
• da mesma conta,
• da mesma rede,
• da mesma estação de engenharia,
• ou do mesmo programa,

então talvez não tenhamos duas camadas de proteção independentes.

Temos uma única camada descrita em dois documentos.

Por isso, não precisamos de uma tabela enorme com o nome:

“avaliação de risco safety & cybersecurity”.

Precisamos de duas análises corretas, realizadas com métodos adequados, e de um ponto de contacto controlado entre ambas.

A ISO 12100 deve descrever a pessoa, a tarefa, a fonte de perigo, a zona, a situação perigosa, o acontecimento perigoso e o dano possível.

A IEC 62443 deve ajudar a descrever o sistema, as suas zonas, os canais de comunicação, os ativos, as ameaças, as vulnerabilidades, os caminhos de ataque e as proteções necessárias.

E o fabricante tem de demonstrar se o cenário da segunda análise pode desencadear o cenário da primeira ou retirar eficácia à medida que deveria impedi-lo.

Um ciberataque não tem de criar um novo perigo. Basta que abra um novo caminho para um acidente antigo.

4. Um pentest antes do FAT é uma fotografia. O CRA exige um filme

Em muitos projetos, a cibersegurança só surge duas semanas antes do FAT.

É encomendado um pentest.

É elaborado um relatório.

As vulnerabilidades críticas são corrigidas, as médias são aceites, e o documento vai para a pasta do projeto.

A máquina está cibersegura.

Até à terça-feira seguinte.

Um pentest pode ser um elemento de verificação muito valioso. No entanto, mostra o estado de uma versão específica do produto, numa configuração concreta e com base em cenários de teste definidos.

Não responde à pergunta sobre o que o fabricante fará depois.

E o CRA aplica-se a todo o ciclo de vida do produto. A avaliação do risco de cibersegurança deve influenciar o planeamento, a conceção, o desenvolvimento, a produção, a entrega e a manutenção do produto. Após a sua colocação no mercado, o fabricante tem de gerir as vulnerabilidades durante o período de suporte declarado.

Voltemos à máquina de embalagem de legumes.

A máquina passou no FAT.

O pentest não detetou vulnerabilidades críticas.

Oito meses depois, o fabricante do router de serviço publica informação sobre uma vulnerabilidade que permite comprometer o equipamento.

E é aí que começa o verdadeiro trabalho.

Que máquinas entregues têm esse modelo de router?

Que versão de firmware foi instalada em cada unidade?

O acesso remoto está ativo?

A vulnerabilidade pode ser explorada na configuração real?

O comprometimento do router dá acesso apenas ao diagnóstico ou também ao HMI, PLC, acionamentos e safety PLC?

É possível apenas ler dados ou também alterar o programa ou os parâmetros?

O ataque pode afetar uma função de segurança?

O fornecedor disponibilizou uma correção?

A atualização do router vai alterar os certificados, as regras de comunicação ou a forma de estabelecer o túnel?

Após a atualização, é necessário voltar a verificar o serviço remoto, a comunicação e parte das funções de segurança?

Que clientes devem ser notificados?

E a situação cumpre os critérios de notificação de uma vulnerabilidade explorada ativamente ou de um incidente grave?

Um relatório de pentest realizado antes do FAT não responde a nenhuma destas perguntas.

Descreve uma máquina que já não existe.

Porque, desde a realização do ensaio, mudaram as versões do software, as configurações, o ambiente do utilizador e o conhecimento sobre vulnerabilidades.

Por isso, o fabricante precisa não apenas de um teste, mas de um processo:

• identificação das versões de hardware, firmware e software em cada exemplar fornecido,
• monitorização das informações sobre vulnerabilidades,
• avaliação da sua exploração na arquitetura real,
• verificação dos possíveis efeitos no processo e na segurança da máquina,
• preparação e teste de atualizações,
• informação aos utilizadores,
• documentação das decisões tomadas,
• tratamento das notificações exigidas.

A partir de 11 de setembro de 2026, os fabricantes passam a ter a obrigação de reportar vulnerabilidades exploradas ativamente e incidentes graves que afetem a segurança de produtos com elementos digitais. O aviso preliminar deve ser enviado no prazo de 24 horas, e a notificação completa no prazo de 72 horas.

Isto significa que, depois de detetado o problema, já não haverá tempo para começar a procurar:

“Quem foi, afinal, o fabricante deste router e onde temos a lista das máquinas em que o instalámos?”

A IEC 62443-4-1 mostra bem a diferença entre proteger um produto de forma pontual e assegurar um ciclo de desenvolvimento seguro. Abrange não só o projeto e a verificação, mas também a gestão de defeitos, correções e fim de vida do produto.

O FAT pode, por isso, encerrar a fase de projeto.

Não encerra o ciclo de vida do produto.

Não encerra o período de suporte.

Não põe fim à monitorização de vulnerabilidades.

Nem significa que a configuração existente na data da receção fique congelada para os quinze anos seguintes.

A máquina pode embalar legumes para supermercados durante muito tempo.

Mas o fabricante não pode embalar a sua cibersegurança juntamente com o manual, selá-la em película e considerar que foi entregue de uma vez por todas.

O pentest pode fechar um ponto da lista do FAT. O CRA abre um processo que dura até ao fim do período de suporte do produto.