Migration of your coding to post-quantum cryptography begins with locating all the places where your application carries out encryption. Then changing the quantum-vulnerable algorithms (mainly RSA, ECDSA and the various Diffie-Hellman key exchanges) with NIST's post-quantum algorithms that are standardized, most likely first deployed in hybrid mode together with the classical ones, is the next step. It's really not about just switching a single library call, but rather it is about discovering and disentangling cryptography which has been all over your codebase, dependencies, and infrastructure over years. For most teams it is a multi-quarter project rather than a sprint.
It is developers who should be Most of all interested in this since the standards were no longer theoretical as of August 2024 when NIST published FIPS 203, 204, and 205, dealing with ML-KEM for key encapsulation, ML-DSA for signatures, and SLH-DSA as a hash-based signature backup. Tooling did not lag behind much: OpenSSL 3.5 comes with native ML-KEM and ML-DSA support, and the Open Quantum Safe project's liboqs gives you a way to try out the entire set of algorithms today. The pieces are there. What most organizations lack is the inventory work and the architecture that will enable you to actually use them.
Why You Can't Just Swap RSA for a New Algorithm
Most of us have a tendency to think of it like this. "Yes, I know. It's like upgrading a hashing function. I locate the calls, change the algorithm name, and publish it." Post-quantum migration shatters that thought process because new algorithms have different features that affect your code, your protocols, and your performance budget. ML-KEM is a key encapsulation mechanism, so it is not a drop-in replacement for RSA encryption. So, where you were using RSA to wrap a key, the API shapes will change.
Size is a major issue, by the way. Developers also tend to make this mistake. Post-quantum keys and signatures are Really larger than classical ones. Public key of ML-KEM-768 is more than 1,000 bytes versus a 32-byte X25519 key, and ML-DSA signatures go into the low thousands of bytes whereas ECDSA signature is about 64. SLH-DSA signatures can be tens of kilobytes. If your protocols consist of fixed buffer sizes, packet limits, certificates embedded in constrained spaces, or assumptions baked about the size of a signature, those assumptions will be invalidated. Embedded systems and anything communicating over low-bandwidth links will get the biggest impact. Performance also changes. But, not always the way people fear. ML-KEM for raw compute is typically faster than RSA. But bigger payloads means more data traffic and more memory usage, Because of this, the final impact varies according to your system's use of cryptography and real traffic patterns So you need to benchmark against them instead of believing a generic claim.
Building Your Cryptographic Inventory First
You can't migrate what you don't uncover, and the discovery phase is really where most of the work and most of the nasty surprises come from. The aim is to produce a cryptographic bill of materials, aka a CBOM, which lists every algorithm key certificate, and protocol your software interacts with, even those buried in dependencies you didn't write. Begin with the evident attack surfaces: TLS configuration, any direct OpenSSL, BoringSSL, or your language's crypto library invocations, JWT signing, code-signing pipelines, API authentication, and encrypted data at rest. But then dig even more, because crypto is the sort of thing that teams tend to forget. It's in container image signatures, in the libraries your own libraries depend on, in hardcoded certificates, in firmware, and even in that one microservice which was written four years ago and nobody has ever opened since.
Automated scanners that look for cryptographic API calls and analyze your dependency tree can give you a hand, but they won't catch everything, so manual review of your trust-critical paths continues to really matter. The result of this phase should be a prioritization based on data lifespan and exposure. Any piece of data encryption that needs to remain confidential beyond roughly 2030, as well as anything involved in the authentication of long-lived artifacts like firmware or root certificates, gets moved up the queue because of the harvest-now-decrypt-later threat: an attacker is able to store your encrypted traffic today and decrypt it when quantum hardware becomes available.
Session tokens that are valid for only an hour represent a Much lower priority than the encryption of the database containing records that you are legally obligated to keep for ten years.
Implementing Hybrid Cryptography in Practice
By consensus, hybrid approach is preferred in the upcoming years i.e. running a classical algorithm and a post-quantum one together, so that even if one is broken, you are still protected. With TLS, this is represented by the X25519MLKEM768 key exchange group that combines the well-known X25519 with ML-KEM-768 and it's already being supported in the current OpenSSL versions, major browsers, and Cloudflare's edge. Switching it on for your servers is in most cases a matter of configuration rather than coding, which makes it the easiest and the most effective early win opportunity.
Where you control the code, the design principle that pays off is crypto-agility: abstracting cryptographic choices behind an interface so swapping algorithms later is a configuration update, not a refactor. Hardcoding "RSA-2048" across forty files is exactly the pattern that made this migration painful in the first place, and repeating it with a post-quantum algorithm just sets up the next emergency. Centralize key and certificate management, automate rotation, and keep the algorithm choice in one place. Teams that want a structured plan beyond the code itself, covering risk prioritization and timelines, often bring in quantum strategy guidance to map the migration to their specific systems rather than improvising the sequencing.
One caution worth internalizing: the post-quantum algorithms are new, and newness carries risk. NIST's earlier candidate SIKE was broken by a classical computer in 2022 after years of analysis, which is the entire argument for hybrid deployment. You keep the battle-tested classical algorithm in the loop precisely because the new one hasn't earned decades of trust yet.
What the Timeline and Effort Actually Look Like
Generally, it could take weeks or even months for the discovery phase of a midsize application with only a few services, hybrid TLS rollout to be quite fast after inventory, and the full code-level migration of your own cryptographic usage to be possible for several quarters. Large enterprises with a high number of legacy systems are currently planning five to ten years for the complete migration, which is in line with the typical time taken by past transitions, such as the retirement of SHA-1, in the broader ecosystem. Embedded and IoT fleets take the longest for the changeover as the hardware life cycle, not the software, determines their pace.
The effort depends partly on the extent to which you have developed your own cryptographic methods rather than platforms in the first place. If you are a major user of managed services, you will be treated mainly as a vendor management issue, asking your cloud provider, CDN, and certificate authority about their post-quantum roadmaps and turning on the options as they ship. Then again, if you have your own protocols, custom handshakes, or signing infrastructure, then the work is entirely up to you and the inventory will tell you how extensive it is. The teams that come out clean are those that inventory early and crypto-agility into the design, so that when an algorithm must be changed again, and it probably will, the next migration is just a config edit rather than another multi-year project.
