PQC StatusO Artigo 21(2)(h) da NIS2 exige que as entidades essenciais e importantes tenham políticas e procedimentos relativos ao uso de criptografia e, quando adequado, de cifragem. A diretiva não prescreve modelo, lista de algoritmos nem prazo, portanto a qualidade do documento fica a seu critério. Este artigo apresenta uma estrutura seção por seção que você pode copiar, relaciona cada seção às evidências que um avaliador vai solicitar e mostra exatamente onde entram as disposições de transição pós-quântica.
O que o Artigo 21(2)(h) exige, e o que não exige
A Diretiva (UE) 2022/2555 lista, no Artigo 21(2), as medidas mínimas de gestão de riscos de cibersegurança que as entidades abrangidas devem adotar. A alínea (h) ocupa uma única linha: políticas e procedimentos relativos ao uso de criptografia e, quando adequado, de cifragem. O texto está disponível no EUR-Lex (data.europa.eu/eli/dir/2022/2555/oj). O Artigo 21(1) estabelece que todas essas medidas devem ser proporcionais ao risco enfrentado e baseadas no estado da arte.
Daí decorrem três consequências. Primeiro, a obrigação é documental e procedimental: você precisa de uma política escrita e dos procedimentos que a aplicam, não de um cipher suite específico. Segundo, como a diretiva não cita nenhum algoritmo nem tamanho de chave, a própria política precisa conter essa lista e dizer como ela evolui ao longo do tempo. Terceiro, a expressão quando adequado significa que a decisão de não cifrar algo deve ser uma decisão documentada e baseada em risco, e não uma omissão. Nossa página de referência sobre o Artigo 21(2)(h) da NIS2 reúne o texto e os marcos relacionados.
Este artigo tem caráter informativo e não constitui aconselhamento jurídico. A lei nacional de transposição, o seu setor e a sua autoridade competente determinam o que é suficiente na prática.
A estrutura de política que você pode copiar
A estrutura abaixo é um esboço de trabalho, não um requisito legal. Ela está ordenada de modo que um leitor que comece na seção 1 chegue a uma decisão sobre algoritmos aprovados na seção 5, e de modo que cada seção seguinte produza um artefato que um avaliador possa inspecionar. Uma política de oito a quinze páginas, com os parâmetros técnicos em um anexo que você pode revisar sem reaprovar o documento inteiro, costuma ser suficiente.
| # | Seção | O que estabelece |
|---|---|---|
| 1 | Finalidade e base legal | Que o documento implementa o Artigo 21(2)(h) da NIS2 conforme transposto no âmbito nacional, e lista qualquer outro regime aplicável (DORA, PCI DSS, Cyber Resilience Act, normas setoriais). |
| 2 | Escopo | Entidades, subsidiárias, ambientes (produção, teste, nuvem, OT), classes de dados e serviços de terceiros abrangidos. Exclusões nomeadas e respectivas justificativas. |
| 3 | Papéis e responsabilização | Quem é responsável pela política, quem aprova mudanças de algoritmo, quem aprova exceções, quem exerce as funções de custódia de chaves, e o envolvimento do órgão de administração esperado pela NIS2. |
| 4 | Classificação de riscos e de dados | Como o tempo de vida de confidencialidade é atribuído a cada classe de dados. É esse dado que decide quais sistemas migram primeiro. |
| 5 | Algoritmos e parâmetros aprovados | A lista permitida com parâmetros mínimos, por caso de uso: dados em trânsito, dados em repouso, assinaturas, hashing, derivação de chaves, geração de números aleatórios. |
| 6 | Algoritmos descontinuados e proibidos | O que não pode mais ser implantado, o que continua tolerado apenas para verificação legada, e a data de remoção de cada item. |
| 7 | Baselines de protocolo e configuração | Versão mínima de TLS, ordem de grupos e cipher suites, acordo de chaves SSH, configurações de VPN e de bancos de dados. Uma baseline por família de plataforma. |
| 8 | Gestão de chaves | Geração, distribuição, armazenamento, rotação, custódia (escrow), arquivamento e destruição, com os requisitos de hardware para cada classe de chave. |
| 9 | Gestão de certificados | Autoridade emissora, validade máxima, automação da renovação, revogação e um registro de certificados com seus responsáveis. |
| 10 | Inventário criptográfico | O que é inventariado (algoritmo, parâmetros, biblioteca e versão, sistema, responsável, classe de dados), como é coletado e com que frequência é atualizado. |
| 11 | Agilidade criptográfica e transição pós-quântica | As condições de acionamento, a sequência de migração e as datas-alvo. Veja a próxima seção. |
| 12 | Requisitos para fornecedores e aquisições | Cláusulas exigidas de fornecedores e provedores de nuvem: divulgação dos algoritmos em uso, suporte a troca de chaves híbrida, aviso prévio de mudanças criptográficas. |
| 13 | Exceções | Formato da solicitação, nível de aceitação de risco exigido, controles compensatórios, data de expiração obrigatória, registro central. |
| 14 | Monitoramento, testes e revisão | Periodicidade das varreduras externas e internas, detecção de desvios de configuração e o ciclo de revisão da própria política. |
| 15 | Tratamento de incidentes criptográficos | O que fazer em caso de comprometimento de chave, emissão indevida de certificado ou publicação de um ataque prático contra um algoritmo aprovado, incluindo os vínculos com o processo de notificação de incidentes da NIS2. |
Seção 5: o que a lista aprovada deve conter
Cite normas finais e informe parâmetros. Para encapsulamento de chaves, o ML-KEM está padronizado no NIST FIPS 203, publicado como norma final em 13 de agosto de 2024, juntamente com o ML-DSA no FIPS 204 e o SLH-DSA no FIPS 205 (csrc.nist.gov/pubs/fips/203/final). Para proteção simétrica, o AES-256 é preferível para dados de longa duração: algoritmos simétricos e funções hash não são quebrados pelo algoritmo de Shor, e o algoritmo de Grover é o motivo pelo qual se escolhe o tamanho de chave maior. Se você opera na Alemanha, a BSI TR-02102-1 (versão 2026-01, publicada em 23 de janeiro de 2026) é uma diretriz técnica que recomenda o acordo de chaves pós-quântico híbrido e RSA de pelo menos 3000 bits, e recomenda o acordo de chaves clássico isolado somente até o fim de 2031, ou até o fim de 2030 para necessidades de proteção muito elevadas. Diretrizes desse tipo são recomendações, não obrigações, a menos que sua lei nacional ou um contrato as torne vinculantes.
Seção 6: o que proibir explicitamente
O RC4 é proibido no TLS pela RFC 7465. MD5 e SHA-1 estão obsoletos para assinaturas. O DSA não é mais aprovado para geração de assinaturas segundo o FIPS 186-5 e só pode ser usado para verificar assinaturas legadas. Os grupos TLS Kyber pré-padronização, como o X25519Kyber768Draft00 no codepoint 0x6399, estão obsoletos e devem ser removidos em favor dos grupos ML-KEM registrados. Acrescente uma data de remoção a cada linha; caso contrário, a seção vira uma lista de desejos.
Seção 11: as disposições de transição pós-quântica
A NIS2 não menciona a criptografia pós-quântica. O motivo para incluí-la mesmo assim é o harvest now, decrypt later (coletar agora, decifrar depois): o tráfego gravado hoje é protegido apenas pela troca de chaves que o negociou, de modo que uma sessão capturada agora poderá ser decifrada mais tarde se a troca de chaves for vulnerável a computadores quânticos. É por isso que a troca de chaves híbrida vem primeiro e que assinaturas e certificados podem migrar depois. Observe que a COM(2026) 13, publicada em 20 de janeiro de 2026, é uma proposta da Comissão Europeia para alterar a NIS2 de modo que as estratégias nacionais incluam uma política de transição pós-quântica. Trata-se de uma proposta, ainda não adotada, e ela se dirige às estratégias dos Estados-Membros em vez de impor uma obrigação direta às entidades (EUR-Lex CELEX 52026PC0013).
Registre quatro elementos nesta seção. Primeiro: o requisito de inventário, atualizado em uma periodicidade definida, já que não é possível migrar o que não se consegue listar. Segundo: a sequência, troca de chaves antes de assinaturas, serviços expostos externamente antes dos internos, dados de confidencialidade longa primeiro. Terceiro: as datas de referência com as quais você decide se alinhar, identificadas pelo que realmente são. O EU Coordinated Implementation Roadmap v1.1 (publicado em 23 de junho de 2025) é uma orientação coordenada para os Estados-Membros, não um regulamento vinculante para empresas: ele define primeiros passos que incluem um inventário criptográfico e roteiros nacionais até o fim de 2026, a migração dos casos de uso de alto risco até o fim de 2030 e dos de médio risco até o fim de 2035, com os de baixo risco na medida do possível (nosso resumo e a página na biblioteca da Comissão Europeia). O NIST IR 8547 continua sendo um rascunho público inicial, publicado em 12 de novembro de 2024: ele propõe descontinuar os algoritmos vulneráveis a computadores quânticos com segurança de 112 bits após 2030 e proibir todos os algoritmos de chave pública vulneráveis a computadores quânticos após 2035. Cite-o como rascunho. Quarto: a cláusula de agilidade, ou seja, as condições técnicas e contratuais sob as quais você pode trocar de algoritmo sem redesenhar o sistema.
A baseline que deve constar do anexo é curta. Grupo híbrido primeiro, fallback clássico mantido, testado em homologação antes da produção:
# OpenSSL 3.5 or later is required for the ML-KEM TLS groups
# openssl.cnf, ssl_conf section: hybrid first, classical fallback retained
Groups = X25519MLKEM768:SecP256r1MLKEM768:X25519:P-256O X25519MLKEM768 está registrado pela IANA em 0x11EC (4588), o SecP256r1MLKEM768 em 0x11EB (4587) e o SecP384r1MLKEM1024 em 0x11ED (4589); o registro de parâmetros TLS da IANA é a fonte oficial (iana.org). A RFC 10024 (agosto de 2026) especifica o acordo de chaves híbrido pós-quântico e tradicional para o TLS 1.3. As versões atuais do Chrome, do Edge e do Firefox já oferecem o X25519MLKEM768 por padrão, portanto habilitá-lo normalmente é imperceptível para os usuários. No lado do SSH, o OpenSSH 10.0 (9 de abril de 2025) tornou o mlkem768x25519-sha256 o acordo de chaves padrão, e o OpenSSH 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico.
Da cláusula da política à evidência
Um avaliador lê a política e depois pede provas de que ela é aplicada. Definir o artefato no momento da redação custa menos do que reconstruí-lo depois. A coluna da direita abaixo é a nossa interpretação das boas práticas, não um requisito literal do Artigo 21(2)(h).
| Cláusula da política | Evidência a manter |
|---|---|
| Algoritmos e parâmetros aprovados | Política assinada com histórico de versões e o registro de aprovação da última alteração. |
| Inventário criptográfico | Exportação datada do inventário com o responsável pelo sistema em cada entrada. Um CBOM (cryptographic bill of materials, ou lista de materiais criptográficos) é uma forma prática de produzi-lo, conforme descrito em nossa nota sobre o que é um CBOM. |
| Baselines de protocolo | Registros de gestão de configuração e resultados de varredura externa para cada endpoint público. |
| Gestão de chaves e certificados | Registro de chaves, logs de rotação e um registro de certificados com datas de expiração e responsáveis. |
| Exceções | Registro de exceções com aceitação de risco, controle compensatório e data de expiração. |
| Periodicidade de revisão | Ata da última revisão e a lista de alterações resultante. |
| Transição pós-quântica | Plano de migração com responsáveis e datas-alvo, e um relatório de progresso em relação a ele. |
A NIS2 não define frequência de revisão. Se você também está no escopo do PCI DSS v4.0.1, o requisito 12.3.3 exige que os cipher suites e protocolos em uso sejam documentados e revisados pelo menos a cada 12 meses, incluindo uma estratégia documentada para mudanças previstas nas vulnerabilidades criptográficas, obrigatória desde 31 de março de 2025. Adotar uma periodicidade de doze meses para toda a política é uma baseline única defensável. As entidades financeiras devem alinhar o mesmo documento com o DORA: o Artigo 6 do Regulamento Delegado (UE) 2024/1774 da Comissão exige uma política de cifragem e de controles criptográficos que inclua disposições para atualizar ou substituir a tecnologia criptográfica com base na evolução da criptoanálise, e o Artigo 7 exige a gestão de chaves ao longo de todo o ciclo de vida, além de um registro de certificados para os ativos de TIC que suportam funções críticas ou importantes. Nosso guia sobre a política de cifragem do DORA segundo o Artigo 6 aborda a redação mais prescritiva, e um único documento pode atender aos dois regimes se a seção de escopo for explícita.
Transposições nacionais e o que evitar
A NIS2 é uma diretiva, portanto produz efeitos por meio da legislação nacional. Atos de transposição, orientações das autoridades nacionais e atos de execução podem acrescentar detalhes: uma estrutura de política exigida, diretrizes nacionais de referência específicas, frequências de revisão determinadas ou formatos de notificação. Esses detalhes variam conforme o Estado-Membro e o setor, então consulte as orientações publicadas pela sua autoridade nacional antes de finalizar o documento. Não presuma que o mínimo da diretiva é o seu teto.
Vale a pena apontar quatro fragilidades frequentes. Uma política que lista algoritmos, mas nenhuma data de remoção, não pode ser auditada. Uma política sem processo de exceção empurra as equipes para a não conformidade silenciosa. Uma política que cita um produto de fornecedor em vez de uma família de algoritmos deixa de funcionar na próxima migração. E uma política que alega prontidão pós-quântica sem um inventário não consegue mostrar quais sistemas estão envolvidos. Mantenha as ressalvas precisas também no documento: uma norma em rascunho é um rascunho, e uma recomendação de uma agência nacional não é uma obrigação, a menos que o seu escopo a torne uma. A ANSSI, por exemplo, afirma que a hibridização é obrigatória dentro do seu escopo regulado (qualificação de produtos, área de defesa, SAIV e SIIV), enquanto suas recomendações pós-quânticas mais amplas ainda não são obrigações regulatórias nos demais casos.
Próximo passo: meça o que a sua política afirma
A seção 7 da estrutura é a única parte da política que um terceiro pode verificar de fora, então verifique-a você mesmo primeiro. Faça a varredura do seu domínio com o PQC Status para ver as versões de TLS, os cipher suites, o suporte a grupos híbridos ML-KEM e a cadeia de certificados que os seus endpoints públicos realmente negociam, e depois anexe o resultado ao anexo de baselines como evidência datada dessa cláusula. Uma varredura descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade. Execute-a em todos os hostnames públicos, registre as lacunas no registro de exceções com uma data de expiração, e a seção pós-quântica da sua política deixa de ser apenas uma aspiração.