IBM Defined Application-Level Crypto-Agility. QNSI Takes It Into Enterprise Execution

IBM Research has made an important contribution to cryptographic agility. Its 2026 work does more than repeat the familiar instruction to abstract cryptography: it decomposes application-level agility into assessable dimensions, identifies recurring failures in widely used APIs, and proposes a concrete intent-based design.

We reviewed IBM's published papers and technical note against QNSI's current codebase. The result is more useful than a claim of similarity. QNSI already implements much of the operational pattern IBM describes, and it extends beyond the application boundary into enterprise discovery, governance, migration execution, and evidence. The review also found two real gaps in our own implementation - and because a gap named honestly is a defect to fix, both were closed the same review cycle, each with a regression guard that fails without the fix. We describe both below.

This is an independent technical comparison. IBM has not reviewed, certified, endorsed, or partnered on QNSI, and QNSI does not implement or claim conformance to IBM's work-in-progress reference implementation.

What IBM actually published

IBM's assessment framework treats cryptographic agility as a profile, not a single maturity score. It evaluates what application code knows about algorithms and providers, how configuration and governance are separated, and whether the system can actually evolve keys over time.

The companion API design derives thirteen principles from five architectural properties: abstraction, stability, temporal flexibility, separation, and extensibility. Its central move is a scope-based intent vocabulary. An application asks for a capability such as a standard digital signature; centrally managed policy selects the algorithm and provider. Stable identifiers then survive rotation, algorithm transformation, provider migration, and recorded evolution history.

IBM tested the assessment framework against six widely used cryptographic APIs and services named in the paper. The researchers report three pervasive gaps: no intent-based key creation, no policy-driven algorithm selection, and no first-class transformation of existing keys to new algorithms. IBM's July technical note describes its own reference server and Go SDK as partial and work in progress. The research is therefore a strong design contribution, not a claim that enterprise transformation is now automatic.

What QNSI had already implemented

The comparison is striking because QNSI arrived at many of the same engineering requirements from the operational side of post-quantum migration. The following capabilities are present in the current monorepo, not merely listed on a roadmap:

Policy-driven selection. Tenant cryptographic policy defines allowed KEM and signature sets, default algorithms, key-age limits, hardware-custody requirements, and provider strategies. Services resolve and enforce that policy centrally.
Provider separation. A common provider interface and runtime registry separate cryptographic operations from liboqs, independent verification, TLS, and custody-provider choices. Policy tiers determine primary, secondary, and TLS-provider strategy.
Stable key identity and evolution history. A logical key ID persists while version records capture algorithm, provider, wrapping mechanism, evidence, and creation time across rotations.
Key evolution with verified transformation. The KMS preserves a logical key ID while version records retain algorithm, provider, sealed key material, and evidence history. The transformation workflow selects a policy target, generates the real target keypair, self-tests it - a signature key must sign and verify, a KEM key must encapsulate and decapsulate to the identical shared secret - and only then commits. A failed self-test rolls the whole transformation back.
Operational migration. QNSI can turn discovered assets into a hash-bound dry run, require approval, execute durable migration waves, pause or resume work, support customer-driven and managed cutovers, reconcile provider outcomes, and preserve rollback anchors.
Continuous posture and evidence. Crypto inventory, source and host discovery, code findings, CycloneDX CBOM output, policy violations, readiness scoring, migration history, and hash-verifiable evidence packs connect the API decision to the estate that must be changed.

The gaps we found - and closed

Honest comparison cuts both ways, so here is what the forensic review found in our own code. First: QNSI's SDK let a caller attach a purpose such as signing or encryption, but that value was metadata - the create-key contract still expected an explicit algorithm. That is policy enforcement, not IBM's model in which application code supplies only an intent and policy makes the entire algorithm decision. Second, and more serious: the low-level algorithm-upgrade path recorded a policy-selected PQC destination without generating the corresponding PQC keypair. A key relabelled to ML-DSA had no ML-DSA material.

