Marin Ivezic
Twelve months will not migrate an enterprise off RSA, but it will produce four things a board can inspect: a cryptographic inventory, a working test lab, a certificate infrastructure capable of issuing post-quantum credentials, and two production services running hybrid key exchange. NIST IR 8547 is an initial public draft, Transition to Post-Quantum Cryptography Standards, and it proposes deprecating RSA-2048 and 256-bit elliptic curve cryptography after 2030 and disallowing them after 2035. If those dates hold, most organizations have a decade, and the first year of it decides whether the remaining nine are orderly.
The sequence below assumes you’re starting from close to zero, with an executive sponsor and a small core team rather than a funded program office. Adjust the calendar for your size. Keep the order.
Weeks 0 to 2: Mandate
Nothing in Phase 1 survives contact with an application owner who hasn’t been told the program exists. So the first two weeks are governance, not technology.
Charter a crypto steering committee with named members from IT, security, privacy, legal, and procurement. Then get your sponsor to issue a one-page crypto-agility policy. It doesn’t need technical specification. It needs to say that systems must maintain an inventory of their algorithms, keys, and certificates, that RSA-2048 and equivalent strengths are on a phase-out clock, and that new systems must be able to change algorithm without being rebuilt. The point of the memo is to make “we’ve always used RSA” an unacceptable answer six weeks later.
Define success numerically in the same fortnight. Something like: inventory covering 90 percent of internet-facing services by month ten, two post-quantum pilots running in production by month twelve.
Publish a data-lifetime rubric alongside it. This is what drives prioritization, because the threat that binds today is harvest now, decrypt later: an adversary records encrypted traffic in 2026, stores it, and decrypts it when a cryptographically relevant quantum computer exists. Data with a ten-year confidentiality requirement is already exposed. Data that’s stale in ninety days is not. Assign each data class a required secrecy lifetime and let that number, rather than system criticality, set the queue. US federal agencies have been under an inventory mandate since OMB memorandum M-23-02, and the pattern they follow is the same one: inventory, then rank by exposure.
Weeks 2 to 10: Discovery on two tracks
Run top-down and bottom-up in parallel, because neither is complete alone.
Top-down means interviewing service owners, service by service, starting with the ones handling your longest-lived data. What protects this in transit, what protects it at rest, who issued the certificates, what happens when they expire. In our experience the answers are often wrong. That’s fine; the interview surfaces who to ask next.
Bottom-up means scanning. Sweep the network for TLS and SSH endpoints and record the negotiated parameters. Pull every certificate out of internal certificate authorities and cloud certificate managers. Grep source repositories for cryptographic library calls. Query key management systems for key types, sizes, and creation dates.
Both tracks feed one artifact: the cryptographic bill of materials, or CBOM. Think of it as an inventory that answers, for each system, which algorithms it uses, which keys and certificates it depends on, who owns it, and how hard it would be to change. Your first CBOM will be partial. Publish it anyway, with the gaps marked as gaps. A partial inventory that gets corrected by annoyed engineers converges faster than a complete one that never ships.
End the phase with a tiered backlog. Tier 1 is long-lived sensitive data on systems you control. Tier 2 is everything else you can change. Tier 3 is what a vendor has to fix before you can.
Weeks 10 to 16: The lab
Build a slice of your environment in a non-production network and break it deliberately.
Two mechanisms are in play. A key encapsulation mechanism, or KEM, is how two parties agree a shared secret over an open channel; ML-KEM (standardized in FIPS 203, formerly Kyber) is the approved post-quantum one. A signature scheme proves who sent something; ML-DSA (FIPS 204, formerly Dilithium) is the general-purpose choice, with SLH-DSA (formerly SPHINCS+) as a conservative alternative and FN-DSA (formerly FALCON) still in draft. Hybrid means running the classical and post-quantum mechanism together, so the connection stays secure if either one holds.
Stand up a test server and client using a hybrid key exchange such as X25519 combined with ML-KEM-768, which Chrome and Cloudflare both run in production. Then measure. ML-KEM-768 adds a 1,184-byte encapsulation key and a 1,088-byte ciphertext to the handshake, which is enough to push the client’s first message past a single network packet. Inject 100 milliseconds of latency and record what that does to connection setup. Point a client that doesn’t support the hybrid group at the same server and confirm the fallback behaves.
Do the same for signatures. An ML-DSA-44 signature is 2,420 bytes and its public key 1,312 bytes, against roughly 64 bytes each for ECDSA on P-256. Issue a test certificate with those sizes, chain it, and find out which of your parsers, load balancers, and inspection appliances choke. Log every failure with the component name and version. That log is the input to your vendor conversations for the rest of the year.
Months 4 to 6: PKI and key management
Now upgrade the supply side, before applications start asking for post-quantum credentials and find nowhere to get them.
Public key infrastructure, or PKI, is the machinery that issues and validates your certificates: the certificate authorities, the policies governing them, and the hardware security modules, or HSMs, that hold the private keys in tamper-resistant hardware. All three need work.
Confirm your CA software recognizes the new algorithm identifiers and can handle the larger key and signature sizes. Where it can’t, that becomes a procurement item with a date. Draft the certificate policy language for post-quantum issuance now, because approval cycles are slower than engineering ones. Stand up a dedicated intermediate CA for pilots so experiments don’t touch the production hierarchy.
On the HSM side, test firmware that supports post-quantum key generation in a non-production unit. If your installed units won’t get support, get the vendor’s roadmap date in writing and use software tokens for lab work in the meantime. Then update key management policy with explicit dates: which algorithms are allowed for new systems, which are permitted until when, which are refused at review.
Finish with a dry run. Take a copy of a real database, re-wrap its master key using an ML-KEM-derived secret, and see what breaks.
Months 6 to 12: Two production rollouts
Pick two candidates. One should be low risk with a clear security gain, the other slightly harder, to prove the pattern generalizes.
Code and firmware signing is the usual first choice. Sign one product’s releases with both a classical and a post-quantum signature, keep enforcing the classical one, and let the new signature ride along until every verifier understands it. Runtime performance is untouched and the rollback is simply ignoring the new signature.
The second is an internal TLS link you own at both ends: web tier to API, or the administrative VPN. Enable hybrid key exchange, keep the classical group as backup, and watch error rates and latency percentiles for a fortnight. Route a small share of traffic through the post-quantum path first and compare against the control.
Now, a warning, because this is where first-year plans slip: the pilot is not the deliverable. The deliverable is the policy gate. By month twelve, deployment reviews should reject systems that can’t change algorithm, and your build pipeline should fail a container whose inventory shows a disallowed algorithm. Without that gate, next year’s inventory will contain systems built this year that need migrating.
What the first year won’t deliver
It won’t deliver customer-facing TLS at scale, any legacy algorithm retirement, or anything at all in embedded and operational technology, where the hardware refresh cycle sets the pace. Say so at the outset. A steering committee told in month one that year one produces capability, and year two produces coverage, is a very different audience from one that discovers it in month eleven.
For the methodology underneath this calendar, the migration framework at pqcframework.org goes deeper on inventory and prioritization, and Marin Ivezic’s longer treatment of quantum readiness planning covers the technical detail behind each phase.
Running the program
The plan above fails in one predictable way: the person holding it can’t tell a vendor’s roadmap from a vendor’s brochure, and can’t tell an engineer why the handshake got bigger. Program management for post-quantum migration is a technical skill, and the gap is rarely governance.
We built our post-quantum program certifications around exactly this sequence, from inventory design and CBOM structure through pilot selection and the policy gates that keep the backlog from growing. Explore the programs at quantumacademy.com/.