Regulamento de Ciber-Resiliência: a obrigação de notificação aplica-se desde 11 de setembro de 2026

A maior parte dos regulamentos europeus dá-lhe uma data de conformidade e um período de tolerância durante o qual todos se vão organizando discretamente. O Regulamento de Ciber-Resiliência (Cyber Resilience Act, CRA) faz outra coisa. A sua primeira obrigação a sério é um prazo de notificação de 24 horas, e aplica-se desde 11 de setembro de 2026.

Um prazo de 24 horas não se introduz aos poucos. Ou o processo está montado quando aparece uma vulnerabilidade explorada, ou o prazo falha-se.

O que é o CRA

O Regulamento (UE) 2024/2847 fixa requisitos de cibersegurança para os produtos com elementos digitais colocados no mercado da UE. A expressão abrange muito mais do que as pessoas costumam pensar à primeira: qualquer produto de software ou hardware, e as respetivas soluções de tratamento de dados à distância, cuja utilização prevista ou razoavelmente previsível inclua uma ligação de dados direta ou indireta.

Os dispositivos conectados estão abrangidos. O mesmo acontece com a maior parte do software comercial, sistemas operativos, browsers, aplicações móveis, firmware e os componentes integrados noutros produtos.

O Regulamento foi publicado em novembro de 2024 e aplica-se por fases:

• 11 de junho de 2026: obrigações dos organismos de avaliação da conformidade.
• 11 de setembro de 2026: obrigações de notificação de vulnerabilidades ativamente exploradas e de incidentes graves.
• 11 de dezembro de 2027: aplicação integral, incluindo os requisitos essenciais de cibersegurança, a marcação CE, a documentação técnica e a lista de materiais de software.

A data do meio é a que já está em vigor, e depende de capacidades que talvez ainda não tenha.

O que se aplica desde 11 de setembro de 2026

Desde essa data, os fabricantes têm de notificar:

As vulnerabilidades ativamente exploradas nos seus produtos com elementos digitais, e

Os incidentes graves que afetem a segurança desses produtos.

A notificação é feita através da plataforma única de notificação do CRA (CRA Single Reporting Platform), gerida pela ENISA, à CSIRT designada no Estado-Membro do estabelecimento principal do fabricante, que depois a partilha com as outras CSIRT afetadas e com a ENISA. A ENISA pôs uma primeira versão da plataforma em funcionamento a 11 de setembro de 2026, o dia em que a obrigação começou, e diz que vai acrescentar funções ao longo dos próximos meses.

Os prazos:

• No prazo de 24 horas a contar do conhecimento: um alerta precoce.
• No prazo de 72 horas: uma notificação completa, incluindo as medidas corretivas ou de mitigação tomadas.
• No prazo de 14 dias a contar da disponibilização de uma medida corretiva: um relatório final sobre uma vulnerabilidade ativamente explorada.
• No prazo de um mês: um relatório final sobre um incidente grave.

Vinte e quatro horas a contar do conhecimento, não da confirmação, nem da correção. Se uma vulnerabilidade num componente do seu produto estiver a ser explorada no terreno num sábado, o prazo está a correr no sábado.

Porque é mais difícil do que parece

A obrigação de notificação, em si, é o preenchimento de um formulário. A dificuldade está em tudo o que tem de existir antes de o conseguir preencher.

Tem de saber o que está no seu produto

Para notificar que uma vulnerabilidade no seu produto está a ser ativamente explorada, tem de saber que o componente vulnerável está no seu produto. Numa aplicação moderna com centenas de dependências transitivas, isso não é coisa a que alguém consiga responder de memória.

É por isso que as equipas estão já a construir pipelines de lista de materiais de software (SBOM), mais de um ano antes do requisito formal de SBOM, em dezembro de 2027. O SBOM não é o objetivo. O objetivo é conseguir responder em poucas horas à pergunta «somos afetados?», e é o SBOM que torna possível responder-lhe.

A parte incómoda é que isto se aplica a produtos que lançou há anos. Se tem dispositivos suportados no terreno com firmware compilado em 2022 a partir de uma árvore de dependências que ninguém registou, reconstruí-la é trabalho a sério.

Tem de estar atento

O conhecimento faz começar o prazo, e espera-se que esse conhecimento seja ativo e não acidental. Isso significa monitorizar fontes de vulnerabilidades, subscrever os avisos de segurança dos seus componentes, acompanhar os catálogos de vulnerabilidades conhecidas e exploradas e ter um canal através do qual os investigadores de segurança o possam contactar e obter resposta.

Tem de ter um circuito de decisão

Alguém tem de poder decidir, a qualquer hora, se um incidente atinge o limiar e se o prazo começou a correr. Sem uma função atribuída e um circuito de escalamento, as primeiras horas perdem-se a apurar quem tem autoridade para tomar a decisão.

As dependências em fim de vida tornam-se um passivo

Se um componente do seu produto deixou de receber atualizações de segurança, continua a ter a obrigação de notificação quando ele for explorado, e não tem nenhuma correção a montante para apresentar. Fazer o levantamento das dependências em fim de vida é das coisas mais úteis a fazer já, porque a resposta obriga, por vezes, a uma migração com o seu próprio prazo de preparação.

O que a aplicação integral traz em dezembro de 2027

As obrigações de dezembro de 2027 são o programa maior, e têm de começar muito antes dessa data.

