Cyber Resilience Act

Em síntese

Durante anos, a cibersegurança dos produtos digitais foi tratada essencialmente como uma questão de risco tecnológico. Vulnerabilidades, atualizações, desenvolvimento seguro ou dependências de software eram matérias importantes, mas frequentemente geridas no interior das funções de IT, Engineering ou Cybersecurity.

O Cyber Resilience Act (CRA) — Regulamento (UE) 2024/2847 — altera significativamente este paradigma. O Regulamento estabelece requisitos horizontais de cibersegurança para produtos com elementos digitais e regras aplicáveis à sua disponibilização no mercado. Para os fabricantes abrangidos, introduz requisitos relativos às propriedades de cibersegurança dos produtos, ao tratamento de vulnerabilidades, à avaliação de risco, à documentação e demonstração de conformidade e ao acompanhamento do produto ao longo do respetivo período de suporte.

As obrigações de reporting são aplicáveis desde 11 de setembro de 2026, enquanto a aplicação geral do Regulamento ocorrerá em 11 de dezembro de 2027.

CRA changes the economics and governance of digital products.

A questão deixa de ser apenas se um produto é suficientemente seguro. Passa também a ser se reúne as condições regulatórias aplicáveis para ser colocado e mantido no mercado, durante quanto tempo terá de ser suportado, que capacidade será necessária para gerir as suas vulnerabilidades, que investimento será necessário para o adaptar e que evidências permitirão demonstrar a sua conformidade.

01. Da cibersegurança à conformidade do produto

O Anexo I do CRA estabelece requisitos essenciais de cibersegurança relativos, por um lado, às propriedades dos produtos com elementos digitais e, por outro, ao tratamento de vulnerabilidades.

Ao colocar um produto no mercado, o fabricante deve assegurar que este foi concebido, desenvolvido e produzido de acordo com os requisitos aplicáveis. Deve ainda assegurar, durante o período de suporte, que as vulnerabilidades do produto, incluindo as dos seus componentes, são tratadas eficazmente.

O fabricante deve igualmente realizar uma avaliação dos riscos de cibersegurança associados ao produto e considerar os respetivos resultados durante o planeamento, conceção, desenvolvimento, produção, entrega e manutenção.

Product  →  Risk  →  Security Requirements  →  Controls  →  Evidence  →  Conformity

A segurança deixa, assim, de poder ser observada exclusivamente através dos controlos corporativos da organização. Uma empresa pode dispor de um ISMS maduro, de processos de gestão de vulnerabilidades e de uma função de cibersegurança estruturada e, ainda assim, necessitar de demonstrar que cada produto abrangido satisfaz os requisitos CRA que lhe são aplicáveis.

02. Market Access: quando um risco cyber pode tornar-se um risco de receita

O CRA estabelece mecanismos formais de fiscalização do mercado. Quando uma autoridade de fiscalização conclui, nos termos do artigo 54.º, que um produto com elementos digitais não cumpre os requisitos do Regulamento, pode exigir ao operador económico as medidas corretivas adequadas para assegurar a conformidade, retirar o produto do mercado ou proceder ao seu recall, dentro de um prazo proporcional à natureza do risco de cibersegurança.

O artigo 57.º prevê ainda medidas proporcionais que podem incluir retirada do mercado ou recall relativamente a determinadas categorias de risco significativo, mesmo quando o produto e os processos do fabricante estejam conformes com o Regulamento.

Isto não significa que qualquer vulnerabilidade ou não conformidade determine automaticamente a proibição de comercialização. O CRA estabelece procedimentos de avaliação, medidas corretivas e respostas proporcionais à natureza do risco e da não conformidade.

Cybersecurity deficiency or significant risk  →  Regulatory assessment  →  Corrective/restrictive measures  →  Potential withdrawal or recall  →  Business impact

Para uma organização cujo negócio depende da comercialização de software, equipamentos conectados, IoT, sistemas industriais, firmware, equipamentos de rede ou outros produtos abrangidos, a exposição ao CRA pode traduzir-se não apenas em risco de compliance, mas também em risco de continuidade comercial e de receita associado ao produto.

 
03. Product Compliance: não basta implementar, é necessário demonstrar

O CRA introduz uma forte dimensão de evidência. Avaliação de risco, requisitos de segurança, tratamento de vulnerabilidades, documentação técnica, procedimentos de avaliação da conformidade, declaração UE de conformidade e marcação CE integram a arquitetura de conformidade estabelecida pelo Regulamento.

“Temos controlos de segurança?”  ≠  “Conseguimos demonstrar, para este produto, que os requisitos aplicáveis foram satisfeitos?”

A diferença entre ambas é a diferença entre security implementation e product compliance evidence. A utilização de referenciais e sistemas de gestão pode contribuir para estruturar esta resposta, mas a existência de um sistema de gestão não substitui, por si só, a necessidade de produzir as evidências, documentação e demonstração de conformidade exigidas pelo regime aplicável.

 
04. Lifecycle: o custo do produto não termina com a venda

