Post-quantum:
Taurus is ready.
Crypto-agile by design, built for the post-quantum migration. Taurus started preparing institutional digital asset custody for post-quantum cryptography in 2021, long before regulators asked. Key connections already run hybrid key exchange, backups are quantum-safe, and migration follows FIPS and CNSA guidelines.
What Taurus did
We started our quantum-readiness work in 2021. Not because regulators asked, but because the risk cannot be ignored, like any high-impact scenario in our business continuity planning.
Our team has advocated for the transition to post-quantum cryptography (PQC) for years and has advised private and public organizations on it. Concretely, six measures are deployed:
Crypto inventory and prioritization
In 2022 we reviewed all the places where Taurus uses cryptography and identified which ones must migrate first.
Post-quantum VPN connectivity
Our infrastructure runs post-quantum hybrid key exchange, protecting confidentiality even against "store-now, decrypt-later" attacks.
Quantum-immune backups
Our long-term backups, including databases and digital asset keys, rely only on quantum-safe cryptography.
PQC in our policies
The standards ML‑DSA, SLH‑DSA, and ML‑KEM, as well as hybrid modes and key lifecycle requirements, are already defined in our key management and cryptography policy.
Taurus‑PROTECT designed for PQ integration
The API, key-derivation logic, and signing modules can accommodate PQC signatures and PQC/hybrid KEMs the moment blockchains support them. This is called cryptographic agility, or "crypto agility."
Outreach and awareness
In 2023 we published articles on quantum risk assessment and the post-quantum technology landscape, and presented at the BlackAlps conference on proactive mitigation measures.
Why prepare now
A large enough quantum computer running Shor's algorithm could break most deployed public-key cryptography: transaction signing, TLS, SSH, key wrapping, PKI. Nobody knows when such a machine will exist, and migrations take years.
The risk is not only in the future. Harvest-now-decrypt-later attacks work today: an adversary records encrypted traffic, stores it, and decrypts it once a capable quantum computer exists. Any data that must stay confidential for years is at risk right now, so transport encryption and backups come first.
The tools exist and the deadlines are set. NIST published its first post-quantum standards in August 2024, and NIST IR 8547 deprecates ECDSA, EdDSA, and RSA after 2030 and disallows them after 2035.
Post-quantum signature readiness:
HSM vs. MPC
Tier-1 HSMs already support every post-quantum signature family within a protected hardware boundary. MPC requires a new threshold protocol for each family: very recent for ML‑DSA, and mathematically impossible for the hash-based schemes selected by Circle and Aptos and under consideration by Ethereum.
Source: Taurus white paper "Quantum Computing Risk in Digital Asset Custody: HSM vs. MPC" (June 2026).
MPC can make key compromise harder, but it does not change the signature scheme accepted by the blockchain. If the network validates ECDSA or EdDSA, the final on-chain security still depends on elliptic curve cryptography. Distributing the signing process does not change that.
No provider can claim full
post-quantum coverage today
Three constraints cap what any custody or tokenization provider can honestly promise:
01 · Blockchains Custodians cannot switch unilaterally
Bitcoin and Ethereum validate signatures under the rules of their own protocols. A post-quantum signature submitted today would simply be rejected, whatever signing infrastructure produced it. Moving on-chain signing to post-quantum schemes requires protocol changes and ecosystem consensus, expected by or before 2029.
02 · Standards Compatibility is the real bottleneck
The NIST algorithms are published, but their integration across TLS, SSH, JWT, KMS, and SDKs has not converged. Hybrid modes are standardized for transport protocols, while many toolchains and libraries are still catching up, so end-to-end compatibility, not cryptography, is the limiting factor.
03 · Third parties Hardware vendors, partners, and clients set the pace
HSM firmware, hardware tokens, and partner and client integrations each follow their own roadmaps. A custody stack migrates only as fast as its slowest dependency, which is why crypto agility matters more than any single migration date.
The realistic objective is to make every layer you control ready, keep the architecture crypto-agile, and migrate on-chain when the ecosystem gets there. This is what Taurus did.
A practical migration framework
Post-quantum migration has no fixed completion date: legacy cryptography may stay in production alongside post-quantum controls for years. These five steps are how Taurus recommends financial institutions manage the transition. Select a step to explore it.
Build the cryptographic inventory
An inventory of the places where public-key cryptography is used cannot be built from memory or vendor documentation alone. It requires reviewing live configurations, firmware versions, and integration specifications. The goal is a specific, named list of systems with an assigned owner for each.
- Blockchain transaction signing and the signature schemes in use
- HSM key types and firmware versions; MPC protocol dependencies
- TLS, SSH, IPsec, VPN configurations; internal PKI; approval tokens
- Code signing, backup encryption and key wrapping, client API authentication, third-party integrations
- For vendors: verify claimed post-quantum support on live systems, and ask for a formal roadmap where support is missing
Prioritize by risk and cost
Prioritize systems along two dimensions: the impact of quantum computing attacks (assets, breadth of impact, compliance) and how hard the system is to migrate. Use the risk model your organization already knows.
- Sort systems into three groups: upgrade now, pilot, or accept the residual risk with a defined review date
- Long-lived confidential data first: harvest-now-decrypt-later makes key agreement, encryption, and key wrapping the immediate priority
- Systems that authorize asset movement next: transaction signing, policy enforcement, approval workflows
Turn assessment into explicit decisions
Which systems need action now? Where should hybrid or non-hybrid schemes be deployed? Which vendors need roadmap commitments written into contracts? Inaction by default is not the same as consciously accepting the risk: if a system is not being migrated yet, make that an explicit, documented decision.
- Align internal deadlines with NIST's 2030 deprecation and 2035 disallowance schedule
- Select HSM features for test environments; identify MPC subprotocols needing cryptographic audit
- Build blockchain asset migration watchlists and update cryptography policies
Calibrate the message for each audience
Systems are not suddenly unsafe, but the cryptographic assumptions they rely on are changing, and the institution has a structured plan to address that. That is the message, calibrated per audience.
- Internal: board and executive updates, engineering guidance, risk and compliance documentation, procurement requirements, operational runbooks
- External: client-facing roadmap summaries, regulator and auditor responses, vendor coordination plans, ecosystem participation in blockchain protocol upgrades
Implement, review, and catch regressions
Deploy hybrid transport where available, update cryptography and key management policies, test HSM post-quantum features. As in any IT project, expect the unexpected.
- Apparent readiness does not mean you are done: as new products, commits, and vendors arrive, quantum-unsafe cryptography may sneak back in
- Maintain processes that catch quantum-unsafe regressions as early as possible
- Monitor blockchain migrations actively and HSM FIPS 140-3 post-quantum validation
Taurus-PROTECT Custody
Taurus-CAPITAL Tokenization
Taurus-PRIME Trading
Taurus-NETWORK Collateral
