How to Implement PQC in Your Organization

Why Post-Quantum Migration Cannot Wait

The transition from classical cryptography to post-quantum cryptography (PQC) is one of the largest coordinated technology upgrades in history. Every organization that uses public-key cryptography, which is effectively every organization, will need to migrate. The question is not whether to migrate, but when and how.

The urgency comes from two directions. First, the "Harvest Now, Decrypt Later" threat means that encrypted data intercepted today can be stored and decrypted once a sufficiently powerful quantum computer becomes available. If your organization handles data that must remain confidential for 10 or more years (medical records, financial data, trade secrets, classified information), the window to act is already closing.

Second, regulatory pressure is mounting. In the United States, the Office of Management and Budget issued Memorandum M-23-02 in November 2022, requiring federal agencies to submit cryptographic system inventories. NIST published Special Publication 1800-38, "Migration to Post-Quantum Cryptography," providing detailed migration guidance. CISA launched its Post-Quantum Cryptography Initiative to coordinate federal transition efforts. In Europe, ETSI published TR 103 619, "Migration Strategies and Recommendations to Quantum Safe Schemes."

This guide presents a practical, seven-step approach to implementing post-quantum cryptography in your organization, drawing on published guidance from NIST, CISA, the NSA (CNSA 2.0 Suite), and ETSI.

Step 1: Conduct a Cryptographic Inventory

Before you can migrate, you need to know what you are migrating from. NIST SP 1800-38 identifies cryptographic discovery as the essential first step. A cryptographic inventory catalogs every place your organization uses public-key cryptography.

This includes:

• TLS/SSL certificates protecting web services, APIs, and internal communications
• VPN tunnels using IKE with RSA or ECDH key exchange
• Code signing certificates for software distribution
• Email encryption using S/MIME or PGP with RSA or ECC keys
• SSH keys used for server access and automation
• Database encryption at rest and in transit
• Data encryption for sensitive documents and backups
• Hardware security modules (HSMs) and key management systems
• Embedded and IoT devices with firmware signing or encrypted communications

For each system, record the algorithms in use (RSA-2048, ECDSA P-256, ECDH, DH, etc.), the key sizes, the protocol versions, and the data sensitivity level. Automated scanning tools can help with discovery, but manual review is also necessary, especially for custom applications and legacy systems.

Step 2: Assess Risk and Prioritize

Not all systems face equal quantum risk. Prioritization should be based on two factors: the sensitivity of the data and how long it must remain confidential.

Data with a long confidentiality requirement is the most urgent to protect. Healthcare records, for example, may need to remain confidential for decades. Financial records, trade secrets, and government classified data often have similar long-term requirements. If the data will still be sensitive 10 or 15 years from now, and an adversary could intercept it today, PQC protection is already overdue.

Systems with high exposure to interception, such as internet-facing TLS endpoints and VPN gateways, should also be prioritized, since they are the most likely targets for "harvest now, decrypt later" collection.

A practical risk matrix considers:

• Data retention period. How long must this data remain confidential?
• Interception exposure. Does this data traverse public networks?
• Threat actor capability. Are nation-state adversaries a plausible concern?
• Replacement complexity. How difficult is it to upgrade this system?

Systems that score high on sensitivity and exposure but low on replacement complexity are natural candidates for early migration.

Step 3: Choose a Migration Strategy

There are three broad approaches to PQC migration. The hybrid approach is recommended by NIST, the NSA (in the CNSA 2.0 Suite guidance), and ETSI.

Option A: Hybrid (Recommended). Layer post-quantum algorithms on top of existing classical algorithms. An attacker must break both the classical and the post-quantum algorithm to compromise the data. If a weakness is discovered in a PQC algorithm, the classical algorithm provides a safety net. If a quantum computer breaks the classical algorithm, the PQC algorithm provides protection. This belt-and-suspenders approach is the safest path forward.

