Post-Quantum Cryptography: Why You Should Start Your Crypto Inventory Now

No quantum computer today can break the public-key cryptography that protects your data. But NIST published its first post-quantum cryptography standards in August 2024, and a November 2024 NIST draft proposes disallowing today's quantum-vulnerable algorithms after 2035. Replacing cryptography across an organization takes years, and data encrypted today can be recorded now and decrypted later. That's why the practical first step, a cryptographic inventory, is worth starting now.

This post explains what has been published, why the timing matters and how to build an inventory that turns into a migration plan.

Why does post-quantum cryptography matter now?

A sufficiently large quantum computer running Shor's algorithm could break the public-key algorithms that almost everything relies on: RSA, Diffie-Hellman and elliptic curve cryptography (ECDH, ECDSA and EdDSA). These protect key exchange in TLS, SSH and VPNs, and the digital signatures behind certificates, software updates and firmware.

Symmetric encryption and hash functions are far less exposed. NIST's November 2024 draft on the transition states that approved symmetric primitives providing at least 128 bits of classical security, such as AES-128, are believed to meet its lowest post-quantum security category.

Nobody can say when a cryptographically relevant quantum computer will exist, and we won't guess. The useful point is that you don't need a date to plan. NIST and the NSA have now published or proposed their own timelines, and your vendors will plan around them.

What is "harvest now, decrypt later"?

An attacker who records encrypted traffic or copies encrypted files today can store them and wait. If a quantum computer capable of breaking the key exchange arrives later, that stored data becomes readable.

The risk depends on how long your data needs to stay confidential. Marketing plans lose value in months. Health records, legal files, trade secrets, long-term contracts and personal data can matter for decades. If the confidentiality lifetime of your data plus the time you need to migrate extends past the arrival of a capable quantum computer, you're already exposed.

Signatures work differently. A forged signature needs a quantum computer at the time of the attack, so recorded data isn't the concern. The concern is long-lived trust anchors, such as firmware signing keys and root keys built into hardware that will still be in service in ten or fifteen years.

What did NIST publish in 2024?

On August 13, 2024, NIST approved its first three post-quantum FIPS standards:

NIST has said it is also developing a signature standard derived from FALCON as an additional option.

In November 2024, NIST released NIST IR 8547, Transition to Post-Quantum Cryptography Standards, as an initial public draft. It proposes that quantum-vulnerable algorithms at the 112-bit security level, such as RSA-2048, be deprecated after 2030. All quantum-vulnerable public-key algorithms for signatures and key establishment, including RSA, ECDSA, EdDSA and Diffie-Hellman, would be disallowed after 2035.

The comment period closed on January 10, 2025, and the dates could change in the final version. As a planning horizon, though, they're the clearest signal yet.

What is CNSA 2.0 and does it apply to you?

In September 2022, the NSA announced the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) for U.S. national security systems. It specifies the lattice-based algorithms NIST later standardized as ML-KEM and ML-DSA, stateful hash-based signatures (LMS and XMSS) for software and firmware signing, plus AES-256 and SHA-384 or SHA-512.

CNSA 2.0 applies formally to national security systems and the vendors that supply them. Its timeline still matters to everyone else, because it shapes vendor roadmaps:

NSA's stated goal is for all national security systems to be quantum-resistant by 2035. If you sell to the U.S. defense sector, these dates may reach you through contracts. If you don't, expect them to show up in the products you buy.

How do you build a cryptographic inventory?

A cryptographic inventory records where your organization uses cryptography, which algorithms and key sizes are in play, what they protect and who can change them. The joint CISA, NSA and NIST quantum-readiness factsheet from August 2023 lists building one, alongside engaging vendors, among the steps organizations should take now.

Here's a practical sequence.

