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.

This is a migration program, not a reason to replace algorithms blindly. Compatibility, protocol support, implementation quality, performance, certificate ecosystems, hardware, vendor roadmaps, and data-retention needs all affect order and timing.

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.

It does not mean every product is ready, every protocol profile is final, or every organization should perform the same migration at the same time. It means procurement, architecture, and software teams can now ask vendors and internal owners concrete questions.

A useful cryptographic inventory

A list of TLS certificates is a start, not the inventory. Record at least:

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

Prioritize by exposure, lifetime, and change difficulty

Long-lived confidential data

Data that must remain confidential for many years deserves early attention because an adversary could collect encrypted material now and attempt decryption later. The exact threat horizon is uncertain; the data-lifetime fact is usually knowable.

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.

Trust anchors and signing systems

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

SaaS platforms, payment systems, identity providers, certificate authorities, libraries, partners, and hardware vendors determine when some paths become available. Roadmap evidence belongs in the inventory.

A six-step migration program

1. Assign ownership. Place post-quantum readiness under security architecture with software, infrastructure, procurement, privacy, and product participation.
2. Build evidence-backed inventory. Search configuration, code, binaries, certificates, network observations, SBOMs, cloud services, and vendor records.
3. Classify urgency. Combine data lifetime, external exposure, product lifetime, consequence, and change difficulty.
4. Demand crypto agility. New designs should avoid hardcoded algorithms and make protocols, keys, libraries, and trust anchors replaceable.
5. Test interoperability. Use isolated environments to measure performance, message size, handshake behavior, key management, 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 Argus can support the work

Argus artifact analysis, signing identity, firmware and mobile inspection, SBOM handling, asset relationships, source provenance, and remediation lifecycle provide parts of a cryptographic inventory and migration record. The system should report what it can observe and mark unknown coverage rather than guessing that an unobserved primitive is absent.