Post-Quantum Ledger Security 2026.1
Cosmos released Ledger Security 2026.1, bringing the first native post-quantum secure key option to the Cosmos stack, along with other critical enterprise security features.
With recent improvements in AI models, it's never been more difficult or more important to secure blockchain applications at every layer. Hackers and their AI models are becoming more capable at finding and exploiting vulnerabilities in their attacks every day. In the longer term, AI will likely accelerate our ability to develop quantum computers that can break traditional encryption, threatening user and asset safety across all types of digital ledgers.
The release brings the first native post-quantum secure key option to the Cosmos stack and is a comprehensive upgrade to its security capabilities. With support for both user accounts and consensus signing, a chain can move to a fully quantum-resistant architecture, as defined today. This is just the beginning of our investment in post-quantum. We’ll continue to work with our enterprise users to improve the primitives and stay at the cutting edge of post-quantum cryptography as the field moves forward.
The release also adds two more validator security enhancements that enterprise operators have requested. First, it introduces native support for signing with keys in remote key management services (KMS) and hardware security modules (HSM). Second, the release adds zero-downtime validator key rotation.
These two enhancements bring FIPS 140-3 validated cryptographic modules to the validator, which is a requirement for FedRAMP-authorized and other US federal deployments. Separately, operators subject to SOC 2, HIPAA, or GDPR can point to this validation as evidence when demonstrating their encryption controls.
The 2026.1 Ledger Security release ships across four artifacts: Cosmos SDK v0.55.0, CometBFT v0.40.0, the enterprise PoA module v1.1.0, and cosmos/kms v0.1.0. These upgrades are bundled together and join the existing 2026.1 release family.
Post-quantum signatures (ML-DSA/FIPS 204)
Blockchains can now use ML-DSA signatures for consensus and user-account keys, one of the first native post-quantum secure key options in Cosmos or any open source enterprise blockchain platform. Many enterprises, especially regulated financial businesses, are facing tight timelines to become post-quantum secure in the next 5 to 10 years, as a result of AI progress and standards/regulations, e.g.:
- NIST deprecates RSA-2048 and ECC-256 in 2030 and disallows them outright in 2035
- The G7 Cyber Expert Group's January 2026 roadmap asks financial institutions to migrate their most critical systems in 2030–32
- Switzerland's FINMA already expects every supervised institution to have a board-approved post-quantum roadmap by mid-2027
As a result, banks, financial institutions, and large protocols must begin planning their migration to a post-quantum architecture now. That is now possible with Cosmos.
Post-Quantum Signatures in Ledger Security 2026.1
A ledger engineering team can set the allowed key types through consensus parameters. Existing ledgers can enable ML-DSA keys and migrate one validator or operator at a time, and new ledgers can decide whether to include ML-DSA at the outset. If a ledger allows ML-DSA as a validator key type, each validator can rotate to an ML-DSA key on their own schedule without downtime.
This means a network can become post-quantum secure without a coordinated network upgrade or even network downtime. A chain reaches post-quantum security once validators holding two-thirds of voting power have rotated to ML-DSA keys. Cosmos-based ledgers connected to the post-quantum secure network over IBC must also support ML-DSA verification to verify CometBFT light client proofs. Because of this, engineers should verify that their Cosmos counterparties are running CometBFT v0.40.0, v0.38.26, or later before upgrading.
It is important to note that there are some performance tradeoffs when migrating to post-quantum keys. For example, ML-DSA keys are larger than the standard ed25519 keys used in Cosmos. Because of this, there is added overhead both in terms of network bandwidth and block size when a chain migrates to these keys. When measuring at the scale of enterprise PoA networks, this impact is negligible.
The Cosmos Docs provide several guides on post-quantum keys and how to enable them:
Validator key rotation with no downtime
This release enables staked validators and PoA operators to rotate their consensus keys directly. Implementing cryptoperiods, i.e., using keys for fixed rather than indefinite periods of time, is strongly recommended by NIST and a common regulatory requirement. It’s also a need that arises naturally over time as a result of staffing changes and possible compromises. But before this, rotating a validator’s key meant standing up a new validator entirely. On proof-of-stake networks, this required rebuilding the delegator base. On permissioned operator networks, it required expensive coordination with the admin and/or governance.
Now a validator can rotate their consensus key directly without coordinating with delegators or network administrators. The rotation keeps the validator's identity, voting power, misbehavior, and delegations intact and doesn’t incur any downtime. On permissioned networks, admins can also rotate keys on an operator's behalf.
We provide complete guides on rotating keys for both PoS and PoA validators. To learn more about how key rotation works, visit the Cosmos Docs.
Remote signing with cosmos/kms
cosmos/kms introduces native support for remote validator signing via hardware security modules and key management services. Hardware-backed key management is a requirement under many regulatory regimes and a nearly universal best practice for key management in sensitive environments, like validator operation.
Up to this point, Cosmos has had support for hardware-backed signing through TMKMS, an open source project graciously maintained by Iqlusion and included in the bug bounty program Cosmos Labs administers. TMKMS had two major limitations that cosmos/kms addresses.
- First, it only supported three HSMs (
fortanix-dsm,yubihsm, andledger) and no major cloud-based key management services. cosmos/kms introduces support for a much larger set of backends, including all HSMs that support the industry-standard PKCS#11 interface as well as AWS KMS. The release removes support foryubihsmandledger.fortanix-dsmis supported through PKCS#11. - TMKMS only supported standard cosmos consensus keys (ed25519), which has become insufficient to support EVM-based and quantum-resistant architectures. cosmos/kms supports
ed25519,secp256k1eth, andml_dsa_65keys through HSM, AWS KMS, and local file-based backends.
To learn more about remote signing and cosmos/kms, check out the Cosmos Docs. Follow the hands-on tutorial to learn how to use cosmos/kms as a validator. If you previously used TMKMS for remote signing, follow the migration guide.
TMKMS Migration Timeline
As a result of this release, Cosmos Labs will remove TMKMS from the Cosmos Bug Bounty Program at the beginning of 2027Q1. This gives operators about three months to evaluate migrating, decide whether to do so, and perform a migration.
Upgrading to v0.55
Visit the upgrade guide to learn how to upgrade your chain to v0.55. The guide covers upgrading from Cosmos SDK v0.54 as well as v0.53. Post-quantum functionality is also available in Comet v0.38.26, released on 2026-08-13, which enables backward compatibility for IBC connections to chains using post-quantum secure consensus signing.
You can read the release notes and changelog for more information on Cosmos SDK v0.55.
About the Author
Alex Johnson is Cosmos Security Operations Lead. He has spent years working on distributed systems as both an engineer and a manager, so he understands how the technology works under the hood as well as what to build with it. What drives him is developer empathy, building tools that institutions and developers can actually pick up, use and succeed with.
