O relógio de 24 horas do CRA começa em 11 de setembro de 2026: garanta que alguém atenda

A partir de 11 de setembro de 2026, o Cyber Resilience Act da UE dá aos fabricantes 24 horas para enviar um alerta antecipado — pelo navegador, sem nenhuma API de reporte. Veja como transformar esse gatilho em uma chamada telefônica com o Echobell, e o que um alerta mais alto ainda não resolve.

Sumário

Em 11 de setembro de 2026, as obrigações de reporte do Cyber Resilience Act (CRA) da UE passam a valer. A partir dessa data, um fabricante que toma conhecimento de uma vulnerabilidade explorada ativamente em um produto com elementos digitais — ou de um incidente grave que afete um deles — tem 24 horas para enviar um alerta antecipado ao seu CSIRT coordenador e à ENISA (Comissão Europeia, Regulamento (UE) 2024/2847).

Esse prazo tem uma característica que a maioria dos prazos de conformidade não tem: ele corre em horas de relógio. Não há exceção para dias úteis, não há pausa de fim de semana e não há tolerância enquanto a pessoa responsável pelo reporte está dentro de um avião. E a plataforma pela qual você envia, a Single Reporting Platform da ENISA, é um formulário web — "nenhuma interface de programação de aplicações será fornecida nesta fase" (FAQ da ENISA). Uma pessoa nomeada precisa fazer login e enviar.

Isso faz da regra das 24 horas um problema de alerta antes de ser um problema de papelada. Este guia mostra como levar o momento do conhecimento até um telefone tocando com o Echobell, e é honesto sobre a parte grande do preparo para o CRA que nenhuma ferramenta de notificação toca.

O que exatamente começa em 11 de setembro de 2026?

Fabricantes de produtos com elementos digitais precisam reportar vulnerabilidades exploradas ativamente e incidentes graves por uma única plataforma da UE, em um relógio escalonado que começa no momento em que eles tomam conhecimento. Todo o resto do CRA — marcação CE, os requisitos essenciais do Anexo I, avaliação de conformidade — vale a partir de 11 de dezembro de 2027. O reporte chega quinze meses antes, e vale para produtos que já estão no mercado, não só para o que você lançar depois dessa data (cyberresilienceact.eu).

O Artigo 14 define dois trilhos paralelos com o mesmo formato:

EtapaVulnerabilidade explorada ativamente — art. 14(2)Incidente grave — art. 14(4)
Alerta antecipadoEm até 24 horas depois de tomar conhecimentoEm até 24 horas depois de tomar conhecimento
NotificaçãoEm até 72 horas depois de tomar conhecimentoEm até 72 horas depois de tomar conhecimento
Relatório finalNo máximo 14 dias depois de uma medida corretiva ou de mitigação estar disponívelEm até um mês depois da notificação de 72 horas

O texto diz "sem demora injustificada e, em todo caso, no prazo de 24 horas após o fabricante tomar conhecimento" (Artigo 14). Vinte e quatro horas são o teto, não a meta.

O Artigo 14(5) define a régua do que é "grave": um incidente se qualifica quando afeta negativamente, ou é capaz de afetar negativamente, a capacidade do produto de proteger a disponibilidade, a autenticidade, a integridade ou a confidencialidade de dados ou funções sensíveis ou importantes, ou quando levou ou é capaz de levar à introdução ou à execução de código malicioso. Esse "é capaz de" importa — você pode dever um reporte antes que algo tenha de fato dado errado para um cliente.

O Artigo 14(8) acrescenta uma segunda obrigação que corre em paralelo: você também precisa informar os usuários afetados do produto sobre a vulnerabilidade ou o incidente e, quando necessário, sobre as medidas corretivas que eles podem adotar. Esse é um público diferente do CSIRT, com um caminho próprio.

Quem realmente tem essa obrigação?

Fabricantes de produtos com elementos digitais, onde quer que estejam estabelecidos, mais os administradores (stewards) de software de código aberto, de forma mais restrita. Uma empresa fora da UE que vende para a União não escapa do dever; o regulamento espera que um operador econômico na UE seja responsável pelas obrigações aplicáveis (cyberresilienceact.eu).

Você reporta ao CSIRT designado como coordenador no Estado-membro onde fica o seu estabelecimento principal na União, e à ENISA ao mesmo tempo — mas envia uma única vez, pela Single Reporting Platform, que encaminha para os dois (Comissão Europeia).