1. Set scope and ownership. Name an owner, usually in security or infrastructure. Start with systems that protect long-lived sensitive data and anything exposed to the internet, rather than trying to cover everything at once.
2. Collect what you already know. Export certificates from your internal certificate authorities and certificate management processes. List keys held in hardware security modules, cloud key management services and secrets managers.
3. Scan the network. Open-source scanners can record the protocol versions, cipher suites, key exchange groups and certificate key types offered by your TLS and SSH endpoints, internal as well as external.
4. Look inside software. Identify cryptographic libraries in your applications and their versions. Search your own code for hard-coded algorithm choices. Software bills of materials help here, and some SBOM formats, such as CycloneDX, can now describe cryptographic assets.
5. Ask vendors. Much of your cryptography sits in SaaS, appliances, firmware and operating systems you can't inspect. The questions below will fill the gaps.
6. Record the right attributes. For each entry, capture the system, owner, purpose (key exchange, signature or encryption), algorithm and key size, protocol or library, the sensitivity and confidentiality lifetime of the data, and who controls the change: you or a vendor.
7. Prioritize. Rank entries by data lifetime, exposure and how hard they'll be to change. Hardware with a ten-year service life and fixed firmware signing keys belongs near the top.

Treat the inventory as a living record. Tie updates to change management and procurement so new systems enter it as they're deployed.

What is crypto agility?

Crypto agility is the ability to change algorithms, key sizes and parameters without redesigning the systems that use them. It's what turns the inventory into a manageable migration rather than a series of emergency projects.

Practical ways to build it:

• Use maintained libraries and protocols. Don't implement cryptography yourself. Standard libraries will add the new algorithms, and your code inherits them.
• Make algorithms configuration, not code. Where you choose algorithms in your own software, do it in one place that can be changed without a rebuild.
• Automate certificate lifecycle. If certificates are issued and renewed automatically, changing their key type later becomes a policy change rather than a manual project.
• Plan for larger sizes. Post-quantum keys and signatures are much bigger. An ML-DSA signature is measured in kilobytes, compared with roughly 64 bytes for an ECDSA P-256 signature. Constrained devices, protocols with size limits and certificate chains may need testing.
• Expect hybrids first. Many early deployments combine a classical and a post-quantum algorithm, so security holds as long as either one does. OpenSSH has used a hybrid post-quantum key exchange by default since version 9.0 in 2022, and version 9.9 added an ML-KEM-based option in 2024.

What should you ask your vendors about post-quantum cryptography?

In a typical small or mid-sized organization, vendors control much of the cryptography in use. Add these questions to renewals, security reviews and procurement:

• Do you have a published post-quantum roadmap, and which of FIPS 203, 204 and 205 does it cover?
• Where do your products use RSA, Diffie-Hellman or elliptic curve cryptography today?
• Can algorithms be changed through configuration or software updates, or will it take new hardware?
• How is your firmware signed, and can devices in the field accept a new signature algorithm?
• When will your TLS and VPN endpoints support hybrid post-quantum key exchange?
• Will your validated cryptographic modules include the new algorithms?
• Can you provide details of the cryptography in your product, for example in an SBOM?

Pay most attention to hardware you'll keep for many years. A device bought in 2025 with no upgrade path may still be running when the 2035 deadline in NIST's draft arrives.

Frequently asked questions

When will quantum computers be able to break RSA?

No one knows, and estimates vary widely. Planning against published deadlines, such as the 2030 and 2035 dates in NIST's draft, is more useful than betting on a particular year.

Should we start switching to post-quantum algorithms now?

For most organizations, not wholesale. Build the inventory and improve agility first, and turn on hybrid post-quantum options when your vendors and libraries support them. Don't adopt unvetted implementations just to be early.

Do we need to replace AES?

No. NIST's transition draft treats approved symmetric algorithms with at least 128-bit security as acceptable. CNSA 2.0 requires AES-256, so organizations in its scope should use that key size.

Is this only a concern for government and large enterprises?

No. Smaller organizations hold long-lived sensitive data too, and they depend on the same vendors, protocols and certificates. Their advantage is that the inventory is smaller.

Next steps

• Name an owner and scope the inventory around long-lived sensitive data and internet-facing systems.
• Export certificate and key data, then scan TLS and SSH endpoints.
• Add post-quantum questions to vendor reviews and hardware purchasing.
• Move cryptographic choices into configuration and automate certificate renewal.
• Revisit the plan when NIST finalizes its transition guidance.

The deadlines are years away. The inventory is the part that takes the longest, so it's the part to start first.