A migração para a criptografia pós-quântica (PQC) já começou e, para boa parte do tráfego da internet, aconteceu sem que ninguém percebesse. O Chrome negocia chaves com ML-KEM por padrão desde a versão 131, o OpenSSH 10.0 adotou um esquema pós-quântico como padrão em abril de 2025 e o iOS 26 ativou o recurso nas conexões TLS dos aplicativos. Quem ainda não começou é, em geral, o sistema interno da empresa: o VPN antigo, o certificado com validade de dez anos, o equipamento industrial que nunca recebe atualização.

Este guia resume o que foi padronizado, quem já adotou (com versões e datas) e um roteiro de seis etapas para equipes de TI. O pano de fundo físico está em computação quântica: o que é e o que ainda não consegue fazer.

O problema em três frases

A criptografia de chave pública usada hoje (RSA e curvas elípticas, como X25519 e ECDSA) se apoia na fatoração de números grandes e no logaritmo discreto. Em 1994, Peter Shor mostrou um algoritmo quântico que resolve esses dois problemas com eficiência, desde que exista um computador quântico grande e com correção de erros, algo que em outubro de 2026 ainda não existe. A criptografia simétrica (AES) e as funções de hash (SHA-2, SHA-3) são bem menos afetadas: AES-256 continua considerado adequado.

O risco que justifica agir antes do tempo tem nome: coletar agora, decifrar depois (harvest now, decrypt later). Um adversário pode gravar hoje uma conexão cifrada e guardá-la até ter a máquina capaz de abri-la. Se um dado precisa ficar sigiloso por 15 anos, ele já está exposto a esse risco.

Assinaturas digitais têm um calendário diferente. Uma assinatura falsificada só é possível depois que a máquina existir, então a urgência é menor. A exceção são sistemas de vida longa, como raízes de certificação, firmware gravado em hardware e documentos que precisam ter validade por décadas.

O que o NIST padronizou

Em 13 de agosto de 2024, o NIST, instituto de padrões dos Estados Unidos, publicou os três primeiros padrões, resultado de um concurso público iniciado em 2016. Todos rodam em computadores comuns: PQC é matemática e software, não exige hardware quântico.

PadrãoAlgoritmoBaseado emServe paraTamanho típico
FIPS 203ML-KEM (ex-Kyber)ReticuladosTroca de chaves (encapsulamento)ML-KEM-768: chave pública de 1.184 bytes
FIPS 204ML-DSA (ex-Dilithium)ReticuladosAssinatura digital (padrão principal)ML-DSA-65: assinatura de 3.309 bytes
FIPS 205SLH-DSA (ex-SPHINCS+)Funções de hashAssinatura digital (reserva, outra matemática)Assinaturas de cerca de 8 KB a 50 KB
FIPS 206 (em elaboração)FN-DSA (ex-Falcon)ReticuladosAssinaturas menoresAinda sem versão final em outubro de 2026
Seleção de março de 2025HQCCódigos corretores de erroTroca de chaves (reserva ao ML-KEM)Rascunho previsto para 2026, padrão final para 2027

Para comparar: uma chave pública X25519 tem 32 bytes e uma assinatura Ed25519 tem 64. O salto de tamanho é o principal custo prático da migração, e é ele que quebra equipamentos com buffers pequenos e protocolos com limite de pacote.

O HQC foi escolhido em 11 de março de 2025 justamente para não depender de uma única família matemática. Se alguém encontrar uma fraqueza nos reticulados, existe uma troca de chaves baseada em outro problema.

O prazo de referência: 2030 e 2035

No rascunho do documento NIST IR 8547, publicado em novembro de 2024, o NIST propõe que algoritmos vulneráveis a computadores quânticos sejam considerados obsoletos (deprecated) a partir de 2030 e proibidos (disallowed) em 2035 nos sistemas do governo americano. Em outubro de 2026 o documento ainda aparece como rascunho na página do NIST, mas o calendário virou referência para fornecedores no mundo todo.

