Post-Quantum Migration Is Really a Cryptography Inventory Problem
Post-quantum migration is usually described as a technology swap: out with the old public-key algorithms, in with new ones designed to resist attack by quantum computers. That description is accurate but misleading. The harder, slower and more expensive part is finding every place cryptography already lives. Public-key algorithms are not confined to a single security layer. They sit in firmware, chips, communication protocols, certificate authorities, code-signing systems, virtual private networks and third-party software components. They are embedded in devices designed years ago that may remain in service for many more. Before an organisation can replace an algorithm, it has to know where that algorithm is used, who supplied it, whether it can be updated and what depends on it.
Standards bodies and national cyber agencies have begun publishing migration guidance for post-quantum cryptography, and most of that guidance starts with the same instruction: establish an inventory. The message is beginning to reach engineering and procurement teams, not just security specialists. Crypto-agility, a maintained cryptographic inventory and supplier attestation are becoming design and procurement disciplines rather than late-stage information-technology upgrades. For the Global Tech Awards, which recognises engineering across the technology sector, the topic sits where security engineering, hardware design and supply-chain management meet.
Discovery comes before deployment
Few organisations hold a complete record of where RSA, elliptic-curve cryptography or legacy algorithms sit inside their products and systems. The gap is not usually caused by carelessness. Cryptography is often inherited. It arrives inside a software library, a communication protocol, a hardware security module, a microcontroller firmware package or a supplier component. It may be used for device identity, secure boot, code signing, key exchange, certificate validation or protected storage. Each use has its own lifecycle, and each may be owned by a different team.
A cryptographic inventory is more than a spreadsheet listing algorithms. It needs to record where keys are generated and stored, how long they remain valid, which protocols depend on them, which components supply them and whether they can be replaced. It also needs to cover fielded devices, not only products still in development. That is where many inventories stall. A design team may know the cryptography in a current model, but the installed base can include earlier hardware revisions, regional variants and supplier substitutions that were never fully documented.
The urgency is not only about future quantum computers. Data protected by today's public-key algorithms may already be exposed to collection now and decryption later. An organisation does not need to believe that a practical quantum attack is imminent to treat migration as a present-day risk. It needs to accept that some data has a long confidentiality requirement and that the systems protecting it may outlive the algorithms they currently use.
Why connected products make the inventory hard
Connected products, industrial systems and embedded firmware make discovery particularly difficult. Cryptography can be buried in bootloaders, network stacks, device certificates, debugging interfaces and update mechanisms. It can be supplied by an operating-system vendor, a chip maker, a software library maintainer or a contract manufacturer. The product team may integrate only a small part of it directly. The rest arrives as a dependency.
Long service lives raise the stakes. Equipment fielded today may still be in service when quantum risk becomes practical, and replacement cycles for industrial controllers, medical devices, vehicles and infrastructure equipment are often measured in decades. A product that cannot update its cryptographic libraries or replace key material may have to be physically replaced to complete migration. That is a design consequence, not an operational detail.
This is why calls for component-level disclosure are growing. Manufacturers need something in the spirit of a software bill of materials for cryptography: a record of which algorithms and key lengths are used in which components, where keys are stored, and how updates will be delivered. Supplier assurances that a product is secure are not enough. Buyers need evidence they can inspect, maintain and audit.
Crypto-agility as a design brief
Crypto-agility is sometimes treated as a feature to add later. In practice, it is determined early. Firmware updatability, isolated key storage, hardware roots of trust and clean abstraction of cryptographic libraries decide whether a product can be migrated at all without replacement. If an algorithm is hard-coded across multiple layers with no update path, agility is limited. If key material is fused into a device with no way to rotate it, migration may be impossible in the field.
Agility does not mean that every product must support every future algorithm. It means that cryptographic choices are separated from application logic, that keys can be replaced, and that updates can be authenticated and applied safely. It also means testing. Hybrid schemes, which combine established and post-quantum algorithms during transition, add complexity. Performance overhead can be significant on constrained hardware, and certificate and protocol dependencies may need to change alongside the algorithm. Cryptography skills are scarce, and test laboratories and certification bodies need time to assess new implementations.
Supplier evidence and procurement leverage
Procurement is becoming one of the main mechanisms for pushing migration commitments back up the supply chain. Contract lifetimes, warranty periods and support agreements determine how long a buyer may depend on a supplier's cryptographic choices. If a contract runs for a decade, the supplier's ability to update algorithms and disclose component details matters for the whole term.
Buyers can ask for more than a promise. They can require a cryptographic inventory for supplied components, disclosure of algorithms and key lengths, a description of update mechanisms and commitments on how and when security updates will be delivered. They can make crypto-agility part of acceptance criteria and require notification when a component's cryptographic profile changes. These are not exotic demands; they are the disciplines that software supply-chain security has already made familiar.
For manufacturers, the commercial consequence is clear. A supplier that cannot describe its cryptography may be excluded from long-lived programmes. A supplier that can provide evidence, update paths and a credible migration plan becomes easier to trust and easier to support. The burden is shifting from the buyer's security team to the product's design and procurement chain.
From inventory to shipped update
Post-quantum migration will not be won by choosing an algorithm. It will be won by knowing where cryptography is used, keeping that knowledge current, designing products that can be updated and requiring suppliers to provide evidence rather than reassurance. Organisations that treat the inventory as a one-off compliance exercise will find it out of date before migration is complete. Those that treat it as a maintained engineering record, linked to procurement and product lifecycle management, will have a clearer path from plan to shipped update.
The Global Tech Awards recognises engineering across the technology sector, and this is an engineering problem as much as a security one. The migration to post-quantum cryptography is already exposing how little visibility many organisations have into their own products. Those that close that gap early will not only be better prepared for quantum risk; they will be better at building products that can change when the next cryptographic transition arrives.