POST-QUANTUM CRYPTOGRAPHYMIGRATION

Post-quantum cryptography migration is the most consequential cryptographic transition since the move from DES to AES. Every application that relies on RSA, ECDSA, Diffie-Hellman, or ECDH for key exchange or digital signatures needs to be upgraded. The National Institute of Standards and Technology finalized the first three post-quantum standards in August 2024, and the National Security Agency has set a 2035 deadline for National Security Systems to complete the transition. For organizations under the Cybersecurity Maturity Model Certification program, for federal contractors, for healthcare providers with long-lived protected health information, and for financial institutions with long-retention records, 2035 is closer than it looks.

Petronella Technology Group guides organizations through the full migration lifecycle. We start with a quantum readiness assessment to build a cryptographic inventory, then design the phased rollout, validate the architecture against NIST guidance, and support production deployment across your tech stack. We have been doing cryptography work for regulated clients since 2002 and have been following the post-quantum standardization process since the first NIST call for proposals in 2016.

What makes this transition different from prior algorithm migrations is the sheer number of places cryptography lives in a modern enterprise. TLS certificates, code signing keys, document signing, VPNs, SSH, hardware security modules, cloud key management services, application-layer encryption, payment processing, and dozens of third-party dependencies all need to be planned for. The work is manageable when sequenced well and painful when rushed at the last minute. Our job is to make sure your organization ends up in the first category.

ML-KEM (FIPS 203, originally CRYSTALS-Kyber)

ML-KEM is the lattice-based key encapsulation mechanism that will replace RSA and ECDH for key exchange in TLS, SSH, VPN, and other protocols. It is fast, with competitive performance against classical algorithms, but the public keys and ciphertexts are larger than RSA or elliptic-curve equivalents. ML-KEM comes in three parameter sets. ML-KEM-512 targets roughly AES-128 security, ML-KEM-768 targets AES-192 security, and ML-KEM-1024 targets AES-256 security. For most enterprise deployments, ML-KEM-768 is the sensible default. We recommend ML-KEM-1024 for long-lived data or for environments covered by NSA CNSA 2.0. Hybrid deployments that pair ML-KEM with classical X25519 or P-256 key exchange are already supported in recent versions of OpenSSL and major TLS libraries.

ML-DSA (FIPS 204, originally CRYSTALS-Dilithium)

ML-DSA is the lattice-based digital signature algorithm that replaces RSA and ECDSA signatures. Parameter sets are ML-DSA-44, ML-DSA-65, and ML-DSA-87, again mapping to roughly AES-128, AES-192, and AES-256 security. ML-DSA signatures are much larger than ECDSA, typically several kilobytes, which means certificate chains will grow and you may need to revisit protocol limits in constrained environments. Code signing, document signing, firmware signing, and certificate authority signing are all appropriate targets. We recommend ML-DSA-65 as the default for most commercial use cases and ML-DSA-87 for long-lived signatures such as root certificates or firmware.

SLH-DSA (FIPS 205, originally SPHINCS+)

SLH-DSA is a stateless hash-based signature scheme. It relies only on the security of the underlying hash function rather than any new mathematical assumption, which makes it a conservative backup option in case the lattice-based schemes are weakened in future research. Signatures are large, on the order of tens of kilobytes, and signing is slow compared to ML-DSA. For most production use SLH-DSA will be reserved for high-assurance applications such as root certificates, firmware, and long-lived signing keys where the size and speed cost is acceptable in exchange for the minimal security assumption.

FN-DSA (draft FIPS 206, originally Falcon)

FN-DSA is a lattice-based signature scheme based on NTRU lattices. It produces smaller signatures than ML-DSA, which is useful in bandwidth-constrained or size-sensitive deployments. The tradeoff is that FN-DSA implementations must handle floating-point operations carefully to avoid side-channel leakage, which makes it harder to implement safely than ML-DSA. We treat FN-DSA as the right choice for specific use cases where signature size matters more than implementation simplicity, and default to ML-DSA where either would work.

Phase 1: Inventory and Classification

