Bitkey Has No Seed Phrase. Where Does the Trust Go?

A conventional hardware wallet gives its owner one secret: a 12- or 24-word recovery phrase capable of rebuilding the wallet on any compatible device. Anyone who obtains the recovery phrase can control the Bitcoin, meaning an owner who loses the seed phrase may permanently lose access.

Block’s Bitkey removes the recovery phrase from the customer experience. Private keys still exist, but recovery is distributed across three keys, an encrypted cloud backup, Block’s co-signing service, notification channels and software-enforced recovery rules. This article explores where that trust and risk go once the seed phrase disappears, using Ledger's certification-backed model as the contrast throughout.

Before Bitkey: How Does the Ledger Hardware Wallet Protect and Generate a Seed Phrase?

Ledger concentrates private-key generation and transaction signing inside a dedicated smartcard-grade Secure Element. 

The Ledger Nano X security target, prepared for its French CSPN evaluation, identifies that Secure Element as the ST33J2M0. The component was separately evaluated under Common Criteria, with its certification maintained in an official report issued by ANSSI, France’s national cybersecurity authority. Together, the records provide evidence for both the security properties of the underlying component and the integration into the Nano X, although the component certificate alone does not certify the complete wallet.

Ledger OS, the internal Donjon security team and external review form further security layers around the Secure Element. Ledger said the Donjon was staffed by eight security and smartcard specialists when it introduced the laboratory in 2018. The dedicated team attempts to break Ledger’s hardware and software using techniques including code review, fault injection and side-channel analysis, while also testing components produced by Ledger’s suppliers and other wallet manufacturers.

Ledger states that its Secure OS and Ledger-developed device applications are 95% open source and available for review. The remaining portion includes Secure Element-adjacent code that Ledger says it cannot publish under agreements with its chip supplier. The 95% figure therefore applies to Ledger’s OS and applications, not necessarily to every component within the complete device.

The holder of a Ledger device must protect a seed phrase capable of reconstructing the entire wallet. Coinjuice traced how such a seed is generated, and what happens when the generation path fails, in an earlier investigation into weak seed generation.

How Bitkey Changes the Bitcoin Security and Custody Model

Bitkey replaces that single seed backup with several recovery pieces spread across a phone, the Bitkey device, an encrypted cloud backup and Block’s server.

Bitkey is a 2-of-3 multisignature wallet. Multisignature, or “multisig,” means the Bitcoin network accepts a transaction only when it carries signatures from the required number of keys controlling the wallet. Bitkey requires two of its three keys, and the Bitkey recovery architecture sets out where each key lives:

• Phone key: Created during setup and stored in the Bitkey mobile app. An encrypted backup copy is also placed in the customer’s personal iCloud or Google Drive account for phone-loss recovery. Block calls this the App Key.

• Hardware key: Created and stored inside the physical Bitkey device. Block says the key is generated and kept completely offline. The holder unlocks its use with a fingerprint and taps the device against the phone to communicate over NFC. NFC stands for Near-Field Communication, a short-range wireless technology that lets two devices exchange data when held within a few centimeters of each other, without pairing or an internet connection.

• Server key: Created and managed by Block on its own infrastructure. Block does not receive a copy of either the phone key or the hardware key.

How Bitkey’s Three Spending Paths Work

An example: A holder sends 0.4 BTC. The Bitkey app signs with the phone key, the holder unlocks the device with a fingerprint and taps it against the phone, and the device adds the second signature. Two of three signatures now exist, the network accepts the payment, and Block was never involved. 

Three routes exist in normal operation:

• Phone plus hardware: The standard spending path, fully independent of Block.

• Phone plus Block: With the optional Transfer without hardware setting, the holder picks a daily limit in advance. Small payments under the limit clear with the phone alone, because Block's server adds the second signature. Larger ones wait for the Bitkey device, so a coffee needs no hardware and a house deposit does.

• Phone plus Block during recovery: If the hardware device is lost, the holder can combine the phone’s App Key with Block’s server key to set up a replacement device and regain access to the Bitcoin.

What Block Can and Cannot Do

Block cannot move the Bitcoin by itself because it controls only one of the three keys. Blocks role is important, however, because spending without the hardware device and recovering from device loss depend on Block’s server, Bitkey allows independent everyday spending without providing complete independence across every feature. 

This structure resembles collaborative custody, one of the five arrangements examined in the Coinjuice guide to Bitcoin self-custody security layers.

What Replaces the Seed Phrase?