Segurança desde a conceção e por defeito. Os produtos têm de ser concebidos, desenvolvidos e produzidos de forma a garantir um nível de cibersegurança adequado ao risco. Sem palavras-passe por defeito. Configuração segura de origem. Redução da superfície de ataque. Proteção dos dados em trânsito e em repouso.

Tratamento de vulnerabilidades. Um processo documentado que abranja a identificação, a correção, os testes, a distribuição e a divulgação. As atualizações de segurança têm de ser disponibilizadas sem demora e gratuitamente, durante um período de suporte que reflita a vida útil prevista do produto, sendo cinco anos uma referência comum.

Lista de materiais de software. Num formato de leitura automática, que abranja pelo menos as dependências de primeiro nível, e mantida atualizada.

Documentação técnica e avaliação da conformidade. A maior parte dos produtos faz uma autoavaliação. As categorias de produtos importantes e críticos, que incluem coisas como gestores de palavras-passe, VPN, sistemas operativos e sistemas de controlo industrial, exigem a intervenção de terceiros.

Marcação CE. O equivalente digital da marca física, que declara a conformidade.

Política de divulgação coordenada de vulnerabilidades. Publicada, com um ponto de contacto que funcione.

Quem está realmente abrangido

Há alguns casos de fronteira que surgem constantemente.

O software livre e de código aberto desenvolvido fora de uma atividade comercial fica, em grande medida, fora do âmbito. O Regulamento introduz a figura do administrador de software de código aberto, com obrigações mais leves. Mas, se comercializar código aberto, ou o incluir num produto que vende, as obrigações relativas ao produto são suas.

O software como serviço fica, em geral, fora do CRA e enquadra-se antes na Diretiva NIS 2, embora as soluções de tratamento de dados à distância que sejam parte integrante de um produto com elementos digitais fiquem abrangidas. Se o seu dispositivo depende do seu backend na cloud para funcionar, esse backend acompanha o produto.

Os importadores e os distribuidores também têm obrigações. Se colocar no mercado da UE um produto de terceiros com o seu próprio nome ou marca, é tratado como fabricante.

Os produtos já regulados noutros diplomas, como os dispositivos médicos, os automóveis e os equipamentos de aviação, são tratados nos respetivos quadros.

As questões de âmbito não são nada triviais, e é aqui que uma hora com um advogado poupa meses de engenharia mal orientada.

O que faríamos agora

Se está abrangido e começa agora, a ordem que funciona:

Primeiro, faça o inventário dos produtos. O que tem, de facto, no mercado da UE? Incluindo versões antigas ainda em uso, variantes em marca branca e produtos que distribui por conta de outros. Esta lista é normalmente mais longa do que alguém espera.

Segundo, integre a geração de SBOM na integração contínua. Gere um SBOM em cada compilação, em CycloneDX ou SPDX, guarde-o junto do artefacto da versão e mantenha-o pesquisável. A ideia é poder perguntar «quais das versões que lançámos contêm esta biblioteca?» e obter uma resposta em minutos.

Terceiro, ligue a monitorização de vulnerabilidades. Alimente com os dados do SBOM uma ferramenta de análise que acompanhe os avisos de segurança e os catálogos de vulnerabilidades conhecidas e exploradas, e encaminhe os alertas para um canal que alguém leia.

Quarto, escreva o runbook de incidentes. Quem declara, quem avalia, quem notifica, quem comunica. Pessoas concretas, substitutos e contactos fora de horas. Depois ensaie-o uma vez com um aviso fictício. É no ensaio que descobre que a pessoa que tem as credenciais da plataforma de notificação está de férias.

Quinto, publique uma política de divulgação de vulnerabilidades. Um ficheiro security.txt, um endereço vigiado e um prazo de resposta declarado. É uma tarde de trabalho, e é a diferença entre saber de um problema por um investigador ou por um jornalista.

Sexto, comece o trabalho para dezembro de 2027. Configurações seguras por defeito, mecanismos de atualização, decisões sobre o período de suporte e documentação são questões de arquitetura, não papelada. Os produtos que conceber em 2026 ainda vão estar no mercado em 2028.

A sobreposição que ninguém aproveita

Há uma duplicação significativa entre o CRA e outros regimes, e a maioria das empresas trata cada um em separado, o que é um desperdício.

Um SBOM construído para o CRA responde à maior parte das questões de cadeia de abastecimento da Diretiva NIS 2. O runbook de incidentes sobrepõe-se ao alerta precoce de 24 horas da NIS 2 e à notificação de violações de 72 horas do RGPD. Os processos de tratamento de vulnerabilidades alimentam diretamente os questionários de segurança dos clientes e os processos de compra das grandes empresas.

Construa estas peças uma vez, como capacidade de plataforma. A alternativa são três equipas a construir três versões do mesmo inventário de ativos.

Onde obter ajuda

Desenvolvemos e mantemos software para empresas que vendem na UE, o que cada vez mais significa construir a visibilidade da cadeia de abastecimento e a infraestrutura de atualizações que o CRA pressupõe. Se está a tentar perceber se está abrangido, ou se a obrigação de notificação já se lhe aplica e nada está a vigiar os seus componentes, contacte-nos através de office@c9group.dev.

O nosso serviço de manutenção de sistemas legados é muitas vezes o ponto de partida, porque os produtos com pior visibilidade das dependências costumam ser os mais antigos. O panorama regulamentar mais amplo está no nosso guia de conformidade digital na UE para 2026.

Somos engenheiros, não juristas. As decisões de âmbito e de classificação cabem ao seu advogado, e nós desenvolvemos de acordo com a resposta que ele der.