You cannot migrate what you have not inventoried. The first three to four months of a realistic migration program are spent building a complete picture of where cryptography lives in your environment. TLS configurations, PKI topology, SSH key sets, VPN endpoints, hardware security modules, key management services, application-layer encryption, code signing, document signing, and third-party dependencies all need to be cataloged with algorithm, key length, rotation schedule, and data lifetime. This is the deliverable of our quantum readiness assessment engagement and it is the foundation of every downstream decision.

Phase 2: Architecture and Hybrid Design

With an inventory in hand, the next phase is designing the target state. For most enterprises, that means a hybrid model during the transition where classical and post-quantum algorithms run side by side. This preserves backward compatibility with partners and vendors who have not yet adopted post-quantum cryptography while giving you the quantum resistance you need for long-lived data. We design the abstraction layers that let applications consume cryptography without being coupled to specific algorithms, document the key management lifecycle, plan the certificate and signature strategy, and write the engineering specifications that downstream teams will execute against.

Phase 3: Pilot Implementation

We recommend piloting in a non-critical environment first. Good pilot candidates are internal TLS terminators, a subset of SSH servers, code signing for a non-customer-facing product line, or a VPN gateway serving a single business unit. The pilot validates the architectural choices, surfaces unexpected interactions with logging and monitoring, and gives your engineering team hands-on experience before a high-stakes rollout. Pilots typically run for three to six months and the lessons learned feed directly into the production rollout plan.

Phase 4: Production Rollout

Production rollout is sequenced by risk and by dependency. Certificate authority migration usually goes first because every downstream signature chain depends on the root. Public TLS follows, then internal TLS, then code signing, then document signing, then application-layer encryption. Throughout the rollout we maintain hybrid deployments so that compatibility with external partners is preserved. We track progress against a concrete milestone plan that finance and executive leadership can follow without needing to read cryptographic specifications.

Phase 5: Classical Deprecation

The last phase is turning off classical algorithms once the hybrid deployment has been stable long enough and all external dependencies have completed their own migrations. This phase is what actually gives you quantum resistance. Running only the post-quantum algorithm means that traffic captured today cannot be decrypted in the future. We hold hybrid deployments for typically one to two years after initial rollout and deprecate classical algorithms only after formal risk acceptance and verification that partner systems have kept pace.

Most TLS libraries now support hybrid key exchange that combines a classical elliptic curve algorithm with ML-KEM. Recent OpenSSL releases, the Rustls project, and the Go crypto library have either shipped or are shipping experimental hybrid support. Browser vendors including Google Chrome have been running hybrid X25519 plus ML-KEM-768 in production for public web traffic. Enterprise adoption lags public adoption by a typical margin because enterprise TLS terminators, load balancers, and reverse proxies roll out new cryptographic features on slower cycles. Our migration plan calls out the specific minimum versions required for each of your TLS-terminating products and schedules upgrades accordingly.

SSH post-quantum key exchange follows a similar pattern. OpenSSH shipped hybrid key exchange based on Streamlined NTRU Prime and X25519 starting in OpenSSH 9.0 and continued updates have aligned with the emerging IETF drafts for ML-KEM-based hybrid SSH. For environments with long-term SSH session captures, post-quantum key exchange for SSH is a high-priority quick win because it protects against harvest-now-decrypt-later attacks on administrative traffic. We recommend prioritizing SSH infrastructure in the pilot phase of migration for exactly this reason.

IPsec and WireGuard are slower-moving. IETF drafts exist for hybrid IKEv2 with post-quantum key exchange, and some commercial VPN vendors have shipped early implementations, but most enterprises will wait for standards to finalize before deploying hybrid IPsec in production. WireGuard has its own post-quantum proposals in research but has not committed to a specific standard at the library level. For VPN environments with very long-lived session captures or with particular sensitivity, we design a transition path that uses hybrid IKEv2 where supported and preserves the option to move to newer schemes as they stabilize.

