Why start now
Enterprise cryptography migrations take years. TLS/1.2 → 1.3, SHA-1 → SHA-256 and MD5 deprecation each took roughly a decade to reach the long tail. Post-quantum migration is larger in scope because it touches asymmetric primitives that sit under identity, code signing, secure boot, HSMs and embedded firmware — not just transport.
The immediate risk is harvest-now-decrypt-later: an adversary who records ciphertext today can decrypt it once a cryptographically relevant quantum computer exists. Anything with a 10–20 year confidentiality horizon (health records, legal case files, national-security data, source IP, long-life keys embedded in devices) is at risk now, not in 2035.
Cryptography inventory
- Every use of RSA, DH, ECDH, ECDSA and EdDSA across services, HSMs and libraries.
- The data lifetime behind each — how long does what this key protects need to remain confidential or authoritative?
- The owner of each key or certificate, so migration has an assignee.
- Third-party dependencies: TLS libraries, JWT libraries, cryptography SDKs, hardware security modules.
The NIST NCCoE has a published playbook for cryptographic asset discovery — see the Sources page.
Priority order
- Long-life secrets with high confidentiality horizon.
- Root keys — root CAs, code-signing roots, embedded device roots.
- Transport (TLS, VPN, SSH) — highest attack surface, best upstream library support.
- General-purpose signing — JWT, artifact signing, document signing.
- Legacy embedded devices with long field lifetimes.
Vendor questions
The vendor questions template covers the full list. In short:
- Which NIST-standardised algorithms do you support today?
- Is hybrid mode available and default?
- What is your public timeline for pure-PQC deployments?
- How do you handle crypto-agility for future parameter or algorithm swaps?
- Have you completed a third-party review referencing NIST guidance?
Building the roadmap
- Group inventory items by shared migration path (TLS termination, HSM firmware, code-signing pipeline).
- Assign a NIST-aligned target algorithm for each group.
- Sequence: hybrid deployment first at the perimeter, pure-PQC once upstream libraries stabilise.
- Build crypto-agility into new systems from day one so the next parameter change is a config edit, not a project.
Score your organisation
Run the Business Readiness assessment to score across eight dimensions and export a PDF. If you want an external review with a public badge, see Trust Badge.
Frequently asked questions
What does 'quantum readiness' actually mean for a business?
It is the ability to identify where classical public-key cryptography (RSA, ECDH, ECDSA) is used across your systems and vendors, and to migrate that inventory to post-quantum algorithms — currently NIST-standardised ML-KEM, ML-DSA and SLH-DSA — before an adversary can meaningfully attack them.
Do we need to move now?
The migration itself takes years in most enterprises because it touches TLS, VPN, PKI, code signing, HSMs, vendor libraries, embedded devices and long-life documents. Even if a cryptographically relevant quantum computer is a decade away, harvest-now-decrypt-later means that data with a long confidentiality horizon is at risk today. Starting the inventory is not premature.
How do we score where we are?
Use our /business-readiness tool. It walks you through eight scoring dimensions — cryptography inventory, PKI, key management, vendor exposure, long-life data, code signing, embedded firmware and crypto-agility — and generates a PDF roadmap you can share internally.
What should we ask vendors?
Ask which post-quantum algorithms they support, whether hybrid modes are enabled, what their migration timeline is, how they handle crypto-agility for future parameter changes, and whether they have completed a NIST-referenced review. The /blog/vendor-questions-pqc note has a longer template.