A Microsoft recomendou em 8 de outubro que organizações comecem a testar seus ecossistemas de certificados antes de adotar autenticação pós-quântica em produção. O alerta acompanha um programa piloto no qual autoridades certificadoras aprovadas podem emitir raízes e certificados experimentais baseados em ML-DSA-87. Eles não são certificados públicos confiáveis e devem permanecer em ambientes controlados.
O objetivo do piloto é encontrar incompatibilidades em uma cadeia que vai muito além do algoritmo criptográfico. Autoridades certificadoras, módulos de segurança, sistemas operacionais, bibliotecas TLS, dispositivos, proxies, aplicações e ferramentas de inspeção precisam reconhecer certificados maiores e novas assinaturas. Uma falha em qualquer ponto pode interromper autenticação ou comunicação mesmo quando a matemática está correta.
ML-DSA já é um padrão do NIST
ML-DSA é a sigla de Module-Lattice-Based Digital Signature Algorithm. O NIST publicou o algoritmo no FIPS 204, em agosto de 2024, como padrão de assinatura digital resistente a ataques de computadores quânticos de grande escala. Assinaturas digitais ajudam a detectar alterações e a autenticar quem assinou um dado.
O padrão define três conjuntos de parâmetros: ML-DSA-44, ML-DSA-65 e ML-DSA-87. O número maior representa um nível de segurança mais alto, acompanhado por chaves e assinaturas maiores. O piloto citado pela Microsoft usa ML-DSA-87 em certificados experimentais.
Pós-quântico não significa que o algoritmo usa um computador quântico. Significa que ele foi projetado para resistir a classes de ataque que poderiam se tornar práticas nesse tipo de máquina. A implantação ocorre em computadores convencionais e precisa conviver por anos com protocolos, equipamentos e aplicações existentes.
O certificado muda de tamanho e comportamento
Certificados X.509 carregam identidade, chave pública, emissor, validade e uma assinatura que permite verificar a cadeia de confiança. Quando a assinatura e a chave mudam para um esquema pós-quântico, o documento pode ficar substancialmente maior do que uma cadeia baseada em RSA ou curvas elípticas.
Esse crescimento afeta buffers, mensagens TLS, limites de hardware e tempo de processamento. Um componente antigo pode rejeitar um identificador de algoritmo desconhecido. Outro pode aceitar a sintaxe, mas falhar ao validar a assinatura. Dispositivos embarcados e módulos de segurança podem ter memória, firmware ou interfaces rígidas demais para a nova estrutura.
O problema também aparece em sistemas intermediários. Balanceadores, firewalls, proxies de inspeção, gateways de API e ferramentas de observabilidade participam do caminho de autenticação. Se apenas cliente e servidor forem atualizados, um intermediário incompatível ainda pode encerrar a conexão.
O piloto não cria confiança pública
O programa piloto da Microsoft foi lançado em 27 de agosto de 2026. Autoridades certificadoras participantes podem testar raízes e certificados com ML-DSA-87, mas a empresa ressalta que eles não devem ser usados na internet pública nem confundidos com certificados emitidos pelas hierarquias atuais.
Uma raiz experimental só se torna confiável quando é instalada deliberadamente no ambiente de teste. Essa separação evita que uma cadeia ainda em validação altere o comportamento de navegadores, sistemas e serviços públicos. Também permite remover a confiança ao fim do experimento sem afetar a infraestrutura de produção.
Para laboratórios internos, o isolamento precisa ser real. Certificados, chaves e raízes de teste não devem vazar para pipelines, imagens ou equipamentos de produção. O inventário deve registrar onde a âncora foi instalada e quem pode emitir certificados sob ela.
O inventário vem antes da troca
A primeira etapa recomendada é mapear onde certificados e assinaturas são usados. Isso inclui TLS em sites e APIs, autenticação mútua entre serviços, assinatura de código, firmware, documentos, VPNs, dispositivos, identidades de máquina e comunicação com parceiros.
O inventário precisa incluir dependências menos visíveis: bibliotecas criptográficas, versões de runtime, keystores, módulos HSM, agentes instalados, appliances, certificados incorporados a dispositivos e processos de renovação. A lista de certificados ativos não mostra sozinha quais componentes conseguem receber outro algoritmo.
Também é necessário identificar responsáveis e ciclos de atualização. Um serviço web atualizado toda semana tem caminho de migração diferente de um equipamento industrial com firmware anual ou de um dispositivo que ficará dez anos em operação. O prazo de substituição do componente pode ser maior que o prazo para mudar o algoritmo.
Testes devem cobrir a cadeia inteira
Um teste útil começa com um serviço não crítico e percorre emissão, instalação, negociação, validação, renovação e revogação. O resultado precisa ser observado no cliente, no servidor e nos intermediários. Medir apenas se uma página abriu não revela aumento de tamanho, fallback silencioso ou falhas em caminhos menos usados.
Entre os casos relevantes estão conexão inicial, retomada de sessão, rotação de certificado, cadeia incompleta, certificado expirado, revogação e recuperação depois de falha. Em autenticação mútua, cliente e servidor devem ser testados nas duas funções. APIs internas também precisam confirmar compatibilidade com SDKs e runtimes suportados.
Métricas de latência, CPU, memória, tamanho de handshake e taxa de erro ajudam a separar incompatibilidade funcional de custo operacional. A comparação deve usar a mesma aplicação e a mesma rede, alterando somente os elementos necessários da cadeia criptográfica.
Agilidade criptográfica reduz o custo da transição
Agilidade criptográfica é a capacidade de trocar algoritmos, parâmetros, chaves e certificados sem reconstruir todo o sistema. Ela depende de configuração externa, inventário confiável, rotação automatizada e contratos claros entre componentes. Um algoritmo fixado no código ou no firmware transforma uma mudança de política em projeto de substituição.
Esse trabalho não serve apenas para a transição pós-quântica. Certificados vencem, chaves vazam, autoridades mudam requisitos e algoritmos perdem força. A mesma disciplina melhora a resposta a incidentes atuais e a adoção de autenticação forte em serviços que dependem de identidade confiável.
Automação também precisa prever rollback. Se um certificado novo interromper dispositivos ou parceiros, a equipe deve restaurar temporariamente a cadeia anterior sem perder rastreabilidade. Isso exige manter chaves protegidas, períodos de sobreposição e critérios explícitos para encerrar o fallback.
Migração será gradual e híbrida
A Microsoft descreve a transição como um programa de vários anos. Durante esse período, organizações podem usar certificados e protocolos híbridos que combinam mecanismos atuais e pós-quânticos. A composição reduz o risco de depender imediatamente de um único algoritmo novo, mas aumenta tamanho, complexidade e necessidade de interoperabilidade.
Nem todo certificado precisa mudar no mesmo momento. Sistemas expostos, dados com longa vida útil e equipamentos difíceis de atualizar podem receber prioridade. Serviços com ciclos curtos e baixo impacto podem aguardar suporte estável dos fornecedores, desde que permaneçam inventariados.
A autenticação pós-quântica ainda está em fase de teste em grande parte do ecossistema de certificados. O programa da Microsoft oferece uma hierarquia controlada para encontrar incompatibilidades com ML-DSA-87, enquanto o FIPS 204 fornece o padrão criptográfico. A passagem para produção depende de suporte efetivo em toda a cadeia, política de confiança e plano de reversão, não apenas da disponibilidade do algoritmo.