Migration budgets vary widely based on environment size and legacy debt, but the cost structure is consistent. The largest line items are typically labor for architecture, engineering, and testing, followed by hardware or firmware refresh for any HSMs and network appliances that cannot run post-quantum cryptography in their current state, followed by vendor subscription changes where existing contracts need to be amended or renewed, and followed by contingency. We scope budget envelopes for each migration phase separately so finance can fund the work in tranches rather than committing to a single multi-year line item.

For a mid-sized regulated client with a few data centers, two or three clouds, and a typical payment, PKI, and identity footprint, a multi-year migration program typically runs several hundred thousand dollars total when combined across internal labor, consulting, hardware, and vendor amendments. Very small organizations with a clean, modern stack run much less, while very large enterprises with deep legacy debt run materially more. We always cost the inventory phase separately because the inventory answers the question of how big the full program actually is, and committing to a multi-year budget without an inventory is how organizations overspend.

Every migration engagement we deliver is anchored to publicly referenceable standards and guidance. We cite the full NIST Post-Quantum Cryptography Standardization project, the finalized FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, FIPS 205 for SLH-DSA, and the draft FIPS 206 for FN-DSA. For transition planning we reference NIST Special Publication 800-131A on algorithm transitions and NIST Internal Report 8547 on transition planning to post-quantum cryptography. For federal and defense clients we map to the National Security Agency Commercial National Security Algorithm Suite 2.0, which sets the 2035 deadline for National Security Systems, and we reference the Cybersecurity and Infrastructure Security Agency Post-Quantum Cryptography Initiative for critical infrastructure sector guidance.

We also track research and practice publications from the Internet Engineering Task Force, where post-quantum extensions to TLS, SSH, and IPsec are being standardized, and from the major cryptographic library projects such as OpenSSL and libsodium. Migration engagements include guidance on which IETF drafts are mature enough to deploy and which should be avoided until they stabilize.

Defense contractors have the most explicit timeline because the National Security Agency Commercial National Security Algorithm Suite 2.0 sets 2035 as the deadline for National Security Systems. Flowdown from prime contractors is likely to tighten requirements sooner. For defense clients we pair the migration with CMMC scope analysis so that Controlled Unclassified Information handling is covered end to end. See CMMC compliance for the broader framework context.

Healthcare providers face a different pressure profile. Electronic protected health information has retention requirements measured in years to decades and in some cases for the life of the patient plus a statutory period. Radiology and imaging archives commonly run longer than a human career. For healthcare clients we emphasize data-at-rest migration planning alongside the more visible network cryptography work, because the decryption risk is larger for archived data than it is for in-flight traffic that rotates keys every session.

Financial services has distinctive complications around payment processing, interbank messaging, and long-term archival. Payment card trust chains involve certificate authorities whose root signing keys are expected to last for decades. Interbank messaging over protocols with embedded cryptography has its own migration cadence set by industry consortia. For financial clients we engage with the specific card scheme, messaging network, and regulatory examiner expectations, and we phase the migration so that card processing and deposit operations are never impaired by cryptographic transition work.

State and local government, critical infrastructure operators, and legal services have their own wrinkles. Government clients often inherit federal transition deadlines through grant requirements. Utility and water system operators are governed by sector-specific CISA guidance. Legal services work with attorney-client privileged material with indefinite retention. In every case the migration methodology is the same, but the sequencing and the compliance overlay changes. We adapt the roadmap to the sector rather than running a generic playbook.

Our migration engagements are staffed by senior consultants with applied cryptography experience. Craig Petronella leads cryptography practice and holds CMMC Registered Practitioner, Certified Forensic Examiner, CCNA, and CWNE credentials. The broader team holds CMMC Registered Practitioner credentials and we are a CMMC-AB Registered Provider Organization under RPO-1449. We have been serving regulated clients in the Raleigh and Research Triangle area since 2002 and maintain a Better Business Bureau A+ accreditation in good standing.

Post-quantum migration work pairs well with our broader cybersecurity program and CMMC compliance offerings. For clients who want an all-in-one partner for regulated security operations, we run the migration as a workstream inside a larger program. For clients who want a focused engagement with internal or other third-party implementation, we scope the work as a standalone advisory and handoff.