Cyber Resilience Act UE e IoT: O Que Muda no MQTT

O Cyber Resilience Act (CRA) da União Europeia muda a forma como produtos conectados são projetados, lançados e mantidos na UE. Este artigo resume o que o Cyber Resilience Act significa para fabricantes de IoT cujos dispositivos se comunicam via MQTT, abordando padrões seguros, atualizações, gestão de vulnerabilidades e documentação, e mostra quais decisões de engenharia na sua camada de mensageria apoiam esse trabalho. É uma visão geral técnica, não uma orientação jurídica; confirme suas obrigações com assessoria qualificada e com o texto oficial.

O que é o Cyber Resilience Act

O CRA é um regulamento da UE que estabelece requisitos horizontais de cibersegurança para "produtos com elementos digitais", ou seja, produtos de hardware e software cujo uso previsto inclui uma conexão de dados com um dispositivo ou uma rede. Ele entrou em vigor em dezembro de 2024, e suas obrigações se aplicam em etapas: as obrigações de notificação de vulnerabilidades ativamente exploradas e de incidentes graves valem a partir de setembro de 2026, e a maioria das demais obrigações a partir de dezembro de 2027.

Para equipes de IoT, o ponto importante é o escopo. Um sensor, gateway, eletrodoméstico inteligente ou controlador industrial que se conecta a uma rede e é colocado no mercado da UE muito provavelmente está no escopo, junto com seu firmware e os componentes de software que inclui. Isso vale também para fabricantes brasileiros: um gateway projetado em Manaus ou um controlador fabricado em Joinville e vendido na UE entra no escopo da mesma forma. Alguns setores com regras próprias, como determinados produtos médicos e automotivos, recebem tratamento diferente.

Os produtos são divididos em categorias. A maioria se enquadra em uma categoria padrão, na qual os fabricantes podem avaliar a conformidade por conta própria. Produtos listados como "importantes" ou "críticos" passam por rotas de avaliação mais rigorosas. A categoria do seu dispositivo determina quanto envolvimento de terceiros é necessário.

Obrigações centrais dos fabricantes

Os requisitos essenciais do regulamento se dividem em dois grupos: propriedades do produto e processos de gestão de vulnerabilidades. De forma simplificada para IoT:

Área	O que o CRA espera (simplificado)	O que isso significa para um dispositivo MQTT
Seguro por padrão	Produtos lançados com configuração segura, sem vulnerabilidades exploráveis conhecidas	Sem senhas padrão, TLS ativado por padrão, sem topics de depuração habilitados
Controle de acesso	Proteção contra acesso não autorizado por meio de autenticação e gestão de identidades adequadas	Credenciais exclusivas por dispositivo, nada de conexões anônimas ao broker
Confidencialidade	Proteger dados armazenados e transmitidos, por exemplo com criptografia	MQTT sobre TLS, armazenamento protegido de credenciais
Integridade	Proteger dados, comandos e firmware contra modificação não autorizada	Firmware assinado, comandos validados
Minimização de dados	Processar apenas os dados necessários para a finalidade prevista	Publicar o que o caso de uso precisa, nada além disso
Disponibilidade e resiliência	Manter as funções essenciais funcionando, inclusive sob condições de negação de serviço	Backoff, buffer, bom comportamento diante dos limites do broker
Limitar a superfície de ataque	Minimizar as interfaces expostas	Nenhuma porta de entrada; apenas MQTT de saída
Atualizações de segurança	Fornecer atualizações durante o período de suporte, de preferência automáticas e separadas das atualizações de funcionalidades	Um caminho OTA seguro que funcione sobre a sua conectividade
Gestão de vulnerabilidades	Identificar, documentar e corrigir vulnerabilidades; política de divulgação coordenada	SBOM incluindo as bibliotecas MQTT, um contato para divulgação, um processo de correção
Notificação	Notificar vulnerabilidades ativamente exploradas e incidentes graves dentro dos prazos definidos	Um processo interno para detectar, fazer a triagem e notificar
Documentação	Documentação técnica, informações ao usuário, período de suporte	Documentar como o dispositivo se conecta e como os usuários o protegem

Padrões seguros na camada MQTT

Muitos problemas históricos de IoT vieram de padrões inseguros. Em termos de MQTT, a direção do CRA se traduz em decisões de projeto concretas:

