
Neste artigo (4)
Análise das obrigações de notificação do Artigo 14 da Lei de Resiliência Cibernética da UE
Principais conclusões
- Trate a ciência de exploração como um gatilho para notificação, não apenas como um chamado de engenharia.
- Prepare modelos que capturem o impacto no produto, detalhes da exploração, mitigações adotadas e ações dos usuários.
- Mantenha o dever de comunicação do Artigo 14 vigente hoje separado das obrigações completas da CRA que serão exigidas posteriormente.
A CRA ainda não é totalmente aplicável, mas o prazo de notificação de incidentes e vulnerabilidades já está em andamento para os produtos abrangidos.
A CRA ainda não se aplica totalmente, mas o prazo para a notificação de incidentes e vulnerabilidades já está correndo para os produtos cobertos.
Um chamado de vulnerabilidade costumava ser um item em uma fila. Desde 11 de setembro, para produtos com elementos digitais vendidos na União Europeia, ele também pode ser um relógio regulatório. A Lei de Resiliência Cibernética (Cyber Resilience Act, CRA) ainda está, em grande parte, aguardando nos bastidores, e é exatamente por isso que o Artigo 14 importa: uma parte da lei chegou antes, e ela entra diretamente na resposta a incidentes. A pergunta prática não é se uma equipe de produto leu a CRA. É se alguém consegue decidir, dentro de 24 horas, se uma vulnerabilidade explorada ativamente ou um incidente grave precisa ser reportado, quem faz o envio e quais evidências vão junto. Advogados chamam isso de obrigação de reporte. Quem constrói produtos deveria chamar de fluxo de trabalho de produção com um regulador no final.
A parte da
CRA que já está no calendário A Pearl Cohen descreve a CRA como sendo implementada em três fases: obrigações para organismos de avaliação de conformidade a partir de 11 de junho de 2026, reporte de vulnerabilidades do Artigo 14 a partir de 11 de setembro de 2026 e a CRA completa a partir de 11 de dezembro de 2027. A Cybersecurity Time acrescenta a correção útil de que a Lei entrou em vigor em 10 de dezembro de 2024, enquanto suas principais obrigações se aplicam mais tarde. Essa distinção não é acadêmica; ela significa que equipes podem estar fora do escopo dos requisitos completos de produto hoje e ainda assim dentro do escopo de reporte.
A Pearl Cohen afirma que a CRA abrange tanto produtos de hardware quanto de software com elementos digitais colocados no mercado da UE. Essa é a frase que fornecedores de software deveriam sublinhar, de preferência antes que vendas assine com mais um cliente da UE em uma sexta-feira à tarde. Isso não é apenas um problema de termostato conectado; pode alcançar produtos de software se eles forem produtos cobertos com elementos digitais.
O que o Artigo 14 realmente exige
A Crowell diz que a obrigação de reporte do Artigo 14 da CRA se aplica a partir de 11 de setembro de 2026 e pode ser aplicada a partir dessa data, enquanto o restante da CRA geralmente se aplica a partir de 11 de dezembro de 2027. O escritório também diz que os fabricantes enviam uma notificação por meio da plataforma única de reporte ao Time de Resposta a Incidentes de Segurança Computacional relevante designado como coordenador e à ENISA. Essa notificação é então compartilhada com outros CSIRTs relevantes, conforme apropriado, o que é misericordiosamente diferente de regimes em que o mapa de envio vira seu próprio incidente.
O texto legal do Artigo 14 diz que um fabricante deve notificar qualquer vulnerabilidade explorada ativamente em um produto com elementos digitais assim que tomar conhecimento dela, simultaneamente ao coordenador CSIRT e à ENISA, usando a plataforma única de reporte. Ele também exige um alerta inicial dentro de 24 horas após a tomada de conhecimento, e uma notificação adicional de vulnerabilidade dentro de 72 horas, a menos que as informações relevantes já tenham sido fornecidas. O aviso de 72 horas deve incluir, conforme disponível, informações gerais sobre o produto, a natureza da exploração e da vulnerabilidade, medidas corretivas ou mitigadoras tomadas e medidas que os usuários podem tomar.
Traduzido para operações, o Artigo 14 significa que seu fluxo de trabalho de incidentes precisa de pelo menos quatro campos que chamados de segurança muitas vezes espalham por chats, postmortems e notas de versão. Você precisa do produto afetado, da descrição geral da exploração e da vulnerabilidade, do que a empresa fez e do que os usuários podem fazer. Se essas informações não puderem ser capturadas rapidamente, o problema de reporte já está visível.
Quem deve se importar, incluindo vendedores fora da UE
A Faegre Drinker enquadra os prazos de setembro de 2026 como aplicáveis a fabricantes de produtos conectados e observa alcance extraterritorial para empresas dos EUA. O resumo da Pearl Cohen sobre a orientação da Comissão confirma que a CRA se aplica a produtos de hardware e software colocados no mercado da UE. Em português claro: estar incorporado fora da UE não é uma capa mágica de invisibilidade se o produto é disponibilizado lá.
É aqui que contratos com fornecedores e propriedade interna importam. Se um fabricante depende de um provedor de serviços gerenciados, revendedor, pesquisador de vulnerabilidades, host de nuvem ou fornecedor de componentes para saber sobre exploração, a empresa ainda precisa de um caminho desde esse sinal até o tomador de decisão do Artigo 14. As evidências apresentadas aqui não dizem que todo fornecedor deve fazer o reporte, então não deixe o folclore de compliance correr à frente do texto. A medida operacional mais segura é garantir que os contratos exijam notificação de segurança rápida, detalhes técnicos utilizáveis e cooperação nas comunicações de mitigação.
A Crowell também destaca representantes autorizados e processos de escalonamento capazes de operar contra o relógio de 24 horas. Essa é uma forma educada de dizer que a rota de reporte não pode morar na caixa de entrada de uma única pessoa. Produto, segurança, jurídico, suporte e comunicações com clientes precisam de uma passagem de bastão ensaiada, porque o relógio começa quando o fabricante toma conhecimento, não quando o rascunho perfeito do postmortem está pronto.
O que operacionalizar esta semana
A Crowell recomenda exercícios de simulação, treinamento de equipe e atualizações de políticas cibernéticas em resposta ao relógio do Artigo 14. Esses não são objetos cerimoniais de compliance se testarem os modos de falha certos: quem identifica exploração ativa, quem decide a gravidade, quem abre o processo na plataforma única de reporte e quem aprova a linguagem de mitigação para usuários. Uma simulação que termina com todos concordando em investigar mais não é prontidão; é uma reunião com lanches.
A divisão útil é entre o que a lei exige agora e o que a internet vai afirmar que ela exige. Agora: reporte de vulnerabilidades exploradas ativamente e incidentes graves sob o Artigo 14, com um alerta inicial de 24 horas e uma rota de acompanhamento de 72 horas, de acordo com a Crowell e o texto do Artigo 14. Depois: o conjunto completo de requisitos essenciais de cibersegurança da CRA, que a Pearl Cohen diz se aplicar a partir de 11 de dezembro de 2027.
Para quem constrói produtos, o trabalho imediato é pequeno, mas implacável. Mapeie produtos vendidos ou colocados no mercado da UE, defina gatilhos de tomada de conhecimento, prepare modelos de notificação, atribua um representante autorizado quando necessário e ensaie a rota até a plataforma única de reporte. Depois, continue observando a lacuna entre a aplicação do Artigo 14 e a data da CRA completa, porque reguladores tendem a aprender com os primeiros envios muito antes de aparecer a primeira multa.