What does quantum readiness mean, and where do you start?

Quantum readiness means knowing where your organization uses public key cryptography, which of it a future quantum computer could break, and having a ranked plan to replace it. The first deliverable is an inventory, not a product. CISA tells organizations to begin preparing now, although no machine capable of the attack exists yet.

Is this a real problem if the machine does not exist?

CISA's page on its post-quantum initiative is direct on both halves. It says quantum computing capable of breaking modern public key encryption does not yet exist. It also says government agencies and critical infrastructure entities must begin preparing now, because once such machines are powerful enough they will break many of today's widely used encryption and digital signature algorithms.

The practical reason for the head start is lead time. Cryptography is buried in protocols, hardware, firmware, certificates and third party services. Finding it all takes longer than most plans assume. The standards themselves are already out, as the NIST publications on ML-KEM, ML-DSA and SLH-DSA show, so the waiting is not for a specification.

What does CISA ask federal agencies to do?

The CISA page lists several workstreams. Two matter to any organization. First, guidance that requires each federal agency to keep a current inventory of IT vulnerable to quantum decryption, with criteria for prioritizing the inventory work. Second, CISA's work with NIST's National Cybersecurity Center of Excellence on automated cryptographic discovery and inventory tools, to streamline how inventories are built. CISA also maintains a list of product categories that include technologies supporting or planning to support the new standard algorithms, which is a useful lookup when you ask a supplier about its roadmap.

You do not have to be a federal agency to borrow the structure. Inventory, prioritize, ask suppliers, migrate, test, and check again.

Where does cryptography hide?

The obvious places are web servers and VPNs. The ones that cause delays are less visible:

• Code signing keys and firmware verification routines in devices already shipped.
• Certificate authorities and the roots baked into clients.
• Embedded libraries in applications, often several versions old.
• Hardware security modules and smart cards with fixed algorithm support.
• Long lived archives and backups that were encrypted with a key exchange that can be recorded and attacked later.
• Third party SaaS and APIs where you do not control the TLS configuration.

How do you rank what you find?

Use two questions. How long must this stay secret or trustworthy? And how hard is it to change? A session token that expires in minutes is low priority. A medical archive that must stay confidential for decades, protected by a key exchange someone could record today, is high. A signing key inside ten thousand deployed devices is hard to change, so it needs the earliest start even if the risk date is far off.

NIST's draft report IR 8547 gives a date anchor. It shows quantum vulnerable algorithms such as RSA and ECDSA at 112 bits of security strength deprecated after 2030 and disallowed after 2035. It is a draft, so check the current version, but it shows how short the window is for hard to change assets.

A constructed example

A regional insurer lists 140 internal applications. A first pass with a scanner and a survey of application owners finds TLS at the load balancer for all of them, RSA signed tokens in 22, a vendor supplied document signing module in 3, and a file archive encrypted under a key exchange that was set up in 2016. Ranking by lifetime and difficulty puts the archive and the signing module first, the token issuers second, and the load balancers last, since a library or appliance upgrade will carry them. The plan names an owner for each line and a date to ask each vendor for a roadmap.

How to check or apply this

1. Name an owner and set a scope: all systems, or critical systems first.
2. Build the inventory from three sources: code and dependency scans, network and certificate discovery, and supplier questionnaires.
3. Record, for each item, algorithm, key size, purpose, data lifetime and who can change it.
4. Rank by lifetime and difficulty, and mark the items with no upgrade path.
5. Ask suppliers for dated support for the NIST standard algorithms in writing.
6. Make algorithms configurable in code you own, so a change is a settings update.
7. Test one migration end to end before the rest, and repeat the inventory on a schedule.

Safeguard's SBOM and dependency scanning can show which cryptographic libraries each repository pulls in and at what version. That covers the code part of the inventory only. Certificates, hardware and suppliers need other sources.

Quick check

Sources

• CISA Post-Quantum Cryptography Initiative
• NIST IR 8547 initial public draft, Transition to Post-Quantum Cryptography Standards
• NIST Post-Quantum Cryptography project
• NIST FIPS 203, ML-KEM

Last reviewed: 18 October 2026.