PQC Status
Verificar um domínio
Menu
Scanner Selo verificado Relatório de prontidão Preços Regulamentações Algoritmos Observatório Guias Entrar
Guia

Checklist de prontidão pós-quântica para equipes de segurança

Seis fases, cada item com um comando a executar ou um documento a arquivar, para que o trabalho resista a uma revisão.

· 9 min

Um checklist de prontidão para a criptografia pós-quântica (PQC) tem uma única função: transformar uma migração de vários anos em itens que uma equipe consiga concluir neste trimestre, cada um deixando evidências que outra pessoa possa ler. A ordem importa. A troca de chaves vem primeiro porque o tráfego gravado é protegido apenas pela troca de chaves; inventário, fornecedores, assinaturas e monitoramento vêm em seguida. Cada item abaixo indica o artefato a produzir, não apenas a ideia a considerar.

Como usar este checklist

Siga as fases na ordem, mas conduza a descoberta (fase 2) e os ganhos rápidos (fase 3) em paralelo: esperar por um inventário completo antes de habilitar a troca de chaves híbrida em um endpoint web público adia o único controle que mitiga o tráfego gravado. Atribua a cada item um responsável, uma data e um artefato. O artefato é o essencial: PCI DSS, DORA e NIS2 pedem políticas, inventários e revisões documentados, e uma migração não documentada parece exatamente igual a nenhuma migração. Este artigo é informativo e não constitui aconselhamento jurídico.

Quatro termos são usados ao longo do texto. ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) é a troca de chaves pós-quântica padronizada no NIST FIPS 203, publicado como padrão final em 13 de agosto de 2024. Um KEM (key encapsulation mechanism, mecanismo de encapsulamento de chaves) é a primitiva que estabelece um segredo compartilhado. HNDL (harvest now, decrypt later, ou coletar agora, decifrar depois) é a prática de gravar hoje tráfego cifrado para decifrá-lo quando existir um computador quântico capaz. Um CBOM (cryptographic bill of materials, lista de materiais criptográficos) é um inventário legível por máquina dos ativos criptográficos.

Fase 1: governança e escopo

Datas de referência para o planejamento

FonteMarcosNatureza
EU Coordinated Implementation Roadmap v1.1 (23/06/2025)Inventário criptográfico e roteiros nacionais até o fim de 2026; casos de uso de alto risco migrados até o fim de 2030; de risco médio até o fim de 2035Orientação coordenada para os Estados-Membros, não um regulamento que vincule empresas
NCSC do Reino Unido (20/03/2025)Descoberta e plano inicial até 2028; migrações de maior prioridade até 2031; conclusão até 2035Orientação
Governo federal dos EUA: EO 14412 e OMB M-26-15 (junho de 2026)Planos de migração PQC das agências com prazo em 22/10/2026; TLS 1.3 exigido até 02/01/2030; sistemas de alto valor com estabelecimento de chaves PQC até o fim de 2030, assinaturas PQC até o fim de 2031; migração completa até 2035 (NSM-10)Vinculante para as agências federais dos EUA
BSI TR-02102-1 (versão 2026-01)PQC híbrida recomendada; acordo de chaves clássico isolado recomendado apenas até o fim de 2031, até o fim de 2030 para necessidades de proteção muito elevadas; RSA de pelo menos 3000 bitsDiretriz técnica
ANSSI (França)Hibridização obrigatória em seu escopo regulado; PQC visada para produtos que entrarem em qualificação a partir de 2027; após 2030, a compra de produtos sem PQC é considerada não razoávelObrigatória no escopo regulado, nos demais casos recomendação (a ANSSI afirma que suas recomendações de PQC ainda não são obrigações regulatórias fora desse escopo)
NIST IR 8547Propõe descontinuar os algoritmos vulneráveis ao quântico com segurança de 112 bits (por exemplo RSA-2048) após 2030 e proibir todos os algoritmos de chave pública vulneráveis ao quântico após 2035Rascunho público inicial (12/11/2024), ainda um rascunho

Fase 2: descoberta e inventário

openssl version
openssl s_client -connect example.com:443 -tls1_3 -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated TLS1.3 group"
ssh -Q kex | grep mlkem
ssh -v user@example.com 2>&1 | grep "kex: algorithm"

O OpenSSL 3.5 ou posterior é necessário para os grupos ML-KEM. Se o openssl s_client rejeitar o nome do grupo, o cliente é antigo demais e o resultado nada diz sobre o servidor.

Fase 3: ganhos rápidos na troca de chaves

# nginx built against OpenSSL 3.5 or later: hybrid first, classical kept as fallback
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

A sintaxe e a compilação necessária variam entre servidores e distribuições; nosso guia para habilitar ML-KEM no nginx, Apache, HAProxy e Caddy traz as diretivas de cada servidor. A RFC 10024 (agosto de 2026) especifica o acordo de chaves híbrido pós-quântico e tradicional para TLS 1.3.

Fase 4: fornecedores e compras

A maior parte do parque tecnológico pertence a terceiros. Envie as mesmas cinco perguntas a cada fornecedor crítico e arquive as respostas junto com o contrato.

  1. Quais grupos de troca de chaves TLS o seu serviço oferece hoje, e podemos verificar isso externamente?
  2. Qual é o seu roteiro datado para o suporte a ML-KEM, e quais notas de versão vão anunciá-lo?
  3. Quais implementações de FIPS 203, 204 ou 205 vocês utilizam, e em quais componentes?
  4. Vocês podem fornecer um CBOM ou um inventário criptográfico equivalente para o produto entregue?
  5. Como o contrato trata uma mudança forçada de algoritmo caso a criptoanálise avance?