Nada de credenciais compartilhadas ou padrão. Cada dispositivo recebe credenciais exclusivas durante a fabricação ou o onboarding. Veja provisionamento seguro de dispositivos IoT.
TLS ativado por padrão, com verificação de certificado. Nenhum modo "insecure" no firmware de produção.
Conexões somente de saída. O dispositivo abre uma conexão com o broker; ele não escuta MQTT de entrada.
Nada de brokers públicos para dados reais. Brokers públicos de teste são úteis no desenvolvimento, mas o firmware de produção deve se conectar a um broker privado e autenticado.
Topics mínimos. Não publique dumps de diagnóstico, credenciais ou dados pessoais desnecessários. Se houver dados pessoais de pessoas no Brasil, o mesmo cuidado também ajuda no atendimento à LGPD.
Tratamento seguro de comandos. Valide cada comando contra uma lista de permissões antes de agir.

Veja como isso fica em um firmware de ESP32 usando WiFiClientSecure e PubSubClient:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

// ISRG Root X1 (raiz da Let's Encrypt) em formato PEM, usada para verificar o broker
static const char ROOT_CA[] PROGMEM = R"EOF(
-----BEGIN CERTIFICATE-----
...paste ISRG Root X1 here...
-----END CERTIFICATE-----
)EOF";

// Exclusivos por dispositivo, carregados de armazenamento protegido em produção
extern const char* DEVICE_CLIENT_ID;  // YOUR_CLIENT_ID
extern const char* DEVICE_USERNAME;   // YOUR_USERNAME
extern const char* DEVICE_PASSWORD;   // YOUR_PASSWORD

WiFiClientSecure net;
PubSubClient mqtt(net);
unsigned long nextAttempt = 0;
unsigned long backoffMs = 1000;

void connectMqtt() {
  if (mqtt.connected() || millis() < nextAttempt) return;
  if (mqtt.connect(DEVICE_CLIENT_ID, DEVICE_USERNAME, DEVICE_PASSWORD)) {
    backoffMs = 1000;
  } else {
    nextAttempt = millis() + backoffMs + random(0, 1000);  // backoff com jitter
    backoffMs = min(backoffMs * 2, 300000UL);
  }
}

void setup() {
  WiFi.begin("YOUR_WIFI_SSID", "YOUR_WIFI_PASSWORD");
  while (WiFi.status() != WL_CONNECTED) delay(500);
  net.setCACert(ROOT_CA);               // verifica o servidor; nunca chame setInsecure()
  mqtt.setServer("YOUR_BROKER_HOST", 8883);
}

void loop() {
  connectMqtt();
  mqtt.loop();
}

Os detalhes que importam para padrões seguros estão visíveis: verificação de certificado ativada, credenciais que não ficam fixas no corpo do sketch e uma estratégia de reconexão que não sobrecarrega o broker. O tutorial de MQTT com ESP32 mostra o loop de publicação completo.

Atualizações e gestão de vulnerabilidades

O CRA dá um peso significativo ao que acontece depois que um produto é lançado. Para dispositivos MQTT, a camada de conectividade faz parte dessa história:

Conheça seus componentes. Mantenha uma lista de materiais de software (SBOM) com sua biblioteca de cliente MQTT, sua biblioteca TLS e as respectivas versões. Quando surgir um boletim, você precisa saber em poucas horas quais produtos usam o código afetado.
Tenha um canal de atualização. Muitas equipes usam MQTT para sinalizar que há uma atualização disponível e HTTPS para baixar uma imagem assinada. Seja qual for o mecanismo, ele precisa ser autenticado e protegido quanto à integridade.
Separe as atualizações de segurança. Sempre que possível, entregue correções de segurança independentemente das releases de funcionalidades.
Publique uma política de divulgação. Dê aos pesquisadores uma forma clara de relatar problemas.
Prepare-se para as notificações. Defina quem faz a triagem de vulnerabilidades e incidentes e como as notificações chegam às autoridades dentro dos prazos exigidos.

A visão geral das vulnerabilidades comuns do MQTT é um bom ponto de partida sobre o que acompanhar nas bibliotecas de cliente.

Onde o broker se encaixa

O CRA impõe obrigações ao fabricante do produto. Escolher um determinado broker não torna um produto conforme, e nenhum provedor de broker pode assumir essa responsabilidade. O que o backend pode fazer é facilitar a implementação e a documentação de projetos seguros.

