3 Questions Every IT Team Should Ask Before Starting a Post-Quantum Migration

It sounds like a simple question, but cryptography is embedded across products, protocols and connections, and is often accumulated over the years, often times without teams keeping track.

Cryptography sits underneath far more than just a web browser. For instance, a CCTV camera may quietly rely on TLS or SSH connections, and systems accumulate cryptography over the years, so most teams would need to catalogue their full cryptographic scale.

The first step is a cryptographic bill of materials (CBOM) - an inventory of the cryptography in a system. It builds on the software bill of materials (SBOM), which lists the software packages and libraries in a build, by adding details such as algorithms, key strengths and post-quantum readiness. Introduced by IBM, the CBOM can be attached to software and hardware inventories through mechanisms like the CycloneDX standard, so the whole system can be mapped together.

The first order of business is to assess security risks and technical dependencies before deciding what to migrate first. From there, define the measures needed, then the architecture requirements: how much bandwidth and throughput do you need? 

A good gauge is to apply Mosca’s theory of inequality: 

X (time your data must stay confidential) + Y (time your migration takes) 

< Z (time to Q-Day).  

However, these time horizons can vary enormously. For instance, medical data may need protecting for around 25 years, while state agency data may need protecting for as long as 50. The migration time, Y, depends on whether enterprises run highly connected products or relatively isolated systems.

While a static inventory shows where cryptography is used, it cannot show how systems behave at runtime. Servers may open second channels that a static analyser never sees. Building pilots, or digital twins of the infrastructure, lets teams observe these real-world dependencies as they emerge.

Many post-quantum public keys, ciphertexts and signatures are much larger than their classical counterparts. A common assumption is that teams can compensate with more storage and a faster computer, but Stöttinger cautioned that this is not enough, because computing speed is not the only bottleneck.

In a past project migrating the Internet Key Exchange protocol, the algorithm’s computation was not the main cost. 

Moving the data across the network took longer, because larger payloads had to be split into multiple chunks. Signature-generation runtime can also vary. Some signature schemes use “rejection sampling”, so the number of iterations needed to generate a signature can vary. This cannot simply be predicted from whether the message is a fixed control signal or a free-form chat message. The advice is to benchmark with standardised test vectors and with data resembling your own application, and to measure bandwidth as well as processing time.

There is no shortage of options, and therein lies the problem. The researchers' literature search yielded over 3,700 results, and their framework analysis identified four general stages: identify the cryptography, plan when and how to migrate, execute the migration, and maintain cryptographic agility afterwards.

The handbook from TNO, the Dutch research organisation, addresses identification, planning and execution, and recommends cryptographic agility. For smaller organisations without in-house cryptographers, Singapore’s Cyber Security Agency’s (CSA) guidance published this year links operational and technical concerns, and covers which roles to involve and why management buy-in matters.

The first core standards are ready. NIST published its first post-quantum standards in August 2024. Much of the remaining work is operational: knowing what you have, deciding what to fix first, and building a system you can change again.