CRA Artigo 14: Tem 24 Horas para Comunicar e a Plataforma Ainda Não Existe

A maioria das equipas de GRC arquivou o Cyber Resilience Act sob duas palavras: "produto" e "2027".

Ambas estão erradas.

A obrigação de reporte prevista no Artigo 14 aplica-se a partir de 11 de setembro de 2026. Não em dezembro de 2027. Essa é a data que toda a gente memorizou, e é a errada.

Três semanas.

E não abrange apenas o que vai colocar no mercado no próximo ano. Abrange o que já colocou. Um produto colocado no mercado da UE em 2018 e ainda disponível hoje está no âmbito do reporte a partir do dia em que a obrigação entra em vigor.

Se a sua organização vende qualquer coisa com elementos digitais na UE, este é o seu processo de gestão de incidentes, não a burocracia da equipa de produto.

O Que o Artigo 14 Exige Efetivamente

Dois gatilhos, três relógios, um canal.

Os gatilhos:

• uma vulnerabilidade ativamente explorada no seu produto
• um incidente grave com impacto na segurança do seu produto

Os relógios:

• 24 horas: alerta precoce, a partir do momento em que toma conhecimento
• 72 horas: notificação completa, incluindo as medidas corretivas ou de mitigação adotadas
• 14 dias: relatório final, assim que estiver disponível uma medida corretiva para uma vulnerabilidade ativamente explorada
• um mês: relatório final para um incidente grave, após resolução

O canal:

Uma única comunicação através da Plataforma Única de Reporte da ENISA, dirigida ao CSIRT onde tem o seu estabelecimento principal, disponibilizada simultaneamente à ENISA.

Note o que não consta. Não se trata de "reportar todos os CVE". O gatilho é a exploração ativa na prática, ou um incidente grave. Essa distinção é a diferença entre um processo funcional e uma equipa que afunda na segunda semana.

Vamos analisar o que é necessário acertar.

1. A Data É 2026. A Que Memorizou É 2027.

O CRA (Regulamento (UE) 2024/2847) entrou em vigor a 10 de dezembro de 2024. A maior parte das obrigações (segurança por conceção, documentação técnica, avaliação de conformidade, marcação CE) aplica-se a partir de 11 de dezembro de 2027.

O n.º 2 do Artigo 71 isola as obrigações de reporte e antecipa-as quinze meses.

Depois, o n.º 3 do Artigo 69 fecha a saída de emergência. As disposições transitórias que permitem aos produtos existentes permanecer no mercado até dezembro de 2027 sem conformidade plena não se estendem ao reporte.

Assim, o universo em âmbito a 11 de setembro não é o seu roadmap de 2027. É toda a sua base instalada.

Conselho: Se o seu inventário de produtos só lista o que está em desenvolvimento ativo, não tem um inventário de produtos. Tem um backlog.

2. O Relógio Começa no "Conhecimento". Ninguém Definiu Isso.

É aqui que tudo se decide, e não é uma questão jurídica.

Vinte e quatro horas não é muito tempo. É um dia de trabalho, ou uma noite de sábado. O relógio não começa quando a equipa jurídica concorda que há um problema. Começa quando a organização toma conhecimento.

Então, quem é "a organização"?

• um engenheiro de suporte que vê um ticket estranho às 19h00
• um investigador que envia um e-mail para o seu endereço genérico security@
• um feed de threat intel que sinaliza o nome do seu produto
• o SOC de um cliente que liga ao seu account manager

Qualquer um destes pode ser o momento de tomada de conhecimento. Se nenhum deles souber o que fazer a seguir, as suas 24 horas estão a correr enquanto um e-mail fica por ler.

Precisa de três coisas escritas antes de setembro:

• que evento constitui tomada de conhecimento, em linguagem clara
• quem está autorizado a declará-la, com um substituto nomeado
• onde o relógio fica registado, para poder provar quando começou

Este último ponto é mais importante do que as pessoas pensam. Se um regulador perguntar por que motivo o alerta precoce chegou à hora 31, "tomámos conhecimento mais tarde do que pensa" só é uma resposta se o conseguir demonstrar.

Anedota: Todos já vimos isto acontecer com o GDPR. Uma violação é declarada três semanas depois, e não porque alguém estava a esconder algo. O suporte registou-a como um bug. A TI chamou-lhe um problema de configuração. Ninguém na cadeia tinha alguma vez acordado o que contava efetivamente como uma violação de dados pessoais, pelo que o relógio nunca começou. A equipa jurídica soube quando um cliente fez uma pergunta.

O mesmo mecanismo no CRA, com uma janela mais curta. As definições são a parte aborrecida. São também a parte que decide se chegou tarde.

3. O CRA Pede-lhe que Reporte Antes de Pedir que Escute

Este é o problema de ordenação que ninguém assinala, e é o que vai apanhar as equipas mais cuidadosas.