Os administradores de software de código aberto entram por um subconjunto bem definido: a obrigação do Artigo 14(1) se aplica na medida em que eles participam do desenvolvimento de produtos com elementos digitais, e o Artigo 14(3) e (8) se aplicam na medida em que incidentes graves afetem as redes e os sistemas de informação que eles fornecem para esse desenvolvimento. Se você administra um projeto amplamente usado, leia o Artigo 24 junto com o Artigo 14, em vez de presumir um dos extremos.

O Artigo 15 também permite reportes voluntários — de vulnerabilidades, ameaças cibernéticas, incidentes e quase incidentes — por fabricantes e por qualquer outra pessoa. Reportes voluntários não criam novas obrigações, mas passam pela mesma plataforma e esbarram no mesmo problema: alguém precisa estar acordado.

Por que um prazo de 24 horas é um problema de alerta?

Porque o relógio começa quando você toma conhecimento, e o conhecimento raramente chega em horário comercial. O gatilho é um fato que chega à sua organização, não uma decisão que ela toma.

Veja de onde esse fato costuma vir. Um pesquisador de segurança escreve para security@ às 23:40 de um sábado. Um cliente na ponta abre um chamado descrevendo a exploração. Um feed de CVE ou KEV acende sobre um componente que você distribui. Seu próprio EDR sinaliza execução em um sistema de build. A análise de preparo da DLA Piper aponta especificamente a versão disso na cadeia de suprimentos: os fabricantes muitas vezes não são os primeiros a saber, e a informação chega por importadores, distribuidores, pesquisadores ou fornecedores de componentes (DLA Piper).

Cada um desses caminhos termina em uma notificação que a sua configuração atual provavelmente entrega em silêncio — um e-mail em uma caixa compartilhada, uma mensagem no Slack em um canal que ninguém acompanha de madrugada, um chamado em uma fila que só é triado na segunda-feira. Nenhum deles falha. Todos entregam corretamente, para ninguém.

Três detalhes deixam a lacuna pior do que ela parece:

  • Não existe API. A ENISA afirma com todas as letras que nenhuma API de reporte será fornecida nesta fase. Você não tem como deixar um script enviar o alerta antecipado enquanto todo mundo dorme.
  • O acesso é configurado por pessoa e com antecedência. Os representantes autorizados se registram com uma conta EU Login, e o CSIRT coordenador designado valida a autoridade deles depois do primeiro acesso. Existe um representante principal e um suplente, e o convite ao suplente expira depois de sete dias (FAQ da ENISA, cyberresilienceact.eu). Se a única pessoa que pode enviar estiver inacessível, o prazo não se importa.
  • A faixa de multa é a mais alta. O Artigo 64 coloca o descumprimento das obrigações dos Artigos 13 e 14 na faixa de multas administrativas "de até 15 000 000 EUR ou, se o infrator for uma empresa, de até 2,5 % do seu faturamento anual mundial total do exercício financeiro anterior, prevalecendo o valor mais alto" (Artigo 64).

Uma ressalva honesta sobre esse último ponto, porque ela muda a conta para times pequenos: o Artigo 64 exclui os fabricantes que se qualificam como microempresas ou pequenas empresas das multas administrativas por descumprir o prazo do Artigo 14(2)(a) ou 14(4)(a) — ou seja, especificamente o alerta antecipado de 24 horas. O dever de reportar continua de pé, e a exceção não se estende à notificação de 72 horas nem ao resto do Artigo 14. Leia o artigo e busque orientação, em vez de acreditar em um post de blog sobre onde a sua empresa se encaixa.

O que o alerta antecipado de 24 horas contém, na prática?

Muito pouco — e é justamente esse o ponto. A orientação da ENISA descreve um conjunto pequeno de campos obrigatórios na etapa do alerta antecipado: tipo de comunicação (vulnerabilidade ou incidente), nível da comunicação, horário do reporte, dados de quem reporta, nome do fabricante ou administrador, o produto, um título e, no caso de incidentes, se há suspeita de atos ilícitos ou maliciosos. Entre os campos opcionais dessa etapa estão um CVE ID ou um EUVD ID.

O quadro técnico mais completo — a natureza geral da vulnerabilidade ou do exploit, uma avaliação inicial, medidas corretivas e de mitigação — pertence à notificação de 72 horas, não às primeiras 24 horas.

Ou seja, o alerta antecipado não é um projeto de pesquisa. É um formulário curto que uma pessoa preparada preenche em minutos. A restrição que pesa não é o formulário. É se uma pessoa registrada, autorizada e acordada vai ficar sabendo a tempo. Isso é um problema de roteamento de notificações, e tem solução hoje.

