A comunicação de vulnerabilidades CRA torna-se obrigatória a partir de 11 de setembro de 2026. A partir dessa data, todos os fabricantes de software que vendem na UE terão de comunicar uma vulnerabilidade explorada ativamente no prazo de 24 horas após terem conhecimento dela. Não são 24 horas úteis. São vinte e quatro horas.
Esse prazo está a semanas de distância, não a meses, e a capacidade de uma equipa de engenharia cumprir esse prazo depende quase inteiramente do trabalho que já deveria ter começado há meses. Para uma grande parte das organizações, isso não aconteceu. Um inquérito da OpenSSF de 2026 revelou que 72% das organizações norte-americanas ainda sabem pouco ou nada sobre a sua exposição legal ao CRA e, embora a situação na Europa seja melhor, não é muito melhor.
Abaixo, detalhamos o que o reporte de vulnerabilidades do CRA em setembro de 2026 exige, a quem se aplica, qual infraestrutura técnica possibilita a conformidade e onde residem as lacunas comuns.
O Regulamento da Ciber-resiliência e os seus prazos faseados
O Regulamento da Ciberresiliência, formalmente Regulamento (UE) 2024/2847, é a primeira regulamentação a nível da UE a colocar requisitos obrigatórios de cibersegurança em produtos digitais ao longo de todo o ciclo de vida, desde o design e desenvolvimento até à implementação e fim do suporte. Entrou em vigor a 10 de dezembro de 2024, mas as obrigações chegam por fases, pelo que a maioria das equipas tem vindo a planear com vista à data de dezembro de 2027.
Article 14 is the exception, because the reporting duty starts on 11 September 2026. Everything else follows on 11 December 2027: conformity assessments, CE marking, technical documentation and the Software Bill of Materials requirement. Teams that worked through the EU AI Act August 2026 deadline will recognise the pattern, since the reporting and transparency duties land first and the heavier conformity machinery follows later.
Que produtos a monitorização de vulnerabilidades CRA abrange
Todos eles. O dever aplica-se a todos os produtos abrangidos que já foram disponibilizados no mercado da UE, não apenas aos lançamentos que surgem após a data. Um produto enviado em 2019 e ainda vendido ou suportado hoje acarreta a mesma obrigação de 24 horas que um lançado no próximo mês. Como os produtos legados raramente têm um inventário de dependências atual, é precisamente aí que se encontra a maior parte da exposição.
Quem é considerado fabricante ao abrigo do CRA
A maioria das organizações comete este erro, porque a definição vai além do sentido quotidiano da palavra. Um fabricante é qualquer pessoa singular ou coletiva que desenvolve ou fabrica um produto com elementos digitais, ou que o manda desenvolver ou fabricar, e o comercializa sob o seu próprio nome ou marca comercial.
Onde se situam os serviços SaaS e cloud
A resposta direta que circula na maioria das sínteses de conformidade está errada. Os serviços puramente na nuvem entregues como SaaS, PaaS ou IaaS não são produtos com elementos digitais, uma vez que a Consideração 12 os remete para a NIS2. O que o regulamento abrange é uma solução de processamento remoto de dados: o processamento de dados à distância, concebido pelo ou sob a responsabilidade do fabricante, cuja ausência impediria o produto de desempenhar uma das suas funções. O back-end de controlo na nuvem de um dispositivo inteligente está, portanto, abrangido. Uma ferramenta SaaS de uso geral que o seu produto, por acaso, chama, não está.
Relatório de vulnerabilidades CRA em setembro de 2026: a cascata exata
A obrigação decorre num prazo definido e as três fases são cumulativas e não alternativas.
A cascata não cobre todas as CVEs divulgadas. Cobre vulnerabilidades que foram exploradas e estão a ser utilizadas em ataques reais, o que é um conjunto muito mais restrito. Ainda assim, a restrição funciona nos dois sentidos, porque saber que uma CVE passou de divulgada a explorada requer inteligência de ameaças em vez de uma revisão mensal de dependências. O relógio começa a contar quando o fabricante tem conhecimento, pelo que uma lacuna de monitorização não o pausa.
Onde os relatórios de vulnerabilidade da CRA são apresentados
Os relatórios passam por um único canal: a Plataforma Única de Relatórios da CRA, que a ENISA desenvolve e gere ao abrigo do Artigo 16. Um fabricante submete uma vez, e o envio é encaminhado simultaneamente para o CSIRT designado como coordenador para o seu estabelecimento principal e para a ENISA. Isto substitui as notificações separadas a todas as autoridades nacionais.
Seguem-se dois pontos práticos. Primeiro, em meados de 2026, a plataforma ainda estava pré-operacional, e o lançamento inicial deverá ser feito através de introdução manual num portal sem APIs, pelo que a comunicação de sistema para sistema não estará disponível no primeiro dia. Segundo, um atraso na plataforma não é motivo para esperar, pois identificar o seu CSIRT coordenador, acordar quem submete e redigir o modelo de alerta precoce são trabalhos que ocorrem fora da plataforma. Os detalhes de integração aparecem na Comissão Página de relatório do CRA e em Página da Plataforma Única de Relatórios da ENISA.
Dependências do fim de vida, desde dívida técnica a responsabilidade legal
Esta é a parte que causará a maior perturbação imediata para as equipas que não a analisaram. Muitos produtos empresariais enviam frameworks de código aberto que chegaram ao fim de vida, o que significa que não haverá atualizações de segurança provenientes de ninguém.
Antes de 11 de setembro, manter estes componentes em produção era uma decisão de gestão de risco, pelo que as equipas ponderavam o custo da migração contra a exposição. Após essa data, torna-se uma questão de conformidade com uma consequência definida. Se uma nova CVE (Vulnerabilidade e Exposição Comum) surgir num componente de fim de vida útil e essa CVE for ativamente explorada, o fabricante tem 24 horas para notificar. Não existe um patch, por definição, pelo que a organização tem de reportar uma vulnerabilidade que não consegue remediar. Esse problema não pode ser resolvido após a data definida. Ou a migração acontece primeiro, ou a exposição é aceite de forma consciente.
O que o SBOM tem a ver com a comunicação de vulnerabilidades do CRA em setembro de 2026
Uma lista de materiais de software (SBOM) é um inventário completo dos componentes de um produto de software. O requisito formal de SBOM pertence ao prazo de dezembro de 2027 e não a setembro, embora na prática essa distinção seja enganosa. A janela de 24 horas só é alcançável se a equipa já souber exatamente o que está no produto, até à última dependência e versão. Sem um inventário em tempo real, a notificação começa com a descoberta manual, e a descoberta manual não termina dentro de um dia.
A infraestrutura por
Para além do próprio inventário, têm de existir quatro capacidades.
Relatar vulnerabilidades de CRA e código aberto: o que os mantenedores devem
O software de código aberto desenvolvido e fornecido fora de uma atividade comercial não está sujeito às obrigações do fabricante. O regulamento reconhece explicitamente o ecossistema, criando assim uma categoria mais leve para os gestores de software de código aberto, significando as fundações e organizações que fornecem apoio sustentado a componentes utilizados em produtos comerciais. Os gestores documentam a sua política de segurança e prática de divulgação. Não estão sujeitos a avaliação de conformidade ou à obrigação do SBOM.
O que os mantenedores sentirão em vez disso será pressão da procura. Uma vez iniciado o cumprimento, os fabricantes que transportam vulnerabilidades em componentes não mantidos recorrerão ao upstream com pedidos urgentes, embora os projetos voluntários não tenham obrigação de lhes responder. Planear uma correção de upstream a chegar a tempo não é, portanto, uma estratégia de conformidade. A nossa visão mais ampla sobre a posição das equipas de engenharia europeias reside no nosso Perspetiva de resiliência cibernética para 2026.
Lista de verificação de prontidão para relatórios de vulnerabilidades CRA setembro de 2026
Cinco questões, por ordem de importância.
O que a Caixa Mágica traz a isto
Desenvolvemos software para o setor público português e para clientes empresariais europeus há mais de 20 anos, e as nossas credenciais de segurança incluem a certificação ao nível Secreto pelo Gabinete Nacional de Segurança de Portugal. Caixa Mágica Linux, o nosso sistema operativo de código aberto, é ele próprio um produto com elementos digitais sob regulamentação. As questões deste artigo foram as que tivemos de responder para o nosso próprio produto antes de aconselharmos mais ninguém sobre elas.
Se necessitar de ajuda com a implementação de SBOM, infraestrutura de monitorização de vulnerabilidades ou uma avaliação da preparação para relatórios de vulnerabilidades CRA em todo o seu conjunto de produtos, os nossos desenvolvimento de software e costa próxima as equipas podem trabalhar em conjunto com a sua.
Perguntas frequentes
Relatório de vulnerabilidades CRA - setembro de 2026: âmbito e prazos
Quem é considerado um fabricante no âmbito do Regulamento de Ciber-resiliência da UE?
A obrigação de comunicação da CRA de setembro de 2026 exige o quê?
O CRA aplica-se a produtos SaaS?
SBOMs, dependências e código aberto
O que é um SBOM e por que é importante para a conformidade com o CRA?
As dependências de código aberto em fim de vida são uma responsabilidade para as CRA?
Os mantenedores de código aberto enfrentam obrigações do CRA?
