Crypto-Agility Is an Operating Capability: How QNSI Connects Policy, Inventory, and Migration

The migration nobody finishes once

Every cryptographic algorithm you deploy will eventually be replaced. SHA-1 went from standard to SHAttered. RSA-1024 and 3DES followed the same arc from default to disallowed. Today's post-quantum picks are young - FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) were finalized in August 2024, FN-DSA is still draft - so parameter revisions over their deployed lifetime are a when, not an if. And the mandates now test for the ability to move: EO 14412 (June 2026) demands a cryptographic bill of materials, CNSA 2.0 reaches new national-security systems in January 2027, and DORA and PCI DSS 4.0 both expect a live algorithm inventory.

Crypto-agility - changing cryptography without rebuilding every caller - is usually pitched as an architecture principle your team must design, build, and maintain forever. QNSI operationalizes much of that work through per-tenant policy, inventory, approvals, migration control, and evidence. It does not make every provider transformation automatic, and the normal key-creation path does not yet remove algorithm choice from callers entirely.

The 60-second concept

A crypto-agile system treats the algorithm as data - selected by configuration or negotiation behind a stable interface - rather than as an assumption hard-coded across a thousand call sites. The anti-pattern is familiar: algorithm identifiers scattered through code, key sizes baked into structs, one verification routine wired to one scheme. When the algorithm has to change, every site is a code change, a re-test, and a redeploy. That is how a routine deprecation becomes a multi-quarter project.

Algorithm choice lives in policy, not code.
Keys carry algorithm metadata, so two schemes can coexist during a transition.
Verification paths accept more than one scheme at once (hybrid / dual-stack).
One place knows what is in use everywhere - without that, agility is theoretical.

On QNSI, policy is the control point-not the whole migration

QNSI's per-tenant crypto policy is the governance layer: four tiers - default, strict, maximum, government - pin which of the platform's 87 PQC algorithms (24 KEMs and 63 signatures across 13 families) a tenant may use, enforced centrally on every key, secret, and object. Tightening from strict to government narrows the estate to FIPS-finalized algorithms at the highest security levels. No application code changes; the platform enforces the new set.

Because an algorithm swap is a security-critical act, it is dual-controlled: crypto-policy changes go through maker-checker approval (live since July 2026) - the same control QNSI applies to tenant deletion and root/master key revocation. Your auditors see a governed change, not a hero commit.

Policy establishes the permitted destination. QNSI's migration control plane then handles inventory-backed planning, approvals, execution modes, cutover confirmation, reconciliation, and evidence. The actual cryptographic change still depends on the selected provider, protocol, and asset type.

You cannot govern what you cannot see: CBOM first

Agility presumes a single source of truth for what is in use. Most estates do not have one - cryptography hides in TLS terminators, application libraries, column encryption, signing pipelines, and dependencies-of-dependencies. QNSI's crypto inventory draws from cloud, infrastructure, host, TLS, and source-code discovery, classifies each asset's quantum posture, and exports a CycloneDX CBOM.

The full loop, operationalized end to end on the platform:

Discover - configured cloud and infrastructure connectors, host reports, TLS observations, source-code findings, and imports feed the crypto inventory.
Inventory - a normalized CBOM with per-asset quantum posture, exported as CycloneDX.
Govern - crypto policy tiers pin the permitted set; dual-control approvals gate every change.
Migrate - governed workflows choose automated, managed, customer-driven, or manual execution according to the asset and provider; re-discovery confirms the result and catches drift.

Inventory is the load-bearing stage. Skip it and governance has nothing to enforce against, migration has nothing to measure against, and your EO 14412 CBOM request becomes an archaeology project.

Breadth is the substrate, evidence is the proof

An agility story is only as good as the places you can move to. QNSI catalogs 87 PQC algorithms through liboqs and defines an overlapping noble cross-verification path. The audit source defines hash chaining and ML-DSA checkpoint signatures, while compliance surfaces package recorded observations against seven framework mappings. Complete runtime cross-verification, event ingestion, report availability, and auditor acceptance remain separate evidence questions.

Verify before you buy: QNSI's NIST ACVP conformance results for FIPS 203/204/205 are published live and re-runnable at qnsi.heossi.com/verify/conformance.

Start now

Run the loop yourself on QNSI's Free Forever tier: set a crypto policy, create a key, upgrade it, and watch the signed audit trail record every step - https://cloud.qnsi.heossi.com/auth?mode=signup. Developer plans start at $149/month; enterprise tiers (maximum and government policy) are custom.

If your next algorithm event is already on the calendar - a CNSA 2.0 deadline, a DORA finding, an EO 14412 CBOM request - talk to a QNSI architect at /contact and make the swap a policy change before it becomes a program.