Como coloco um telefone tocando na frente do relógio de 24 horas?

O Echobell transforma uma chamada de webhook ou um e-mail em um alerta que toca e vibra como uma ligação recebida, e é assim que ele atravessa o modo Foco e o Não perturbe do iOS (veja como driblar o modo Foco do iOS). A configuração abaixo convive com o processo de chamados e de PSIRT que você já tem — ela não substitui nenhum dos dois.

Passo 1 — Crie um canal de Chamada reservado a candidatos a CRA

No app, crie um canal e defina o tipo de notificação como Chamada (tipos de notificação). Dê a ele o nome da decisão que ele dispara, não o da fonte de dados: "CRA — o relógio de 24 h pode ter começado" é melhor que "Alertas de segurança".

Esse canal precisa ficar quieto. Se ele tocar a cada aviso, a cada varredura que falha e a cada atualização de dependência, as pessoas vão parar de atender e você terá gasto seu único canal barulhento com ruído. Mande isso para outro lugar — o guia sobre fadiga de alertas explica a divisão.

Copie a URL do webhook nos detalhes do canal; ela se parece com https://hook.echobell.one/t/<channel-token>. Trate-a como um segredo, porque quem a tiver pode fazer os celulares do seu time tocarem (guia de webhooks).

Defina modelos legíveis na tela de bloqueio às 02:00 por alguém meio dormindo:

Título: Possível reporte CRA — {{product}}
Corpo: {{kind}} — {{summary}} (conhecido desde {{time}} UTC)

{{time}}, {{date}}, {{hour}} e as demais variáveis de tempo do sistema são sempre injetadas em UTC, então a notificação registra um horário mesmo que quem enviou tenha esquecido de mandar um. Esse horário não é prova jurídica de quando o conhecimento começou, mas é uma âncora útil quando você for reconstruir a linha do tempo depois.

Passo 2 — Aponte seus caminhos de detecção para o canal

Qualquer sistema capaz de chamar um webhook pode acionar o canal. Os campos que você envia viram variáveis de modelo:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "vulnerabilidade explorada ativamente",
    "summary": "relato de pesquisador, exploit funcional em anexo",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

A variável especial externalLink vira um link clicável no registro da notificação, então atender a chamada deixa quem responde a um toque do chamado que guarda os detalhes.

Vale a pena conectar, mais ou menos na ordem de quantas vezes são o primeiro sinal:

  • Sua fila de entrada de PSIRT ou de segurança — um webhook quando um caso é marcado como candidato a CRA.
  • Avisos de segurança do GitHub e alertas do Dependabot nos repositórios que constroem produtos distribuídos (integração com o GitHub).
  • Seu SIEM, EDR ou WAF, para detecções contra a infraestrutura de build, release ou assinatura — o Artigo 14(5) alcança explicitamente incidentes que possam levar à introdução de código malicioso.
  • Feeds de inteligência de vulnerabilidades que você já consome, filtrados para os componentes que aparecem nos seus próprios SBOMs.

Passo 3 — Use condições para que só candidatos plausíveis toquem

Este é o passo que mantém o canal confiável. As condições do Echobell avaliam as mesmas variáveis e os mesmos cabeçalhos HTTP que os seus modelos usam, e um canal só dispara quando a expressão é verdadeira:

craCandidate == true && confirmed == true

Ou filtre por um cabeçalho, se o sistema que envia não conseguir moldar o corpo:

header["x-cra-severity"] == "reportable"

Coloque o limiar em "uma pessoa competente deveria olhar isso dentro de uma hora", não em "isso é definitivamente reportável". Decidir se o Artigo 14 se aplica é um julgamento que exige uma pessoa com os fatos em mãos; o trabalho do canal é levar essa pessoa até os fatos rapidamente. Filtrar demais aqui é o erro caro, porque um reporte que você nunca começou é pior que uma chamada de que você não precisava.

Passo 4 — Capture os sistemas que só mandam e-mail

A maior parte do primeiro contato vindo de fora da sua empresa chega por e-mail — o pesquisador, o cliente, o CSIRT nacional, o fornecedor do componente. Todo canal do Echobell pode ter o próprio endereço, então uma regra de encaminhamento no security@ transforma essas mensagens em chamadas (gatilhos por e-mail).

Os gatilhos por e-mail expõem from, to, subject, text e html como variáveis, então você consegue filtrar sem precisar fazer parsing de nada:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