Both findings were treated as defects and closed. Key creation now accepts a first-class, validated intent - signing, key-encapsulation, or data-encryption - that the tenant's crypto policy resolves to a concrete algorithm, with the decision recorded in the key's metadata; explicit algorithm selection remains only as a governed compatibility path, and a request carrying both is rejected.

Transformation is now cryptographically complete and self-verifying: the real target keypair is generated, a post-generation self-test must round-trip (sign/verify for signature keys, encapsulate/decapsulate for KEM keys) before the transaction commits, the private key is sealed under an HSM-wrapped KEK, and the key's public half and versioned history advance together. Every transformation additionally emits a dual-signed evidence record - ML-DSA-65 and Ed25519 over the same canonical bytes, both proofs required at verification - extending the same downgrade-resistant signing discipline QNSI uses for its published product facts to every key transformation.

Each fix ships with a committed regression guard that fails without it: with the transformation fix reverted, five of nine integration tests fail - the transformed key cannot sign, the KEM round-trip falls back to the wrong provider, and the evidence record is absent. That revert-proof is what makes 'closed' a verified claim rather than a promise.

Application agility and enterprise transformation are different layers

IBM's application-level work answers a hard question: how should software request cryptography so that algorithms, providers, and keys can evolve without rewriting every caller? That layer is necessary.

An enterprise still has to discover where cryptography exists, normalize the inventory, identify owners and dependencies, choose migration targets, secure approvals, stage changes, prove cutovers, handle systems that cannot be changed automatically, detect drift, and retain evidence. Those responsibilities do not diminish IBM's contribution; they define the surrounding system required to put the design into production across a real estate.

This is QNSI's focus. Its control plane connects cryptographic policy to CBOM-backed discovery and governed execution. A policy decision is not treated as complete until the affected assets are identified, the migration path is chosen, the result is reconciled, and evidence is retained.

IBM's CBOM work reinforces the same boundary

IBM Research has also published a 2026 analysis of Cryptography Bills of Materials in CycloneDX. That work addresses inventory structure, dependencies, evidence, policy evaluation, and the distinction between cryptographic capabilities a component provides and the cryptography it actually consumes.

That distinction is operationally important. A library supporting ML-KEM does not prove that a deployed application uses it. A cloud KMS capability does not prove every dependent workload has migrated. QNSI's discovery and CBOM layer measures observed estate posture; its migration layer tracks the work from planned change through verified outcome.

The practical architecture

Applications declare cryptographic intent through a stable operation and scope.
Versioned policy selects an allowed algorithm, parameter set, provider, custody boundary, and rotation requirement.
Stable key identifiers and explicit evolution records preserve continuity across material rotation, algorithm transformation, and provider migration.
Continuous discovery and CBOM evidence reveal legacy use, unmanaged dependencies, and drift outside the abstraction layer.
Governed migration executes the change in waves, with approvals, rollback, cutover confirmation, reconciliation, and durable evidence.

Our assessment

IBM Research has provided one of the clearest public engineering models yet for application-level cryptographic agility. It gives architects a useful vocabulary, an assessment method, and a concrete direction for API design. It deserves careful implementation and independent testing.

QNSI's architecture covers central policy, provider abstraction, stable key versioning, cryptographic inventory, governed migration, reconciliation, and evidence - and now the three capabilities IBM found missing across the industry: intent-based creation, policy-driven selection, and first-class transformation of existing keys. QNSI's transformation goes one step beyond the papers: the new material must prove itself with a cryptographic self-test before cutover, and the transformation record itself is dual-signed and independently verifiable. It goes beyond the application API into the enterprise execution problem.

That is the useful outcome of comparing serious engineering with serious engineering: credit the contribution, test the claims, identify the overlap, and name your own gaps - then fix them with proof rather than hiding them behind the phrase 'quantum-ready.'

Primary sources

Evaluate the full loop

If your organization is moving from cryptographic inventory to governed post-quantum execution, explore QNSI's migration architecture at /pqc-migration and its public conformance evidence at /verify/conformance. For an estate-specific assessment, talk to a QNSI architect at /contact.