O Cyber Resilience Act – Regulamento (UE) 2024/2847 – está em vigor desde 10 de dezembro de 2024, mas suas obrigações passam a valer de forma escalonada. A próxima data-limite, e a mais importante na prática, está iminente: a partir de 11 de setembro de 2026 valem as obrigações de notificação segundo o artigo 14. Os fabricantes devem então notificar inicialmente vulnerabilidades ativamente exploradas e incidentes de segurança graves em até 24 horas – um processo que não se improvisa na emergência, mas se constrói antes.
O tema é, com isso, menos dramático do que muitas vezes se apresenta, porém logisticamente exigente – e afeta bem mais empresas do que atualmente se sentem interpeladas: quem coloca no mercado da UE, sob o próprio nome, hardware ou software com conexão de dados direta ou indireta é, no sentido do regulamento, „fabricante“ – inclusive o fabricante de máquinas com software de controle próprio e a software house do mercado médio.
Quem o CRA interpela como fabricante
O âmbito de aplicação abrange „produtos com elementos digitais“: hardware e software, incluindo o processamento remoto de dados associado, que são colocados no mercado da UE. O termo é deliberadamente amplo. Muitas empresas do mercado médio – fabricantes de máquinas e equipamentos, fabricantes de componentes conectados, software houses com produto próprio – ainda não se classificam como destinatárias, embora o sejam.
Quem cai no âmbito de aplicação carrega, como fabricante, um pacote de obrigações:
- avaliação de risco de cibersegurança para o produto,
- cumprimento dos requisitos essenciais segundo o Anexo I,
- documentação técnica,
- um período de suporte definido com atualizações de segurança,
- marcação CE e declaração de conformidade da UE.
Para o tratamento de vulnerabilidades vale, nesse contexto, um período de suporte de no mínimo cinco anos – mais curto apenas quando a própria vida útil esperada for mais curta.
Três datas-limite – e por que a do meio é a mais importante
O artigo 71 escalona a aplicação do regulamento em três etapas:
- 11 de junho de 2026: as regras relativas aos organismos notificados (organismos de avaliação da conformidade) valem – essa data-limite já foi atingida.
- 11 de setembro de 2026: as obrigações de notificação segundo o artigo 14 tornam-se vinculantes.
- 11 de dezembro de 2027: o regulamento vale integralmente, incluindo todos os requisitos de produto.
Para produtos já existentes há um direcionamento importante: produtos colocados no mercado antes de 11 de dezembro de 2027 estão sujeitos aos requisitos completos apenas se, depois disso, forem substancialmente modificados. As obrigações de notificação segundo o artigo 14, em contrapartida, valem segundo o artigo 69 independentemente de quando o produto foi colocado no mercado. Dito de outra forma: também para o portfólio de produtos que já está em campo hoje, o processo de notificação deve estar de pé em 11 de setembro de 2026. É justamente por isso que essa data é o verdadeiro motor de ação – não o ano de 2027.
O que concretamente deve ser notificado a partir de 11 de setembro de 2026
Sujeitos à notificação são dois grupos de casos: vulnerabilidades ativamente exploradas em um produto e incidentes graves com impacto sobre a segurança dele. Para ambos vale uma cascata de prazos:
- Alerta precoce em até 24 horas após o conhecimento,
- notificação em até 72 horas com uma primeira avaliação,
- relatório final – em caso de vulnerabilidades, no máximo 14 dias após uma medida corretiva estar disponível; em caso de incidentes, no máximo um mês após a notificação das 72 horas.
Os destinatários das notificações são o CSIRT designado como coordenador e a ENISA, tecnicamente por meio de uma plataforma central de notificação (Single Reporting Platform). Aqui reside uma particularidade da situação atual: em meados de julho de 2026, essa plataforma ainda não estava em operação – ela deve estar pronta para uso em 11 de setembro de 2026. Esperar pelos detalhes da plataforma é, ainda assim, a estratégia errada. O prazo de 24 horas fracassa, na prática, não pelo formulário de notificação, mas pelo fato de a informação não chegar a tempo, internamente, à instância correta.
As demais obrigações: olhar para dezembro de 2027
Quem organizou a obrigação de notificação não deve perder de vista o segundo bloco. Até 11 de dezembro de 2027, os produtos recém-colocados no mercado devem cumprir os requisitos completos. Dois pontos merecem, nesse contexto, atenção especial:
- Avaliação de conformidade: produtos classificados como „importantes“ (Anexo III) ou „críticos“ (Anexo IV) estão sujeitos a procedimentos de avaliação mais rigorosos – uma mera autoavaliação basta, para produtos „importantes“ da classe I, apenas quando as normas harmonizadas pertinentes forem plenamente aplicadas; para classes superiores, ela está excluída.
- Situação normativa: normas harmonizadas para o CRA ainda não foram publicadas no Jornal Oficial da UE; após o adiamento de prazo proposto pela Comissão em julho de 2026, espera-se que as primeiras normas prontas surjam entre outubro e dezembro de 2026 – a listagem no Jornal Oficial vem depois. Os fabricantes que começarem a implementação agora trabalham, portanto, por ora diretamente contra os requisitos do Anexo I.
A ameaça de sanção deve ser levada a sério: infrações podem ser punidas com multas de até 15 milhões de euros ou 2,5 por cento do faturamento anual mundial – conforme o valor que for maior. Há um alívio para microempresas e pequenas empresas: elas não são multadas se apenas perderem o prazo de 24 horas para o alerta precoce. Isso não é, expressamente, um salvo-conduto para o processo como um todo.
Readiness-check: cinco passos até 11 de setembro
A boa notícia: para a obrigação de notificação não é preciso um grande projeto, mas um processo limpo. Cinco passos, nesta ordem:
1. Elaborar o inventário de produtos
Quais produtos com elementos digitais você coloca no mercado da UE – incluindo firmware, apps e o processamento remoto de dados associado? Sem essa lista, qualquer planejamento subsequente permanece fragmentário.
2. Organizar a entrada de vulnerabilidades
Como você sequer fica sabendo de uma vulnerabilidade no seu produto? É preciso um canal de entrada definido – tanto para notificações externas de pesquisadores de segurança e clientes quanto para descobertas próprias do desenvolvimento e da operação.
3. Definir o caminho interno de escalonamento de 24 horas
Do primeiro indício até a decisão „sujeito à notificação ou não“ não podem se passar 24 horas. Isso exige responsabilidades claras, regras de substituição e disponibilidade também fora do horário de expediente.
4. Nomear a responsabilidade pela notificação
Quem envia a notificação, quem a aprova, quem cuida da atualização de 72 horas e do relatório final? Um papel nomeado com substituição basta – mas ele deve estar nomeado antes da data-limite.
5. Aprovar a política de período de suporte
Defina, por produto, o período de suporte e documente a justificativa. Isso é, ao mesmo tempo, a base para a comunicação com os clientes e para o posterior trabalho de conformidade rumo a 2027.
Classificação: logística em vez de pânico
O CRA não exige, a partir de setembro, nada que uma empresa que trabalhe de forma ordenada não conseguisse entregar. Ele exige, porém, compromisso: processos definidos, responsáveis nomeados, prazos cumpridos. Quem enfrentar o tema agora com um projeto de preparação de proporções administráveis estará apto a agir na data-limite – e terá, ao mesmo tempo, lançado o alicerce para os requisitos completos de produto a partir de dezembro de 2027.
Como a sector7 apoia
Como casa de gestão própria, combinamos a consultoria de compliance (ISO 27001, NIS-2, DORA, TISAX) com a operação técnica por trás dela – e aplicamos a mesma sistemática à preparação para o CRA. A entrada de vulnerabilidades e o caminho de escalonamento de 24 horas nós conectamos diretamente ao nosso monitoramento 24/7 no NOC, para que os indícios não fiquem parados na caixa de entrada, mas sejam escalonados o tempo todo à instância correta. Tudo isso a preços mensais fixos e planejáveis, para que a preparação para o CRA permaneça orçável.
Este artigo é uma classificação técnica e não substitui aconselhamento jurídico no caso concreto.
Fontes
- https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2847
- https://cyberresilienceact.eu/state-of-play.html
- https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp