- A cryptographic inventory lists every cipher, key, and signature across your stack. Migration begins with discovery, not buying products.
- Track technical owners, vendors, ciphers, key sizes, data lifespan, and upgrade paths for each link.
- Focus early on long-lived data and core hardware. Ask vendors for tested options and trial updates away from production traffic.
Quantum computers do not break business encryption today. Yet the shift to quantum-safe methods will take years. Security teams say planning must start now.
A cryptographic inventory is an organised catalog of every place your systems use encryption algorithms, digital signatures, public keys, and certificates. Building a cryptographic inventory is the mandatory starting point for post-quantum planning. You cannot replace weak public-key methods until you locate where they run. You must also know who owns each service and how long sensitive records must stay private.
The first useful step is never buying a tool. It is finding where your company uses public-key encryption and digital signatures. This list turns a distant risk into clear engineering tasks. Teams can assign, rank, and test each item.
Why a cryptographic inventory comes before algorithm upgrades
Public-key encryption protects web traffic, remote logins, and data exchanges. Digital signatures prove that code, files, and messages come from the real source. Many systems rely on RSA or elliptic curve math. Our Ed25519 vs RSA key comparison explains how those core designs differ in production.
Large quantum machines could break RSA and elliptic curve ciphers. No one knows the date. Still, NIST advises teams to begin migration work now. High-risk systems must move well before the 2035 target date.
There is also an immediate threat. Attackers can collect encrypted traffic today and store it until quantum machines arrive. This tactic is known as Harvest Now, Decrypt Later. Sensitive data that must stay private for ten or twenty years is exposed right now.
You cannot judge that risk without a cryptographic inventory. Ciphers run inside cloud setups, network boxes, code-signing flows, and vendor contracts. The inventory makes those hidden links clear.
Set a small scope and name an owner
Start with one core service. Do not try to audit the whole firm at once. Pick a service that handles valuable records or must stay online. Good choices include user login, payroll, build pipelines, or links to key partners.
Name one technical owner for the cryptographic inventory. That person does not need to be a cryptographer. The job is to gather facts, involve the right staff, and keep the list fresh. Security, IT, DevOps, and legal may each hold part of the answer.
Write down the goal in plain terms. For example, set a quarterly target to map public keys in login flows. Decide who runs them and learn how long data stays private.
Core data fields to record in your inventory
A simple database or spreadsheet is plenty for the first pass. Do not wait for a perfect automated scanner. Add one row for each distinct use of public-key encryption or a digital signature.
| System and owner | Cryptographic primitive | Key size and location | Data life and tier | Upgrade route |
|---|---|---|---|---|
| Customer web portal (Web Team) | TLS key exchange (ECDHE P-256) | 256-bit EC, Cloudflare Edge | Ephemeral web sessions (Tier 3) | NIST ML-KEM hybrid support |
| Production SSH bastion (DevOps) | Host keys (RSA-3072 / Ed25519) | 3072-bit private key on disk | Admin access, 1-year rotation (Tier 2) | OpenSSH hybrid sntrup761 / ML-KEM |
| Application release signing (CI/CD) | Digital signature (RSA-4096) | Hardware Security Module (HSM) | Binary provenance, 10-year validity (Tier 1) | NIST ML-DSA or SLH-DSA migration |
| Session authentication tokens (API) | JWT signing (RS256) | Internal KMS key ring | Tokens expire in 15 minutes (Tier 3) | Transition to Ed25519 or post-quantum signatures |
| Customer database archive (DBA) | Asymmetric envelope encryption | Cloud KMS asymmetric key | Financial records, 7-year retention (Tier 1) | Re-encrypt under post-quantum KEM wrappers |
| Site-to-site IPsec VPN (Network) | IKEv2 key agreement (Diffie-Hellman) | Hardware firewall appliances | Corporate network traffic (Tier 2) | Firmware upgrade with post-quantum preshared keys |
When tracking login tokens and API services, remember that key swaps need overlapping validation windows. See our guide on graceful JWT signing key rotation for a clear pattern. Mark unknown items instead of guessing. A useful inventory shows blind spots.
Rank systems by data lifespan and quantum risk
Not every cryptographic asset needs an instant swap. Use a simple scoring rule based on data life and update effort. Give top priority to files that must stay private for decades and tools with slow hardware refresh cycles.
A simple formula helps teams test Harvest Now, Decrypt Later risk. Take your data life, add the time needed to migrate, and subtract the threat window. If data life plus migration time tops the threat window, that system belongs in your top queue.
The UK NCSC asks teams to finish discovery and an initial plan by 2028. It wants high-priority work done by 2031. Its wider target date is 2035. These are planning checkpoints, not proof that every workload can wait.
- Tier 1 (Act early): Long-lived private files, root certs, firmware signing keys, and gear with multi-year hardware cycles.
- Tier 2 (Plan next): Production setups with clear vendor update paths and normal renewals in the next two to three years.
- Tier 3 (Monitor): Low-impact services, short session tokens, and lab tools where standards are still forming.
Audit software suppliers and third-party dependencies
A quantum-safe label on a sales page is not a plan. Ask vendors which NIST standards their tools support, which builds include them, and whether that code is ready for production. Ask how their software handles larger keys and older clients during the shift.
Our software vendor security evidence guide explains how to verify claims before renewal. If a cloud tool works with bots, include those non-human accounts in your quarterly SaaS access review too.
Ask for speed benchmarks and failure modes. Larger keys can slow down handshakes and use more bandwidth. Ask what happens when a client rejects a quantum-safe handshake. Make sure monitoring will catch that mismatch before users see errors.
Put firm dates and roadmaps in contracts for key tools. When planning domain updates, coordinate your rules cleanly. See our guide on HSTS preload rollout controls for best practices.
Test post-quantum algorithm candidates in isolation
Do not switch live traffic in one leap. Set up isolated test labs to check compatibility and speed. NIST set its first post-quantum standards in August 2024: FIPS 203 (ML-KEM) for key exchange, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures.
Measure network delay and packet splits carefully. Post-quantum public keys and signatures are much larger than older keys. For example, an ML-KEM-768 public key is 1,184 bytes, compared to 256 bytes for RSA-2048 or 64 bytes for P-256. This size jump can split TLS handshake packets across older firewalls and routers.
Make sure you also check deployment pipelines before turning on production flags. That process mirrors our guide on proving TLS certificate renewals reached production. Confirm that fallback routes work well without weakening overall connection safety.
Log all test results in your cryptographic inventory. A failed lab test gives valuable data. It shows which client tool or network box needs an upgrade.
Make cryptographic agility an ongoing engineering process
An inventory quickly loses value if treated as a one-time project. Add cipher reviews to your yearly architecture audits and buying checks. Update the inventory whenever TLS setups, signing certs, or cloud gateways change.
Review high-risk inventory rows at least twice each year. Track vendor release dates and standards updates. Keep technical owners accountable for their systems. This habit builds crypto agility, meaning the team can swap ciphers without rewriting entire apps.
Start small this week. Pick one critical user-facing app, list its cipher links in a sheet, and send three clear questions to its main vendor. That direct work brings far more value than vague claims of quantum readiness.
Sources and documentation
- NIST: Post-Quantum Cryptography Project
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
- UK NCSC: Timelines for Migration to Post-Quantum Cryptography
- Meta Engineering: PQC Migration Framework and Engineering Lessons
Frequently asked questions
What is a cryptographic inventory and why is it needed?
A cryptographic inventory is a catalog of all ciphers, keys, certificates, and protocols across a company. It is needed to spot weak public-key tools and plan safe upgrades.
How does Harvest Now, Decrypt Later affect current encryption?
Adversaries can record encrypted web traffic today and store the ciphertext. Once quantum computers arrive, they can read old data that stays sensitive, putting long-term secrets at risk right now.
Which NIST post-quantum standards should teams evaluate?
Teams should evaluate FIPS 203 (ML-KEM) for general key exchange, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures and code signing.