The NIST post-quantum cryptography standards are finalized. The first commercial quantum computers capable of threatening production cryptographic systems are projected within the decade by multiple intelligence agencies. And adversaries — primarily nation-state actors — have been conducting harvest-now-decrypt-later operations for years, stockpiling encrypted communications to decrypt when quantum hardware matures.
This is not a future problem. For any data that must remain confidential for five or more years, the quantum threat is already active. The question is no longer whether to migrate to post-quantum cryptography, but how to do it without breaking your systems, missing compliance deadlines, or creating new vulnerabilities in the migration process itself. This is your operational guide.
Where We Are in 2026
The cryptographic landscape shifted decisively in 2024 when NIST finalized its first post-quantum standards. As of early 2026, the operational status is:
- ML-KEM (FIPS 203): Finalized. The primary standard for key encapsulation. Now required by several federal agencies and increasingly specified in enterprise procurement requirements
- ML-DSA (FIPS 204): Finalized. The primary standard for digital signatures. TLS 1.3 with ML-DSA certificates is now supported by all major browsers
- SLH-DSA (FIPS 205): Finalized. The backup signature scheme based on hash functions. Larger signatures but no dependence on lattice assumptions
- TLS 1.3 hybrid mode: Now widely deployed by major cloud providers. Combines X25519 (classical) with ML-KEM-768 (post-quantum) for forward security during the transition
- SSH post-quantum support: OpenSSH 10.x supports hybrid key exchange. Most enterprise SSH deployments are behind on this
Intelligence community estimates place cryptographically relevant quantum computers (CRQCs) between 5 and 15 years away. But data encrypted today with RSA-2048 and transmitted over the internet is being stored by adversaries right now. If that data has a sensitivity lifetime of 10 years, the threat is already in effect.
The Migration Challenge Is Not the Algorithm
Security engineers often focus the post-quantum migration discussion on algorithm selection — which lattice scheme, which parameter set, which hybrid configuration. This is the easy part. The hard part is everything else: finding every place cryptography is used in your organization, understanding the protocol and operational constraints at each location, executing the migration without causing outages, and maintaining crypto agility so future algorithm updates are manageable.
The Cryptographic Inventory Problem
Most large organizations cannot accurately enumerate their cryptographic dependencies. Cryptography appears in TLS configurations, certificate authorities, PKI infrastructure, encrypted storage, API authentication, service-to-service communication, code signing, document signing, VPN configurations, embedded device firmware, and dozens of application-specific implementations. Getting a complete inventory is itself a significant project.
Tools that help: certificate transparency log analysis, network traffic scanning for TLS handshake parameters, static analysis of codebases for cryptographic API calls, and cloud provider cryptographic asset inventories. None of these are complete on their own; a thorough inventory requires all of them working together.
Migration Priority Framework
Not all cryptographic uses are equal. Prioritize migration based on two dimensions: data sensitivity (how damaging is exposure?) and data longevity (how long must it remain confidential?). This creates a 2x2 that drives sequencing:
- High sensitivity + long longevity: Migrate immediately. Government communications, trade secrets, long-term financial data, strategic plans. These are actively targeted by harvest-now-decrypt-later operations
- High sensitivity + short longevity: Migrate soon. Payment card data, session tokens, ephemeral secrets. Less urgent but still priority
- Low sensitivity + long longevity: Migrate in scheduled cycles. Public-facing certificates, content signing. Lower urgency but needs to be tracked
- Low sensitivity + short longevity: Migrate as part of standard infrastructure refresh. No urgency
Hybrid Cryptography: The Practical Path
Deploying pure post-quantum cryptography in 2026 creates compatibility problems with legacy systems and introduces risk if a newly standardized algorithm is found to have unexpected weaknesses. The operational recommendation is hybrid cryptography: combine a proven classical algorithm with a post-quantum algorithm such that the session is secure as long as either holds.
# TLS 1.3 Hybrid Configuration (nginx)
ssl_protocols TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
# Hybrid key exchange: X25519 + ML-KEM-768
# Both must be compromised to break confidentiality
ssl_ecdh_curve x25519mlkem768:x25519:secp384r1;
# Certificate: hybrid classical + post-quantum signature
# Enables PQ verification while maintaining classical fallback
ssl_certificate /etc/ssl/hybrid-ecdsa-mldsa.pem;
ssl_certificate_key /etc/ssl/hybrid-ecdsa-mldsa-key.pem;
# Session ticket encryption should also use PQ-safe keys
ssl_session_ticket_key /etc/ssl/pq-session-ticket.key;The Certificate Authority Transition
Your internal certificate authority is a critical migration point that organizations frequently underestimate. Every certificate your CA issues inherits the cryptographic properties of the CA itself. An RSA-2048 CA signing post-quantum end-entity certificates provides weaker security guarantees than the post-quantum certificates suggest — the chain is only as strong as its weakest link.
The CA migration path:
- Deploy a new PQ root CA alongside your existing classical root. Do not replace — both must coexist during transition
- Cross-sign: Have your existing classical root sign your new PQ root, and vice versa. This creates trust chains that work on both classical and PQ-aware clients
- Issue hybrid leaf certificates: Certificates that contain both a classical and a PQ public key. Clients use whichever they support
- Monitor adoption: Track what percentage of your clients are successfully verifying PQ signatures. Only sunset classical infrastructure when adoption reaches acceptable thresholds
Building Crypto Agility into Your Systems
The most important long-term investment is not migration to any specific post-quantum algorithm — it is building systems that can swap cryptographic algorithms without architectural changes. The post-quantum standards will evolve. Algorithms that are secure today may be weakened by cryptanalytic advances. Organizations with crypto-agile systems can respond to these developments in days; those without crypto agility face months-long remediation projects each time the cryptographic landscape shifts.
Crypto agility requires: centralized cryptographic policy management (not hardcoded algorithm choices in application code), abstraction layers that separate cryptographic operations from application logic, automated certificate and key rotation infrastructure, and cryptographic algorithm versioning in protocol negotiation. This is an architectural investment that pays dividends across every future cryptographic transition your organization faces.
The organizations beginning their post-quantum migrations now will complete them calmly, methodically, and with time to address edge cases. Those that wait will be forced to rush — and rushed cryptographic migrations are how breaches happen. Contact us for a quantum readiness assessment and migration roadmap tailored to your infrastructure.