Cyber Resilience Act: O que Muda para as PME Portuguesas

O Cyber Resilience Act (CRA) é o regulamento da União Europeia que impõe requisitos de cibersegurança a produtos com elementos digitais — de impressoras a apps, de routers a software de gestão. Para PMEs portuguesas, toca em dois lados: quem fabrica/vende software ou hardware ligado (obrigações directas de fabricante) e quem compra (procurement — exigir conformidade aos fornecedores). Este artigo traduz o regulamento em prazos e acções práticas para sysadmins.

O calendário, verbatim

Segundo a página oficial da Comissão Europeia:

  • 10 de Dezembro de 2024 — entrada em vigor do regulamento.
  • 11 de Setembro de 2026 — começam as obrigações de reporte de vulnerabilidades e incidentes activamente explorados (reporting obligations). Este é o prazo mais próximo e toca já quem fabrica.
  • 11 de Dezembro de 2027 — aplicação plena das obrigações principais para produtos colocados no mercado.

Em 27 de Julho de 2026, a Comissão publicou orientações práticas para ajudar fabricantes e empresas de todas as dimensões a cumprir as obrigações — documento de referência (C(2026) 5252 final, não vinculativo) para interpretar os requisitos na prática, com 67 exemplos práticos e atenção particular às microempresas e PME.

Atenção: os prazos confundem-se com frequência. A data que interessa às PMEs fabricantes em 2026 é a de Setembro (reporte), não a de Dezembro de 2027. Quem coloca um produto novo no mercado antes de Dezembro de 2027 pode ficar sujeito a um regime transitório. Produtos já no mercado continuam pelas regras atuais até à aplicação plena — mas o suporte de segurança exigido (updates durante o ciclo de vida declarado) conta a partir da entrada em aplicação.

Quem é que isto afecta

O CRA aplica-se a “produtos com elementos digitais” colocados no mercado da UE — hardware e software. Na prática:

Afectado directamente (fabricante/importador/distribuidor):

  • Software vendido (SaaS puro tem tratamento próprio no regulamento. Software standalone vendido está claramente dentro).
  • Hardware ligado: NAS, routers, câmaras IoT, switches geridos, impressoras de rede, appliances.
  • Software embutido: firmware, apps móveis, software de gestão de dispositivos.
  • Marcas próprias e integradores que re-branding de hardware — quem “fabrica” no sentido do regulamento pode ser o integrador local.

Não afectado como fabricante (mas afectado como comprador):

  • PMEs que apenas usam software de terceiros — o impacto é de procurement: exigir aos fornecedores a declaração de conformidade CRA.
  • Serviços internos (SSO, portal intranet não vendido) — fora do âmbito de “colocar no mercado”.

A leitura prática: se a PME vende algum software ou dispositivo ligado (mesmo um portal de clientes com login, licenciado), o CRA chega à agenda. Se só consome TI, o CRA chega via procurement e via NIS2 (directiva separada, já coberta noutro artigo).

As obrigações centrais dos fabricantes

O regulamento impõe requisitos de segurança por todo o ciclo de vida do produto:

Antes de colocar no mercado (design e produção):

  • Arquitectura segura por omissão (secure by default) e por configuração (secure by configuration).
  • Gestão de vulnerabilidades durante o ciclo de vida declarado do produto — incluindo updates de segurança automáticos onde apropriado.
  • SBOM (software bill of materials) para o produto — inventário dos componentes de terceiros usados.
  • Documentação técnica à disposição das autoridades de vigilância de mercado.
  • Avaliação de conformidade — auto-avaliação para a maioria dos produtos. Avaliação por terceiro (notified body) para produtos de importância crítica (SO, hipervisores, routers industriais, etc.).

Depois (pós-mercado):

  • Reporte de vulnerabilidades exploradas activamente e incidentes graves à CSIRT/autoridade — os prazos de reporte (24h iniciais, 72h detalhado, actualizações) seguem o modelo do NIS2.
  • Updates de segurança durante o período de suporte declarado — no mínimo 5 anos para a maioria dos produtos.
  • Rastrear e comunicar vulnerabilidades a utilizadores.

Marcação e conformidade:

  • Produtos conformes levam marcação CE com o CRA incluído na avaliação.
  • Declaração de conformidade UE e instruções de utilizador com informação de segurança.

Para PME software houses em Portugal, o esforço típico: adoptar processos de desenvolvimento seguro (já exigidos por clientes enterprise), SBOM automatizado (Trivy/Syft — ver artigo relacionado), processo de triagem e reporte de vulnerabilidades, e documentação técnica organizada. A auto-avaliação cobre a maioria. Os produtos críticos precisam de notified body.

O lado procurement: exigir conformidade aos fornecedores