Peça aos seus relatores frequentes e aos fornecedores importantes que usem um marcador combinado no assunto e filtre por ele. É um detalhe contratual pequeno que transforma uma caixa de entrada sem estrutura em um sinal roteável.

Passo 5 — Coloque no canal todos os representantes registrados

Compartilhe o canal com todo mundo que realmente pode enviar: o representante autorizado principal, o suplente e a liderança de segurança que pode tomar a decisão sobre o Artigo 14. Cada inscrito escolhe o próprio tipo de notificação, então quem está de plantão pode ficar em Chamada enquanto o resto do grupo fica em Urgente.

É esse o ponto do exercício. A SRP exige uma pessoa registrada e validada. Se exatamente uma pessoa na sua empresa está registrada, seu prazo de 24 horas tem um ponto único de falha com bateria de celular.

Passo 6 — Ensaie antes de 11 de setembro, não depois

Dois ensaios, os dois valem a pena ainda este mês:

  1. O caminho do alerta. Dispare o curl acima com o Não perturbe de fato ligado, no celular que realmente vai estar na mesa de cabeceira de alguém. Ative Repetir chamada perdida no app para que uma chamada que falha uma vez seja tentada de novo. Um caminho de escalonamento não testado é só uma suposição.
  2. O caminho do envio. Percorra um reporte no papel, usando os guias passo a passo de registro e envio da ENISA, atualizados ao longo de agosto de 2026 (ENISA SRP). Crie as contas EU Login agora, confirme qual CSIRT é o seu coordenador e envie cedo o convite ao representante suplente — ele expira depois de sete dias.

O segundo ensaio tem um detalhe que vale conhecer: até a orientação da ENISA de julho, a URL pública da plataforma ainda constava como "a ser fornecida no lançamento", então um teste de ponta a ponta ao vivo ainda não era possível (cyberresilienceact.eu). A ENISA se comprometeu a ter a plataforma operacional até 11 de setembro de 2026. Ensaie tudo o que está sob seu controle e não trate o preparo da plataforma como motivo para adiar o seu.

O que o Echobell não faz

Ser específico aqui importa mais do que de costume, porque o assunto é regulatório:

  • Ele não deixa você em conformidade. O Echobell é um canal de notificação. Mapear seus produtos, manter um processo de tratamento de vulnerabilidades, decidir se o Artigo 14 se aplica, se registrar na SRP e enviar dentro do prazo é tudo com você. Nenhuma ferramenta de alerta jamais cumpriu uma obrigação de reporte.
  • Ele não envia nada. Não existe API para enviar, e o Echobell não seria quem a chamaria se existisse. Ele faz um telefone tocar; o resto é com uma pessoa registrada.
  • Ele não é um carimbo de tempo jurídico. A variável {{time}} registra quando o gatilho chegou ao Echobell, em UTC. Quando o "tomar conhecimento" começou é uma questão de fato sobre a sua organização, e quem documenta isso é o seu registro de incidentes — não uma notificação push.
  • Ele não tem políticas de escalonamento nem confirmação de recebimento. Não existe "se ninguém atender em dez minutos, ligue para a próxima pessoa", nem rodízio, nem trilha de auditoria de quem confirmou o quê. Para isso você precisa de uma plataforma de incidentes — veja as alternativas ao Opsgenie.
  • Ele não garante a entrega. Uma chamada depende da infraestrutura de push, da rede e de um celular carregado. Trate-o como a camada que encurta o intervalo entre um fato chegar e uma pessoa saber, não como um controle que você aponta em uma auditoria.
  • Ele não acompanha o horário local. As variáveis de tempo embutidas são só UTC e não seguem horário de verão. Condições que delimitam uma janela de tempo precisam de ajuste manual duas vezes por ano.

FAQ

Usar o Echobell nos deixa em conformidade com o CRA?

Não. O CRA impõe obrigações aos fabricantes, e nenhum app de notificação pode cumpri-las. O que o Echobell resolve é um modo de falha específico: o alerta antecipado de 24 horas é perdido porque a pessoa que poderia enviá-lo só ficou sabendo no dia útil seguinte. Esse modo de falha é real e comum, mas é uma parte de um programa de conformidade bem maior.

Quando o relógio de 24 horas começa de verdade?