O fabricante deve determinar um support period durante o qual assegura que as vulnerabilidades do produto são tratadas eficazmente de acordo com os requisitos do Anexo I. A data de fim desse período deve ser comunicada de forma clara ao utilizador.

O CRA estabelece critérios para determinar esse período e, em regra, prevê uma duração mínima de cinco anos, salvo quando se espere que o produto seja utilizado durante menos tempo.

A obrigação jurídica é assegurar as capacidades exigidas pelo Regulamento durante o período aplicável. A consequência económica é diferente e deve ser analisada pela organização.

Development + Security Monitoring + Vulnerability Management + Security Updates + Component Management + Support + Compliance Evidence

Surge então uma pergunta que não é colocada pelo Regulamento, mas resulta economicamente das suas exigências: o preço e a margem do produto refletem adequadamente o custo de o manter cybersecure e conforme durante o período de suporte?

 
05. Supply Chain: saber o que existe dentro do produto

Os produtos digitais modernos raramente são desenvolvidos integralmente pela organização que os comercializa. Podem incorporar bibliotecas open source, componentes comerciais, firmware, sistemas operativos, módulos de terceiros e outras dependências.

O CRA exige que as vulnerabilidades dos produtos, incluindo as dos seus componentes, sejam tratadas eficazmente durante o período de suporte. O seu Anexo I estabelece igualmente requisitos de identificação e documentação das vulnerabilidades e componentes, incluindo através de uma Software Bill of Materials — SBOM — nos termos previstos pelo Regulamento.

Component  →  Version  →  Vulnerability  →  Affected Product  →  Risk  →  Remediation

A capacidade de estabelecer rapidamente esta relação passa a suportar não apenas cybersecurity, mas também a capacidade da organização para cumprir as suas obrigações de product security. O software supply chain adquire, desta forma, uma dimensão adicional de product compliance e transparência operacional.

 
06. Transactions: que exposição regulatória estamos também a adquirir?

O CRA não estabelece requisitos específicos de M&A due diligence. Mas as obrigações que impõe aos produtos e fabricantes podem criar uma dimensão adicional a considerar em transações envolvendo empresas de software, IoT, produtos conectados ou outros produtos com elementos digitais.

Numa aquisição, podem tornar-se relevantes perguntas como: existe uma avaliação de risco por produto? Existe informação adequada sobre os componentes? O desenvolvimento suporta os requisitos de segurança aplicáveis? Existem vulnerabilidades acumuladas? O produto consegue receber atualizações de segurança? Qual é o período de suporte? Existe documentação técnica suficiente? Que investimento poderá ser necessário para alcançar ou manter conformidade?

Estamos a adquirir um produto ou também o custo futuro da sua conformidade?

A conclusão é transacional, não regulatória: uma aquisição pode transferir não apenas tecnologia, propriedade intelectual e receitas futuras, mas também necessidades futuras de investimento relacionadas com CRA readiness e compliance.

 
07. Contracts: quando a pressão pode chegar através do mercado

O CRA não estabelece uma obrigação geral segundo a qual clientes empresariais tenham de exigir contratualmente SBOM, evidências CRA ou outras garantias específicas aos seus fornecedores.

No entanto, à medida que fabricantes, integradores e compradores adaptem os seus próprios processos de gestão de risco e procurement ao novo contexto regulatório, é plausível que determinados requisitos relacionados com product cybersecurity e conformidade sejam progressivamente refletidos em RFPs, processos de procurement e relações contratuais B2B.

Trata-se de uma possível evolução de mercado, não de uma obrigação contratual universal imposta pelo CRA. Mas, quando ocorrer, a pressão para demonstrar readiness poderá chegar à organização através do cliente antes de resultar de uma intervenção da autoridade de fiscalização.

 
08. Product Modification: quando alterar um produto pode alterar responsabilidades

O CRA contempla expressamente a substantial modification e as circunstâncias em que a intervenção de um operador sobre um produto pode ter consequências para as responsabilidades que assume ao abrigo do Regulamento.

Isto não significa que qualquer customização transforme automaticamente um integrador ou distribuidor em fabricante. A qualificação depende dos critérios estabelecidos no Regulamento e das circunstâncias concretas.

A Comissão Europeia dedicou parte das orientações publicadas em julho de 2026 à clarificação do conceito de substantial modification, juntamente com scope, support periods, reporting e risk assessment. Estas orientações são oficiais, mas não vinculativas.

As alterações que fazemos ao produto alteram também a nossa posição e responsabilidades ao abrigo do CRA?

 
09. Product Strategy: todos os produtos devem ser adaptados?

É provavelmente aqui que passamos mais claramente da obrigação regulatória para a decisão empresarial. O CRA não determina quais os produtos em que uma organização deve continuar a investir, nem obriga uma empresa a preservar todo o seu portfolio. Mas as exigências de conformidade podem alterar a equação económica de determinados produtos.

Alguns produtos poderão necessitar apenas de ajustamentos limitados. Outros poderão exigir alterações arquiteturais, substituição de componentes, novos mecanismos de atualização, melhoria da gestão de vulnerabilidades ou reforço da documentação técnica.

