Classical Crypto Today

1. Discover where classical crypto actually runs

You can't migrate what you haven't found. Most organizations underestimate this list.

Inventory all TLS endpoints (external and internal)

Note each certificate's key type — RSA or ECDSA — and the negotiated key exchange.

Inventory VPN and SSH infrastructure

Which key exchange algorithms are negotiated by default on each device?

Inventory code-signing and firmware-signing keys

These often have the longest effective lifetime of anything in the organization.

Inventory database and disk encryption key management

Usually AES — lower migration priority, but confirm key sizes (AES-256, not AES-128).

Inventory third-party SaaS and API integrations

You can't patch a vendor's TLS stack — track their public migration timelines instead.

Inventory embedded and IoT devices with hardcoded crypto

Often the hardest and slowest to migrate — plan for these earliest, not last.

Not everything needs to move at the same speed — the harvest-now-decrypt-later risk is proportional to how long data must stay confidential.

Identify data that must stay confidential 10+ years

State secrets, medical records, trade secrets — this is exposed today if intercepted today.

Flag systems protecting long-lived secrets

Root CAs, code-signing roots, long-term backup encryption keys.

Deprioritize genuinely ephemeral sessions

A session that's operationally irrelevant a week later carries far less exposure.

How much pain a future algorithm swap causes depends entirely on decisions made before you needed one.

Can each system swap algorithms via config, not a full redeploy?

Hardcoded algorithm choices are the single biggest migration cost multiplier.

Are you using vetted libraries, not custom crypto code?

OpenSSL, BoringSSL, libsodium — custom implementations rarely track new algorithm support.

Do your TLS stack and OS versions support hybrid key exchange?

Check for X25519MLKEM768 or similar hybrid groups in your current TLS library version.

A migration plan, not a migration — most organizations are years from a full cutover, and that's fine if the sequencing is right.

Prioritize systems protecting long-lived data first

Directly follows from the classification step above.

Pilot hybrid key exchange on non-critical internal services

Combine a classical algorithm (ECDH) with ML-KEM in the same handshake — lower risk than a pure PQC cutover.

Track NIST and vendor timelines for ML-KEM/ML-DSA support

Your migration is gated by your dependencies' support, not just your own code.

Budget for a second wave once hardware-backed PQC matures

HSMs and smart cards with native PQC support are still catching up to the software standards.

Leave AES-256 and SHA-384/512 in place

They don't need replacing — Grover's algorithm only halves their effective security, and they already have the margin.