Obrigações de notificação do CRA: separar corretamente passaporte do produto, alerta de segurança e histórico de atualizações

Em 11 de setembro de 2026 começa, para os fabricantes de produtos com elementos digitais, uma das primeiras obrigações operacionais do Cyber Resilience Act (CRA): vulnerabilidades exploradas ativamente e incidentes de segurança graves deverão ser comunicados por meio da nova plataforma central de notificação. Isso é mais do que um novo prazo de conformidade. Em poucas horas, será necessário reunir a identidade do produto, os mercados afetados, a avaliação técnica e as medidas adotadas.

Um passaporte digital do produto ou uma página de produto vinculada por QR pode ajudar a identificar claramente um dispositivo e, mais tarde, informar os usuários sobre uma atualização. No entanto, ele não é o canal legal de notificação nem o local adequado para armazenar detalhes confidenciais sobre a exploração. Por isso, os fabricantes devem separar desde já três fluxos de dados: a notificação às autoridades, a informação pública sobre o produto e o histórico interno de atualizações.

O novo contexto: orientações de 27 e 31 de julho

A Comissão Europeia publicou, em 27 de julho de 2026, sua primeira orientação abrangente sobre o CRA. Ela aborda, entre outros aspectos, obrigações de notificação, avaliação de riscos, períodos de suporte e alterações substanciais. A orientação não é vinculativa, mas, com 67 exemplos, detalha como as empresas podem aplicar o regulamento na prática.

Quatro dias depois, em 31 de julho, a ENISA atualizou suas informações sobre a Single Reporting Platform. Agora, elas incluem o fluxo planejado, os campos de entrada previstos e instruções para o registro. A plataforma deverá estar operacional até 11 de setembro de 2026; segundo a Comissão, os testes funcionais e de segurança já estão em andamento.

A escalonização temporal é importante: as principais obrigações do CRA aplicam-se, em princípio, a partir de 11 de dezembro de 2027. O artigo 14, porém, com as obrigações de notificação, já se aplica a partir de 11 de setembro de 2026. Isso é confirmado tanto pelo artigo 71 do Regulamento (UE) 2024/2847 quanto pela visão geral da Comissão sobre o procedimento de notificação do CRA, atualizada em 31 de julho.

Três espaços de dados em vez de um passaporte do produto sobrecarregado

A notificação do CRA e uma página pública do produto têm objetivos diferentes. Quem representar ambos em um único conjunto de dados corre o risco de oferecer informações insuficientes à equipe de incidentes ou de expor detalhes sensíveis demais na web pública.

1. Notificação confidencial à SRP, ao CSIRT e à ENISA

A Single Reporting Platform é o canal legal de entrada. É necessário notificar dois tipos de eventos: uma vulnerabilidade explorada ativamente, para a qual existam indícios confiáveis de exploração não autorizada, e um incidente de segurança grave que prejudique a disponibilidade, a autenticidade, a integridade ou a confidencialidade de dados ou funções.

A notificação não contém apenas uma designação do produto. A ENISA relaciona, entre outros, os Estados-Membros afetados, uma avaliação inicial, as contramedidas já adotadas, possíveis medidas para os usuários e a sensibilidade da informação como campos. Etapas posteriores podem incluir gravidade, impactos, informações sobre o atacante e detalhes técnicos da atualização de segurança. Essas informações não devem ser automaticamente publicadas em uma página de DPP acessível livremente.

2. Informações públicas sobre o produto e a segurança

O fluxo de dados público responde a outras perguntas: Qual produto e versão eu tenho? Ele ainda é compatível? Há uma atualização de segurança disponível? O que devo fazer concretamente como usuário? Para isso, pode ser útil uma página estável do produto acessada por um código QR ou outro suporte de dados.

A página pública deve exibir apenas informações aprovadas: intervalos de modelos e versões afetados, versão segura disponível, instruções de instalação, contato de suporte e data de publicação. Detalhes da exploração, regras internas de detecção, caminhos de ataque ainda não corrigidos ou dados pessoais do incidente permanecem no procedimento protegido. A decisão sobre um alerta público não cabe ao código QR: nos termos do artigo 17 do CRA, o CSIRT coordenador pode informar o público ou solicitar que o fabricante o faça, quando isso for necessário para prevenção ou contenção.

3. Histórico interno de atualizações e evidências

O terceiro fluxo é o registro de trabalho rastreável. Ele conecta ID do produto, versão de hardware e software, lista de componentes de software, momento em que se tomou conhecimento, decisões de triagem, níveis de notificação, aprovação do patch e comunicação pública. Esse histórico deve versionar as alterações, em vez de substituir silenciosamente avaliações anteriores.