Evidência: respostas escritas e datadas por fornecedor, além de uma cláusula de agilidade criptográfica nas renovações. Para produtos vendidos na UE, o Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e), exige a proteção da confidencialidade, por exemplo cifrando dados relevantes em repouso ou em trânsito por meio de mecanismos no estado da arte; ele não nomeia algoritmos pós-quânticos. Suas obrigações de notificação se aplicam a partir de 11/09/2026 e ele se aplica integralmente a partir de 11/12/2027.

Fase 5: assinaturas, certificados e PKI

openssl x509 -in cert.pem -noout -subject -issuer -enddate
openssl x509 -in cert.pem -noout -text | grep -i -E "Signature Algorithm|Public-Key"

Fase 6: monitoramento e revisão

Transforme o checklist em uma primeira medição

As fases 2 e 6 precisam da mesma entrada: uma visão externa do que os seus servidores realmente negociam. Você pode analisar o seu domínio com o PQC Status gratuitamente para ver as versões de TLS, os grupos de troca de chaves oferecidos e a cadeia de certificados, e depois guardar a exportação como linha de base datada para o item de inventário. Uma varredura descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade. O próximo passo concreto é executá-la nos seus três hostnames mais expostos, arquivar os resultados e abrir um chamado para cada hostname que ainda não ofereça um grupo híbrido.

Perguntas frequentes

Por onde deve começar um checklist de prontidão pós-quântica?

Comece pela governança e pela superfície externa ao mesmo tempo. Nomeie um único responsável e inclua a cláusula de agilidade criptográfica na política de criptografia, enquanto habilita a troca de chaves híbrida nos endpoints TLS públicos. A troca de chaves vem primeiro porque o tráfego gravado é protegido apenas pela troca de chaves, e é isso que faz do harvest now, decrypt later (coletar agora, decifrar depois) um risco presente, e não futuro.

As assinaturas precisam migrar ao mesmo tempo que a troca de chaves?

Não. Uma assinatura protege a autenticidade de um handshake ou de um artefato no momento em que ele ocorre, portanto um adversário não pode forjá-la retroativamente a partir de uma gravação. É por isso que a troca de chaves híbrida é a prioridade e que certificados, assinatura de código e assinatura de firmware podem vir depois, segundo um cronograma planejado. As orientações federais dos EUA refletem essa ordem: estabelecimento de chaves PQC para sistemas de alto valor até o fim de 2030 e assinaturas PQC até o fim de 2031.

Que evidências devemos guardar para cada item do checklist?

Guarde um artefato por item: a versão datada da política, o inventário ou CBOM com finalidade e localização por entrada, o diff de configuração com os resultados de varredura antes e depois, as respostas escritas dos fornecedores arquivadas com o contrato, o registro de certificados e o registro da revisão anual. O requisito 12.3.3 do PCI DSS v4.0.1 espera um inventário documentado de cipher suites e protocolos revisado pelo menos a cada 12 meses, e as normas técnicas do DORA esperam uma política de criptografia e um registro de certificados. Reunir as evidências à medida que o trabalho avança custa muito menos do que reconstituí-las depois.

Um checklist de prontidão pós-quântica é exigido por lei?

O checklist em si não é. O que vários textos exigem é algo próximo: as normas técnicas de regulamentação do DORA exigem uma política de criptografia com disposições para alterar a tecnologia criptográfica conforme a criptoanálise evolui, a NIS2 exige políticas sobre o uso de criptografia, e o PCI DSS exige um inventário documentado e revisado. A maioria dos cronogramas pós-quânticos, incluindo o EU Coordinated Implementation Roadmap, as datas do NCSC do Reino Unido e o BSI TR-02102-1, são orientações ou recomendações técnicas, e não obrigações para as empresas, enquanto os requisitos de hibridização da ANSSI se aplicam dentro de seu escopo regulado. Este conteúdo é informativo e não constitui aconselhamento jurídico.

Relacionados

Relatório de prontidão pós-quântica

O documento para entregar ao seu CISO, ao seu auditor ou aos seus clientes, gerado em poucos minutos.

ANSSI e criptografia pós-quântica híbrida: o que a França espera

A hibridização é uma obrigação dentro do escopo regulado pela ANSSI e uma recomendação em todos os outros casos, com meta de qualificação em 2027 e um sinal para as compras após 2030.

Requisitos de criptografia do CRA para fabricantes de produtos

Como interpretar o requisito de confidencialidade do Cyber Resilience Act e como manter o firmware e a assinatura de atualizações substituíveis ao longo de um período de suporte longo.

Modelo de política de criptografia NIS2 para o Artigo 21(2)(h)

Uma estrutura seção por seção que você pode copiar, com as disposições pós-quânticas que mantêm a política utilizável pelos próximos dez anos.

AES: risco quântico, prazos e substitutos

Cifra simétrica padrão. O algoritmo de Grover apenas reduz pela metade a segurança efetiva: o AES-256 continua resistente à computação quântica.

ChaCha20-Poly1305: risco quântico, prazos e substitutos

Cifra autenticada moderna de 256 bits, amplamente usada no TLS 1.3 e no SSH. Não é um algoritmo aprovado pelo NIST.