Engineers and business leaders alike know all about the looming specter of technical debt. It comes from kicking the can down the road on complex decisions, putting off code cleanups, and delaying expensive rewrites. Technical debt gets a bad rap, but often it is justified and even desirable in many cases: trading speed and expedience for a mess that needs to be cleaned up later. Security debt, on the other hand, is a different beast. This occurs when you defer closing a security issue or take shortcuts that expose vulnerabilities in your system. The insidious nature of security debt is that, just like technical debt, you can kick the can down the road for a while. Unlike technical debt, however, when security debt comes due, it is often in the form of an exploit or security incident, which may well take the entire business (and its customers!) down with it.
Cryptography is a great example of security debt. Choosing a signature scheme years ago may have been sound engineering, and then that choice spread into key formats, address schemes, database schemas, hardware security module configurations, custody workflows, audit tooling, and every integration that assumes a signature looks a certain way. Technology moves on, computers get faster, new computing architectures emerge, and suddenly the whole structure is built with an impending expiration date.
The reality is that quantum computers are now threatening to expose the security debt built into virtually every software stack in the world. Databases, communication protocols, trust frameworks, and yes, nearly every major blockchain are based on classical forms of cryptography, which quantum computers threaten to break. Some estimates place such quantum computers as being available as early as 2029. The more relevant and critical date for today’s systems is that day minus however long your migration takes. For most institutions, lead time is measured in years.
That is why delay is becoming an increasingly risky choice. Debt carries interest, and deferring quantum migration is accruing it in at least two ways. The first is principal growth. Every new product, smart contract, custody integration, or reporting pipeline built on classical signatures adds one more thing that will eventually need to be unwound. The second is complexity. Post-quantum signatures are not drop-in replacements. They are based on fundamentally different mathematics and have very different performance characteristics. Falcon signatures and public keys, one of the most space-efficient post-quantum schemes, run to over three kilobytes, against dozens of bytes for the elliptic curve schemes most blockchains use today. That difference ripples into transaction sizes, fees, storage, bandwidth, and hardware constraints. Any system that quietly assumes a fixed, small signature size becomes a liability in need of major upgrading or rebuilding instead of a quick crypto swap.
The best defense is to design so the next change is cheap. Algorand’s approach shows what that looks like. The roadmap emphasizes the ability to swap cryptographic schemes in what is called “cryptographic agility.” In addition, we’re adding a host of features around this, such as planned support for hybrid accounts that combine classical and post-quantum keys, so assets are protected against both old and new threats during the transition; tooling that is designed to feel familiar, with SDKs expected to create Falcon-1024 accounts from a standard, familiar seed phrase; and the already existing ability to assign signing authority for an account to a new private key. Falcon verification is also available to smart contracts, so developers can build quantum-safe applications without writing their own cryptography.
It is easy to see a date like 2029 and assume we have time. Those are the most pessimistic estimates after all. And far be it from me to spread Fear, Uncertainty and Doubt. The message here is not that we need to panic or that doom is upon us. The message is, if you don’t want to have to panic, and you don’t want to risk your business and your customers, the time to start thinking about and moving towards quantum security is now, not in 2029.
To get started, you can begin with an inventory of every place keys are generated, stored, and used, across wallets, custody, applications, hardware, and third-party services. Next, put an abstraction layer between your applications and your signing and verification logic, so that algorithms become configuration instead of code. Revisit your technology choices to make sure that you’re comfortable with their timing and roadmap against your risk appetite and the nature of the assets you’re securing. Then pilot on a live network. Algorand executed its first Falcon-authorized mainnet transaction in November 2025, so the path from theory to practice has already been walked, and a staging pilot will surface the signature-size and performance effects before they surface in production. Finally, press your partners for roadmaps with clear dates. Hardware and custody solutions must evolve to support post-quantum signatures, and Algorand acknowledges that end users will not have Falcon-capable hardware devices for a little while. Your partners’ timelines set the ceiling on your own.
You may also want to revisit the build-or-partner decision. The security and cryptography space is not trivial, and expertise is not abundant. It’s worth considering if partnering with a team that has walked the walk may be a more expedient route to go. Algorand has been putting post-quantum technology into production since 2022, when it introduced State Proofs, compact certificates of the ledger’s state signed with Falcon every 256 rounds, and it is now extending those solutions beyond its own network with chain-agnostic options built to fit the systems institutions already run.
Quantum migration is security debt accumulating today, and it compounds every quarter it goes unaddressed. Post-quantum migration is now a mandate. The teams that start while it is still a plan, rather than a crisis, will spend far less and have a much better likelihood of success.
Disclaimer: The content provided in this blog is for informational and educational purposes only. The information is provided by the Algorand Foundation and while we strive to keep it accurate and current, we make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, suitability, or availability of the blog or the information contained in it for any purpose. Nothing in this blog is legal, financial, tax, or investment advice, nor an endorsement, guarantee, or investment recommendation. Technical descriptions are provided as of the date of publication and may change. Any statements about future plans, features, integrations, protocol or consensus upgrades, fees, or timelines are forward-looking and subject to change, including subject to community adoption, and are not commitments. You should conduct your own research and consult a qualified professional before acting on any information here; any reliance you place on it is strictly at your own risk. All third-party names and trademarks are the property of their respective owners, and their mention does not imply affiliation or endorsement.