Software Escrow's Quantum Blind Spot

What happens to the cryptography embedded in this code when the assumptions underneath it break?

Source code deposits routinely contain hard-coded certificate pinning, embedded public keys for licence verification, TLS client implementations, signature-verification routines, and integrity checks: all built on cryptographic primitives that are on a published deprecation path. It is relevant to in-house-built/outsourced software, as well as to open-source components. A deposit made today, released in 2035, may be functionally unrunnable, not because the code is broken but because the cryptographic world it was written for no longer exists. Shor's algorithm breaks RSA and ECC, which are the main components of modern secure communication. NIST has standardised replacements. However, the deposits sitting in escrow vaults today, or highly likely to be deposited in the next few years, are written before those replacements existed.

Considering various regulations applicable to your business, you have a lot of data to save for historical reporting, accountancy, customer service, you name it. The Mosca theorem provides a clear time/risk assessment: X (shelf life) + Y (migration time) > Z (threat timeline). In your business, this means that if you have a requirement to safeguard historical data for 7 years and the migration will take 2 years, you are already behind the estimated quantum risk and should start in 2023.

If you choose a basic source code escrow or an advanced SaaS managed service, you should consider the long-term supportability of the escrowed solution. While we can't predict future business functionality requirements or software bugs that may arise in due course, we can be sure that security needs will always be there. One of the critical elements of security is ensuring data confidentiality and integrity, and both are handled by cryptography.

Software escrow is, in fact, one of the clearest and most concrete instances of the "harvest now, decrypt later" threat model, in the mundane sense that escrow deposits are specifically designed to be read in a future where today's crypto assumptions no longer hold.

How to address this risk?
The Cryptography Bill of Materials (CBOM) is a starting point that provides necessary visibility into dependencies and their post-quantum status.
CBOM includes:

• Algorithm discovery
• Key inventory
• Certificate mapping
• Protocol analysis
• Dependency mapping
• Risk classification

CBOM output is a complete map of every cryptographic dependency in the deposited code, with a risk classification against the NIST post-quantum timeline and will produce 3 documents:

• Detailed results CycloneDX 1.6 format (JSON/XML) with full file paths, line numbers, and call graph context
• Human-readable results in Excel format
• High-level summary report with quantum risk level and recommended action.

While the CBOM by itself will not migrate those components to PQC-resilient algorithms developed and standardised by NIST, it enables timely planning to begin the migration when a vendor is ready.
Your software development team or partner may point to this vendor dependency challenge, and, for once, they will be right. You can't fix it yet, but you can estimate the required effort, manage it as a proper project, and, more importantly, not forget about it.

There is no shortcut that avoids the migration entirely, but there is a practical interim architecture.
As of now, your application should be able to decrypt this data and use it. If you want to ensure the data remains secure, your development team needs to design the new architecture soon. At the moment, the hybrid approach is the most practical, if not the most realistic. Such an approach includes both AES-256 and post-quantum encryption, with AES encrypting the bulk of the data and the PQC algorithm (such as ML-KEM, formerly Kyber, now standardised as FIPS 203) encrypting the AES key. When (not if) the application will migrate to PQC-resistant algorithms, key and signature sizes will increase substantially, PQC signatures can be 10-50x larger than their RSA equivalents, which means your data layer, particularly fields storing keys, certificates, and signed tokens, will need capacity planning before migration begins. Such a migration will require careful planning and necessary hardware/software upgrades.

The technology problem has interim solutions. The contractual and process gap in the escrow chain does not. Your escrow agreement should account for this dependency and proactively mitigate potential issues if it is eventually triggered. Escrow beneficiaries should require a CBOM as part of the verification process for any new deposit. Depositors should include cryptographic metadata alongside their source code. And escrow agents who aren't offering PQC assessment as part of their service are selling a product with a known gap they haven't disclosed.