Quem já usa, com versão e data

A maior parte da adoção usa o modo híbrido: a chave da sessão é derivada de um algoritmo clássico (X25519) e de um pós-quântico (ML-KEM-768) ao mesmo tempo. Para quebrar a conexão, o atacante precisaria derrotar os dois. O nome técnico que você verá em configurações é X25519MLKEM768 no TLS e mlkem768x25519-sha256 no SSH.

ProdutoDesdeO que mudou
Chrome, EdgeVersão 131 (novembro de 2024)Troca de chaves híbrida com ML-KEM ativada por padrão
Firefox132 no desktop, 145 no AndroidIdem, segundo a lista de compatibilidade da Cloudflare
OpenSSH9.0 (abril de 2022) e 10.0 (abril de 2025)9.0 trouxe o sntrup761 por padrão; 10.0 trocou o padrão para ML-KEM; 10.1 avisa quando a conexão não é pós-quântica
iOS, iPadOS e macOS 26Setembro de 2025TLS pós-quântico ativado por padrão em URLSession e Network framework; CryptoKit ganhou ML-KEM e ML-DSA
OpenSSL3.5.0Suporte nativo; um NGINX compilado com ele passa a aceitar o grupo híbrido
Go / Node.jsGo 1.24; Node 24.5.0 e 22.20.0Cliente TLS com ML-KEM habilitado
SignalPQXDH (2023) e SPQR (outubro de 2025)Primeiro na abertura da conversa, depois em toda a troca contínua de chaves, com ML-KEM-768

A consequência prática: se o seu site está atrás de um CDN ou de um servidor atualizado e o visitante usa um navegador recente, a troca de chaves daquela conexão provavelmente já é híbrida. O que costuma faltar são as assinaturas (certificados continuam RSA ou ECDSA) e os sistemas internos.

E no Brasil

O movimento mais concreto vem da ICP-Brasil, a infraestrutura que emite os certificados digitais usados em e-CPF, e-CNPJ e notas fiscais. No início de fevereiro de 2026, o ITI publicou a Instrução Normativa nº 35, que incorpora algoritmos pós-quânticos à cadeia da ICP-Brasil e alcança também a assinatura avançada do GOV.BR, definindo algoritmos, tamanhos de chave e suítes de assinatura.

Em 26 de junho de 2026, a Portaria ITI nº 38 criou um grupo de trabalho técnico (GTT-PQC-ICP-Brasil) para inventariar as aplicações que precisam migrar, com foco nos motores de assinatura, e entregar um diagnóstico de risco quântico e um plano de migração em 90 dias, prorrogáveis. Para empresas que assinam contratos, notas e documentos fiscais com certificado ICP-Brasil, é esse cronograma que vai ditar quando os certificados mudam.

Roteiro de migração em 6 etapas

O roteiro abaixo segue a lógica das orientações do NIST e da CISA, a agência de cibersegurança dos EUA: primeiro saber onde a criptografia está, depois priorizar pelo tempo de vida dos dados.

Etapa 1: inventário criptográfico

Liste onde a criptografia de chave pública aparece: certificados TLS (internos e públicos), VPNs, SSH, assinatura de código, HSMs, tokens, bibliotecas embarcadas em aplicativos, integrações com bancos e órgãos públicos, dispositivos IoT e equipamentos industriais. Ferramentas de varredura de rede ajudam a achar endpoints TLS, mas não encontram criptografia escondida dentro de software de terceiros: para isso é preciso perguntar ao fornecedor.

Um atalho útil é começar pelo que já tem dono: o time de infraestrutura conhece os certificados, o time de desenvolvimento conhece as bibliotecas e compras conhece os contratos.

Etapa 2: classificar pelo tempo de sigilo

Para cada sistema, responda: por quantos anos esse dado precisa continuar confidencial? Prontuário médico, dados pessoais sensíveis tratados sob a LGPD, segredos industriais e contratos de longo prazo ficam no topo. Uma sessão de comércio eletrônico que perde valor em minutos fica no fim da fila.

