Is your cryptography ready for the quantum era? A practical walkthrough

Ask a CISO whether their organization is ready for post-quantum cryptography and you will usually get one of two answers: “we use TLS 1.3 everywhere” or “we are waiting for the standards to settle.” Both answers miss the point. The standards have settled, and TLS is a fraction of the cryptography your organization actually runs.

Here is a walkthrough you can actually execute.

Step 1: accept the scope

Cryptography lives in more places than anyone expects:

• Source code: encryption calls, signing routines, key derivation, hard-coded algorithm choices.
• Configuration: TLS settings in web servers, database encryption options, framework crypto defaults.
• Artifacts: certificates, keystores, SSH keys, JWKs scattered across repositories and servers.
• Compiled binaries: crypto libraries linked into applications you may not have source for.
• Protocols: what your services actually negotiate with each other, which is not always what the config says.

A readiness assessment that only checks TLS versions covers the first surface partially and the rest not at all.

Step 2: build the inventory from evidence

The industry name for this inventory is a CBOM, a cryptography bill of materials. The critical property is that it must be generated from your actual artifacts, not assembled from what teams remember using. Memory-based inventories miss the algorithm choice buried in a dependency, the certificate a long-departed contractor installed, and the legacy service nobody wants to claim.

Evidence-based generation means parsing source, configuration, certificates, and binaries, and recording where each asset was found. Where something cannot be resolved, an honest tool declares it as a known-unknown rather than guessing. This is exactly the job BOMNexa was built for.

Step 3: classify against the real standards

NIST has finalized its first post-quantum standards: ML-KEM for key encapsulation, ML-DSA for signatures, and SLH-DSA as a hash-based signature alternative. That gives every asset in your inventory a clear verdict:

• Quantum-vulnerable: RSA, elliptic-curve key exchange and signatures, finite-field Diffie-Hellman. These break when a sufficiently capable quantum computer exists.
• Quantum-safe: the new NIST standards, plus symmetric encryption at adequate key sizes. AES-256 is fine.
• Needs attention regardless: anything already weak classically, like 3DES or RSA below 2048 bits, which should not wait for the quantum threat to be retired.

Step 4: rank by data lifetime, not by system age

The question that orders the migration is: how long does the data this cryptography protects need to stay secret? Data with a ten-year confidentiality requirement, encrypted today with RSA key exchange, is already exposed to harvest-now-decrypt-later collection. Systems protecting long-lived secrets migrate first. Ephemeral data can wait longer.

This is why the migration is urgent even though large quantum computers do not exist yet: the deadline is set by your data’s lifetime, not by the attacker’s hardware.

What “ready” actually looks like

By the end of this walkthrough, ready means:

1. A complete, evidence-based cryptographic inventory that regenerates automatically with every build.
2. A quantum-readiness verdict on every asset, tracked as a percentage you can report quarterly.
3. A migration backlog naming specific components, services, and target algorithms.
4. New code held to a policy that stops the vulnerable population from growing.

None of that requires quantum expertise. It requires the same discipline you already apply to vulnerabilities: inventory, classify, prioritize, fix, and measure. The organizations that treat it that way will find the quantum transition uneventful. The ones waiting for a headline will find it expensive.

If you want to see what an evidence-based cryptographic inventory looks like on a real codebase, that is a 30-minute demo.