Strategic Value × Revenue × Remaining Lifecycle × CRA Exposure × Remediation Effort × Cost of Support

Esta análise pode suportar decisões da organização sobre manter, remediar, redesenhar, substituir ou descontinuar determinados produtos. Estas não são decisões prescritas pelo CRA; são decisões de portfolio que podem ser influenciadas pelo custo e impacto das obrigações CRA.

10. Governance: afinal, quem é responsável pelo CRA?

O CRA estabelece responsabilidades para fabricantes e outros operadores económicos. Não prescreve, contudo, um modelo organizacional interno único nem determina que a responsabilidade deva pertencer ao CISO, Engineering, Product, Quality ou outra função específica.

A transversalidade dos requisitos torna, porém, relevante uma resposta coordenada. Cybersecurity, Product, Engineering, Quality, Risk, Legal/Compliance, Supply Chain, Finance e Management podem assumir papéis diferentes consoante a organização e o produto.

Cybersecurity × Product × Engineering × Quality × Risk × Legal/Compliance × Supply Chain × Finance × Management

A governance transversal não é um modelo organizacional imposto pelo CRA. É uma resposta operacional possível à transversalidade das obrigações que o Regulamento estabelece.

 
11. Da obrigação regulatória à diferenciação competitiva

O cumprimento dos requisitos aplicáveis do CRA não constitui, por si só, uma vantagem competitiva. Para os operadores abrangidos, é uma obrigação. A diferenciação poderá resultar da forma como essa obrigação é incorporada na organização.

• Security by design pode reduzir necessidades de remediação tardia.
• SBOM e component transparency podem melhorar a capacidade de analisar o impacto de vulnerabilidades.
• Evidence by design pode tornar mais eficiente a preparação e manutenção das evidências de conformidade.
• Lifecycle planning pode tornar mais previsíveis necessidades futuras de suporte.
• CRA readiness pode contribuir para a capacidade de responder a pedidos de assurance de clientes e parceiros.

Nenhum destes resultados é garantido pelo CRA. Mas são formas pelas quais uma organização pode procurar transformar uma obrigação regulatória comum numa capacidade operacional mais eficiente e, potencialmente, num elemento de confiança e posicionamento perante o mercado.

 
12. A pergunta é maior do que compliance

O CRA deve começar por uma análise rigorosa de aplicabilidade: que produtos estão abrangidos, qual o papel da organização, que classificação lhes corresponde e que requisitos são aplicáveis. Mas, para a gestão, a análise não deveria terminar aí.

• Market Access — que impacto poderá a conformidade ou não conformidade ter na disponibilização dos nossos produtos no mercado?
• Product Compliance — conseguimos demonstrar que os produtos satisfazem os requisitos obrigatórios aplicáveis?
• Lifecycle — temos capacidade para gerir a segurança e as vulnerabilidades durante o período de suporte?
• Supply Chain — sabemos que componentes e dependências existem nos produtos e conseguimos gerir as vulnerabilidades associadas?
• Transactions — que exposição e necessidades futuras de investimento CRA podem acompanhar uma aquisição?
• Contracts — estamos preparados para responder a eventuais exigências de assurance de clientes e parceiros?
• Product Modification — as alterações que fazemos podem modificar também as nossas responsabilidades regulatórias?
• Product Strategy — que impacto têm os requisitos CRA na viabilidade económica e estratégia futura de cada produto?
• Governance — quem deve participar nas decisões necessárias para assegurar uma resposta coerente ao CRA?

Porque o verdadeiro impacto empresarial do Cyber Resilience Act poderá não estar apenas na forma como as organizações protegem os seus produtos. Poderá estar também na forma como decidem quais os produtos que pretendem continuar a comercializar, quanto estão dispostas a investir na sua evolução e suporte, e como transformam segurança e conformidade demonstráveis em confiança, posicionamento e valor para o mercado.

13. Referências

European Union — Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). EUR-Lex.

European Commission — Cyber Resilience Act: Summary and implementation information.

European Commission — Guidance supporting implementation of the Cyber Resilience Act, July 2026 (non-binding guidance).

European Union — Regulation (EU) 2019/1020 on market surveillance and compliance of products, where referenced by the CRA framework.

 
Sobre o autor

Luís Lobo e Silva é Associate Partner da Crowe Advisory Portugal, com responsabilidade na área de Segurança da Informação.

Sobre a Crowe Advisory Portugal

A Crowe Advisory Portugal apoia organizações na gestão integrada de risco, transformação, governance e resiliência, articulando competências de cibersegurança e segurança da informação, operational resilience, continuidade de negócio, gestão de crise, tecnologia, dados e governance. A abordagem privilegia a ligação entre requisitos regulatórios, risco empresarial e capacidade efetiva de execução.

Este artigo constitui conteúdo de Thought Leadership e não substitui uma avaliação específica das circunstâncias, riscos ou obrigações aplicáveis a cada organização.