Cruze isso com o tempo de vida do equipamento. Um medidor ou sensor instalado hoje e que vai operar até 2040 precisa sair de fábrica com capacidade de atualização criptográfica.

Etapa 3: atualizar o que já tem suporte

Aqui está o ganho rápido, porque é só atualização:

  • Servidores web e balanceadores com OpenSSL 3.5 ou superior, com o grupo X25519MLKEM768 habilitado no TLS 1.3.
  • Servidores e clientes SSH no OpenSSH 10.x, que já usam ML-KEM por padrão.
  • Aplicativos em Go, Node.js, Java e Swift nas versões listadas acima.
  • CDNs e proxies reversos que já oferecem o modo híbrido do lado do visitante.

Teste antes em homologação: o aumento do tamanho da mensagem inicial do TLS já expôs equipamentos de rede antigos que descartavam pacotes maiores do que esperavam.

Etapa 4: cobrar os fornecedores

Inclua perguntas objetivas em contratos e renovações:

  • O produto suporta ML-KEM e ML-DSA, e em que versão?
  • O HSM recebe atualização de firmware para os novos algoritmos?
  • Existe roteiro público com datas?

Fornecedor que responde com "estamos acompanhando" sem versão nem data é um risco a registrar.

Etapa 5: planejar as assinaturas e a PKI

Trocar assinaturas é mais lento do que trocar a troca de chaves, porque envolve autoridades certificadoras, navegadores, sistemas operacionais e validadores de terceiros. Em outubro de 2026, os certificados públicos de sites continuam em RSA ou ECDSA. O trabalho agora é preparar a PKI interna: testar ML-DSA em laboratório, medir o impacto de certificados maiores e acompanhar o cronograma da ICP-Brasil.

Etapa 6: agilidade criptográfica

Projete sistemas em que o algoritmo seja configuração, e não código fixo. Isso inclui não amarrar tamanhos de chave em campos de banco de dados, não presumir que uma assinatura cabe em 256 bytes e centralizar a criptografia em bibliotecas mantidas, em vez de implementações próprias. A lição do concurso do NIST reforça o ponto: o SIKE, um dos candidatos avançados, foi quebrado em 2022 por pesquisadores usando um computador comum.

Erros comuns na migração

  • Confundir PQC com distribuição quântica de chaves (QKD). QKD usa física quântica, fibras e equipamentos dedicados; PQC é algoritmo e roda em qualquer servidor. São soluções diferentes para o mesmo problema.
  • Implementar o algoritmo por conta própria. Ataques de canal lateral (tempo, consumo de energia) quebram implementações corretas no papel. Use bibliotecas validadas.
  • Abandonar o clássico cedo demais. O modo híbrido existe porque os algoritmos novos têm menos anos de escrutínio do que RSA e curvas elípticas.
  • Esquecer os dispositivos limitados. Cartões, sensores e microcontroladores podem não ter memória para chaves e assinaturas maiores, e muitas vezes exigem troca de hardware.
  • Tratar como problema só da TI. Prazo de fornecedor, orçamento de troca de equipamento e risco jurídico de vazamento futuro passam por compras, jurídico e diretoria.

O que muda para o usuário comum

Quase nada exige ação manual. Navegador, sistema do celular e aplicativos de mensagem atualizados já fazem a parte deles; o importante é não adiar atualizações. As ameaças que de fato atingem pessoas em 2026 continuam sendo golpes, senhas vazadas e falta de segundo fator, temas de segurança digital e autenticação em dois fatores.

Quem guarda criptomoedas ouve com frequência que "o quântico vai quebrar o Bitcoin". A assinatura usada pelas principais blockchains é de curva elíptica, portanto vulnerável em tese a uma máquina futura, e as comunidades discutem migrações. Não há, em outubro de 2026, computador quântico capaz de fazer isso; o contexto técnico está em carteiras de criptomoedas.

Fontes