PMEs que compram têm um papel simples mas importante: a partir da aplicação plena, produtos CRA-conformes têm marcação CE com o regulamento cumprido. Na prática de sysadmin:

  • RFPs/contratos: acrescentar a exigência de conformidade CRA (declaração UE de conformidade) a produtos com elementos digitais — NAS, routers, software de gestão, câmaras.
  • SBOM a pedido: para software crítico, pedir o SBOM do fornecedor — é o inventário que permite avaliar impacto quando uma dependência third-party rebenta (ex.: log4j).
  • Fim de suporte declarado: exigir que o período de updates de segurança esteja documentado — um produto com 2 anos de updates declarados é um risco a planear, não uma surpresa.
  • Vigilância de mercado: produtos não conformes vão ser retirados da UE pelas autoridades — monitorizar os avisos de vigilância de mercado (a Comissão mantém uma página de implementação do CRA com os casos).

CRA vs NIS2: não são a mesma coisa

Confusão comum em PME: o CRA (regulamento) e a NIS2 (directiva, transposta em Portugal pelo DL 125/2025) coexistem e complementam-se:

Aspecto CRA NIS2 / DL 125/2025
Quem Fabricantes/importadores/distribuidores de produtos digitais Entidades essenciais/importantes (energia, saúde, MSPs, cloud, etc.)
Âmbito O produto e o seu ciclo de vida A organização e os seus serviços
Forma Regulamento (directo em toda a UE) Directiva (transposta nacionalmente)
Foco Segurança do produto, SBOM, updates, reporte de vulnerabilidades do produto Gestão de risco da organização, reporte de incidentes da entidade
PME afectada Quem vende produtos digitais Quem opera em setores críticos ou é MSP/cloud provider

Uma PME pode estar nos dois: uma MSP que fabrica o seu RMM está no CRA (produto) e na NIS2 (serviço gerido). As obrigações de reporte coordenam-se — o reporte ao CNCS/CSIRT nacional serve os dois regimes quando os factos são os mesmos.

O que fazer em 2026 (checklist por perfil)

Se a PME fabrica/vende software ou hardware:

  • ✓ Inventariar todos os produtos no mercado com elementos digitais e o seu estado de suporte
  • ✓ Identificar produtos “importância crítica” (precisam de notified body)
  • ✓ Preparar o fluxo de reporte para 11/09/2026 (vulnerabilidades exploradas activamente)
  • ✓ SBOM automatizado no pipeline de build
  • ✓ Documentação técnica por produto (arquitectura, medidas de segurança, testes)
  • ✓ Declaração UE de conformidade + marcação CE no caminho para Dezembro de 2027
  • ✓ Revisão das orientações práticas da Comissão (27/07/2026)

Se a PME só compra:

  • ✓ Exigir declaração de conformidade CRA em novos contratos de hardware/software
  • ✓ Pedir o período de suporte/updates declarado por produto
  • ✓ SBOM para software crítico de negócio
  • ✓ Verificar a página de implementação da Comissão para produtos sob vigilância
  • ✓ Alinhar procurement com o responsável de segurança (NIS2, se aplicável)

Erros comuns

Problema Causa Solução
“O CRA não se aplica a mim” Só se olhou para o âmbito de fabricante Avaliar os dois lados: fabricante E procurement
Prazo perdido de reporte Confundir Setembro 2026 com Dezembro 2027 Marcar 11/09/2026 — obrigações de reporte começam nessa data
SBOM manual em folha de cálculo Sem automação no pipeline Trivy/Syft no CI — SBOM por build, não por auditoria
Fornecedor diz “está em conformidade” sem prova Procurement sem exigência documental Pedir a declaração UE de conformidade (documento, não palavra)
Produto crítico sem notified body Classificação de “importância crítica” ignorada Rever o anexo do regulamento — routers, SO, hipervisores exigem terceiro
Confusão CRA/NIS2 Dois regimes com prazos diferentes Mapa de obrigações por entidade: produto (CRA) vs organização (NIS2)

Como evitar no futuro

  • Integrar os requisitos CRA no ciclo de desenvolvimento (secure by default, threat modelling, SBOM) — mais barato do que retrofit em 2027.
  • Monitorizar a página de implementação da Comissão e o CNCS — orientações e casos de vigilância de mercado saem por lá.
  • Incluir cláusulas CRA em todos os novos contratos de fornecimento, com renovação na renegociação.
  • Para fabricantes: treinar a equipa de desenvolvimento nos requisitos de reporte — o fluxo de 24h/72h exige processo ensaiado, não improviso.
  • Manter o SBOM corrente por produto — um SBOM de 2025 não responde por um build de 2027.

Artigos Relacionados