O que você vai aprender
Por que a preparação precisa começar antes de existir um computador quântico capaz de quebrar a criptografia atual.
Onde RSA, Diffie-Hellman e curvas elípticas aparecem na infraestrutura, mesmo quando não são visíveis no inventário tradicional.
Como montar um inventário criptográfico de TLS, SSH, VPNs, certificados, assinatura de código e fornecedores.
Como priorizar a migração e realizar testes isolados, verificáveis e reversíveis.
A migração começou antes da máquina chegar
Em 27 de outubro de 2026, o NIST publicou a versão final do NIST IR 8547, seu roteiro para retirar gradualmente padrões vulneráveis à computação quântica e adotar algoritmos pós-quânticos. O documento não anuncia que computadores quânticos já conseguem quebrar a criptografia usada na internet. Ele reconhece outro problema: descobrir dependências, atualizar produtos, testar interoperabilidade e substituir certificados pode levar anos.
Para sistemas federais dos Estados Unidos, o planejamento trabalha com 2035 como referência geral de conclusão. Uma ordem executiva posterior antecipou a migração de ativos de alto valor e sistemas de alto impacto para 2030, no caso do estabelecimento de chaves, e 2031, para assinaturas digitais. Esses prazos não são obrigações brasileiras, mas influenciam fabricantes, bibliotecas, serviços em nuvem e cadeias de fornecimento presentes no mundo inteiro.
A pergunta útil para uma equipe de infraestrutura, portanto, não é “quando o computador quântico ficará pronto?”. É “quanto tempo levaremos para descobrir onde a criptografia vulnerável está e substituí-la sem interromper serviços?”.
Pós-quântica não significa usar um computador quântico
Criptografia pós-quântica, ou PQC, é um conjunto de algoritmos matemáticos executados em computadores convencionais. Ela não exige hardware quântico e não deve ser confundida com distribuição quântica de chaves, que depende de infraestrutura física especializada.
O risco principal está na criptografia assimétrica. Um computador quântico criptograficamente relevante poderia comprometer problemas matemáticos que sustentam RSA, Diffie-Hellman e criptografia de curvas elípticas. Esses mecanismos aparecem no estabelecimento de chaves, em certificados e em assinaturas digitais.
Criptografia simétrica e funções de hash também precisam ser avaliadas, mas não sofrem o mesmo tipo de ruptura. A RFC 9958, voltada a engenheiros, recomenda separar essas categorias e alerta que a migração não será necessariamente uma substituição direta: diferenças de chaves, assinaturas, mensagens e interfaces podem exigir mudanças em protocolos e aplicações.
Em 2024, o NIST finalizou três padrões principais: ML-KEM para estabelecimento de chaves, ML-DSA e SLH-DSA para assinaturas digitais. Isso não autoriza trocar algoritmos manualmente em qualquer produto. A implementação precisa ser oferecida e suportada pelo protocolo, pela biblioteca, pelo equipamento e pelo fornecedor responsável.
O relógio dos dados já está correndo
Uma informação capturada hoje pode continuar valiosa daqui a dez ou quinze anos. No cenário conhecido como “coletar agora, descriptografar depois”, um adversário armazena tráfego protegido para tentar abri-lo quando uma capacidade futura estiver disponível.
Isso não torna todo pacote antigo automaticamente recuperável. O risco depende do protocolo, do método de troca de chaves e do valor que a informação conservará. Ainda assim, ele muda a prioridade: prontuários, propriedade intelectual, credenciais, dados financeiros, projetos estratégicos e segredos de longa duração merecem atenção antes de informações que perdem valor rapidamente.
O primeiro cálculo de risco pode ser expresso assim:
tempo necessário de sigilo + tempo estimado de migração > tempo até a ameaça se tornar viável
Nenhum dos três valores é conhecido com exatidão. A desigualdade serve como ferramenta de decisão, não como previsão. Quanto maior a vida útil do dado e mais lenta a substituição do sistema, menor é a margem para esperar.
O inventário criptográfico é o primeiro entregável
Inventários tradicionais registram servidores, switches, aplicações e responsáveis, mas raramente mostram qual algoritmo protege cada comunicação ou assinatura. A orientação do projeto de migração do NCCoE começa pela visibilidade criptográfica: uma organização não consegue priorizar o que ainda não identificou.
O inventário deve responder onde a criptografia existe, para que é usada, quem depende dela e como pode ser atualizada. Registre pelo menos:
Ativo e serviço: aplicação, equipamento, API, domínio, túnel, firmware ou processo de assinatura.
Função criptográfica: confidencialidade, autenticação, estabelecimento de chave, integridade ou assinatura.
Protocolo e versão: TLS, SSH, IPsec, S/MIME, código assinado, PKI ou mecanismo proprietário.
Algoritmos e parâmetros: informações obtidas de configurações, certificados, bibliotecas e documentação do fornecedor.
Certificados e chaves: emissor, finalidade, validade, armazenamento e processo de renovação — sem registrar o material secreto.
Dados protegidos: classificação, tempo necessário de sigilo e consequências de exposição.
Dependências: cliente, servidor, autoridade certificadora, HSM, balanceador, proxy, agente ou serviço externo.
Responsável e fornecedor: equipe que opera o ativo e organização que controla sua atualização.
Capacidade de mudança: atualização disponível, limitação de hardware, janela operacional e possibilidade de reversão.
Não confunda inventário criptográfico com coleta de chaves privadas. O objetivo é mapear metadados e dependências. Material secreto deve permanecer nos mecanismos de proteção já definidos pela organização.
Onde procurar na infraestrutura
Uma varredura de serviços expostos é útil, mas não encontra tudo. O levantamento precisa combinar descoberta técnica, inventário de ativos, revisão de configuração e perguntas aos fornecedores.
TLS e certificados
Inclua sites, APIs, balanceadores, proxies reversos, inspeção TLS, bancos de dados, mensageria e conexões entre serviços. Registre certificados públicos e privados, cadeias intermediárias, autoridades internas e processos automáticos de renovação.
SSH e administração remota
Mapeie servidores, appliances, automações, chaves de usuários e contas de serviço. Uma equipe pode atualizar o OpenSSH dos servidores e ainda permanecer dependente de um equipamento antigo que aceita apenas algoritmos legados.
VPN e conectividade entre redes
Relacione concentradores, clientes, túneis site a site, IPsec, SSL VPN, dispositivos de borda e autenticação baseada em certificados. A compatibilidade precisa existir nos dois extremos; trocar apenas um lado pode derrubar o túnel.
Assinatura de código, firmware e documentos
Verifique pipelines de desenvolvimento, repositórios de pacotes, boot seguro, atualização de firmware, assinatura de scripts, documentos e carimbos de tempo. Confidencialidade e assinatura são funções diferentes e podem exigir cronogramas distintos.
Nuvem e serviços contratados
Nem toda criptografia é configurada diretamente pelo cliente. Descubra quais componentes pertencem ao provedor, quais dependem de configuração da empresa e como será comunicada uma mudança. O artigo Local ou nuvem? Comece pela necessidade ajuda a separar responsabilidade operacional de localização física.
Exemplo hipotético: a dependência que não aparece no firewall
Considere uma empresa com lojas conectadas à matriz por VPN, aplicações publicadas por um balanceador e backups enviados a um provedor de nuvem. O inventário de rede mostra todos os equipamentos, mas não registra que o firmware de dois appliances antigos não receberá suporte pós-quântico. Também não mostra que uma aplicação interna fixa uma biblioteca TLS desatualizada nem que o processo de atualização dos terminais depende de assinatura de código.
Uma decisão apressada poderia habilitar um novo mecanismo no concentrador principal e descobrir, durante a janela, que parte das filiais não negocia a conexão. Um inventário criptográfico muda a sequência: identifica os extremos do túnel, confirma suporte com os fornecedores, separa laboratório e produção e define retorno à configuração anterior.
Esse cenário é hipotético. Ele ilustra por que “o firewall suporta PQC” não equivale a “o processo de negócio está pronto para PQC”. A unidade de migração não é um equipamento isolado; é o caminho completo percorrido pela comunicação ou assinatura.
Como priorizar sem transformar tudo em emergência
Nem todo item precisa migrar ao mesmo tempo. Classifique cada dependência por quatro critérios:
Longevidade do dado: por quanto tempo a informação deve permanecer confidencial ou a assinatura precisa ser verificável?
Impacto: o que acontece se a confidencialidade, autenticidade ou integridade falhar?
Exposição: o tráfego pode ser coletado fora do ambiente? O serviço está na internet ou atravessa terceiros?
Dificuldade de substituição: há suporte do fornecedor, hardware compatível, testes e janela de manutenção?
Uma conexão que protege dados estratégicos de longa duração e depende de um appliance sem atualização merece prioridade alta. Um serviço interno descartável, sem dados persistentes e com substituição simples pode entrar em uma etapa posterior.
O resultado deve ser uma fila explicável, não uma pontuação automática. A equipe de negócio precisa validar o tempo de vida da informação; infraestrutura e segurança avaliam exposição, dependências e capacidade de mudança.
As perguntas que fornecedores precisam responder
“Produto preparado para o futuro quântico” é uma frase insuficiente. Solicite respostas verificáveis:
Quais versões, protocolos e algoritmos pós-quânticos são suportados hoje?
O suporte é experimental, opcional ou recomendado para produção?
Existe modo híbrido combinando mecanismos tradicionais e pós-quânticos?
Quais impactos foram medidos em latência, CPU, memória, tamanho de mensagens e capacidade de sessões?
O recurso exige novo hardware, licença, firmware ou alteração de certificado?
Como clientes antigos e integrações incompatíveis serão tratados?
Quais registros permitem comprovar qual algoritmo foi negociado?
Qual é o procedimento documentado de retorno?
Qual é o ciclo de suporte do produto e quem responde por vulnerabilidades de implementação?
Guarde as respostas no inventário com data e versão. Roteiros de fornecedores mudam; uma apresentação comercial não substitui documentação de produto nem teste no ambiente da organização.
Testar é diferente de ativar em produção
A transição deve começar em laboratório ou em um segmento controlado. Antes de qualquer teste, confirme autorização, escopo, cópias de segurança e forma de desfazer a mudança.
Um piloto seguro pode seguir esta sequência:
reproduzir cliente, servidor, certificados e dispositivos intermediários em ambiente isolado;
medir a linha de base com o mecanismo atual;
ativar apenas combinações documentadas pelo fornecedor;
verificar negociação, autenticação, renovação, reconexão e tratamento de falhas;
comparar latência, consumo, tamanho de mensagens e capacidade de sessões;
testar clientes antigos e comportamento de fallback sem permitir redução silenciosa de segurança;
interromper o teste, restaurar a configuração anterior e confirmar a recuperação;
registrar evidências, limitações e condições necessárias para ampliar o piloto.
Combinações híbridas podem reduzir o risco de depender exclusivamente de um algoritmo novo durante a transição, mas também aumentam tamanho, processamento e complexidade. A RFC 9958 recomenda cuidado na escolha da construção híbrida; não basta concatenar mecanismos de forma improvisada.
O movimento já chegou ao Brasil
Em fevereiro de 2026, o Instituto Nacional de Tecnologia da Informação publicou a Instrução Normativa ITI nº 35, atualizando o documento de padrões e algoritmos da ICP-Brasil para incorporar algoritmos pós-quânticos. Em junho, o órgão criou um grupo de trabalho técnico sobre PQC na ICP-Brasil para estudar e propor diretrizes de implementação.
Isso não significa que todas as empresas brasileiras receberam um prazo único de migração nem que qualquer certificado atual deixou de funcionar. O fato relevante é que a infraestrutura nacional de confiança digital já trata a transição como trabalho de engenharia e governança, não como hipótese distante.
Organizações brasileiras devem acompanhar normas aplicáveis ao seu setor, orientações da ICP-Brasil, atualizações de fabricantes e contratos internacionais. Prazos dos Estados Uni
dos podem influenciar a oferta tecnológica, mas não devem ser apresentados como obrigação jurídica local.
Um roteiro possível para os próximos 90 dias
Primeiros 30 dias: descobrir e organizar
Nomeie um responsável e envolva infraestrutura, segurança, desenvolvimento, compras e gestão de riscos.
Defina o modelo do inventário e aproveite dados de CMDB, certificados, scanners, configuração e contratos.
Comece por serviços expostos, VPNs, PKI, assinatura de código e dados com sigilo de longa duração.
Registre lacunas e produtos cujo suporte ainda não foi confirmado.
De 31 a 60 dias: priorizar e consultar
Relacione cada mecanismo aos dados e processos que protege.
Classifique longevidade, impacto, exposição e dificuldade de substituição.
Envie perguntas técnicas aos fornecedores e peça versões, evidências e cronogramas.
Escolha um caso de baixo risco para laboratório, com critério de sucesso e retorno definidos.
De 61 a 90 dias: testar e decidir
Execute o piloto isolado e registre compatibilidade, desempenho, falhas e recuperação.
Atualize o inventário com evidências reais, não apenas declarações comerciais.
Crie uma fila de migração por risco e dependência.
Defina quando reavaliar fornecedores, padrões e produtos.
Não amplie para produção até que aprovação, monitoramento e reversão estejam documentados.
O objetivo dos 90 dias não é converter toda a empresa para PQC. É sair da incerteza: saber onde a criptografia está, quais dados merecem prioridade, quais fornecedores estão prontos e qual caminho pode ser testado com segurança.
Erros que atrasam a preparação
Esperar uma data exata para o computador quântico: a migração pode ser mais lenta que a previsão da ameaça.
Comprar uma solução antes de mapear dependências: o produto pode proteger apenas uma parte do caminho.
Tratar PQC como sinônimo de QKD: são abordagens diferentes, com requisitos diferentes.
Coletar chaves privadas no inventário: metadados são necessários; segredos devem continuar protegidos.
Ignorar assinatura e firmware: a transição não se limita à criptografia de tráfego.
Aplicar prazos estrangeiros como lei brasileira: use-os como sinal técnico e comercial, não como obrigação local automática.
Alterar produção sem compatibilidade e retorno: novos algoritmos não eliminam riscos de implementação, configuração ou indisponibilidade.
Preparação pós-quântica é um caso concreto de segurança adaptativa: observar mudanças, localizar exposição, testar controles e ajustar prioridades. Esse ciclo é aprofundado no artigo Cibersegurança adaptativa e preventiva: proteger antes, ajustar sempre.
Conclusão
A ameaça quântica ainda não quebrou RSA ou curvas elípticas em uso real, mas o trabalho necessário para substituir essas dependências já começou. Padrões foram publicados, protocolos estão sendo adaptados, fabricantes estão definindo suporte e a ICP-Brasil abriu sua própria frente de transição.
Para equipes de redes e infraestrutura, a ação mais útil agora não é habilitar uma opção desconhecida no firewall. É construir visibilidade: identificar onde a criptografia assimétrica sustenta conexões, identidades, certificados, atualizações e assinaturas; relacionar essas dependências aos dados protegidos; e testar mudanças em ambientes controlados.
Quem conhece seu inventário pode migrar por risco, acompanhar fornecedores e preservar reversibilidade. Quem não conhece tende a descobrir a dependência durante uma renovação, uma atualização obrigatória ou uma indisponibilidade. Na transição pós-quântica, mapear cedo é a forma mais prática de evitar pressa depois.