Post-quantum migration starts with inventory

In August 2024, NIST approved FIPS 203, FIPS 204, and FIPS 205. They specify ML-KEM for key establishment, ML-DSA for digital signatures, and SLH-DSA for stateless hash-based signatures. NIST now says organizations should begin applying the standards to migrate systems to quantum-resistant cryptography.

Treat it as a migration program. Compatibility, protocol support, hardware, and vendor roadmaps all affect what you can move and when — and none of them move at your pace.

What publication of the standards changes

Before standardization, organizations could inventory dependencies and test candidates but had limited basis for production decisions. Published FIPS provide stable references for principal key-establishment and signature families. That moves planning from abstract awareness toward engineering.

Not every product is ready, and not every protocol profile is final. What has changed is that your procurement, architecture, and software teams can now ask vendors a concrete question and expect a concrete answer.

A useful cryptographic inventory

TLS certificates are one part of the inventory. Record at least:

• Use: transport and stored-data encryption; code and document signing; identity and key exchange; backup, device enrollment, firmware verification, or secrets protection.
• Asset and owner: applications, services, and libraries; appliances and cloud services; mobile apps, build systems, devices, vendors, and the accountable team.
• Algorithm and parameters: protocol version with key type and size; curve and signature scheme; KDF, cipher suite, certificate chain, and provider.
• Data lifetime: how long confidentiality or signature validity must survive.
• Dependency: runtime library and operating system; hardware security module or certificate authority; API, partner, device firmware, or external standard.
• Change path: configuration or software update; protocol redesign or hardware replacement; vendor release or contract renewal.
• Evidence: configuration source or observed handshake; signed artifact or SBOM component; code location or vendor attestation.

Prioritize by exposure, lifetime, and change difficulty

Long-lived confidential data

Data that has to stay confidential for years deserves attention first, because an attacker can collect it encrypted now and try to decrypt it later. Nobody knows when that becomes practical. You do know how long your data has to last — start there.

Long-lived products and embedded systems

Devices, firmware, industrial systems, vehicles, and infrastructure may remain deployed longer than their current cryptographic stack. Update mechanisms and signing roots can become migration bottlenecks.

Certificate authorities and signing keys

Code-signing, firmware-signing, package distribution, certificate authorities, and document-signing workflows require careful transition because both producers and verifiers must understand the new scheme.

Externally controlled dependencies

Your SaaS platforms, identity providers and hardware vendors decide when some of these paths open at all. Put what each vendor has actually committed to, in writing, in the inventory.

A six-step migration program

1. Assign ownership. Place post-quantum readiness under security architecture, with participation from software and infrastructure teams. Procurement, privacy, and product owners also have work here.
2. Build the inventory from evidence by searching configuration and code, then binaries and certificates. Add network observations, SBOMs, cloud-service records, and vendor records.
3. Classify urgency by combining data lifetime with external exposure and product lifetime, then account for consequence and change difficulty.
4. Demand crypto agility. New designs should avoid hardcoded algorithms. Protocols and keys must be replaceable, as must libraries and trust anchors.
5. Test interoperability. Use an isolated environment to measure performance and message size. Check handshake behavior and key management, then record failure modes and fallback.
6. Preserve migration evidence. Record what changed, which standard and implementation were used, which dependencies remain, and how compatibility was verified.

How KernelHawk can support the work

KernelHawk covers part of this: artifact analysis, signing identity, SBOM handling and firmware inspection all feed a cryptographic inventory. It reports what it observed and marks the rest as unknown coverage — it will not tell you a primitive is absent when it simply never looked.