O n.º 8 do Artigo 13 exige que os fabricantes disponham de políticas e procedimentos, incluindo a política de divulgação coordenada de vulnerabilidades prevista no Anexo I, Parte II, ponto (5), para tratar e corrigir as vulnerabilidades reportadas por fontes internas ou externas.

Existem de facto três obrigações juridicamente distintas, e na maior parte das empresas uma única caixa de entrada serve as três:

• uma política CVD, escrita, publicada e aplicada
• um endereço de contacto para reporte de vulnerabilidades nos seus produtos e nos componentes de terceiros que distribui
• um ponto de contacto único através do qual os utilizadores possam contactar diretamente um ser humano

Agora, quanto ao calendário. Essas obrigações constam do Anexo I, Parte II. O Anexo I torna-se juridicamente vinculativo a 11 de dezembro de 2027. O reporte ao abrigo do Artigo 14 torna-se vinculativo a 11 de setembro de 2026.

Leia novamente. Durante quinze meses, a lei exige que reporte vulnerabilidades a ser ativamente exploradas nos seus produtos, sem ainda exigir que opere o canal através do qual tomaria conhecimento.

Uma equipa que siga as datas à letra passará esses quinze meses com um relógio de 24 horas sem forma fiável de saber que o relógio começou. Porque a resposta honesta a "como é que a maioria dos fabricantes descobre a exploração ativa do seu próprio produto?" é: alguém diz-lhes.

Há uma segunda razão para agir agora. De tudo o que consta no CRA, a política CVD e o endereço de contacto são as duas coisas visíveis a partir do exterior da sua organização. Uma autoridade de vigilância do mercado a formar uma primeira impressão sobre a sua postura vai olhar para o seu sítio web antes de lhe pedir qualquer documento.

O que é bom parece:

• política num URL público estável, não enterrada numa página legal
• um ficheiro security.txt no seu domínio
• uma caixa de entrada monitorizada com um responsável nomeado e um substituto, não um alias que ninguém lê
• âmbito declarado, prazos de resposta esperados, o que está dentro e fora dos limites para testes, como gere o crédito e a publicação
• todos os reports registados, porque aplicar a política é em si mesma a obrigação

Conselho: Não precisa de inventar isto. ISO/IEC 29147 e ISO/IEC 30111 são as normas de referência para divulgação e tratamento, e o toolkit de divulgação de vulnerabilidades do NCSC é um bom ponto de partida gratuito. Publicar algo funcional em três semanas é melhor do que publicar algo perfeito em dezembro de 2027.

4. Não Pode Reportar o Que Não Consegue Nomear

A fase das 72 horas pede o tipo e a classificação do produto. Isso significa que precisa, antes de um incidente e não durante um:

• da lista de produtos com elementos digitais que coloca no mercado da UE
• para cada um, se é padrão, importante (Anexo III, Classe I ou II) ou crítico (Anexo IV)
• de um SBOM num formato amplamente utilizado e legível por máquina

A classificação segue a função principal do produto e, quando mais de uma classe se aplica, prevalece a mais restritiva.

O SBOM é a parte que as equipas subestimam. O Artigo 14 pede-lhe que reporte uma vulnerabilidade no seu produto. Se o seu produto inclui uma framework em fim de vida que não inventariou, não vai saber que está a ser explorada pela sua própria telemetria. Vai saber por um cliente, ou pelas notícias, o que é uma forma muito cara de iniciar um relógio de 24 horas.

Conselho: Faça o exercício ao contrário. Escolha um componente que sabe estar em três dos seus produtos. Consegue produzir essa lista em menos de uma hora, hoje, sem perguntar à engenharia? Se não consegue, é aí que está o primeiro gap.

5. A Plataforma Não Está Operacional. Registe-se Mesmo Assim.

Esta é a parte que transforma isto numa história e não num memorando de conformidade.

A Plataforma Única de Reporte, criada ao abrigo do Artigo 16 e operada pela ENISA, está prevista para entrar em funcionamento a 11 de setembro de 2026. Não antes. Em meados de agosto, o URL de acesso público ainda não foi publicado. Estão prometidos pequenos vídeos e um webinar duas semanas antes do lançamento.

A obrigação é fixa. A ferramenta não é. Esse hiato é problema seu, não do regulador.

Três coisas não dependem da existência da plataforma:

Crie as contas EU Login agora. O registo é feito através do EU Login em ecas.ec.europa.eu. Pode criar a conta hoje. Fazê-lo durante um incidente, com um relógio de 24 horas a correr, é um atraso auto-infligido.

Configure dois acessos, não um. Existe um Representante Designado Principal que se regista selecionando o papel, escolhendo o CSIRT coordenador, aceitando o acordo e introduzindo os dados do fabricante. O substituto, ou AR Secundário, é convidado por e-mail, e esse convite expira ao fim de sete dias. Envie-o e confirme-o. Um convite não aceite não é um substituto.

