Cyber Resilience Act (CRA) 2026–2027: o que já sabemos, o que ainda falta e como preparar o produto de forma realista — antes de surgirem normas harmonizadas

O que já sabemos com certeza hoje (e porque isto não é um “tema para 2027”)

O Cyber Resilience Act pode parecer mais um documento “de Bruxelas” que dá para deixar para mais tarde. É uma reação natural, sobretudo quando a empresa vive ao ritmo dos projetos: protótipo, implementação, produção em série, assistência. Muitas vezes, as regulamentações chegam como um “requisito final” — algo que se fecha na reta final. O CRA muda essa lógica, porque não diz respeito apenas ao que é visível no produto no dia da venda. Diz respeito a saber se o fabricante consegue manter a segurança do produto ao longo do tempo e demonstrar que o fez de forma consciente, e não por acaso.

O facto mais importante é simples, mas tem consequências estratégicas: o CRA é um regulamento de produto, assente na mecânica do mercado da UE (incluindo a marcação CE). A Comissão Europeia indica explicitamente que os produtos devem ostentar a marcação CE como sinal de conformidade com o CRA, e que a fiscalização cabe às autoridades de supervisão do mercado. Portanto, não se trata de uma “norma de TI” que possa ser tratada como um programa interno de melhoria. É um enquadramento que condiciona a possibilidade de venda.

Datas que ajudam a estruturar o pensamento

No próprio texto do Regulamento (UE) 2024/2847 vê-se uma aplicação faseada. O CRA aplica-se a partir de 11 de dezembro de 2027, mas com exceções claras. O artigo 14 (reporting) aplica-se a partir de 11 de setembro de 2026, e o capítulo sobre a notificação dos organismos de avaliação da conformidade (Chapter IV) a partir de 11 de junho de 2026. São três datas que vale a pena encarar como “marcos”, porque correspondem a três tipos diferentes de prontidão: operacional, institucional e de produto.

A Comissão comunica isto de forma ainda mais simples: o CRA entrou em vigor em 10 de dezembro de 2024, as obrigações essenciais a partir de 11 de dezembro de 2027, e o reporting a partir de 11 de setembro de 2026. Quando alguém na empresa diz “temos tempo até 2027”, na maioria das vezes está a referir-se aos requisitos de conceção e à avaliação da conformidade. Mas o reporting é mais cedo e diz respeito a acontecimentos que não esperam pelo cronograma.

Reporting: uma obrigação que impõe um processo (e não um documento)

O requisito de reporting é um bom teste decisivo, porque mostra como o CRA entende a “cibersegurança do produto”. Não é uma declaração de intenções nem uma “política”. É um processo que tem de funcionar sob pressão: quando surge uma vulnerabilidade explorada ativamente ou um incidente grave.

A Comissão descreve isto de forma inequívoca: o fabricante deve reportar vulnerabilidades exploradas ativamente e severe incidents que afetem a segurança do produto. É exigido um “early warning” no prazo de 24 horas após ter conhecimento, uma notificação completa em 72 horas e um relatório final: até 14 dias após a disponibilização de uma medida corretiva para vulnerabilidades exploradas ativamente e, no caso de severe incidents, no prazo de um mês.

Na prática, isto significa que a organização precisa de mais do que uma checklist. Precisa de um mecanismo que responda a três perguntas: como vamos saber que o problema existe; quem decide se já é “explorada ativamente” ou “severe”; e como vamos organizar a comunicação da informação e a correção dentro de um prazo que não deixa margem para improvisos.

Se, nas formações, aparece confusão, muitas vezes é porque o CRA cai numa lacuna entre TI e produto. Para TI, um “incidente” pode ser um evento na infraestrutura. Para o fabricante, um “incidente” é um evento que afeta o produto no cliente, a versão, a configuração, a forma de implementação. O CRA obriga a ligar estes dois mundos numa responsabilidade única.

O que o CRA abrange: o produto como relação com a rede, não como “um dispositivo em cima da mesa”

Na prática, ao aprendermos avaliações de risco de máquinas, percebemos que o risco não é uma característica da própria máquina — surge na relação homem–máquina. No CRA há uma mudança de perspetiva semelhante: a segurança não existe “no dispositivo”, mas na relação do produto com o ambiente digital, na forma de utilização e na capacidade do fabricante de reagir.

A Comissão, ao resumir o CRA, chama a atenção para a definição de “produtos com elementos digitais” e para o facto de as obrigações de reporting abrangerem todos esses produtos disponibilizados no mercado da UE — incluindo os colocados no mercado antes de 11 de dezembro de 2027. Este é um esclarecimento essencial, porque elimina um mito frequente: “para produtos antigos isto não conta”. O reporting conta — e muito.

O que ainda não existe (normas harmonizadas) e porque isso não deve paralisar

