Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Artigos

Artigos

O reporte de 24h e 72h: como funciona a obrigação aplicável desde 11 de setembro de 2026

Desde 11 de setembro de 2026, um fabricante que saiba de uma vulnerabilidade ativamente explorada no seu produto tem 24 horas para o primeiro aviso. O que se reporta, a quem, por onde, e o que convém ter pronto.

Publicado
Atualizado

Nota de atualização (23 out 2026). Texto revisto depois de a obrigação passar a aplicar-se: a plataforma de notificação funciona desde 11 set 2026, as orientações da Comissão de 27 jul 2026 passaram a ser a referência citada, e entraram os componentes de terceiros, o aviso aos utilizadores e os produtos já colocados no mercado.

O artigo 14.º do Cyber Resilience Act foi a primeira grande obrigação dos fabricantes a entrar em aplicação: a 11 de setembro de 2026, quinze meses antes da aplicação plena. Desde essa data, um fabricante de produtos com elementos digitais que tome conhecimento de uma vulnerabilidade ativamente explorada, ou de um incidente grave com impacto na segurança do produto, entra num calendário medido em horas.

O que dispara a obrigação

Este ponto é o mais mal compreendido. O artigo 14.º não cobre todas as vulnerabilidades. Cobre duas coisas:

  • Vulnerabilidades ativamente exploradas: falhas no produto relativamente às quais há provas fiáveis de que um agente mal-intencionado as explorou num sistema sem autorização do proprietário (art. 3.º, ponto 42);
  • Incidentes graves com impacto na segurança do produto: os que afetam, ou podem afetar, a capacidade do produto de proteger a disponibilidade, autenticidade, integridade ou confidencialidade de dados ou funções sensíveis ou importantes, e os que provocam, ou podem provocar, a introdução ou execução de código malicioso no produto ou nos sistemas do utilizador (art. 14.º, n.º 5).

Uma vulnerabilidade que a equipa descobre e corrige antes de ser explorada segue o processo normal de gestão de vulnerabilidades. Não abre nenhum relógio de 24 horas.

O relógio começa no momento em que o fabricante toma conhecimento. As orientações da Comissão de 27 de julho de 2026 (C(2026) 5252, não vinculativas) clarificam o que isso significa: há conhecimento quando, após uma avaliação inicial do evento suspeito, o fabricante tem um grau razoável de certeza de que há exploração ativa ou incidente grave. O prazo conta a partir do resultado dessa triagem, o que faz dela um processo formal, com dono e critério escrito.

Com componentes de terceiros (uma biblioteca, um runtime, o servidor web de um painel de administração), a pergunta da triagem é se a falha foi ou está a ser explorada no próprio produto. Segundo as mesmas orientações (ponto 218), se o código vulnerável não é alcançável no produto, ou se não houve exploração nele, não há reporte obrigatório para esse fabricante. A exploração do componente noutros sistemas é um sinal para essa triagem. A vulnerabilidade segue então o processo normal, que para os produtos colocados no mercado a partir de 11 de dezembro de 2027 inclui comunicá-la a quem mantém o componente (art. 13.º, n.º 6). O artigo 09 aplica este critério às falhas do PHP e do Node.js corrigidas a 21 de outubro de 2026.

A obrigação cobre também o parque já instalado. Por derrogação expressa (art. 69.º, n.º 3), o artigo 14.º aplica-se a todos os produtos abrangidos, incluindo os colocados no mercado antes de 11 de dezembro de 2027, que de resto só ficam sujeitos ao CRA se sofrerem uma modificação substancial. As orientações da Comissão acrescentam que o reporte continua a aplicar-se depois de terminado o período de suporte.

Os três prazos

  1. 24 horas, notificação de alerta precoce. Deliberadamente magra: existe uma vulnerabilidade ativamente explorada ou um incidente grave, que produto é afetado, e em que Estados-Membros o fabricante sabe que o produto foi disponibilizado.
  2. 72 horas, notificação de vulnerabilidade (nos incidentes graves, notificação de incidente). Informação geral sobre o produto, a natureza do exploit e da vulnerabilidade, medidas corretivas ou de atenuação já tomadas e as que os utilizadores podem tomar.
  3. Relatório final. Para vulnerabilidades: até 14 dias depois de haver medida corretiva ou de atenuação disponível. Para incidentes graves: até um mês após a notificação de incidente. Inclui descrição, gravidade e impacto, informação sobre o ator malicioso quando disponível, e detalhes da correção.

Há ainda um quarto texto, este dirigido aos utilizadores. Depois de tomar conhecimento, o fabricante tem de informar os utilizadores afetados (e, quando adequado, todos os utilizadores) da vulnerabilidade ou do incidente e, se necessário, das medidas de atenuação ou corretivas que podem aplicar, quando adequado num formato estruturado e legível por máquina (art. 14.º, n.º 8). Se não o fizer em tempo útil, o CSIRT designado coordenador pode fazê-lo.

Linha de tempo do artigo 14.º: o conhecimento, apurado pela triagem, abre o relógio; notificação de alerta precoce às 24 horas; notificação de vulnerabilidade ou de incidente às 72 horas; relatório final 14 dias após haver medida corretiva ou de atenuação, ou um mês após a notificação nos incidentes graves.
O calendário do artigo 14.º. O relógio abre com o conhecimento, e é isso que faz da triagem um processo formal.

A quem e por onde