Option B: Full Replacement. Replace classical algorithms entirely with post-quantum alternatives. This is simpler but riskier. If a PQC algorithm is found to have an unexpected weakness (as happened with SIKE, which was broken in 2022 after reaching the fourth round of the NIST standardization process), there is no fallback.

Option C: Phased Replacement. Migrate different systems at different times, starting with the highest-risk systems. This is a scheduling strategy rather than a technical one, and it can be combined with either hybrid or full replacement.

For most organizations, the recommended path is hybrid migration deployed in phases. Start with the highest-risk systems, layer PQC on top of classical crypto, and proceed to lower-risk systems over time.

Step 4: Select Standards-Compliant Algorithms

NIST finalized the first set of post-quantum cryptographic standards in August 2024. These are the algorithms your organization should adopt:

Standard	Algorithm	Purpose	Based On
FIPS 203	ML-KEM (Kyber)	Key encapsulation	Module lattices
FIPS 204	ML-DSA (Dilithium)	Digital signatures	Module lattices
FIPS 205	SLH-DSA (SPHINCS+)	Digital signatures	Hash functions

For key encapsulation (establishing shared secrets), ML-KEM is the primary standard. It comes in three security levels: ML-KEM-512 (128-bit security), ML-KEM-768 (192-bit security), and ML-KEM-1024 (256-bit security).

For digital signatures, ML-DSA is the general-purpose choice. SLH-DSA offers an alternative based on different mathematical foundations (hash functions rather than lattices), providing algorithm diversity.

In a hybrid configuration, these PQC algorithms are combined with classical counterparts: ML-KEM with X25519 or ECDH for key exchange, and ML-DSA with Ed25519 or ECDSA for signatures. The combined output ensures security against both classical and quantum attacks.

Step 5: Test in Non-Production Environments

Post-quantum algorithms have different performance characteristics than classical algorithms. Before deploying to production, thorough testing is essential.

Key and signature sizes. PQC algorithms generally produce larger keys and signatures than their classical counterparts. An ML-KEM-1024 public key is 1,568 bytes, compared to 32 bytes for X25519. An ML-DSA-65 signature is 3,309 bytes, compared to 64 bytes for Ed25519. These larger sizes can affect network protocols, certificate chains, and storage systems.

Performance impact. Key generation, encapsulation, and signing times differ from classical algorithms. In most cases, ML-KEM is comparable to or faster than RSA for key exchange. ML-DSA signature verification is fast, but key generation is slower than Ed25519. Test with representative workloads to understand the impact on your specific systems.

Protocol compatibility. Some protocols have message size limits or handshake constraints that may need adjustment for PQC. TLS 1.3 hybrid key exchange, for example, increases the ClientHello size significantly. Ensure that firewalls, load balancers, and middleware can handle the larger messages.

Integration testing. Verify that all components in the communication chain support the PQC algorithms. A single legacy component that cannot handle PQC can break the entire chain.

Step 6: Deploy Hybrid First

With testing complete, begin production deployment using the hybrid approach. Layer PQC algorithms on top of your existing classical algorithms rather than replacing them.

For data encryption, this means combining ML-KEM with X25519 for key exchange and using AES-256-GCM for symmetric encryption. The shared secret from both ML-KEM and X25519 is combined (typically through a key derivation function) to produce the final encryption key. An attacker must break both key exchanges to recover the key.

For digital signatures, this means producing both an ML-DSA signature and an Ed25519 signature over the same data. Verification requires both signatures to be valid.

Start with the systems you identified as highest priority in Step 2. Monitor closely for performance regressions, compatibility issues, and operational problems. Document everything, as the lessons learned from early deployments will inform the rest of the migration.

Rollback plans are essential. If a PQC deployment causes unexpected issues, you need the ability to revert to classical-only operation quickly. The hybrid approach makes this easier, since the classical layer is already present and functional.

Step 7: Monitor and Update

