Preparar-se para a era pós-quântica não é atualizar uma biblioteca. É mapear inventário, dependências e protocolos para proteger dados que precisam continuar confidenciais, identidades que devem permanecer verificáveis e sistemas difíceis de alterar depois de implantados.
Um computador quântico suficientemente capaz poderia comprometer mecanismos de chave pública usados amplamente para estabelecer chaves e gerar assinaturas digitais. A data exata é incerta, mas dados capturados hoje podem continuar sensíveis por muitos anos (“capture agora, decifre depois”); certificados, firmware e registros assinados também podem durar mais que as premissas criptográficas que os originaram. Por isso, a migração é um problema de ciclo de vida, não uma aposta sobre calendário.
Este artigo é um guia de engenharia, não aconselhamento jurídico nem política de seleção de algoritmos. Organizações reguladas precisam cumprir orientações de supervisores, autoridades nacionais e setores, além de usar módulos e perfis criptográficos aprovados quando exigido.
Criptografia pós-quântica (PQC) não é um único algoritmo substituto. Estabelecimento de chaves, assinaturas, emissão de certificados, armazenamento de chaves, negociação de protocolo e verificação de longo prazo têm restrições diferentes. Os primeiros padrões finais do NIST incluem FIPS 203 ML-KEM para encapsulamento de chaves, FIPS 204 ML-DSA e FIPS 205 SLH-DSA para assinaturas digitais. O NIST selecionou HQC para padronização futura como KEM alternativo baseado em outra família matemática; essa seleção ainda não equivale a um padrão final pronto para implantação.
Não confunda KEM com criptografia dos dados em si: ele estabelece material de chave compartilhada, usado depois por um algoritmo simétrico. Da mesma forma, trocar o algoritmo de handshake do TLS não migra assinatura de código, documentos, identidade de dispositivos ou validação de arquivos arquivados.
Um inventário útil registra ativo e responsável, aplicação, algoritmo e parâmetros, biblioteca/provedor, protocolo, propósito da chave, cadeia de certificados, módulo criptográfico, sensibilidade e retenção dos dados, terceiros envolvidos, caminho de substituição e data do último teste. Descubra o uso real em runtime além das dependências declaradas: a criptografia pode estar escondida em serviços gerenciados, appliances, APIs de parceiros e firmware antigo.
Priorize dados cuja confidencialidade precisa durar além da janela de migração, sistemas cujas assinaturas sustentam confiança por muitos anos, protocolos expostos externamente, infraestrutura crítica e ativos com substituição lenta de fornecedor ou hardware. Uma pontuação prática pode combinar impacto, exposição, vida útil dos dados, prazo de migração e incerteza das dependências. Ela serve à triagem, não é uma medida formal de segurança criptográfica.
| Tipo de ativo | Por que pode ser urgente | Primeira ação técnica |
|---|---|---|
| Registros sensíveis de longa duração | Texto cifrado capturado pode continuar valioso além do horizonte previsto. | Mapear fluxos, retenção, estabelecimento de chaves e cópias em fornecedores. |
| Assinatura de firmware e software | Raízes de confiança e artefatos precisam ser verificados muito tempo após o release. | Inventariar raízes, cadeia de boot, updates e evidências arquivadas. |
| TLS/VPN regulados | O protocolo depende dos dois endpoints, appliances e perfis aprovados. | Identificar partes, terminações, HSMs e testes graduais de interoperabilidade. |
| Dispositivos embarcados | Flash, memória, banda e acesso para atualização em campo limitam as opções. | Medir tamanho de artefatos, handshake e update no hardware representativo. |
| Serviços de terceiros | Cronograma e escolhas criptográficas podem estar fora do seu controle. | Incluir capacidade e roadmap do fornecedor em avaliação e renovação contratual. |
A Recomendação (UE) 2024/1101 da Comissão Europeia pede uma transição coordenada. Materiais posteriores descrevem uma migração sincronizada na UE para administrações públicas e infraestrutura crítica, com progresso até 2035 e marcos intermediários até 2030 para casos de alto risco e/ou sistemas muito complexos. São marcos de roadmap de política pública, não um prazo legal universal imposto de forma idêntica a todo sistema privado.
Planos nacionais, regras setoriais, contratos de compra e expectativas de supervisão podem criar obrigações mais específicas. Confirme as regras da jurisdição e do serviço em questão. Mesmo assim, trate as datas do roadmap como limites de planejamento: compra de fornecedores, certificação, padronização de protocolos e atualização em campo podem levar anos.
Cripto-agilidade é poder trocar mecanismos criptográficos com segurança, não carregar todos os algoritmos em um seletor de runtime. Centralize políticas quando possível, use bibliotecas mantidas e perfis suportados, versione capacidades de protocolo e torne rotação de chaves e certificados observável. Evite criptografia e negociação próprias; resistência a downgrade e negociação autenticada são importantes.
Estabelecimento híbrido de chaves pode ser útil durante a transição quando protocolos e perfis padronizados o suportam explicitamente, mas aumenta tamanho de mensagens, complexidade e modos de falha. Use implementações verificadas, teste endpoints e intermediários e documente fallback. Nunca invente uma construção híbrida concatenando segredos no código da aplicação.
Eu criaria um pipeline de inventário criptográfico (CBOM) combinando análise de código, inventário de software, telemetria de rede, repositórios de certificados e declarações de fornecedores. Cada achado teria serviço e ativo de negócio responsáveis, uso do algoritmo, propósito, vida útil dos dados, exposição, dependência de substituição e status de migração. O sistema geraria filas priorizadas por risco, não uma contagem enganosa de “pacotes vulneráveis a quantum”.
Para cada serviço prioritário, criaria um registro por etapa: perfil-alvo aprovado, contrapartes, baseline de desempenho, testes de interoperabilidade, plano de rotação, condições de rollback, responsável operacional e data para remover negociação legada. Integraria os resultados à gestão de mudanças e aos painéis de incidentes; novas varreduras contínuas impediriam que softwares novos reabrissem pontos cegos.
| Falha | Sinal | Controle |
|---|---|---|
| Inventário vê código, mas não runtime | O tráfego negocia criptografia ausente da análise de dependências. | Combine código, endpoint, certificados e tráfego; registre lacunas de visibilidade. |
| Handshake novo quebra intermediários | Aumentam fragmentação, falhas ou timeout ligado ao MTU. | Teste o caminho completo com proxies, firewalls, gateways e links limitados. |
| Híbrido cria downgrade | Clientes fazem fallback silencioso sem política autenticada. | Use negociação definida por protocolo, proteção contra downgrade e telemetria. |
| Migração de assinaturas é esquecida | TLS muda, mas firmware ou documentos ainda dependem de assinaturas antigas. | Trate KEM, assinaturas, PKI e arquivos como frentes separadas. |
| Roadmap do fornecedor vira bloqueio | Dispositivo crítico não oferece suporte nem atualização em campo. | Escalone cedo compras, controles compensatórios e prazo de substituição. |
A migração pós-quântica começa com descoberta, não com troca indiscriminada de algoritmo. Separe estabelecimento de chaves de assinaturas, priorize dados e raízes de confiança por duração e impacto, pilote perfis padronizados ao longo de protocolos completos e distinga cronogramas nacionais/setoriais dos marcos de roadmap da UE. Cripto-agilidade é útil quando governada, observável e testada; não autoriza criptografia própria nem fallback indefinido.
Nota editorial: Referências de normas e cronograma verificadas em 28 de setembro de 2026. Este artigo não define prazo de conformidade para uma organização específica. Consulte orientações europeias e nacionais vigentes, reguladores setoriais, fornecedores e especialistas em criptografia.