How to Start Your Post-Quantum Cryptography Migration: A Practical Guide to NIST Algorithm Selection and Hybrid Deployment
A step-by-step guide for developers and security teams to begin migrating to post-quantum cryptography, covering NIST algorithm selection, hybrid deployment, and testing.
TL;DR: Start by building a cryptographic inventory of all keys and certificates. Prioritize systems handling long-lived secrets or exposed to harvest-now-decrypt-later attacks. Select NIST-standardized PQC algorithms for key encapsulation and signatures, deploy them in hybrid mode alongside classical algorithms to maintain security during transition, and rigorously test before production. Use crypto-agility to enable future algorithm swaps.
Start with a Cryptographic Inventory
Begin by discovering and cataloging every cryptographic asset in your environment—keys, certificates, and the algorithms they use—to understand your exposure and prioritize migration. This inventory is a top recommendation and is already mandated under U.S. Executive Order 14028. Without it, you cannot assess the scope of your transition or identify systems vulnerable to harvest-now-decrypt-later attacks.
Start by scanning your network for public-key cryptography usage across all protocols: TLS, SSH, VPN, code signing, and email (S/MIME). Document the algorithm, key size, and certificate lifetime for each asset. For quick manual checks, use OpenSSL to inspect a live TLS endpoint:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E "Public Key Algorithm|Not After"
This reveals the algorithm (e.g., RSA, ECDSA) and expiration date. For SSH, scan host keys with ssh-keyscan:
ssh-keyscan -p 22 example.com 2>/dev/null | ssh-keygen -lf -
Automated discovery tools like Evertrust Horizon or QRAMM’s CryptoScan can map certificates across your entire infrastructure, including cloud and IoT. They identify algorithm types, key lengths, and issuance chains, then flag assets using quantum-vulnerable algorithms (RSA, ECDSA, DSA).
Once the inventory is complete, classify systems by risk. Prioritize those that protect long-lived secrets (e.g., root CAs, code-signing keys) or are exposed to harvest-now-decrypt-later attacks—where an adversary could capture encrypted traffic today and decrypt it once a cryptographically relevant quantum computer exists. This inventory becomes the foundation for your migration strategy, enabling you to select appropriate post-quantum algorithms and plan hybrid deployments.
Understand NIST’s PQC Standards and Algorithm Selection
NIST’s first PQC standards define one key encapsulation mechanism (ML-KEM) and two digital signature schemes (ML-DSA and SLH-DSA). Use ML-KEM to replace RSA/ECDH key exchange, and ML-DSA or SLH-DSA to replace RSA/ECDSA authentication, matching the NIST security level to your data’s sensitivity and required longevity.
ML-KEM (FIPS 203) is a lattice-based KEM that establishes shared secrets. ML-DSA (FIPS 204) is a lattice-based signature scheme offering small signatures and fast verification, while SLH-DSA (FIPS 205) is a stateless hash-based signature scheme with larger signatures but conservative security assumptions. Selection depends on your use case: for TLS handshakes, ML-KEM-768 combined with ML-DSA-44 is a common starting point. For long-lived firmware signing, SLH-DSA may be preferred despite its size. The QRAMM algorithm selection guide provides detailed comparisons of key sizes, ciphertext overhead, and performance across NIST security levels.
A practical first step is to test algorithm generation with OpenSSL 3.4+ (which includes the NIST PQC algorithms) or the liboqs library. For example, to generate an ML-KEM-768 key pair:
openssl genpkey -algorithm ML-KEM-768 -out private_key.pem
To generate an ML-DSA-44 key pair:
openssl genpkey -algorithm ML-DSA-44 -out ml_dsa_private.pem
NIST security levels map to symmetric-equivalent strengths: Level 1 (AES-128), Level 3 (AES-192), and Level 5 (AES-256). Match the level to your data’s sensitivity and required protection lifespan. For most enterprise applications, Level 1 or 3 is sufficient today, but high-assurance environments should target Level 5.
Adopt a Hybrid Deployment Strategy
Adopt a hybrid deployment that pairs a classical algorithm (e.g., ECDH, RSA) with a NIST-standard PQC algorithm so that the system remains secure as long as at least one component is unbroken. This approach neutralizes harvest-now-decrypt-later threats and provides a safety net against undiscovered PQC weaknesses. Most organizations begin by enabling hybrid key exchange in TLS for public-facing services and VPNs.
Hybrid mode is the safest initial step because it preserves existing security guarantees while introducing quantum resistance. Strategy selection—staged, hybrid, or direct-to-PQC—must be driven by your risk profile, infrastructure constraints, and regulatory obligations. For example, a financial institution with long-lived data confidentiality needs may mandate hybrid everywhere, while a low-risk internal app could test pure PQC in a staging environment.
A practical starting point is configuring a web server to offer a hybrid TLS 1.3 cipher suite. The following OpenSSL command generates a self-signed certificate using the hybrid key-exchange scheme p256_kyber768, which combines ECDH with the NIST-standard ML-KEM (Kyber):
openssl req -x509 -newkey p256_kyber768 -keyout hybrid_key.pem \
-out hybrid_cert.pem -days 365 -nodes \
-subj "/CN=hybrid-test.example.com"
This single certificate enables both classical and PQC key agreement. Clients that support the hybrid scheme negotiate quantum-safe tunnels; legacy clients fall back to ECDH. For VPNs, similar hybrid configurations are available in WireGuard and OpenVPN forks that implement the same NIST-standard composites. Always test hybrid handshakes in a staging environment before production rollout, as PQC algorithms introduce larger key sizes and different performance profiles that can impact session establishment times.
Test and Validate PQC Implementations Before Production
Directly answer: You must benchmark PQC algorithms in a staging environment that mirrors production, because their larger signatures, ciphertexts, and distinct CPU/memory profiles can break existing systems if not validated before rollout. Use open-source tools like PQC-Bench to measure latency, throughput, and handshake times under realistic workloads, and confirm that your certificate lifecycle management can handle the new certificate formats.
PQC algorithms behave differently than traditional ones—signatures can be tens of kilobytes, ciphertexts larger, and key generation or encapsulation may demand more memory or CPU. A staging environment that replicates production network conditions, hardware, and traffic patterns is essential. Measure the impact on TLS handshake duration, transactions per second, and end-to-end latency. For example, use the pqc-bench tool from the QRAMM project to compare algorithm performance:
pqc-bench run --algorithms Kyber1024,Dilithium5 \
--iterations 1000 --output results.json
This command benchmarks Kyber-1024 key encapsulation and Dilithium-5 signing over 1000 iterations, producing a JSON report. Analyze the results for median and tail latencies; a common approach is to flag any operation whose p99 latency exceeds 10× the classical equivalent. Also validate interoperability by deploying hybrid certificates (e.g., X.509 with composite keys) in the staging environment and testing with all client libraries your organization uses. Ensure your CLM can issue, renew, and revoke these larger certificates without truncating fields or breaking automated workflows. Only after confirming that performance, interoperability, and lifecycle management meet your requirements should you proceed to production.
Plan for Crypto-Agility and Continuous Migration
Crypto-agility is the ability to swap cryptographic algorithms without rewriting or redesigning the application, achieved by building abstraction layers and making algorithm identifiers configurable rather than hardcoded. Adopt a structured migration framework like QRAMM, which provides continuous assessment and migration planning tools, to maintain this posture over time.
Hardcoding algorithm names (e.g., RSA2048) directly in source code creates a brittle system that requires a full emergency migration when a standard is deprecated. Instead, externalize the algorithm choice into a configuration file and reference it through a generic interface. The following example shows a simple Java properties file and a factory method that loads the algorithm identifier at runtime:
# crypto.properties
signature.algorithm=ML-DSA-65
key.agreement.algorithm=ML-KEM-768
import java.security.Signature;
import java.util.ResourceBundle;
public class CryptoFactory {
private static final ResourceBundle config = ResourceBundle.getBundle("crypto");
public static Signature getSignatureInstance() throws Exception {
return Signature.getInstance(config.getString("signature.algorithm"));
}
}
This pattern allows you to switch from a classical algorithm to a PQC one (or a hybrid) by updating the properties file alone. For a comprehensive migration, QRAMM’s framework provides a structured five-phase approach and tools like CryptoScan to continuously inventory and assess your cryptographic assets. Regularly monitor NIST’s PQC standardization process, as algorithm recommendations and parameters may be updated. A crypto-agile posture ensures you can respond to new threats or deprecations without a full-scale emergency migration.
FAQ
What is the first step in PQC migration?
Conduct a complete cryptographic inventory to identify all keys, certificates, and algorithms in use. This is mandated by U.S. Executive Order 14028 and is essential for prioritizing systems that handle long-lived secrets or are exposed to harvest-now-decrypt-later attacks.
Which NIST PQC algorithms should I choose?
NIST has standardized a key encapsulation mechanism (KEM) and two digital signature schemes. Choose the KEM for key exchange and a signature scheme for authentication. Selection depends on your performance requirements, key/signature sizes, and security level. Refer to the QRAMM algorithm selection guide for detailed comparisons.
What is hybrid cryptography and why use it?
Hybrid cryptography combines a classical algorithm (e.g., ECDH) with a PQC algorithm so that security holds if either remains unbroken. It protects against harvest-now-decrypt-later attacks and provides a safety net during the transition.
How do I test PQC implementations?
Test in a staging environment before production. PQC algorithms have larger signatures and different performance profiles. Use benchmarking tools like PQC-Bench to measure impact on latency and throughput, and validate interoperability with existing systems.
Is PQC migration a one-time project?
No. It requires crypto-agility—the ability to swap algorithms without system redesign. Plan for continuous monitoring and future updates as standards evolve, using frameworks like QRAMM for ongoing assessment.
References for further reading
Sources consulted while researching this guide, included so you can verify the details and go deeper. Listing them is not a claim that every line was independently fact-checked.
- PQC Migration Playbook | Qtonic Quantum
- Frequently Asked Questions about Post-Quantum Cryptography
- Post-Quantum Cryptography: Enterprise Auth Migration Guide, guptadeepak.com
- NIST PQC Migration Strategies: Steps, Standards & Tips
- Migration to Post-Quantum Cryptography
I packaged the setup above into a ready-to-use kit — **Post-Quantum Crypto Migration Pack: NIST Algorithm Selector + Library Support Matrix + Hybrid Deployment Checklist* — for anyone who'd rather copy-paste than wire it from scratch: https://unfairhq.gumroad.com/l/stwbkb.*
Top comments (0)