Post-quantum migration for machine identity

The timeline

What is actually exposed

The exposure is public-key cryptography specifically: RSA and elliptic-curve signatures (ECDSA, EdDSA, RSA-PSS, RSA PKCS#1 v1.5) and key establishment (RSA key transport, ECDH, finite-field Diffie-Hellman). All fall to Shor's algorithm on a sufficiently capable quantum computer, which is why moving from RSA to ECC is not a mitigation: a surprisingly common misunderstanding in migration planning.

Symmetric cryptography and hashing are far less affected and are handled by increasing sizes rather than by replacing algorithms. If your programme is treating AES and SHA-2 as equally urgent, it is misallocating effort.

Harvest now, decrypt later makes the timeline present-tense for anything with long-term confidentiality requirements: traffic captured today can be decrypted once capability exists. For data with a ten-year sensitivity horizon, the migration deadline has effectively already passed.

The inventory problem

You cannot deprecate what you cannot see, and you cannot report progress against 2030 or 2035 without knowing your starting position. RSA and ECDSA are embedded in TLS configurations, VPN tunnels, code-signing pipelines, certificate authorities, database connections, application libraries and hardware security modules. Most organisations do not have a current, accurate picture of which algorithm and key length is used where.

This is the same inventory problem as machine identity management generally, with one additional field: the algorithm and key size, per credential. Adding that field to an existing certificate inventory is far cheaper than building a separate cryptographic inventory later, and it is the single highest-value thing to do this year.

Four places the inventory usually misses: certificates issued by internal PKI outside the central team, keys embedded in firmware and appliances, cryptographic material inside third-party software you cannot inspect, and long-lived signing keys whose rotation has never been exercised.

Crypto-agility is the deliverable, not the algorithm

The temptation is to plan a one-time swap. That is the wrong target for two reasons: the PQC algorithms themselves may be revised, and hybrid constructions combining classical and post-quantum algorithms are expected to remain permitted after 2035, so you will run more than one configuration.

The capability to build is the ability to reissue your entire estate on a short cycle without downtime. An organisation with that capability completes an algorithm migration in weeks. One without it needs years, and will still be doing it in 2035.

Which is precisely why this and the certificate-lifetime programme are one effort. The CA/Browser Forum reductions to 100 days in March 2027 and 47 days in March 2029 force exactly the automation that post-quantum migration requires, and they arrive first. Treat the 47-day deadline as a funded rehearsal for the 2030 one.

A migration sequence

1. Add algorithm and key size to your certificate and key inventory. Cheap, immediate, and a precondition for everything else.
2. Identify long-confidentiality data subject to harvest-now-decrypt-later, and prioritise the key establishment protecting it.
3. Find what cannot be changed: firmware, appliances, embedded devices, third-party software with no crypto configuration. This is the actual project and it needs lead time measured in years.
4. Automate issuance and deployment so reissuance is not a human process. This is shared with the 47-day work.
5. Pilot hybrid certificates in a controlled environment to establish what breaks with non-PQC clients.
6. Re-key certificate authorities. Re-keying a root requires reissuing the entire subordinate hierarchy and distributing new trust anchors, and it has the longest lead time of anything on this list.
7. Set an internal date earlier than 2030, because CA lead times and chain reissuance mean the practical transition window closes well before the deadline.

Frequently asked questions

When must RSA and ECC be retired?

Under NIST IR 8547, algorithms providing 112 bits of security such as RSA-2048 and ECC P-256 are deprecated after 2030, meaning they should not be used for new deployments though existing systems may continue during migration, and disallowed after 2035. Higher-strength parameter sets are also disallowed after 2035. IR 8547 is an initial public draft rather than a final publication, but organisations treat its timeline as the working baseline.

Does moving from RSA to ECC help with quantum risk?

No. Both RSA and elliptic-curve cryptography fall to Shor's algorithm on a sufficiently capable quantum computer, so migrating between them provides no quantum-resistance benefit. This is a common misunderstanding in migration planning. The replacement algorithms are the standardised post-quantum ones: ML-KEM for key establishment and ML-DSA or SLH-DSA for signatures, published as FIPS 203, 204 and 205 in August 2024.

What is the hardest part of post-quantum migration?

Inventory. The new algorithms are already standardised, so the technical answer exists. What most organisations lack is an accurate picture of which algorithm and key length is used where, across TLS configurations, VPNs, code-signing pipelines, certificate authorities, database connections, application libraries and hardware. You cannot deprecate what you cannot see or report progress without a starting position.

What is harvest now decrypt later?

The practice of capturing encrypted traffic today with the intention of decrypting it once quantum capability matures. It makes the migration timeline present-tense rather than future for anything with long-term confidentiality requirements: if data must stay confidential for ten years, the deadline for protecting it against future decryption has effectively already passed.

How does post-quantum migration relate to the 47-day certificate deadline?

They are the same programme. Both require the ability to reissue an entire certificate estate at speed without downtime, and the CA/Browser Forum reductions to 100 days in March 2027 and 47 days in March 2029 arrive first. An organisation that can reissue on a 47-day cycle can complete an algorithm migration in weeks; one that cannot will need years. Treating the certificate-lifetime work as a funded rehearsal for the 2030 deprecation is the most efficient framing available.

What has the longest lead time in a PQC migration?

Re-keying certificate authorities. Re-keying a root CA requires reissuing the entire subordinate hierarchy and distributing new trust anchors to relying parties, which is a cascading operation with long dependencies. Close behind it is anything embedded in firmware, appliances or third-party software with no cryptographic configuration, which may require hardware or architecture decisions rather than operational ones.