PQC Readiness Without Supply-Chain Control Can Preserve Cryptographic Dependence

New research separates PQC readiness from cryptographic sovereignty. The operational lesson is that migration inventories should capture who controls implementations, validation, hardware, and replacement paths.

A new preprint, “A Global Readiness and Sovereignty Capability Model for Post-Quantum Cryptography Migration,” argues that national readiness and control over the cryptographic supply chain are different things. A country can publish a roadmap, adopt standards, build inventories, and deploy post-quantum cryptography while remaining dependent on external implementations, hardware, validation capacity, and vendors.

The paper proposes a model that scores readiness alongside indigenous cryptographic capability, post-quantum control, and external dependency. Its empirical results are exploratory, and the author explicitly presents the country assessment as a demonstration rather than a definitive ranking. The underlying distinction is nevertheless useful well below the national level: organizations can complete a technical migration while preserving operational dependencies they cannot evaluate, modify, or replace.

A migration can change algorithms without changing control

Most post-quantum programs measure progress through discovery coverage, risk classification, standards adoption, testing, and deployment. Those are necessary dimensions. They do not fully answer who controls the implementation layer or how quickly an organization can respond when assumptions change.

Consider a service that replaces classical key establishment with ML-KEM. Its migration may still depend on a cloud provider’s rollout, a foreign hardware security module, a single cryptographic library, a certificate vendor, specialized validation laboratories, and a supplier’s firmware schedule. The algorithm has changed, but the organization’s ability to inspect, update, or substitute the cryptographic stack may not have improved.

This is not an argument for building every primitive or component internally. International standards, open implementations, specialist vendors, and global supply chains are essential. It is an argument for making dependence visible enough to govern.

Dependency belongs in the cryptographic system of record

A cryptographic inventory usually begins with assets, algorithms, keys, certificates, protocols, and libraries. The research suggests additional relationships that matter for long-term resilience: implementation maintainer, hardware origin, validation authority, deployment operator, supplier support window, replacement options, data portability, configuration control, and access to test evidence.

These fields turn an abstract sovereignty discussion into practical questions. Can the organization patch the implementation on its own schedule? Can it export keys and evidence? Is an alternative provider interoperable? Does the team have enough internal skill to evaluate a supplier claim? Is validation available in the required jurisdiction? Can procurement require a migration path if a selected primitive or parameter set changes?

The answers will differ by system. A widely supported external dependency with multiple implementations and open standards may be less risky than a nominally local product with opaque code, weak support, or no replacement path. Control should be evaluated through evidence, not nationality labels alone.

Crypto agility includes organizational and supplier agility

Crypto agility is often described as the ability to replace algorithms without redesigning an application. The same principle should extend to providers and components. If a migration hard-codes a new algorithm into a proprietary appliance that cannot be updated independently, it may trade one form of rigidity for another.

Teams should evaluate whether algorithm choice is configurable, whether interfaces are standards-based, whether keys and certificates can move safely, whether multiple conforming implementations exist, and whether evidence can be retained when suppliers change. Procurement terms should cover update commitments, vulnerability disclosure, component transparency, end-of-support dates, validation artifacts, and secure exit paths.

A CBOM can help, but only if it represents relationships rather than a flat component list. It should show which product implements which cryptographic function, which assets depend on that product, what version was observed, and what evidence supports the record. Repeating the CBOM against a defined scope can then reveal both cryptographic drift and supplier concentration.

How to apply the idea without overcorrecting

  1. Add control and dependency fields. Identify maintainers, suppliers, hardware roots, validation sources, support horizons, and substitute implementations.
  2. Prioritize concentrated dependencies. Find cryptographic functions with one provider, one implementation, or one unavailable replacement path.
  3. Test exit and update paths. Confirm that configurations, keys, certificates, records, and evidence can move safely.
  4. Invest selectively in internal capability. Build enough expertise to evaluate, integrate, test, and govern critical cryptography, even when implementation remains external.
  5. Preserve interoperability. Avoid sovereignty goals that fragment standards or make systems harder to update.

How Vista Platform can help

Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—can help teams make cryptographic and supplier dependencies visible, connect them to accountable work, and preserve evidence as the migration changes.

Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is not indiscriminate network scanning, Vista is not a vulnerability scanner, and discovery gaps are not proof of absence. See the Vista post-quantum approach or try Vista Core.

What remains uncertain

The proposed model is a new preprint, not a settled international benchmark. Its classifications depend on public evidence, coding judgments, and a purposive sample; they should not be treated as authoritative country rankings. The valuable operational insight is narrower: readiness metrics should not hide who controls the implementation, validation, and replacement layers on which migration depends.

Sources