Crypto-Agility Is Becoming Architecture

For years, organizations have talked about crypto-agility as though it meant one thing:  the ability to replace one cryptographic algorithm with another.

Starknet is demonstrating a more ambitious version. Its community has now voted overwhelmingly to research whether Starknet should eventually become an independent post-quantum Layer 1. The non-binding poll closed with 93.52% of voting power in favor, giving StarkWare and the Starknet Foundation a mandate to begin formal research into the technical requirements and trade-offs.

The reason is revealing.

Starknet already controls parts of its own cryptographic architecture. Its STARK proofs are hash-based, and its account abstraction model allows user accounts to adopt different signature schemes without requiring a protocol-wide upgrade. But as an Ethereum Layer 2, Starknet still depends on Ethereum for elements such as bridging and data availability. Those dependencies inherit Ethereum’s migration timetable.

That creates a strategic question:  What happens when your own cryptography can move faster than the infrastructure you depend upon?

Starknet’s answer may eventually be architectural independence. Most enterprises will not become Layer 1 blockchains. But they will face the same problem.

The Starknet vote is the clearest signal because it shows that post-quantum readiness is beginning to influence platform architecture rather than simply security configuration. Importantly, the vote does not approve a move to Layer 1. It authorizes research. StarkWare and the Starknet Foundation now plan to examine the implications before any further governance decision.

The more interesting technical signal is account-level agility.

A recent Starknet community experiment demonstrated that existing testnet accounts could be upgraded to a hybrid ECDSA + Falcon-512 authorization model while keeping the same account address and funds. The experiment covered multiple wallet classes and showed that users could potentially change the signature mechanism without migrating the underlying assets.

That is a significant design principle.

The ideal post-quantum migration is not necessarily one that forces every user to abandon an existing identity, address, account, or asset. It is one where the underlying cryptographic control can change while the business object remains intact.

A second signal is coming from NIST.

On October 27, NIST finalized IR 8547, Transition to Post-Quantum Cryptography Standards, establishing its official transition approach for moving away from quantum-vulnerable public-key algorithms. NIST explicitly notes that migration will differ by use case, that organizations must consider their entire cryptographic supply chain, and that crypto-agility and visibility are essential to managing the transition.

NIST also makes clear that this is no longer simply standards work. The algorithms exist. The next problem is implementation.

That is exactly what today’s crypto experiments are exposing.

The lesson from Starknet is bigger than Starknet.  Crypto-agility is not an algorithm feature. It is an architectural property.  An organization can claim to be crypto-agile because one software component supports a new algorithm. That does not mean the organization can actually migrate.

What happens if the application can change but the identity provider cannot?

What if the server supports PQC but the certificate infrastructure does not?

What if the organization is ready but its cloud provider, payment processor, device fleet, embedded hardware, or critical vendor is not?

What if changing the cryptography requires changing the customer identity, account number, device, or business process underneath it?

That is where migration becomes expensive.

Starknet’s account-abstraction approach is interesting because it illustrates the opposite model:  preserve the identity, change the cryptographic control.

That should be the aspiration far beyond blockchain.

An enterprise should eventually be able to rotate a machine identity from one signature scheme to another without rebuilding the system around it. A financial institution should be able to change the cryptography protecting a payment workflow without changing the payment itself. A software vendor should be able to replace its signing mechanism without redesigning its distribution architecture. A company should be able to migrate cryptography without forcing customers to migrate the business relationship.

That is true crypto-agility.

And it creates an important distinction for QCI-QS1: Quantum readiness is not demonstrated by having a post-quantum algorithm.

It is demonstrated by having an architecture capable of changing cryptographic assumptions without losing identity, continuity, evidence, or trust.

That gives us today’s boardroom question: “If we had to replace one of our critical cryptographic mechanisms tomorrow, what else would we be forced to change with it?”

If the answer is:

• the account,
• the application,
• the vendor,
• the device,
• the customer workflow,
• or the architecture itself,
• then the organization may not yet be crypto-agile.

Starknet is beginning to ask that question at protocol scale. Enterprises should be asking it now.

Think Earlier. Trust Must Survive.