Não aguarde pela validação do CSIRT. A validação do AR pelo CSIRT coordenador ocorre após o registo. Decorre em paralelo e não o impede de notificar. As equipas que presumem que precisam de luz verde antes de poder submeter perderão horas que não têm.

As orientações da ENISA já foram atualizadas duas vezes este mês. Os guias de registo e notificação foram redatados a 3 de agosto, e o guia de interface surgiu a 14 de agosto. Tudo está marcado como sujeito a alterações. Construa o seu processo interno com base nos campos obrigatórios, não nas capturas de ecrã.

6. Ainda Não Existem Normas Harmonizadas

A 13 de agosto de 2026, o ETSI colocou 17 projetos finais de normas de produto CRA em Consulta Pública. Nenhuma delas é uma norma harmonizada. Os comentários encerram a partir de meados de setembro, com aprovação a decorrer até novembro consoante o setor.

Os organismos notificados chegam em dezembro de 2026.

A posição honesta é esta: a infraestrutura de conformidade do CRA ainda está a ser construída, e a obrigação de reporte chega primeiro.

Se o seu plano era "começamos assim que as normas forem publicadas", já perdeu a janela de reporte. As normas dizem-lhe como provar que o seu produto cumpre os requisitos essenciais. Não lhe dizem quem submete o alerta precoce num domingo.

7. O Seu Reporte NIS2 e DORA Não Cobre Isto

Vejo este pressuposto constantemente, e é perigoso porque está quase certo.

Pode já ter um músculo de 24/72 horas vindo do NIS2 ou do DORA. Ótimo. Não é a mesma obrigação.

Um único evento pode acionar ambos. Um incidente grave num produto que fabrica e também opera corresponde a duas comunicações, dois destinatários, dois registos.

O reflexo a construir agora não é um novo processo. É um ponto de decisão no topo do que já existe: que regimes toca este evento? Responda no minuto cinco, não na hora vinte.

Anedota: Vou ser direto quanto ao estado do mercado. Quase nenhum dos meus clientes está a perguntar sobre o CRA agora, porque ainda não estão a levar o NIS2 suficientemente a sério para chegarem a esse ponto. Três semanas. Este é o panorama honesto.

O exemplo que posso dar é o meu próprio. Na Mobilexpense, onde sou CISO, é exatamente isto que estamos a construir: um processo de incidentes com duas ramificações. Mesmo intake, as mesmas primeiras perguntas, e depois uma bifurcação no ponto em que se decide se o evento é uma questão de entidade, de produto, ou ambos. A bifurcação é barata de desenhar agora. É muito cara de improvisar na hora três.

8. O Que Pode Efetivamente Concluir Antes de 11 de Setembro

Três semanas não chegam para construir um programa. Chegam para construir a parte que dispara primeiro.

Semana um:

• criar as contas EU Login, principal e substituta
• enviar e confirmar o convite do AR Secundário antes de expirar
• identificar o seu CSIRT coordenador
• iniciar a política CVD em revisão jurídica, porque é o processo mais demorado

Semana dois:

• publicar a política CVD, o endereço de contacto e o security.txt
• fechar a lista de produtos em âmbito, incluindo legados
• atribuir a cada um uma classificação
• redigir a definição de "conhecimento" e nomear as duas pessoas que o podem declarar

Semana três:

• construir o alerta precoce de 24 horas como um formulário interno curto correspondente aos campos obrigatórios
• acrescentar a questão de encaminhamento por regime ao topo do processo de incidentes
• ensaiá-lo em papel. Um cenário, uma noite de sábado, um cronómetro

Este último passo é o que toda a gente salta e o único que lhe diz se os outros onze funcionaram.

Consideração Final

A verdade incómoda de 11 de setembro é que o regulador chega antes das suas próprias ferramentas, e isso não muda nada na sua posição.

Não pode submeter um alerta precoce com um certificado ISO 27001. Não pode classificar um produto com uma política. E não pode iniciar um relógio de 24 horas com um processo que só existe num documento que ninguém executou.

Os fabricantes que gerirem isto bem em setembro não serão os que tiverem a melhor análise de gaps ao CRA. Serão os que, quando o ticket chegar às 19h00 de um sábado, tiverem um ser humano nomeado que sabe que tem autorização para carregar no botão.

Tudo o resto é preparação para esse único momento.

As coimas por incumprimento dos requisitos essenciais e das obrigações dos fabricantes atingem €15 milhões ou 2,5% do volume de negócios anual mundial total, consoante o valor mais elevado. Mas a coima não é o risco. O risco é descobrir, no próprio dia, que o conhecimento não era responsabilidade de ninguém.

Se quiser construir devidamente o músculo de 24/72 horas (gatilhos, escalada, evidências e encaminhamento regulatório que decide quais os regimes que um evento toca), é exatamente isso que trabalhamos no ISO/IEC 27035 Lead Incident Manager. Cinco dias, alinhado ao DORA e ao NIS2, e agora ao CRA Artigo 14. Certificado ou reembolsado.