Post-quantum cryptography is an evolving field. NIST continues to evaluate additional algorithms for standardization. The cryptographic research community continues to analyze the security of the standardized algorithms. Your PQC deployment should include processes for:

• Tracking NIST updates. NIST may publish additional PQC standards, updated parameter recommendations, or security advisories.
• Monitoring the research community. Academic papers analyzing PQC algorithms are published regularly. Stay aware of any advances that affect the algorithms you have deployed.
• Crypto agility. Design your systems so that algorithms can be replaced without a complete overhaul. This is valuable regardless of the quantum threat, as cryptographic best practices evolve over time.
• Regular re-assessment. Revisit your cryptographic inventory periodically to ensure new systems are covered and that your risk assessments remain current.

Common Challenges and How to Address Them

Larger Key and Signature Sizes

PQC algorithms produce significantly larger keys and signatures. This can affect bandwidth, storage, and protocol compliance. The practical solution is to evaluate the impact system by system. For data encryption, the overhead is negligible relative to file sizes. For protocols with tight size constraints (such as DNS or some IoT protocols), more careful engineering is required.

Performance Overhead

While PQC algorithms are generally fast in absolute terms, they can be slower than optimized classical implementations. ML-KEM encapsulation and decapsulation are fast. ML-DSA signing and verification are also efficient. The performance impact is typically small for most applications, but high-throughput servers handling thousands of TLS handshakes per second should benchmark carefully.

Library and Tooling Availability

PQC library support has improved significantly since the NIST standards were finalized, but coverage is not yet universal. Major cryptographic libraries (OpenSSL, BoringSSL, liboqs) now include PQC algorithm support. However, some platforms, languages, and frameworks may lag behind. Evaluate your technology stack early to identify gaps.

Staff Training

Your security and engineering teams need to understand PQC concepts, the reasons for migration, and the operational differences from classical cryptography. Invest in training early. Misconfigurations during migration can introduce vulnerabilities that undermine the entire effort.

Legacy System Compatibility

Some legacy systems cannot be upgraded to support PQC. For these, consider network-level protections (such as PQC-enabled VPN tunnels) that can shield legacy systems without modifying them directly. Plan for eventual replacement of systems that cannot be adequately protected.

How QNSQY Fits Into Your Migration

QNSQY provides a ready-to-use implementation of all NIST-standardized post-quantum algorithms, combined with classical cryptography in a hybrid configuration. It supports ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), always paired with X25519 and Ed25519 for defense in depth.

For organizations beginning their PQC migration, QNSQY addresses several common pain points:

• No library integration required. QNSQY is a standalone tool. You do not need to integrate a PQC library into your codebase to start protecting files.
• Hybrid by default. Every encryption and signing operation uses hybrid PQC plus classical cryptography. There is no way to accidentally deploy PQC-only without a classical fallback.
• Cryptographic inventory support. The qnsqy scan command can identify files encrypted with classical-only algorithms, helping you build your cryptographic inventory.
• Migration tooling. The qnsqy migrate command helps transition files from classical encryption to post-quantum hybrid encryption.
• All tiers include PQC. Even the free tier uses ML-KEM-512 hybrid encryption. PQC protection is not gated behind a paywall.

To learn more about the algorithms QNSQY uses, see our guides on post-quantum cryptography and the NIST FIPS standards.

Sources

• NIST SP 1800-38: Migration to Post-Quantum Cryptography
• OMB Memorandum M-23-02: Migrating to Post-Quantum Cryptography (November 2022)
• CISA Post-Quantum Cryptography Initiative
• NSA CNSA 2.0 Suite Announcement
• ETSI TR 103 619: Migration Strategies and Recommendations to Quantum Safe Schemes
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)

Related Articles

• NIST FIPS 203/204/205: The Complete Guide
• Post-Quantum Encryption for Healthcare and HIPAA
• Post-Quantum Cryptography for Government and Defense
• Why Hybrid Encryption Matters