Bitkey does not remove secret key material. Bitkey removes the requirement for the holder to write down one master recovery phrase. For phone recovery, the replacement works like a locked box: the customer’s cloud account holds the box, while the Bitkey hardware helps unlock the device.

The Bitkey Recovery Features paper describes the process:

• The app creates an encrypted backup: During setup, the mobile app places an encrypted copy of the phone key in the customer’s personal iCloud or Google Drive account. Bitkey does not complete onboarding if this backup fails.

• The app creates the backup-encryption key: A 128-bit Cloud Storage Encryption Key, or CSEK, encrypts the mobile-key backup.

• The hardware protects that encryption key: The app sends the CSEK to the Bitkey device over NFC. The hardware wraps it using a separate Hardware Data Encryption Key, or HWDEK, that Block says never leaves the device.

• The cloud stores encrypted material: The encrypted phone-key backup and wrapped CSEK are uploaded to the customer’s cloud account. Access to those files alone should therefore be insufficient to recover the wallet.

Restoration reverses the process: After installing Bitkey on a replacement phone and signing in to the same cloud account, the holder taps the hardware device against the phone. The hardware unwraps the CSEK, allowing the app to decrypt and restore the phone key.

Different losses produce different recovery paths:

• Phone lost, cloud backup available: Install the app on a replacement phone, sign in to the same cloud account and use the hardware device to restore the App Key.

• Hardware device lost: Use the phone key with Block’s server-assisted Delay and Notify process to establish a replacement hardware keyset.

• Phone and cloud backup unavailable: Begin Delay and Notify from the surviving hardware device on a new phone.

• Phone and hardware both lost: The normal recovery routes no longer work. Recovery requires the optional Recovery Contacts feature to have been configured beforehand, together with access to the required cloud material.

• Block’s service unavailable: Phone-plus-hardware spending remains possible. The Emergency Exit Kit provides a separate route for using those two surviving customer keys without Block’s server.

• Block ceases to exist entirely: The exact scenario the Emergency Exit Kit was built for. Two of the three keys are already in the holder's hands, so the Bitcoin can still be moved with no help from Block at all, using a separate app installed by hand rather than from an app store. The catch is not the maths, it is the paperwork: the kit sits in cloud storage and the app sits on GitHub, so anyone planning for the company disappearing keeps their own copy of both, saved offline. Block's own documentation carries the current procedure.

Takeaway: The contrast with a written recovery phrase is clear. A seed phrase is portable across compatible wallets but gives complete control to anyone who reads it. The Emergency Exit Kit reveals no immediately spendable secret, but it cannot help an owner who has also lost the hardware device required to use it.

How Does Bitkey Generate Its Randomness?

Entropy is the unpredictable randomness used to create secret keys that attackers cannot guess.

• Three separate starting points: The phone creates one Bitkey key, the hardware creates another and Block creates the third on its server. No single device generates the two keys normally required to move the Bitcoin.

• What remains unclear: Bitkey’s public documentation does not explain exactly how each of those three places produces its randomness or provide independent test results covering all three processes.

• What the hardware can do: Bitkey uses a Silicon Labs processor containing a hardware random-number generator. However, Coinjuice did not find Bitkey-specific documentation confirming that its software uses this feature to create the Hardware Key.

What this means: The missing detail is not evidence that Bitkey’s randomness is weak. It means the separation between the three keys is publicly documented more clearly than the process used to generate each one.

How Ledger Differs

• Ledger relies on one protected generator: Ledger creates its 256-bit wallet seed inside an STMicroelectronics Secure Element using its hardware random-number generator. The Nano X security target identifies this generator as a security function of the ST33J2M0 chip and records its successful evaluation under the AIS 31 methodology.

• Bitkey spreads the risk: Instead of relying on one seed and one generator, Bitkey creates three keys in separate places. This reduces the danger of one faulty generator compromising the complete wallet, although less public evidence is available about how each Bitkey key is generated.

Inside the Bitkey Hardware

Block has been unusually open about the hardware. Its processor-selection post names the part and explains the reasoning:

• The chip: A Silicon Labs EFR32MG24, a general-purpose wireless system-on-chip on an ARM Cortex-M33 core, sold mainly into smart-home and building-automation products, carrying a security subsystem named Secure Vault alongside the main processor.

• Transparency drove the choice: Block wrote a Secure Element would have met its security criteria but would also have blocked publication of certain firmware layers, because Secure Element vendors impose non-disclosure agreements rooted in government smartcard compliance.

• Secure boot and signed firmware: Block states secure boot means a chip checks a cryptographic signature on its own software before running it, so modified firmware fails to start. Block states the device runs only firmware signed for Bitkey and cannot be debugged or reflashed even by the Bitkey team.

• Device certificates: Each chip receives a unique secret before manufacturing, which Block says lets the app detect counterfeit or modified hardware.

• A physical unclonable function protects stored keys: Block states a PUF derives a secret from microscopic manufacturing variations unique to each chip, so the key exists only while the device is powered, meaning a powered-off Bitkey holds nothing directly extractable.

• Compromising the device is not enough: Two signatures being required, an attacker defeating the hardware entirely still holds one key of three.

What Certification Exists?

Four separate propositions get compressed into one claim:

• The chip family markets security properties: The EFR32MG24 datasheet advertises Secure Vault, a true random number generator, secure boot with a root of trust, power-analysis countermeasures and, in the High tier, PUF-based key management. A datasheet is a manufacturer claim about a component family.

• Certified Secure Vault records name other variants: The PSA Certified entry for Secure Vault lists Level 3 certifications held by Silicon Labs, tested by Riscure, covering hardware versions EFR32MG21B and EFR32FG23B SE. Neither is an EFR32MG24.

• One end product using the EFR32MG24 carries its own Level 1 certificate: A Tuya TS24-U device certificateissued in September 2023 names EFR32MG24 as its hardware version, at PSA Certified Level 1, with FreeRTOS as the evaluated software.

• None of the above is a Bitkey certification: No public ANSSI, Common Criteria, FIPS 140 or Bitkey-specific PSA certification was located in the reviewed databases.

None of this amounts to certification for Bitkey; the section above traces what certification exists in the surrounding ecosystem precisely to show it stops short of the product itself. This matters because just because the individual sees 'Secure Vault,' 'PSA Certified,' and 'EAL' clustered in the same paragraph the reader could easily assume Bitkey inherited one of these certificates by association, when in fact none of them names Bitkey, Block, or even the exact chip variant Bitkey ships. 

Whilst Ledger's certification trail does not have that gap: the ANSSI security target and Common Criteria report name the exact chip inside the exact device, with no substitution required to make the claim hold.

Open Source, but Not Fully Reproducible

Block publishes an unusual amount of code. Bitkey’s repository contains hardware firmware, the iOS and Android applications, server code including the module managing the third key, and electrical design material. 

The licence is MIT with a Commons Clause modifier restricting commercial reuse, so "source available with a licensing restriction" is the accurate label rather than fully open source. The reproducibility boundary is where precision earns its keep, and the two halves of the product sit on opposite sides of it:

• The mobile app can be checked against the shipped binary: Block publishes a verifiable build process for the Android application, so a competent outsider can rebuild it and compare the result against the Play Store version.

• The firmware cannot: The firmware directory README states external parties cannot build Bitkey firmware, because Block uses "a 3rd party fingerprint sensor that comes with a proprietary matching algorithm" and is contractually barred from releasing the library implementing it. Tests, fuzzers, and a build using replacement stubs remain possible.

What WalletScrutiny Found

The review project WalletScrutiny has assessed both hardware generations, reaching different conclusions for different reasons. Merging them would misstate both.

• The 2024 review, screenless device: Verdict recorded as bad interface. Without a screen, transaction details appeared only on the phone, so the holder approved what the app displayed rather than what the device confirmed.

• The 2026 touchscreen device: WalletScrutiny's 2026 review records a verdict of nosource. Address verification on the device screen now works, resolving the earlier objection, and the review stops instead at the firmware build.

• The stated reason: Verification halted because the proprietary fingerprint library prevented a complete build, leaving reviewers unable to confirm the shipped firmware matches the published source.

• A disclosure travelling with the finding: WalletScrutiny states on both pages the project is sponsored by Spiral, a Block subsidiary, making it an external technical assessment carrying a declared relationship to the vendor, not an arm's-length certification or an independent audit.

Bitkey Missing Audit Layer

Stating the position carefully is the whole job. No complete, publicly accessible third-party security audit report for the Bitkey product was located among the materials reviewed for the article. Absence of a public report is not evidence no assessment happened, and Block may have commissioned private testing never published.

Four categories of evidence get treated as interchangeable and are not:

• Architecture documentation: Explains how a company says its system works.

• Published source code: Permits partial external inspection, bounded here by the firmware build restriction.

• Certification: Evaluates a defined target against a published standard, by a named laboratory, at a stated date.

• A published audit: Names the firm, the scope, the methodology, the date, the limitations and the findings, including the ones a vendor would rather not print.

Bitkey supplies a great deal of the first two and, in the reviewed public record, none of the last two. 

