Hardware custody commits to cryptographic primitives for years through immutable bootloaders that cannot be patched. Algorithm confidence has just demonstrated it can change in sixty hours for about a hundred thousand dollars. Those two timescales do not match, and the mismatch is structural.
A Moving Target: Hardware Custody and the Post-Quantum Migration Problem
The Linkmerica Research Team August 10, 2026
Executive Summary
Two technical findings published three months apart, each unremarkable in isolation, describe together a structural mismatch in the economics of hardware custody migration. In May 2026, Project Eleven documented why deployed hardware wallets cannot easily migrate their boot verification logic to post-quantum cryptography: the bootloader layer that checks firmware authenticity is immutable on most devices in circulation, written at the factory and physically irreversible. In July 2026, Anthropic's Claude Mythos Preview discovered a previously unexploited mathematical symmetry in HAWK, a lattice-based signature scheme that had survived two years and two rounds of expert review in NIST's standardisation process, reducing its expected attack cost from approximately 2^64 operations to approximately 2^38 in about sixty hours at an API cost of roughly $100,000. HAWK was subsequently withdrawn. The attack does not affect deployed systems, remains exponential rather than polynomial, and does not impact other NIST candidates or lattice-based cryptography generally. But the timescale is the point: hardware custody requires multi-year, physically irreversible commitments to cryptographic primitives, while algorithm confidence can demonstrably change in days.
The Upgrade Problem
Hardware wallets are built on immutability as a security property. The lowest layer of a device's software stack, the bootloader, runs before anything else and verifies the digital signature on firmware updates before accepting them. On most hardware wallets currently in circulation, this bootloader layer is immutable—written during manufacturing and locked permanently. An owner cannot update it. A vendor cannot patch it. This design is intentional: it prevents an attacker who compromises a vendor's infrastructure from pushing malicious code to devices in the field.
Project Eleven, a commercial post-quantum cryptography company with a direct interest in this argument, published a technical analysis in May 2026 laying out the consequences. The verification logic in these immutable bootloaders uses classical elliptic curve digital signature algorithms, specifically ECDSA in most implementations. Under a post-quantum threat model—an attacker with access to a sufficiently powerful quantum computer—that verification becomes meaningless. The attacker could forge a valid ECDSA signature on malicious firmware, and the device would accept it as authentic. No firmware update can address this vulnerability, because the component that would verify the update is the component that needs replacing.
The constraints are not only logical but physical. Secure elements in deployed devices have roughly 50 to 64 kilobytes of RAM. ML-DSA, one of the signature schemes finalised by NIST in August 2024 under FIPS 204, requires working sets of roughly 50 to 100 kilobytes. ML-DSA signatures are 2,420 bytes; ECDSA signatures are 64 bytes. The size difference alone creates compatibility problems for devices designed around classical primitives. Memory, storage, and processing assumptions written into hardware years ago do not accommodate the new standards without material redesign.
Project Eleven also notes that the post-quantum landscape itself has not converged. NIST finalised ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) as its first post-quantum signature standards in August 2024, but blockchains are not settling on a single approach. BIP-360 names multiple candidates for Bitcoin. Ethereum uses account abstraction rather than committing to one scheme. Even within a single NIST standard there are multiple parameter sets, each with different performance and security characteristics. A device vendor choosing a single algorithm at the factory is not only betting that the algorithm survives, but that the ecosystem it serves will choose the same one.
The Moving Target
HAWK was a lattice-based digital signature scheme and, as of May 2026, the only lattice-based candidate among nine that NIST advanced to Round 3 of its Additional Digital Signatures process. It had survived approximately two years of scrutiny and two rounds of expert human review. On July 28, 2026, Anthropic published findings showing that Claude Mythos Preview had discovered a previously unexploited symmetry—a nontrivial automorphism—in the lattice structure underlying HAWK.
The attack reduced the expected cost of full key recovery against the HAWK-256 challenge parameter set from about 2^64 operations to about 2^38. The work required approximately sixty hours in a multi-agent environment at an API cost of roughly $100,000. The human operator provided project-management guidance and was not a specialist in lattice cryptography. The HAWK team subsequently withdrew the scheme from NIST consideration.
Several caveats matter and should be stated clearly. No deployed system is affected, because HAWK was a candidate, not a finalised standard, and no production implementation was using it for custody or key management. The attack remains exponential, not polynomial—larger HAWK parameter sets remain impractical to attack, meaning this is not a complete break of the mathematical structure. Anthropic states explicitly that the result is specific to HAWK and does not impact other NIST post-quantum signature candidates or lattice-based cryptography in general. ML-KEM, ML-DSA, and SLH-DSA, the finalised standards, are unaffected. Mitigation for HAWK would have required doubling key sizes, which would have removed much of its efficiency advantage over alternatives and rendered it less competitive.
This outcome is not unprecedented in post-quantum cryptography. During NIST's earlier standardisation process for ML-KEM and ML-DSA, several competing proposals were shown to be insecure. One candidate, SIKE, was broken in approximately one hour on a laptop. The process is working as designed: weaknesses are found and eliminated before deployment. But the timescale is the relevant detail. HAWK moved from Round 3 candidate to withdrawn in the time it took a capable AI system to run for sixty hours. The cost was five figures. The human expertise required was project management, not deep specialisation.
The Timescale Mismatch
Neither finding is novel on its own. Hardware wallets are difficult to update by design; this has been true since their introduction. Post-quantum cryptography is young, and new schemes are sometimes broken during review; this is why review exists. What changes when the two are considered together is the ratio of commitment duration to confidence horizon.
A hardware wallet manufacturer choosing an immutable bootloader design commits every device it ships to the cryptographic primitive written at the factory. That commitment lasts as long as the device remains in service, which in institutional custody is measured in years. The manufacturer has one opportunity to get the choice correct, and the consequences of getting it wrong are not patchable. A device that burns classical ECDSA verification into its bootloader is permanently vulnerable under a post-quantum threat model. A device that burns a single post-quantum algorithm into its bootloader is making a bet that the algorithm will survive longer than the device's service life.
The HAWK case demonstrates that the time required to move from "reviewed and advanced by NIST" to "withdrawn" can be sixty hours and $100,000. The timeline is not hypothetical. The cost is not prohibitive for a capable adversary. The human expertise barrier has lowered. This does not mean ML-DSA or SLH-DSA will fail—the caveats above are not rhetorical—but it does mean that confidence intervals around any single algorithm have widened. The reasonable expectation that a scheme will survive five years of production use now carries a different risk profile than it did before July 2026.
Hardware custody migration is slow, physically constrained, and in the bootloader layer effectively one-shot. Algorithm confidence has just demonstrated it can change in days. The mismatch is structural. A device that commits immutable boot verification to a single post-quantum algorithm is making a multi-year, physically irreversible bet on a landscape that has shown it can move faster than the replacement cycle of the hardware.
This reframes what matters in a custody device design. The question is not whether a vendor has implemented a post-quantum primitive—several have—but whether the device can adapt if that primitive is later withdrawn, deprecated, or surpassed. Crypto-agility, the ability to support algorithm changes rather than locking in a single choice, moves from a nice-to-have property to the property that absorbs the timescale risk.
What Crypto-Agility Looks Like in Practice
Linkmerica scores seven hardware wallets on Quantum Resistance Readiness, an inverted scale where higher scores indicate higher risk. Five of the seven fall into the HIGH risk band or above. The design differences are instructive.
Trezor Safe 7 scores 4.4, in the MODERATE risk band and the lowest risk of the seven. It ships production post-quantum signature verification in an immutable boardloader using a hybrid design: both classical and post-quantum signatures are required for firmware updates. The device also implements device attestation. On the firmware_upgrade_path scoring category specifically, it scores 1.5, the lowest risk in the index. The hybrid approach is the direct hedge against the problem this brief describes. If the post-quantum component is later found vulnerable, the classical signature requirement still holds, and the device remains protected under a classical threat model. If the classical component is rendered insecure by a quantum computer, the post-quantum signature requirement still holds. The device is not betting everything on one algorithm surviving.
Ledger scores 5.4, also in the MODERATE risk band. It has implemented ML-KEM and ML-DSA in its SDK, with documentation covering constant-time implementation and side-channel considerations. However, these implementations are at the SDK layer rather than in the boot trust chain. The distinction matters: application-layer cryptography can be updated via firmware, but boot verification cannot, and boot verification is the layer that determines whether a firmware update is trustworthy in the first place.
Foundation Passport Prime scores 6.3, in the HIGH risk band. It ships ML-KEM on the Bluetooth transport layer, addressing confidentiality of wireless communication, but not on signing or boot verification. Transport-layer protection is meaningful for operational security but does not address the bootloader migration problem.
BitBox02 scores 7.6, in the HIGH risk band. It has not deployed post-quantum primitives and uses BIP32 and ECDSA throughout its signing and verification chains.
Tangem scores 8.0, also in the HIGH risk band. It has not implemented post-quantum cryptography. Its card form factor presents a separate and more severe version of the migration problem: Tangem cards cannot receive firmware updates at all. Any cryptographic transition would require physically replacing every card in circulation. The burden and cost of replacement would fall on users or institutions, and there is no technical path to in-place migration.
SafePal scores 8.3 and ELLIPAL scores 8.7, both in the CRITICAL risk band. Linkmerica has not identified published post-quantum positions from either vendor.
The range is wide. The vendors at lower risk have implemented post-quantum primitives in ways that either allow future algorithm changes or hedge against single-algorithm failure. The vendors at higher risk have not, and some have form factors or architectures that make migration difficult or impossible without hardware replacement.
What Linkmerica's Framework Scores Now
Linkmerica's Quantum Resistance Readiness framework measures vendor preparedness across five categories: post-quantum algorithm support, migration roadmap, firmware upgrade path, key migration tooling, and regulatory alignment. The regulatory_alignment category rewards alignment to NIST standards, which is reasonable—ML-KEM, ML-DSA, and SLH-DSA are the result of years of expert review and remain unaffected by the HAWK finding. This brief complicates that alignment rather than invalidating it.
A vendor that has implemented ML-DSA in its bootloader receives credit for deploying a finalised NIST standard. That credit is deserved. But the HAWK case introduces a question the framework does not yet directly measure: does the implementation allow for algorithm substitution if ML-DSA, or a specific parameter set within it, is later deprecated? A single-algorithm implementation aligned to NIST FIPS 204 is better than no post-quantum implementation at all, but it is not the same risk profile as a hybrid or crypto-agile design that can survive an individual algorithm's withdrawal.
The firmware_upgrade_path category captures some of this. Trezor Safe 7's 1.5 score in that category reflects that its hybrid bootloader can be updated to change algorithms without requiring hardware replacement. Tangem's card form factor, by contrast, has no firmware upgrade path and no technical mitigation available short of replacing the cards. The category is doing its job. But the HAWK finding suggests the weight of this category relative to others may need revisiting. The ability to change algorithms is not a secondary consideration; it is the property that absorbs the risk that algorithm confidence can move faster than hardware replacement cycles.
Five of seven scored wallets are in the HIGH or CRITICAL risk bands. That concentration is not an artifact of the framework; it reflects that most vendors have not yet deployed post-quantum cryptography in their boot trust chains, and several have architectures that make doing so difficult. The two in the MODERATE band, Trezor Safe 7 and Ledger, are there because they have shipped implementations, though at different layers. The gap between MODERATE and HIGH is wide, and the gap between hybrid and single-algorithm designs may be wider than current scoring reflects.
What Institutions Should Ask
The findings discussed in this brief do not require institutions to replace hardware immediately, but they do surface questions that were less urgent six months ago. Asking them now, while devices are being selected or refreshed, is cheaper than asking them later when a chosen algorithm is deprecated and hardware is already deployed.
Is the bootloader updatable? If the answer is no, the device is locked to the cryptographic primitives written at the factory. Under a post-quantum threat model, that means the device's useful life is bounded by the survival of those primitives, and no firmware update can extend it.
Is the boot verification design hybrid or single-algorithm? A hybrid design, requiring both classical and post-quantum signatures, hedges against individual algorithm failure. A single-algorithm design bets that the chosen scheme will outlast the device's service life. The HAWK case demonstrates that bet carries more risk than it did in May 2026.
What happens if the chosen post-quantum algorithm is withdrawn or deprecated? Does the vendor have a documented migration path? Is that path firmware-based, or does it require hardware replacement? If replacement is required, who bears the cost—vendor, institution, or end user—and on what timeline?
Is there a hardware replacement path, and who pays? For devices with immutable bootloaders or no firmware update capability, algorithm deprecation forces physical replacement. Clarifying vendor policy on replacement cycles, warranty coverage, and cost allocation before deployment is simpler than negotiating it under time pressure after a cryptographic event.
How does the vendor track NIST's ongoing standardisation work? ML-DSA and SLH-DSA are finalised, but NIST's Additional Digital Signatures process continues, and parameter sets within finalised standards may be deprecated independently of the standards themselves. A vendor that monitors this process and has engineering capacity to respond is better positioned than one that treats FIPS 204 as static.
What does the vendor's transparency and incident response record show? Post-quantum migration will not be the last cryptographic transition these devices face. How a vendor has handled past vulnerabilities, disclosed issues, and communicated with institutional customers is evidence of how it will handle future ones.
These questions do not have universal answers. A card-form-factor device with no upgrade path may be acceptable in a use case with planned short service life and low quantum threat exposure. A multi-year custody arrangement holding material value under a rising quantum threat model has different requirements. The point is not that one design is always wrong, but that the choice should be made explicitly, with the timescale mismatch and its consequences clearly understood.
The safe answer, where architecture permits, is hybrid cryptography and crypto-agility. The risk is not only that a post-quantum algorithm fails, but that the failure happens faster than the hardware replacement cycle, and the institution is left holding devices it cannot trust and cannot patch. Sixty hours and $100,000 is not a remote threat. It is the demonstrated timeline for moving a NIST Round 3 candidate from reviewed to withdrawn. Hardware custody commitments last longer than that, and they should be designed accordingly.
Disclosure
One of the two findings discussed in this brief was published by Anthropic. Linkmerica's research and scoring pipeline uses Anthropic's API as tooling. Anthropic is not a rated entity, has no involvement in Linkmerica's methodology, scoring, or conclusions, and had no advance sight of this brief. Project Eleven, whose analysis forms the first half of this brief, is a commercial post-quantum cryptography company with a direct interest in the argument that existing hardware cannot migrate. Readers should weigh both sources accordingly. Linkmerica accepts no payment from any rated entity, from its tooling vendors, or from any party discussed here.
Linkmerica is a trade name of CASPO LLC. LISR scores and research are for informational purposes only and do not constitute financial or investment advice. This brief is based on publicly available information as of August 10, 2026.