A practical post-quantum migration for PKI starts with an inventory of every key, certificate and algorithm, then ranks systems by how long their data and signatures must stay trusted. From there, teams make their PKI crypto-agile, test hybrid certificates alongside today’s RSA and ECDSA, and move to NIST’s new standards, such as ML-KEM (FIPS 203) and ML-DSA (FIPS 204), in planned stages rather than all at once.
This guide explains why the work should start now, what NIST has published, and an eight-step plan you can adapt to your own certificate authorities, devices and applications.
Why PKI teams need a plan now
Almost every certificate in use today relies on RSA or elliptic-curve cryptography. A large enough quantum computer could break both. Nobody knows when such a machine will exist, so the risk is about timing, not certainty.
For encryption, the concern is often called “harvest now, decrypt later”. An attacker can record encrypted traffic today and keep it until it can be decrypted. That matters most for data that must stay secret for many years, such as health, financial or government records.
For signatures, the risk is forgery once a capable quantum computer exists. Root CA certificates and devices that stay in the field for 10 to 20 years need the earliest attention, because the keys you choose for them today must still be trusted at the end of their life.
What NIST has standardized
On 13 August 2024, NIST published its first three post-quantum standards:
- FIPS 203 (ML-KEM): a key-encapsulation mechanism for agreeing shared secret keys, for example in TLS.
- FIPS 204 (ML-DSA): a lattice-based digital signature algorithm, the main candidate for certificates and code signing.
- FIPS 205 (SLH-DSA): a hash-based signature algorithm built on different mathematics, useful as a conservative second option.
In March 2025, NIST also selected HQC for standardization as an additional key-establishment algorithm (NIST IR 8545). Guidance will keep evolving, but the core algorithms are published, so there is no reason to wait before you start preparing.
The 8-step migration plan
Step 1: Build a cryptographic inventory
List every CA, certificate, key, algorithm, key size and protocol you rely on. Include devices, code signing, document signing and the certificates built into applications. A cryptographic bill of materials (CBOM) is one way to record the result.
A certificate lifecycle management tool speeds this up. Certinium CLM keeps a unified certificate inventory, tracks issuer and key strength, and produces algorithm reports, which gives you the starting picture for a post-quantum plan.
Step 2: Rank systems by risk
A simple test, often called Mosca’s rule, helps here. Add the number of years your data must stay safe to the number of years your migration will take. If the total is longer than the time until a quantum threat appears, you are already late.
Rank each system by three things: how long its data must stay confidential, how long its devices or signatures must stay trusted, and the business impact if it fails. Long-lived roots, firmware signing and IoT fleets usually rise to the top.
Step 3: Make your PKI crypto-agile
Crypto agility means you can change algorithms through policy and configuration instead of rewriting applications. It is the most useful single investment you can make, because post-quantum guidance will keep changing.
Short certificate lifetimes and automated renewal help, because every renewal is a chance to switch algorithms. Public TLS certificates are already moving to shorter lifetimes, as explained in our guide to 47-day TLS certificates.
Centralizing cryptography also helps. When applications call one service for signing and encryption, you change the algorithm in that service instead of in every application. The DictaLabs cryptographic APIs are built on this idea: the product page lists support for hybrid cryptographic models, readiness for NIST-selected PQC algorithms and the ability to evolve algorithms without application changes.
Step 4: Check your dependencies
Your PKI is only as agile as the systems around it. Ask each HSM vendor when ML-KEM and ML-DSA are supported in firmware, and when those firmware versions are validated. Then check libraries, operating systems, network devices, smart cards and IoT devices.
Size is a common blocker. An ML-DSA signature is roughly 2.4 to 4.6 KB, depending on the parameter set, compared with under 100 bytes for an ECDSA P-256 signature. Larger signatures and public keys can break protocols, database fields and constrained devices that were designed around small certificates.
Step 5: Test hybrid approaches in a lab
Hybrid approaches combine a classical algorithm with a post-quantum one, so you keep today’s protection while you add the new one. Two areas are worth testing:
- Hybrid key exchange in TLS, where a classical exchange such as X25519 is combined with ML-KEM. Test it between your own clients, servers, load balancers and inspection devices.
- Hybrid and composite certificates, which carry or combine a classical and a post-quantum signature so that old and new clients can both validate them.
Before you choose a format, confirm which options your CA, HSMs and relying-party software actually support. Run the tests in a lab first and measure handshake size, latency and failure rates.
Step 6: Plan the new CA hierarchy
Decide how post-quantum trust will sit beside your current hierarchy. Common options are a new post-quantum or composite root alongside today’s root, or cross-certification between the old and new hierarchies. Each choice affects how clients build and validate certificate chains.
Root keys are long-lived, so plan root key ceremonies, HSM capacity and offline storage early. When you evaluate a CA platform, check that it can run classical and hybrid certificate profiles side by side under separate policies.
Step 7: Migrate in waves
Start with private PKI that you control, such as internal services, VPNs and devices. There you set the rules, choose the clients and can roll back quickly.
Public TLS certificates follow browser root program rules and the CA/Browser Forum Baseline Requirements, so move them only when those rules and your public CA support the new algorithms. Keep your automation ready so the switch becomes a configuration change.
Step 8: Monitor, measure and keep a way back
Track the share of certificates and keys on each algorithm, and report it the same way you report patching. Keep rollback plans for clients that fail with new algorithms or larger certificates, and test them before each wave.
Common mistakes to avoid
- Waiting for “final” everything before starting. The inventory and risk ranking do not depend on any future standard.
- Treating PQC as a one-time swap. Algorithms and guidance will change again. Build agility, not just a new algorithm.
- Forgetting long-lived signatures. Code signing, firmware and signed documents may need to stay verifiable for many years.
- Ignoring devices. Constrained and embedded devices are often the slowest to change, so they need the longest lead time.
How DictaLabs can help
DictaLabs products and services map to the steps above. Here is what the product and service pages state today:
- DictaLabs CA: a post-quantum ready certificate authority with hybrid and composite certificate support, NIST-selected post-quantum algorithm readiness, and crypto-agile support for RSA 2048 to 8192, ECDSA P-256, P-384 and P-521, and SHA-256, SHA-384 and SHA-512.
- The DictaLabs crypto service: a REST-based, HSM-backed service that supports hybrid cryptographic models and is designed so algorithms can evolve without application changes.
- Certinium CLM: certificate inventory, algorithm visibility and governance as the foundation for crypto agility and migration planning.
- PKI consulting: quantum risk assessment, algorithm assessment, hybrid and crypto-agile PKI design, and post-quantum readiness planning aligned with evolving NIST standards.
Next step
If you want help with your inventory, risk ranking or crypto-agile design, talk to the DictaLabs PKI consulting team about a quantum-safe strategy and assessment, or contact DictaLabs to discuss your environment.