Reporta-se uma única vez, através da plataforma única de comunicação de informações prevista no art. 16.º (em inglês, Single Reporting Platform, SRP), que a ENISA pôs em funcionamento a 11 de setembro de 2026. A notificação entra pelo ponto do CSIRT designado coordenador do Estado-Membro do estabelecimento principal do fabricante (em Portugal, o CERT.PT, no Centro Nacional de Cibersegurança) e fica simultaneamente acessível à ENISA. Esse CSIRT dissemina depois a notificação aos CSIRT dos restantes Estados-Membros onde o produto está disponível, e alimenta as autoridades de fiscalização de mercado.

Em circunstâncias excecionais, o CSIRT coordenador que recebe a notificação pode decidir adiar a disseminação aos restantes CSIRT, pelo período estritamente necessário e por motivos relacionados com a cibersegurança, em especial a pedido do fabricante (art. 16.º, n.º 2). O Regulamento Delegado (UE) 2026/881 fixa as condições, por exemplo uma divulgação coordenada em curso em que o CSIRT atua como intermediário de confiança, ou uma medida de atenuação que o fabricante prevê disponibilizar no prazo de 72 horas. A decisão é do CSIRT, que tem de informar de imediato a ENISA.

Um detalhe com consequências: o “estabelecimento principal” é o Estado-Membro onde as decisões sobre a cibersegurança dos produtos são predominantemente tomadas. Se não for possível determiná-lo, conta aquele onde o fabricante tem o estabelecimento com mais trabalhadores na União. Fabricantes sem estabelecimento principal na União seguem uma cascata, com base na informação de que dispõem: primeiro o Estado-Membro do mandatário que atua em nome do fabricante para o maior número dos seus produtos, depois o do importador que coloca no mercado o maior número, depois o do distribuidor que disponibiliza o maior número e, por fim, o Estado-Membro com mais utilizadores. Convém resolver esta questão antes de qualquer incidente: segundo a FAQ da ENISA, uma notificação enviada ao CSIRT coordenador errado pode ser invalidada e ter de ser reenviada ao correto.

A plataforma, desde 11 de setembro de 2026

A ENISA abriu a SRP a 11 de setembro de 2026, no mesmo dia em que o artigo 14.º passou a aplicar-se, numa primeira versão a que chama “initial operating capability” (a entrada 004 do diário registou esse dia). Tem limites que convém conhecer antes de precisar dela: só existe em inglês, não tem API e ainda não recebe as notificações voluntárias do artigo 15.º.

Cada pessoa que vai notificar em nome do fabricante precisa de uma conta EU Login com autenticação multifator. O fabricante designa na plataforma um representante principal e até 20 secundários (assigned representatives, um papel da plataforma que não se confunde com o mandatário do regulamento), e é o CSIRT coordenador que valida essa associação. A ENISA aconselha a registar só quando houver o que notificar; o que se prepara antes é saber quem o fará e perante que CSIRT.

Na versão atual, o contador de 72 horas que a plataforma mostra parte da submissão do alerta precoce e marca 48 horas a partir daí. O prazo legal conta do momento em que se tomou conhecimento, e é essa hora que o registo interno tem de guardar. Se a plataforma estiver em baixo, pode contactar-se diretamente o CSIRT coordenador, mas a submissão pela SRP continua a ser obrigatória quando ela voltar. Uma exploração de que o fabricante já tinha conhecimento antes de 11 de setembro de 2026 não se reporta retroativamente; se só tomar conhecimento depois dessa data, reporta, mesmo que a vulnerabilidade seja anterior.

A conclusão prática mantém-se: o processo interno não depende da ferramenta e tem de dizer quem faz a triagem, quem decide “tomámos conhecimento”, quem redige, quem aprova, e com que modelos pré-escritos.

O que isto significa para quem fabrica

O reporte de 24 horas não é um problema de comunicação; é um problema de prontidão. Quatro peças que qualquer fabricante, de qualquer dimensão, consegue montar, e que desde 11 de setembro de 2026 já deviam estar prontas:

  1. Sinais que alimentam a triagem. Monitorização das fontes que levantam a suspeita de que uma “vulnerabilidade conhecida” passou a “ativamente explorada”: os avisos do CERT-EU e do CSIRT nacional (em Portugal, o CERT.PT), os avisos dos mantenedores dos componentes da SBOM, incluindo os pré-anúncios de lançamentos de segurança, o catálogo KEV da CISA, e o canal de receção de relatórios externos (a política de divulgação coordenada que o próprio CRA exige). O KEV é um catálogo norte-americano, com critérios próprios, e pode chegar depois dos primeiros relatos de exploração: a ausência de uma CVE no KEV não prova que não há exploração. A pergunta a que a triagem responde é se a falha foi ou está a ser explorada no produto.
  2. Uma decisão de conhecimento com dono. Quem pode declarar, e com que critério, que a empresa “tomou conhecimento”. Sem esse critério escrito, ninguém sabe ao certo a que hora começou a contar o prazo.
  3. Os textos pré-escritos. O alerta precoce de 24h cabe em meia página; escrevê-lo durante o incidente é a pior altura. Modelos preenchíveis para as três notificações e para o aviso aos utilizadores, aprovados de antemão.
  4. O ensaio. Um exercício de mesa por semestre, com cenário realista, a medir uma coisa: quanto tempo passa entre o sinal e o alerta precoce pronto a submeter.

Numa microempresa, tudo isto cabe em meia dúzia de páginas e numa tarde de exercício. O que não cabe é improvisá-lo às 3 da manhã de uma quinta-feira.

Fontes