W conversas sobre o CRA, aparece muitas vezes a frase: “ainda não há normas harmonizadas, por isso não dá para agir”. Parece lógico, mas há aqui uma armadilha. As normas harmonizadas são uma ferramenta que facilita a demonstração de conformidade (presunção de conformidade), mas não são o único caminho para construir segurança real do produto. E não são uma condição para começar a projetar corretamente.

A Comissão aborda diretamente o tema das normas através da página “CRA Standardisation” e informa que adotou o standardisation request M/606, que abrange um conjunto de 41 normas de apoio ao CRA — tanto horizontais como verticais (de produto). Isto é importante, porque mostra que a UE compreende o problema do mercado: sem normas, as empresas vão construir a conformidade cada uma à sua maneira, e a fiscalização do mercado terá mais dificuldade.

Normas horizontais e verticais: o que isto significa para o fabricante

Em termos simples:

• as normas horizontais devem descrever “como” construir e manter a segurança do produto, independentemente da categoria (processos, métodos, abordagem baseada no risco),
• as normas verticais devem especificar melhor os requisitos para classes concretas de produtos (onde os riscos e as arquiteturas são típicos).

Esta distinção tem consequências práticas. Se está a criar um produto industrial, em que parte do ambiente é “OT” e o ciclo de vida é longo, vai precisar de normas que não são escritas para uma aplicação SaaS. E é precisamente por isso que as normas verticais são relevantes: ajudam a descer do nível de princípios gerais para aquilo que controlar em arquiteturas reais.

Cronograma dos trabalhos: as normas vão surgir por fases, não “num pacote antes de 2027”

A Comissão, nos materiais sobre a implementação do CRA, mostra que o CRA está a ser implementado de forma faseada, e que as normas devem apoiar esse processo ao longo do tempo. Ao nível dos factos que hoje são certos: temos um regulamento formalmente adotado e temos o mecanismo de normalização em funcionamento (M/606).

O mais importante, do ponto de vista prático, é compreender uma frase: mesmo quando uma norma é elaborada pelas organizações de normalização, a “presunção de conformidade”, em sentido jurídico, só surge quando a referência à norma é publicada como norma harmonizada no Jornal Oficial da UE. Esta é a mecânica comum da abordagem europeia à harmonização: as normas são a ponte entre o direito e a prática de engenharia, mas essa ponte tem de ser formalmente “reconhecida” pela UE.

Da perspetiva do fabricante, isto significa que os anos 2026–2027 serão um período em que algumas empresas vão atuar com base nos seus próprios métodos de demonstração de conformidade (baseados no risco + evidências), e outras já vão mapear-se pelas normas que forem surgindo. E isso é normal.

“Falta de normas” não significa “falta de obrigação” — significa maior peso das evidências

Aqui surge uma consequência importante: se não existem normas que ofereçam o caminho mais simples para demonstrar a conformidade, aumenta a importância daquilo que, na prática de auditoria, é sempre determinante: um rasto de decisão coerente.

Que riscos avaliámos? Que cenários considerámos realistas? Como selecionámos as medidas de proteção? Como gerimos vulnerabilidades? Durante quanto tempo damos suporte ao produto? Como informamos o cliente? O CRA não exige que o fabricante “adivinhe futuras normas EN”. Exige que o fabricante consiga mostrar que as suas decisões não foram aleatórias, mas sim baseadas no risco e no state of the art.

Como preparar, de forma realista, um produto para o CRA (roteiro para o fabricante e o integrador)

O maior valor do CRA é que força maturidade: a cibersegurança deixa de ser um extra do produto e passa a ser uma característica intrínseca. Só que a maturidade não nasce de declarações. Nasce de um processo suficientemente preciso para funcionar na prática e suficientemente simples para que a engenharia não comece a contorná-lo.

Na avaliação de risco de máquinas, as melhores decisões de projeto surgem quando deixamos de perguntar “que perigos tem a máquina” e começamos a perguntar “em que tarefas e estados a pessoa fica exposta”. No CRA, de forma análoga: deixamos de perguntar “que vulnerabilidades tem o produto” e começamos a perguntar “em que condições o produto fica exposto e o que o fabricante consegue fazer então”. Esta mudança de perspetiva organiza o trabalho.

Passo 1: Defina o produto como um sistema (e não como um dispositivo)

Comece por definir o que, no seu caso, é um “produto com elementos digitais”. Não apenas hardware e firmware, mas também aquilo que muitas vezes é ignorado por não caber na caixa: componentes, bibliotecas, mecanismos de atualização, serviços sem os quais o produto não cumpre a sua função. No CRA, isto é importante, porque a responsabilidade do fabricante diz respeito ao que é colocado no mercado como produto — e não apenas ao que foi produzido pelo departamento de mecânica.

Este é também o primeiro momento em que os integradores devem ser honestos consigo próprios: se integra componentes e os configura de uma forma que cria um “produto final” aos olhos do cliente, então não é apenas alguém de “implementação”. É coautor do risco e coautor da responsabilidade.

Passo 2: Faça a avaliação de risco do CRA de modo a que seja uma ferramenta de decisão

Não se trata de uma “matriz” em slides. Trata-se de uma avaliação de risco que conduz a decisões de projeto e que é repetível.

Na prática, uma boa abordagem à CRA começa com uma pergunta simples: quais são os cenários reais de uso indevido no ambiente do cliente, e não apenas em laboratório? Quem tem acesso de assistência técnica? Como é a rede? Com que frequência atualizamos? Quais são as consequências de uma paragem? Na indústria, estas perguntas são mais incómodas do que em TI, porque as respostas muitas vezes são: “não conseguimos atualizar todas as semanas” ou “não temos telemetria”. E é precisamente por isso que é preciso fazê-las. A CRA é lei, mas os seus efeitos são de projeto.

Krok 3: Constrói o “vulnerability handling” como um processo de produto, não como uma reação de crise

Os requisitos de reporte descritos pela Comissão (24h/72h/14 dias/mês) são implacáveis para uma organização que não tem processo. Se queres estar pronto para 11 de setembro de 2026, tens de tratar o “vulnerability handling” como parte do ciclo de vida do produto, e não como uma “tarefa da equipa de security”.

Isto significa:

• um único canal para receber reportes (política de CVD + contacto),
• triagem com responsável e critérios definidos,
• um mecanismo para criar e disponibilizar security updates,
• um modelo de comunicação para clientes que não seja improvisado,
• capacidade de reporte (quem reporta, com que dados, com que rapidez).

Tudo isto soa a trabalho “organizacional”. Na prática, é trabalho de produto, porque envolve versões, compatibilidade, arquitetura de atualização e estratégia de suporte.

Krok 4: Define o support period como uma decisão de negócio, não como um requisito mínimo

Se os teus produtos permanecem em operação na indústria durante 10–15 anos, então o support period é estratégico. A CRA obriga a que o suporte não seja uma promessa sem sustentação. Isto significa que o support period deve resultar de uma análise: durante quanto tempo o produto será utilizado, como é a cadeia de fornecimento de componentes, durante quanto tempo conseguirás disponibilizar correções. Na prática, o support period começa a “puxar” por todo o ecossistema: contratos com fornecedores, disponibilidade do build environment, manutenção de toolchains e até decisões sobre se o produto tem funcionalidades remotas ou se está isolado.

Se tratares o support period como uma formalidade, o mais tardar em 2027 vais entrar em conflito: o cliente espera suporte e tu já não tens recursos nem dependências para o fornecer. A CRA não cria este problema — a CRA apenas o expõe.

Krok 5: Organiza a cadeia de fornecimento: falar com fornecedores faz parte da conformidade

Na CRA não há “magia” que faça com que componentes externos se tornem seguros. Se o teu equipamento assenta em bibliotecas, módulos de comunicação, sistema operativo, SDK ou componentes de hardware, então o teu risco depende diretamente da qualidade das práticas do fornecedor.

Por isso, já agora vale a pena introduzir a conversa sobre coisas que não soam a marketing, mas a engenharia:

• se o fornecedor consegue informar sobre vulnerabilidades de forma previsível,
• qual é o seu tempo de resposta,
• se tem um processo de publicação de correções,
• se consegue manter o componente por um período coerente com o teu support period.

É aqui que a CRA toca realmente no negócio: um fornecedor que não consegue tratar vulnerabilidades não é “mais barato”. É um risco regulatório.

Krok 6: Constrói a documentação como um rasto coerente: lei → risco → decisão → evidência

Em auditorias de conformidade, a consistência ganha sempre. Se da avaliação de risco resulta que uma determinada interface é crítica e a documentação não descreve como a proteges; se declaras que as atualizações são seguras e não consegues mostrar como asseguras a integridade dos pacotes; se dizes que tens um processo de tratamento de vulnerabilidades e não consegues mostrar como fazes a triagem dos reportes — isso não é “falta de papel”. É falta de evidência de que o processo funciona.

Na CRA, na ausência de normas harmonizadas, este rasto é particularmente importante. Porque será ele a base da conversa com a autoridade de fiscalização do mercado, com o cliente enterprise e, em algumas categorias de produtos, também com o organismo de avaliação da conformidade. E, tão importante quanto isso: será ele a base da estabilidade interna. A equipa sabe por que fazemos algo, e não apenas “que temos de o fazer”.

Conclusão: a CRA como um novo requisito de projeto, não um “projeto de compliance”

Se eu tivesse de deixar uma única ideia que una as três partes: a CRA não é um problema para resolver no fim. É uma estrutura que muda a forma de pensar o produto. Tal como a ISO 12100 ensina que o risco nasce na relação homem–máquina, a CRA ensina que a cibersegurança nasce na relação produto–ambiente–ciclo de vida do fabricante.

As normas harmonizadas vão chegar e simplificar alguns caminhos. Mas a sua ausência não é motivo para ficar parado. É motivo para te focares naquilo que a CRA avalia sempre: decisões, evidências e capacidade de atuar na realidade — não numa apresentação.