performing-post-quantum-cryptography-migration

name	performing-post-quantum-cryptography-migration
description	Assesses organizational readiness for post-quantum cryptography migration per NIST FIPS 203/204/205 standards. Performs cryptographic inventory scanning to identify quantum-vulnerable algorithms (RSA, ECDH, ECDSA), evaluates hybrid TLS configurations with X25519MLKEM768, and validates CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) readiness. Implements crypto-agility assessment using oqs-provider for OpenSSL. Use when planning or executing the transition from classical to post-quantum cryptographic algorithms across enterprise infrastructure.
domain	cybersecurity
subdomain	cryptography
tags	["post-quantum","PQC","CRYSTALS-Kyber","ML-KEM","ML-DSA","FIPS-203","FIPS-204","hybrid-TLS","crypto-agility"]
version	1.0
author	mukul975
license	Apache-2.0
nist_csf	["PR.DS-01","PR.DS-02","PR.DS-10"]

Performing Post-Quantum Cryptography Migration

When to Use

• When assessing organizational readiness for the NIST post-quantum cryptography transition
• When building a cryptographic inventory to identify quantum-vulnerable algorithms across infrastructure
• When evaluating hybrid TLS 1.3 configurations using X25519MLKEM768 key exchange
• When testing CRYSTALS-Kyber (ML-KEM) and CRYSTALS-Dilithium (ML-DSA) algorithm support
• When implementing crypto-agility to support both classical and post-quantum algorithms
• When preparing migration roadmaps aligned with NIST IR 8547 deprecation timelines
• When configuring oqs-provider with OpenSSL 3.x for post-quantum algorithm support

Common Misconfigurations & Verification

• PQC-only instead of hybrid: deploying ML-KEM alone (not X25519MLKEM768) during the transition removes the classical safety net if the lattice scheme is later broken. Always negotiate a hybrid group; verify with openssl s_client -groups X25519MLKEM768 -connect host:443 that the negotiated group is the hybrid, not a fallback to x25519.
• Silent downgrade to classical: a server that advertises hybrid but selects ECDH for most clients still leaves traffic quantum-vulnerable. Confirm the ServerHello selected_group is the hybrid and that classical-only fallback is intentional, not accidental.
• Inventory blind spots: scans that cover TLS but miss code-signing keys, SSH, S/MIME, VPN/IPsec, embedded firmware, and HSM/KMS-held keys. "Harvest now, decrypt later" makes long-lived data the top migration priority — confirm those channels are in the inventory.
• Wrong security level / non-FIPS params: using ML-KEM-512 where Level 3 (ML-KEM-768) is required, or a pre-standard "Kyber" build instead of FIPS-203 ML-KEM. Pin standardized parameter sets.
• Capacity not planned: larger ML-KEM/ML-DSA keys and signatures can exceed MTU/record/cert-store limits; benchmark handshake cost under load.
• Verification: assert all quantum-vulnerable algos (RSA, ECDH, ECDSA, DH, DSA) are enumerated; ML-KEM encapsulate→decapsulate yields matching 32-byte secrets; an ML-DSA signature over a tampered message is REJECTED; CA/HSM/KMS PQC support is confirmed before declaring readiness.

Prerequisites

• Python 3.8+ with cryptography, requests, pyOpenSSL libraries
• OpenSSL 3.0+ (3.5+ recommended for native ML-KEM/ML-DSA support)