A ConnectMQ oferece recursos que você pode referenciar na sua documentação técnica como parte da sua própria avaliação de riscos:

MQTT sobre TLS na 8883 e WebSockets seguros na 8084 com certificado Let's Encrypt, para que os dispositivos possam verificar o servidor com uma raiz padrão.
Brokers privados autenticados com credenciais geradas e client IDs vinculados a essas credenciais.
Isolamento multi-tenant, ou um cluster isolado nos planos Dedicated, ou implantação na sua própria conta de nuvem com BYOC.
Cotas por plano sinalizadas com o reason code 0x97 do MQTT 5, proteção contra inundação e bloqueio de IP após logins com falha repetidos, que apoiam a disponibilidade em caso de abuso.
Estado de conexão por meio de $SYS/broker/connection/{clientId}/state e alertas por limite no portal para ajudar a detectar comportamentos anormais.

Não descreva a ConnectMQ, nem qualquer outro broker, como uma solução de conformidade com o CRA. Documente-a como um componente da sua arquitetura, liste suas propriedades de segurança e mantenha a responsabilidade pelos controles do lado do dispositivo. O guia de broker MQTT gerenciado explica a divisão da responsabilidade compartilhada.

Um checklist prático de preparação para o CRA em dispositivos MQTT

Confirme se o seu produto está no escopo e qual categoria se aplica.
Realize e documente uma avaliação de riscos de cibersegurança que cubra os fluxos de dados MQTT.
Remova credenciais padrão e compartilhadas; provisione identidades exclusivas por dispositivo.
Exija TLS com verificação do certificado do servidor no firmware de produção.
Garanta que os dispositivos façam apenas conexões de saída e não exponham interfaces desnecessárias.
Valide todos os comandos recebidos e limite o que eles podem alterar.
Implemente backoff na reconexão e buffer offline para resiliência.
Mantenha um SBOM que inclua as bibliotecas MQTT e TLS.
Construa e teste um mecanismo de atualização assinado e autenticado.
Publique uma política de divulgação de vulnerabilidades e defina o processo de notificação.
Defina e comunique o período de suporte.
Prepare a documentação do usuário sobre configuração segura e descomissionamento.

Para um contexto mais amplo, as melhores práticas de segurança MQTT e o artigo sobre zero trust para mensageria IoT abordam muitos dos mesmos controles do ponto de vista da engenharia. As orientações oficiais e o texto do regulamento são publicados pela Comissão Europeia.

Construa uma conectividade segura na ConnectMQ

Comece pela camada de conectividade enquanto avança pelo restante do checklist. Crie um broker privado no plano Serverless (Free) em app.connectmq.com (sem cartão de crédito), conecte um dispositivo de desenvolvimento a ele via TLS com credenciais exclusivas e use o servidor MQTT público (gratuito) apenas para experimentos descartáveis, nunca para dados de produção. Quando precisar de isolamento, o guia de broker MQTT na nuvem compara os modelos de implantação.

Perguntas frequentes

O Cyber Resilience Act se aplica ao meu dispositivo IoT?

Se for um produto com elementos digitais que se conecta a um dispositivo ou rede e é colocado no mercado da UE, muito provavelmente sim, a menos que regras setoriais específicas o excluam. Confirme o escopo e a categoria do seu produto com assessoria jurídica.

Quando as obrigações do CRA começam a valer?

As obrigações de notificação de vulnerabilidades ativamente exploradas e de incidentes graves valem a partir de setembro de 2026, e a maioria das demais obrigações a partir de dezembro de 2027.

Usar um broker MQTT seguro torna meu produto conforme com o CRA?

Não. A conformidade é responsabilidade do fabricante pelo produto como um todo. Um broker seguro apoia o seu projeto, mas firmware, atualizações, gestão de vulnerabilidades e documentação continuam sendo trabalho seu.

MQTT sobre TLS basta para atender ao requisito de confidencialidade do CRA?

O TLS protege os dados em trânsito, o que é uma parte importante. Você ainda precisa proteger as credenciais e os dados armazenados no dispositivo e avaliar se medidas adicionais são necessárias para o seu perfil de risco.

Cyber Resilience Act da UE e IoT: O Que Muda para Dispositivos MQTT