Relatório de vulnerabilidades em 24 horas (Artigo 14 da CRA)

• Regulation (EU) 2024/2847 — Cyber Resilience Act, Article 14
• Directive (EU) 2022/2555 — NIS2, for entities also in its scope
• Regulation (EU) 2016/679 — GDPR Article 33, where personal data is affected

Quem tem de designar

Todo fabricante de um produto com elementos digitais colocado no mercado da UE, a partir de 11 de setembro de 2026, independentemente do tamanho ou setor. O dever recai sobre o fabricante, não sobre o importador ou distribuidor, mas um fabricante fora da União normalmente o cumprirá através de seu representante autorizado ou de uma mesa atuando sob suas instruções. Os administradores de código aberto têm um dever de relatório mais leve e separado.

Limiares e isenções

Sem limite de tamanho. O que aciona a obrigação é factual: uma vulnerabilidade em seu produto que está sendo explorada ativamente, ou um incidente grave que impacta a segurança do produto. 'Explorada ativamente' significa que há evidências confiáveis de que alguém executou código ou afetou o produto sem autorização. Suspeita não é o gatilho, mas o padrão é a consciência das evidências, não a confirmação do quadro completo.

O que deve constar do rótulo

Não é uma obrigação de rotulagem. O que deve ser publicado é um único ponto de contato para relatar vulnerabilidades, fácil de encontrar em seu site, juntamente com uma política de divulgação coordenada de vulnerabilidades que estabelece como os relatórios são recebidos, triados e respondidos.

Campos nos marketplaces

Não aplicável como um campo de mercado. Isso aparece em vez disso em questionários de aquisição empresarial e segurança, onde os compradores agora pedem o ponto de contato de vulnerabilidade, a política de divulgação e evidências de um processo de relatório antes de assinar.

Documentação a conservar

Um procedimento interno de manuseio definindo quem declara a consciência, quem redige, quem aprova e quem arquiva, com um substituto nomeado para fora do horário comercial. Um registro de vulnerabilidades com carimbos de data/hora para cada etapa. A política de divulgação coordenada de vulnerabilidades. Evidências da medida corretiva e a data em que se tornou disponível. Registros de notificações aos usuários, uma vez que o Artigo 14 também exige informar os usuários afetados sobre o incidente e, quando necessário, sobre as medidas corretivas que devem aplicar.

Normas e ensaios

Não aplicável. O que é examinado após o fato é a linha do tempo: quando o fabricante tomou conhecimento, quando o alerta precoce foi registrado e se os intervalos foram cumpridos.

Requisitos linguísticos

Os relatórios são submetidos através da plataforma única de relatórios, que aceita inglês. As comunicações com um CSIRT nacional podem ser realizadas na língua daquele estado membro, e as notificações aos usuários devem ser na língua dos usuários envolvidos.

A partir de quando

Três prazos, todos contados a partir da consciência e não da confirmação. Um alerta precoce dentro de 24 horas, informando que existe uma vulnerabilidade explorada ativamente ou um incidente grave, se outros estados membros estão afetados e — mesmo sem detalhes completos — o suficiente para que o CSIRT possa agir. Uma notificação de vulnerabilidade ou incidente dentro de 72 horas, com informações gerais sobre o produto, a natureza da exploração e quaisquer medidas corretivas tomadas ou aconselhadas. Um relatório final dentro de 14 dias após a medida corretiva se tornar disponível, ou dentro de um mês da notificação de 72 horas para um incidente grave, descrevendo a vulnerabilidade, sua gravidade, a exploração e a correção.

Prazo de conservação

O registro de vulnerabilidades, as notificações arquivadas e seus carimbos de data/hora, pelo menos durante o período de suporte. Esta é a evidência que decide um caso de aplicação, porque a questão será quando você soube.

Em caso de incumprimento

Até €15 milhões ou 2,5% do faturamento anual total mundial por violação das obrigações do fabricante, que incluem o Artigo 14. A exposição é incomum, pois não depende de a vulnerabilidade em si ser sua culpa: uma dependência que você não escreveu, explorada na natureza, ainda inicia o relógio de 24 horas. As autoridades também podem ordenar a retirada do produto enquanto a questão não estiver resolvida.

Quem fiscaliza

O CSIRT designado como coordenador no estado membro de sua principal instalação, ou onde você não tiver nenhuma na União, o designado para seu representante autorizado. A ENISA recebe as notificações em paralelo através da plataforma única de relatórios. As autoridades de vigilância do mercado fazem a aplicação.

Onde está a fronteira

Esta obrigação entra em vigor mais de um ano antes do restante da CRA, e essa lacuna é o que a maioria dos fabricantes perde. Ela está ao lado do relatório NIS2, que tem prazos semelhantes, mas um gatilho diferente — um incidente que afeta seu serviço como entidade, em vez de uma vulnerabilidade em um produto que você vende — e ao lado da notificação de violação do Artigo 33 do GDPR onde dados pessoais estão envolvidos. Um evento pode exigir os três, para três autoridades diferentes, em três bases legais diferentes.

Perguntas frequentes

Quem decide se uma vulnerabilidade está sendo explorada ativamente?

Você decide, com base nas evidências que possui. O caminho seguro é registrar o alerta precoce e refiná-lo na notificação de 72 horas. Registrar tarde porque você ainda estava confirmando é o modo de falha que as autoridades sinalizaram que não aceitarão.

E se soubermos disso por um pesquisador em um sábado?

O relógio conta a partir da consciência, não a partir do próximo dia útil. É por isso que o procedimento precisa de um substituto nomeado e uma rota fora do horário comercial: as 24 horas são horas do calendário.

Relatar nos expõe a responsabilidade?

Os relatórios vão para os CSIRTs e ENISA, não para o público, e o Regulamento restringe seu uso. O que cria exposição não é relatar: uma vulnerabilidade explorada não relatada que depois se torna pública é tanto uma infração quanto evidência disso.

Usamos um componente de terceiros com a falha — ainda é nosso relatório?

Sim, se o produto que você colocou no mercado for afetado. Você também pode precisar notificar o mantenedor do componente, mas isso não exime seu próprio dever.