---
title: "O relógio de 24 horas do CRA começa em 11 de setembro de 2026: garanta que alguém atenda"
description: "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."
date: 2026-08-21
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - Cyber Resilience Act
  - reporte CRA
  - reporte de incidentes
  - divulgação de vulnerabilidades
  - alertas por chamada
---

# Faça o alerta antecipado de 24 horas do CRA tocar um telefone antes que o prazo acabe

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](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting), [Regulamento (UE) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)).

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](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions)). 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](https://apps.apple.com/app/apple-store/id6743597198?pt=128151925&ct=blog-cra-24-hour-reporting-alerts-pt&mt=8), 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](https://www.cyberresilienceact.eu/reporting.html)).

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

| Etapa | Vulnerabilidade explorada ativamente — art. 14(2) | Incidente grave — art. 14(4) |
| --- | --- | --- |
| Alerta antecipado | Em até **24 horas** depois de tomar conhecimento | Em até **24 horas** depois de tomar conhecimento |
| Notificação | Em até **72 horas** depois de tomar conhecimento | Em até **72 horas** depois de tomar conhecimento |
| Relatório final | No máximo **14 dias** depois de uma medida corretiva ou de mitigação estar disponível | Em 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](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_14.html)). 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](https://www.cyberresilienceact.eu/explained.html)).

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](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting)).

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](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)).

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](https://www.enisa.europa.eu/topics/product-security/single-reporting-platform-srp/frequently-asked-questions), [cyberresilienceact.eu](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). 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](https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_64.html)).

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](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)). 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](/docs/notification)). 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](/blog/fix-alert-fatigue-developer-guide) 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](/docs/webhook)).

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](/docs/template) 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:

```bash
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](/docs/developer/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](/docs/conditions) 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](/docs/email-trigger)).

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](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-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](https://www.cyberresilienceact.eu/news/enisa-srp-step-by-step-instructions-31-july-2026.html)). 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](/blog/opsgenie-end-of-life-alternatives).
- **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](https://www.dlapiper.com/en-us/insights/publications/2026/08/the-cras-24-hour-rule-preparing-for-the-cyber-resilience-acts-september-2026-reporting-obligations)). 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](/blog/dora-nis2-incident-reporting-alerts) — 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](https://play.google.com/store/apps/details?id=one.echobell.echobellandroid) ([lançamento do Android](/blog/echobell-android-release)). 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](/docs/features)), mas o hábito certo com material sensível de segurança continua sendo enviar um ponteiro, não o conteúdo.

---

## Relacionados

- [Alertas de reporte de incidentes do DORA e da NIS2](/blog/dora-nis2-incident-reporting-alerts)
- [Como resolver a fadiga de alertas](/blog/fix-alert-fatigue-developer-guide)
- [Como driblar o modo Foco do iOS para alertas críticos](/blog/how-to-bypass-ios-focus-mode-for-critical-alerts)
- [Alternativas ao fim de vida do Opsgenie](/blog/opsgenie-end-of-life-alternatives)
- [Guia de integração de webhooks](/docs/webhook)
- [Gatilhos por e-mail](/docs/email-trigger)
- [Guia de condições](/docs/conditions)