Para uma operação de DPP, essa diferença é central: a visualização pública mostra o estado atual aprovado; o histórico interno comprova como ele foi criado. Quem já mantém os dados do produto com base em eventos pode usar o mesmo princípio aplicado a DPP-atualizações e webhooks: um evento desencadeia processos subsequentes, mas cada destinatário recebe apenas os campos previstos para sua função.

O relógio do CRA começa quando se toma conhecimento

O artigo 14 trabalha com prazos escalonados. Para uma vulnerabilidade explorada ativamente, é necessário enviar um alerta inicial sem demora indevida, no máximo 24 horas após o conhecimento. Em 72 horas, segue-se a notificação mais detalhada da vulnerabilidade. O relatório final deve estar disponível no máximo 14 dias depois que uma medida corretiva ou de mitigação estiver pronta.

Para um incidente de segurança grave, também se aplicam 24 horas para o alerta inicial e 72 horas para a notificação do incidente. O relatório final deve ser apresentado no prazo de um mês após a notificação de 72 horas. Portanto, os prazos não começam com a publicação de um CVE nem com o próximo lançamento regular, mas no momento em que o fabricante é considerado informado.

Na prática, recomenda-se um fluxo claro:

Registrar, com carimbo de data e hora, a entrada proveniente do suporte, monitoramento, pesquisa ou cadeia de suprimentos.
Resolver o produto e a versão com base em um ID interno estável do produto.
Avaliar a exploração ou a gravidade do incidente por meio da equipe responsável.
Gerar o registro de 24 horas com base nos dados mínimos confirmados e enviá-lo pela SRP.
Complementar as informações técnicas até a etapa de 72 horas, sem perder o estado original.
Aprovar separadamente o patch, a medida para o usuário e a informação pública.
Vincular o relatório final ao histórico interno.

Essa cadeia deve ser simulada antes de setembro. A ENISA observa que as organizações podem automatizar seus processos internos e bancos de dados, mas que a plataforma não oferecerá uma API no lançamento. Por isso, um processo de exportação e revisão por duas pessoas é mais realista do que uma integração direta sem verificação.

Um ID comum de produto, mas direitos de acesso separados

Separar não significa manter três cópias sem conexão. A abordagem mais adequada é uma referência de produto comum e imutável, com visualizações baseadas em funções.

No mínimo, estas associações devem estar disponíveis:

ID interno do produto e referência ao modelo, lote ou série;
versão de hardware, firmware e software;
Estados-Membros nos quais a versão afetada foi disponibilizada;
status da avaliação de segurança e momento em que se tomou conhecimento;
referências à notificação de 24 horas, à de 72 horas e ao relatório final;
medida para o usuário aprovada e versão-alvo segura;
status de publicação da página pública do produto.

A autorização deve ser pensada campo a campo. A equipe de incidentes e os responsáveis pelo CRA precisam do registro completo. O suporte e as vendas precisam de uma instrução de ação aprovada. Os usuários veem apenas a notificação pública. Nesse contexto, o código QR deve idealmente transportar apenas um endereço estável do produto; a plataforma por trás dele decide, com base no status e na função, quais informações serão fornecidas.

O que os fabricantes devem testar até setembro

Um caso de teste útil não precisa de uma vulnerabilidade real. Escolha um produto conectado, uma versão de firmware afetada e três Estados-Membros. Simule o momento em que se tomou conhecimento em um dia útil e verifique:

A equipe consegue confirmar, em 24 horas, a cobertura do produto e os dados mínimos?
Está claro quem deverá acessar a SRP como representante por meio do EU Login?
É possível acrescentar informações de 72 horas sem tornar públicos detalhes confidenciais?
A aprovação do patch resulta em uma informação ao usuário revisada em todos os idiomas necessários?
A URL pública permanece estável quando a versão e as medidas mudam?
É possível rastrear quem aprovou qual estado e quando?

Para o último ponto, ajuda manter os dados de forma consistente e versionada. O artigo da qr3 sobre atualização contínua de DPP mostra a ideia básica: a identidade permanece estável, enquanto os dados técnicos são atualizados de forma controlada. No processo do CRA, acrescenta-se uma camada mais rigorosa de confidencialidade e aprovação.

Conclusão: o passaporte do produto é distribuidor, não canal de notificação

As novas orientações tornam operacionalmente concreto o prazo de setembro. Os fabricantes não precisam incorporar um banco de dados confidencial de vulnerabilidades ao passaporte digital do produto. Em vez disso, precisam de uma transição confiável entre três áreas claramente separadas: notificação às autoridades, evidências internas e informação aprovada para os usuários.

Um ID comum de produto mantém essas áreas conectadas. Funções, aprovações e versionamento impedem que detalhes confidenciais cheguem ao exterior ou que os usuários sejam informados tarde demais sobre uma medida disponível. O código QR continua útil, mas deliberadamente discreto: conduz permanentemente ao contexto correto do produto. A verdadeira conformidade com o CRA é criada nos processos por trás dele.