Quando o fabricante toma conhecimento da vulnerabilidade explorada ativamente ou do incidente grave. O regulamento não define um momento exato, e o conhecimento depende dos fatos e da rapidez com que eles podem ser estabelecidos (DLA Piper). Na prática, isso é um argumento a favor de uma triagem rápida e documentada: quanto maior o intervalo entre um sinal chegar e alguém avaliá-lo, mais difícil fica explicar depois.

Somos uma empresa pequena. Estamos isentos?

Do reporte, não. O Artigo 64 exclui microempresas e pequenas empresas das multas administrativas especificamente por perder o prazo de 24 horas do Artigo 14(2)(a) ou 14(4)(a). A obrigação de reportar continua, a notificação de 72 horas e o relatório final não são afetados, e as definições de microempresa e de pequena empresa não são coisa que se presuma. Trate isso como uma atenuação estreita, não como um passe livre.

Nossa caixa de segurança é monitorada em horário comercial. Isso não basta?

Só se você estiver disposto a perder até dois terços da janela em um fim de semana normal. Um reporte que chega às 18:00 de sexta deixa você com um prazo até as 18:00 de sábado. Monitorar em horário comercial é um padrão razoável para todo o resto; o relógio de 24 horas é exatamente o caso que ele não cobre.

Conformidade, jurídico e engenharia podem receber o mesmo alerta?

Podem, e devem. Compartilhe um canal e todo inscrito é notificado no mesmo gatilho, cada um escolhendo a própria urgência. A pessoa que confirma a exploração e a pessoa que vai enviar o formulário precisam começar no mesmo minuto, não uma depois da outra.

Isso ajuda no dever de informar os usuários do Artigo 14(8)?

Indiretamente. O Artigo 14(8) exige informar os usuários afetados sobre a vulnerabilidade ou o incidente e, quando necessário, sobre medidas corretivas. Isso é comunicação com clientes e precisa dos seus próprios canais. O Echobell pode acordar quem responde por essa comunicação ao mesmo tempo que quem responde pelo envio, para que as duas frentes comecem juntas.

Já reportamos sob a NIS2 ou o DORA. É a mesma coisa?

Não, ainda que os formatos rimem. NIS2 e DORA impõem deveres a entidades com base em setor e criticidade; o CRA impõe deveres a fabricantes com base nos produtos que eles colocam no mercado da UE. Uma mesma organização pode estar sujeita aos três, com relógios diferentes e destinatários diferentes. Se esses regimes também valem para você, veja alertas de reporte de incidentes do DORA e da NIS2 — e note que a camada de alerta pode ser compartilhada mesmo quando as obrigações não são.

A chamada realmente atravessa o Não perturbe?

As notificações em Chamada são entregues como alertas em formato de ligação, e é isso que permite que elas rompam o modo Foco no iOS. Não é mágica: continua dependendo das configurações do sistema, da rede e de um celular carregado. Teste no aparelho de verdade, com o modo Foco realmente ligado, antes de contar com isso — e ative Repetir chamada perdida.

Isso é só para iOS?

Não. O Echobell está no iOS e no Android via Google Play (lançamento do Android). O comportamento dos alertas em formato de ligação difere entre as plataformas, então teste no aparelho que a pessoa de plantão realmente vai carregar.

O que devemos colocar no payload do webhook?

O mínimo necessário para decidir se vale levantar da cama: o produto, o tipo de sinal, uma linha de contexto e um externalLink para o chamado que guarda o detalhe. O Echobell mantém o conteúdo e o histórico das notificações no dispositivo e deixa no servidor apenas contas, canais e inscrições (modelo de privacidade), mas o hábito certo com material sensível de segurança continua sendo enviar um ponteiro, não o conteúdo.

Relacionados

Artigos relacionados

Alertas por chamada no Uptime Kuma: faça seu celular tocar

O Uptime Kuma tem mais de 90 formas de notificação, mas nenhuma que faça seu celular tocar. Veja como adicionar alertas por chamada para quedas usando um único webhook.

Leia mais

Seu agente de IA está esperando por você: transforme aprovações em chamadas

Agentes autônomos param e esperam em silêncio quando precisam de uma pessoa. Nada na pilha de agentes faz seu celular tocar. Veja como ligar as pausas de aprovação e as execuções que falharam ao Echobell.

Leia mais

Reporte de incidentes do DORA e da NIS2: receba uma chamada antes que o prazo acabe

O DORA dá 4 horas a partir da classificação. A NIS2 dá 24 horas a partir do conhecimento. Nenhum desses relógios pausa à noite. Veja como transformar um alerta de detecção em uma chamada telefônica de verdade com o Echobell.

Leia mais