The contrast with the Ledger component is not that one company is honest and the other is not. Certification-grade evidence exists for one and was not located for the other. Block's published security reporting policy commits to a response within seven calendar days and asks researchers to observe a ninety-day coordinated disclosure window.

The Reported August 2026 Recovery Issue

One incident belongs in the record, carefully bounded. According to CryptoBriefing, a secondary publication, a researcher flagged a flaw in the enrollment flow for Bitkey's recovery and inheritance contact features on 1 August 2026. The report states Block confirmed and patched the issue the same day and submitted the fix to both app stores. Block's engineering lead is reported as saying exploitation would have required exceptional conditions, and Block characterised the event as placing no funds at risk.

The reviewed materials do not establish the precise affected component, a complete technical description, exploitability, severity, a CVE identifier, or independent confirmation of the no-funds-at-risk characterisation. 

Ledger and Bitkey: Where Trust Resides

Who Is Bitkey For?

The answer depends on which failure a holder considers more likely in their own life, not on which company markets better.

Bitkey suits someone who:

• Fears the phrase more than the attacker: Rating a lost or exposed seed phrase as likelier than a coordinated attack across a phone, a device and a cloud account.

• Wants recovery to be survivable: Preferring a design where one lost object does not end in permanent loss.

• Accepts a company in the loop: Comfortable relying on Block's infrastructure for convenience and assisted recovery.

• Understands the new dependencies: Recognising an Apple or Google account and an email address are now part of the security setup.

• Values the independent route: Taking reassurance from the phone-plus-hardware path working without Block.

A conventional seed-based wallet suits someone who:

• Wants a portable, standardised secret: A phrase restores into many wallets from many manufacturers.

• Can secure it properly: Holding the discipline and physical arrangements to store a backup correctly for decades.

• Prefers minimal vendor dependence: Unwilling to let a company's survival form part of a recovery plan.

• Values interoperability: Wanting freedom to move between software and hardware without a migration project.

• Accepts concentrated consequences: Understanding the full weight of seed loss or theft, and taking it on knowingly.

Risks Grounded in This Session's Research

Bitkey trades a single seed phrase for a more distributed system, and that trade-off comes with its own set of open questions here's where the evidence gaps and dependencies sit:

• No independent certification: No outside lab has certified Bitkey's hardware the way Ledger's chip has been certified.

• No public audit: No public independent security audit exists for Bitkey just company docs and open code.

• Firmware not fully verifiable: You can't fully rebuild the firmware yourself to check it matches what Block published, because of one locked-up fingerprint component.

• Randomness unconfirmed: Nobody outside Block has confirmed exactly how random each key really is when it's created.

• Server dependency: Two features, small phone-only payments and hardware-loss recovery, need Block's server to work, so they'd be affected if Block had problems.

• Hardware loss is disruptive: Losing the hardware device isn't a simple swap, it rebuilds your whole wallet with new keys and takes 7 days.

• Worst-case recovery needs setup: If you lose both your phone and your hardware, you're stuck unless you already set up a backup contact ahead of time.

• One confirmed bug: One real bug was found and fixed in August 2026, but the public details on it are thin.

• Reviewer isn't fully independent: The main outside reviewer of Bitkey is partly funded by Block itself, so it's not fully independent. Ledger has the same situation with Donjon.

• Older hardware lacked a screen: Older Bitkey devices had no screen, so you had to trust the phone app to show you the truth, this is fixed in the newer model.

Conclusion

Bitkey does not remove trust or recovery risk, Bitkey redistributes them across three separately generated keys, an encrypted cloud backup, and Block's server. Neither wallet is universally safer, and a reader finishing this article with a ranking has read it wrong. Newer holders will find the groundwork in the Coinjuice beginner's guide to self-custody.

Ledger concentrates the same categories of risk into one seed and one chip, then backs that chip with an ANSSI security target and a Common Criteria report naming the exact hardware inside the exact device. 

Bitkey backs its design with detailed documentation and open firmware, but no equivalent certification or published third-party audit was located for the product itself. Openness about how a system is built and independent proof that it works as described are not the same thing, and this article has tried to keep that line visible rather than let one stand in for the other. Knowing where the risk sits now, and which claims come from Block versus an outside checker, is the new version of memorizing a seed phrase. If you choose Bitkey, this is how you protect yourself instead.

Readers looking to trade range-bound conditions like this can start with the Coinjuice ebook, Bitcoin Trading Without Leverage, or go deeper with a Coinjuice yearly subscription — currently 30% off — where we start and complete live trades so you can learn to snipe them independently. First 100 yearly subscribers get the ebook free.