The migration nobody finishes once
Most post-quantum programs start with the wrong question. The question teams ask is "which algorithm do we pick?" — usually ML-KEM for key exchange and ML-DSA for signatures, and they are not wrong to land there. But the question that actually determines whether the program succeeds is "can we change that choice later without rebuilding everything?"
That property has a name: crypto-agility. It is the ability to replace a cryptographic algorithm, key type, or parameter set without re-architecting the application or protocol that depends on it. A crypto-agile system treats the specific algorithm as a configurable choice behind a stable interface, not as a hard assumption baked into a thousand call sites.
This post defines crypto-agility precisely, explains why a Cryptographic Bill of Materials (CBOM) is the prerequisite step before any migration, walks the practical discover → inventory → govern → migrate loop, and shows how QNSP — the flagship post-quantum cryptography platform from CUI Labs — enforces crypto-policy and ships CBOM as part of the platform rather than as a manual exercise.
What crypto-agility actually means
Crypto-agility is not "support more algorithms." It is a design property: the algorithm in use is selected at configuration or negotiation time, behind an abstraction, so that swapping it does not require touching the consuming code. TLS cipher-suite negotiation is the canonical good example — endpoints agree on an algorithm at handshake, and adding or retiring one is a policy change, not a protocol rewrite.
The anti-pattern is the opposite: an algorithm identifier hard-coded across the codebase, key sizes assumed in struct layouts, a single signature scheme wired directly into a verification routine. When the algorithm needs to change, every one of those sites is a code change, a re-test, and a redeploy. That is what makes a "simple" deprecation take quarters.
- Algorithm choice is data (config/policy), not code.
- Key material is identified by algorithm metadata, so two algorithms can coexist during a transition.
- Verification and decryption paths can accept more than one scheme at once (hybrid / dual-stack).
- There is a central place that knows what is in use — without it, agility is theoretical.
Why it matters: algorithms get deprecated
Crypto-agility matters because cryptographic algorithms have finite lifespans, and history is consistent on this. SHA-1 was a NIST standard for years before researchers demonstrated a practical collision (the SHAttered attack, 2017) and NIST formally sunset it. RSA-1024 and 3DES (TDEA) followed the same arc from default, to discouraged, to disallowed. None of these were emergencies on day one — they were slow deprecations that organizations without an inventory experienced as fire drills.
Post-quantum cryptography does not exempt you from this cycle — if anything it sharpens it, because the algorithms are new. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. FN-DSA (Falcon), expected as FIPS 206, is still in draft. HQC was selected in March 2025 as a code-based backup KEM but is not yet a finalized FIPS standard. These are well-studied schemes, but they are early in their deployed lifetime relative to RSA's decades. A parameter revision or a future cryptanalytic result is exactly the kind of event crypto-agility is built to absorb.
Get the threat model right first
A precise threat model is part of being crypto-agile, because it tells you what actually needs to change. The quantum threat is not "all encryption breaks."
Shor's algorithm efficiently solves integer factorization and discrete logarithms, which breaks public-key cryptography: RSA, ECDH (key exchange), and ECDSA (signatures). That is why the migration priority is key establishment and digital signatures — the asymmetric primitives.
Grover's algorithm only provides a quadratic speedup against unstructured search, which applies to symmetric ciphers and hashes. The practical effect is that AES-256 retains roughly 128-bit security against a quantum adversary (still safe), and SHA-384 / SHA-512 remain safe. AES-128 drops to about 64-bit effective security, which is marginal and worth moving off, but bulk symmetric encryption is not the headline exposure.
You cannot migrate what you cannot see
Here is the gap between theory and practice: crypto-agility requires a single place that knows where every algorithm, key, and certificate lives. Most organizations do not have that. Cryptography is embedded in TLS terminators, application libraries, database column encryption, signing services, hardware modules, code-signing pipelines, and dependencies-of-dependencies. The honest answer to "where is all our cryptography?" is usually "we are not sure."
That uncertainty is why migration projects stall. You cannot prioritize what you have not found, you cannot prove you finished, and you cannot enforce a policy against an inventory you do not have. The inventory is the foundation — and the standardized form of that inventory is the CBOM.
The CBOM: a Cryptographic Bill of Materials
A Cryptographic Bill of Materials (CBOM) is a machine-readable inventory of the cryptographic assets in a system: the algorithms in use, the keys and their types, the certificates, and the relationships between them — which key protects which data, which algorithm signs which artifact. It is the cryptographic analogue of the Software Bill of Materials (SBOM) that supply-chain security already relies on.
CBOM is standardized as the cryptographic-properties extension of CycloneDX, the OWASP BOM specification. That matters: it means the inventory is interoperable, tool-readable, and auditable rather than a spreadsheet that goes stale the day it is written. A CycloneDX CBOM records each asset's type (algorithm, key, certificate, protocol), the primitive and parameters, and properties such as whether the asset is quantum-vulnerable.
With a CBOM you can answer the questions a migration actually depends on: How many places still negotiate ECDH? Which certificates use RSA below the disallowed threshold? Where is AES-128 in use where AES-256 should be? Which signing keys would need to move to ML-DSA? Without it, those are guesses.
The flow: discover → inventory → govern → migrate
Crypto-agility is operationalized as a continuous loop, not a one-shot project. Each stage feeds the next, and the loop repeats every time an algorithm event (a deprecation, a new standard, a parameter change) occurs.
- Discover — scan systems, traffic, key stores, and certificate inventories to find cryptographic usage, including the assets nobody documented.
- Inventory — normalize discovered assets into a CBOM (CycloneDX), tagging each with its algorithm, parameters, owner, and quantum-vulnerability status.
- Govern — set policy over the inventory: which algorithms are permitted, which are deprecated, which are mandatory for a given data classification — and detect violations against the live inventory.
- Migrate — move non-compliant assets to approved algorithms behind stable interfaces (often via hybrid/dual-stack first), then re-discover to confirm and to catch new drift.
How QNSP enforces crypto-agility
QNSP, the flagship post-quantum cryptography platform from CUI Labs, is built around this loop so that crypto-agility is a platform property rather than a manual program. Two parts of the platform map directly to the govern and inventory stages: crypto-policy tiers and CBOM output.
Crypto-policy tiers are the governance layer. A tenant operates under one of four tiers — default, strict, maximum, or government — and the tier constrains which KEM and signature algorithms are permitted. As the tier tightens, the permitted set narrows toward the highest-assurance, FIPS-finalized algorithms (for example, the government tier restricts KEMs to FIPS 203 ML-KEM at the highest security level). Because the permitted algorithm set is policy, not code, raising or changing a tenant's posture is a configuration change — which is the definition of crypto-agility in practice.
The CBOM layer is the inventory. QNSP's crypto-inventory service aggregates a tenant's cryptographic assets and emits them as a CBOM in CycloneDX 1.5 using the cryptographic-properties extension. That gives buyers an interoperable, auditable artifact for the inventory and govern stages rather than a bespoke export.
Verifiable evidence, not marketing claims
Agility is only trustworthy if the cryptographic operations underneath it are correct. QNSP runs dual-provider cross-verification: the native-C liboqs implementation and the pure-JavaScript @noble/post-quantum implementation execute the same operations independently, so a defect in one provider does not silently produce a wrong result. The platform covers 90 PQC algorithms across 14 families — 27 KEMs and 63 signatures.
The conformance evidence is published, not asserted. The /verify/conformance page reports NIST ACVP results: noble passing 435/435 of its addressable vectors, and liboqs passing 240/240 across the addressable ML-KEM surface. The 240 figure is the ML-KEM portion liboqs is tested against — stated plainly rather than rounded up into a single headline number.
Where QNSP sits versus point tools
The crypto-agility market has strong point players. Vendors such as PQShield focus on PQC implementations and IP cores; QuSecure positions around network/orchestration-layer quantum-safe overlays; and AWS KMS is a managed key-management service that has added PQC-relevant features within the AWS ecosystem. Each is credible in its lane.
QNSP's differentiator is scope: it is a full managed PQC platform that spans the whole loop — discovery and CBOM inventory, crypto-policy governance, key management and vault, and the cryptographic operations themselves — with breadth across 90 algorithms and published conformance evidence. For a buyer who wants the discover → inventory → govern → migrate loop as one managed system rather than assembled from separate tools, that is the relevant comparison. The detailed, fact-checked comparisons live at /compare/pqshield, /compare/qusecure, and /compare/aws-kms.
QNSP is headquartered in Singapore and aligned to PDPA (Personal Data Protection Act) and the MAS Technology Risk Management guidelines, which matters for regulated financial and data-protection use cases in the region.
Start here
If you are scoping a post-quantum program, change the first question. Instead of "which algorithm do we pick," ask "where is all our cryptography, and can we change it without a rewrite?" Build the CBOM, set the policy over it, then migrate behind stable interfaces — hybrid first where it makes sense. That ordering is what turns the next algorithm event from a project into a configuration change.
You can try the loop on QNSP's free-forever tier (10 GB storage, 50,000 API calls, 20 KMS keys, 25 vault secrets), with SDKs in five languages, and review the published conformance evidence before you commit to anything. The point is not to take the claims on faith — it is to verify them.